Ant Financial работает уже много лет, ежегодно поддерживая пиковую стоимость Double Eleven. Как новое направление микросервисов, Service Mesh стал горячей точкой в этой области за последние два года, но как эволюционировать от классической сервис-ориентированной архитектуры к направлению Service Mesh, с какими проблемами можно столкнуться на полпути, справочного опыта почти нет.
В этой статье вы узнаете об эволюции Service Mesh в Ant Financial и популярном взаимодействии QA между старшими техническими экспертами Ant Financial и полевым персоналом по поводу Service Mesh на конференции GIAC Global Internet Architecture Conference, состоявшейся в июне 2018 года.
предисловие
В последнее время Ant Financial начала использовать Service Mesh для решения некоторых архитектурных проблем и имеет некоторый опыт в том, как лучше сочетать Service Mesh с классической сервис-ориентированной архитектурой, и я надеюсь поделиться им с вами. наша практика в этой части. Пусть каждый лучше поймет текущую сервис-ориентированную архитектуру Ant Financial и лучше поймет, как Service Mesh решает проблемы классической сервис-ориентированной архитектуры, а также некоторые соображения по проектированию и будущие перспективы Ant Financial, когда на самом деле он реализован в Service Mesh.Для дальнейшего понимания я также надеюсь поделиться текущим состоянием сервис-ориентированной архитектуры Ant Financial с отраслью.
Прошло почти 10 лет с тех пор, как Ant Financial перешла от одного приложения к сервис-ориентированной архитектуре.В течение всего процесса, чтобы удовлетворить финансовые требования Ant Financial, мы также построили набор распределенных финансовых уровней. -ориентированные Архитектурные решения, то есть SOFA.
SOFA фактически включает распределенное промежуточное ПО финансового уровня, платформы CICD и PAAS.. Часть промежуточного программного обеспечения для дивана включает в себя Framework Solfaboot R & D Frameworks, Frameworks, связанные с Micreading Soffa (RPC, реестр услуг, каркас обработки пакетной обработки, динамическая конфигурация и т. Д.), Сообщение промежуточное программное обеспечение, распределенные транзакции и распределенный доступ к данным и т. Д.
Эти промежуточные программы основаны на стеках технологий Java.Sofa в настоящее время составляет более 90% систем внутри ant pricard, в дополнение к этим системам есть система 10%, использующая nodejs, c++, Python и т. д. исследования и разработки . Эти оставшиеся 10% системы хотят интегрировать во всю систему SOFA, одним из способов написать клиент, соответствующий каждой части промежуточного программного обеспечения SOFA, с соответствующим языком.
На самом деле, мы делали это раньше.У Ant Financial был набор клиентов для компонентов SOFA, созданных с помощью NodeJS.Однако с развитием ИИ и других областей в последние годы C++ также присутствует в Ant Financial.Он применяется во все большем количестве приложений. места, так должны ли мы снова использовать C++ для написания каждого клиента промежуточного программного обеспечения SOFA? Если мы продолжим использовать этот метод для поддержки системы C++, мы сначала столкнемся с проблемами стоимости.Каждый язык имеет набор клиентов промежуточного программного обеспечения, и эти клиенты промежуточного программного обеспечения подобны дымоходам, и все они должны идти независимо друг от друга.Техническое обслуживание, обновление. С другой стороны, с точки зрения стабильности, некоторые из ям, на которые раньше наступали Java-клиенты, возможно, придется снова наступать другим языкам.
Для многоязычной проблемы Service Mesh на самом деле очень хорошо решает эту часть проблемы.Благодаря решению Service Mesh мы можем попытаться переместить большинство функций с клиентской стороны промежуточного программного обеспечения на Sidecar, чтобы мы могли после реализации , все языки будут решены.Для команды инфраструктуры это улучшение стоимости и стабильности.
Другая проблема на самом деле является проблемой, с которой столкнутся все компании, переходящие на облачную архитектуру.Облачная архитектура выглядит очень хорошо, но как мы постепенно переходим к облачной архитектуре? Особенно для устаревших систем, как лучше всего это сделать. Конечно, простым и грубым способом является непосредственное переписывание набора облачных средств и архитектур, но в этом случае инвестиционные затраты очень высоки, а переписывание означает, что могут быть внесены ошибки, приводящие к проблемам со стабильностью в сети. Так есть ли способ для этих устаревших систем легко воспользоваться преимуществами облачных технологий? Service Mesh на самом деле указывает нам направление,Через Service Mesh мы устанавливаем sidecar для устаревшей системы.Путем небольшого изменения конфигурации устаревшей системы или даже без изменения конфигурации устаревшей системы устаревшая система может пользоваться возможностями обнаружения служб, текущего ограничения и сплавление и инжекция неисправности.
Наконец, проблема, с которой мы столкнулись в сервисно-ориентированном процессе Ant Financial, — это проблема обновления промежуточного программного обеспечения. эластичной архитектуры.На самом деле она сопровождается большим количеством обновлений промежуточного ПО.Для каждого обновления не обязательно говорить, что будет выпущена новая версия промежуточного ПО для предоставления новых возможностей.Бизнес-система также нуждается в обновлении зависимое промежуточное ПО. Если есть ошибка в середине, его нужно обновить снова. Страдают не только студенты, занимающиеся исследованиями и разработками промежуточного программного обеспечения, но и студенты, занимающиеся исследованиями и разработками приложений, также очень болезненны.
Мы перешли от одного приложения к сервисно-ориентированной архитектуре.От изначально нескольких команд, поддерживающих одно и то же приложение, к каждой команде, поддерживающей приложения в своих областях, команды общаются через интерфейсы, что максимизирует отношения между каждой бизнес-группой. Определенная степень разъединения, но для группы инфраструктуры она по-прежнему связана с каждой бизнес-группой.
Мы испробовали различные методы решения проблемы сопряжения в процессе обновления.Один из них заключается в управлении всеми библиотеками базовых классов через наш собственный сервер приложений CloudEngine, чтобы свести к минимуму стоимость обновления для пользователей без необходимости предоставления пользователям возможности обновления зависимостей. один за другим, и можно сделать только одно обновление.
Однако с непрерывным развитием бизнеса Ant и непрерывным расширением масштабов количество команд, масштаб бизнеса и эффективность нашей доставки стали основными противоречиями, поэтому мы рассчитываем развивать инфраструктуру с более высокой эффективностью, а не Итерация инфраструктуры ограничена этим масштабом.
Позже OceanBase, база данных, разработанная самим Ant, также использовала прокси-метод для экранирования кластерной нагрузки самой OceanBase, логику переключения FailOver и т. д., и Sidecar-режим Service Mesh также является такой идеей, давайте посмотрим Это общая тенденция и направление отрасли для переноса возможностей инфраструктуры из приложений в Sidecar. Таким образом, инфраструктура приложений и промежуточного программного обеспечения стала двумя процессами. Мы можем ориентироваться на промежуточное программное обеспечение. Инфраструктура обновляется независимо, а не привязана к выпуск и обновление приложения, что не только разгружает команды, занимающиеся исследованиями и разработками приложений и инфраструктурой, но и усиливает возможности группы по доставке инфраструктуры. Требуются годы или даже больше, чтобы применить новые возможности, предоставляемые группой инфраструктуры, ко всем бизнес-системам. мы можем сделать новые возможности доступными для всех бизнес-систем в течение одного месяца. Это также усиливает промежуточные возможности команды инфраструктуры. Таким образом, мы можем понизить некоторые из очень ключевых точек поддержки и некоторую логику в архитектуре, чтобы Перейдите к Sidecar, потому что общая архитектура Ant Financial имеет много логики и возможностей, реализованных в этом наборе архитектуры. Одна из наших самых больших обязанностей в отношении этих вещей — поддерживать их быстрое развитие и гибкость.
Выбор сервисной сетки
Мы говорили о проблемах, возникающих в рамках текущей сервис-ориентированной архитектуры Ant Financial, и о некоторых проблемах, которые мы надеемся решить с помощью Service Mesh. Далее мы сталкиваемся с очень реальной проблемой. Как нам выбрать структуру Service Mesh. Какой стандарт следует использовать для измерения, то я поделюсь с вами некоторыми мыслями о выборе Ant Financial в рамках Service Mesh.
Во-первых, эволюция всех архитектур не достигается в одночасье, а является процессом постепенной эволюции, и чем крупнее компания, тем больше ей нужно учитывать этот момент в процессе эволюции архитектуры. Поэтому нам необходимо учитывать это при выборе моделей и учитывать, может ли целевая платформа быть хорошо интегрирована с текущей архитектурой. Еще один момент, как компания, имеющая дело с деньгами, мы должны обратить особое внимание на то, была ли целевая структура проверена в больших масштабах в производственной среде, и была ли она проверена в различных сценариях.
В настоящее время в отрасли существует три основных фреймворка, связанных с Service Mesh, а именно Istio, в котором участвуют Google, IBM и Lyft, и Linkerd и Conduit, два фреймворка Service Mesh с открытым исходным кодом, разработанные Bouyant.
Прежде всего, давайте взглянем на Istio, поскольку в настоящее время Istio должен быть наиболее востребованным фреймворком ServiceMesh, и он благословлен ореолом ведущих компаний, таких как Google, IBM и т. д. Он также полностью включает в себя Data Plane и Control Plane. , но Istio То, что долгое время подвергалось сомнению, на самом деле является частью Mixer его плоскости управления. Mixer Istio выполняет аутентификацию службы, управление квотами, трассировку, метрики и другие возможности. Это центральный узел. Если кеш не включен, все вызовы должны начинаться с Я был в Mixer.Даже если кеш включен,неизбежно,что некоторые запросы должны идти в Mixer.В Quan Ant более 20000 сервисов,и звонки между сервисами очень частые.После Mixer,Mixer стали единой точкой, а эксплуатация, техническое обслуживание и высокая доступность этой единой точки стали проблемой.
Кроме того, нас всегда беспокоила производительность Istio.Несмотря на выпуск каждой версии Istio, производительность в определенной степени улучшалась. Но давайте взглянем на данные о производительности Istio: 700 TPS в 0.5.1, 1000 TPS в 0.6.0 и 1700 TPS в 0.7.1. все TPS на уровне 10 000. Эти данные о производительности Istio действительно немного мрачны и не могут соответствовать требованиям производительности Ant.
Теперь давайте взглянем на Linkerd. Linkerd является наиболее зрелым из нескольких фреймворков сервисных сеток в отрасли, но у него также есть проблема. Прежде всего, он родился из Finagle от Twitter. Архитектура на самом деле недостаточно открыта, чтобы Кроме того, в Linkerd нет слоя Control Plane, только Sidecar, а правило маршрутизации Linkerd DTab на самом деле довольно сложно понять. Наконец, это был один из вопросов, который нас больше всего волновал при выборе моделей в то время: Linkerd написан на Scala и работает на JVM. Отрывок из блога Linkerd о том, как оптимизировать использование памяти JVM.У такого рода статей обычно есть эта проблема, поэтому я напишу такую статью.Из этой картинки видно, что памяти, требуемой Linkerd, нужно как минимум 100M, именно поэтому Bouyant официально не рекомендует развертывание Linkerd и приложений один на один, а использует для развертывания DaemonSet. Один из методов развертывания, который мы ожидаем, - это развертывание один на один с приложениями. Такое использование памяти слишком дорого для нас. Мы ожидаем контролировать использование памяти Sidecar примерно до 10 МБ.
Наконец, давайте взглянем на Conduit. Во-первых, Conduit также представляет собой фреймворк Service Mesh, недавно запущенный Linkerd. Он не очень зрелый. Во-вторых, Conduit выбрал язык Rust. Давайте посмотрим на рейтинг Rust на Tiebo Java имеет долгую историю Первое место в рейтинге, C++ — третье, Golang достиг 14-го места после бурного развития облачной инфраструктуры в последние годы, а Rust, который не сильно отличается от других языков по степени использования, занимает второе место. 50. .
Поэтому мы, наконец, выбрали Service Mesh собственной разработки.С одной стороны, мы, конечно же, основываемся на двух предыдущих критериях для измерения текущего популярного в отрасли фреймворка Service Mesh, и ни один из них не может полностью удовлетворить наши требования. долгосрочное и глубокое накопление, некоторый опыт в этой части также может помочь нам лучше разработать собственную структуру сервисной сетки.
Конечно, мы не имеем в виду, чтобы начать сервисные рамки сетки полностью с нуля. Мы надеемся, что мы надеемся поглотить отличные идеи в рамках сервисной сети отрасли. С другой стороны, мы также надеемся максимально следить за обслуживанием. Некоторые нормы в обществе.
Дизайн дивана сетки
Прежде всего, SOFA Mesh на самом деле напрямую использует Pilot и Auth Control Plane Istio, потому что мы считаем, что Istio не имеет серьезных проблем в этой области и даже имеет несколько очень хороших дизайнов, таких как Universal Data API в пилотной части. дизайн. Часть Istio Auth также в полной мере использует механизмы безопасности Kubernetes.
Что касается микшера, то я уже упоминал ранее, что мы чувствовали, что существует проблема дизайна, поэтому наша идея состояла в том, чтобы напрямую перенести микшер на коляску.
Кроме того, все знают, что Sidecar Istio — это Envoy, написанный на C++, так как же мы переместим Mixer в Sidecar?На самом деле, Sidecar нашей SOFA Mesh написан на Golang, поэтому мы даем возможность перемещения Mixer в Sidecar. Конечно, мы решили использовать Golang для разработки Sidecar не только для того, чтобы перевести Mixer в Sidecar, но и по другим причинам. Написанный на Golang, включая Docker, Kubernetes и т. д., выбор Golang на самом деле надеется лучше соответствовать этим инфраструктурам в эпоху облачных вычислений.
Кроме того, по сравнению с C++, используемым Envoy, с Golang, очевидно, проще начать работу и легче найти таланты в этой области. Кроме того, по сравнению с JVM, Golang имеет гораздо меньший объем памяти. Sidecar, текущий Использование памяти при пиковом TPS составляет 11 МБ, хотя есть еще некоторый потенциал для оптимизации, он был уменьшен в 10 раз по сравнению с JVM.
Кроме того, несмотря на то, что мы используем Istio Pilot, при его внутреннем использовании использование Pilot напрямую не отвечает нашим требованиям. Во-первых, Pilot напрямую связан с механизмом обнаружения сервисов Kubernetes на Kubernetes.Будь то SOFARPC или Weibo Motan и другие отечественные сервисные фреймворки, по сути, все они являются моделями одного приложения нескольких сервисов и сервисов Kubernetes. Механизм обнаружения на самом деле нацелен на модель одного приложения и одной службы, и эта модель не является согласованной. Кроме того, центр регистрации услуг SOFA SOFARegistry прошел многолетнюю практику в Ant Financial. Его масштабируемость и надежность проверены большой практикой.Вот некоторые данные по SOFARegistry.На нем зарегистрировано около 2W сервисов, а сумма Пабов и Сабов в компьютерном зале составляет десятки миллионов. Исходя из приведенных выше соображений, мы решили добавить адаптер SOFARegistry в пилотную версию, чтобы он мог получить информацию о регистрации службы в SOFARegistry.
Затем возникает еще одна проблема с Pilot.Получается, что Pilot будет синхронизировать все данные, связанные с регистрацией сервиса, в Pilot.Это сильно нагружает кластер Pilot, поэтому мы решили синхронизировать только необходимые данные с Pilot. На узле введите нагрузку на память самого пилота.
Наконец, буду поделиться другим сценарием Financials Ant Financial. В Ant Final, из-за большого количества бизнес-единиц и регулирующих вопросов, некоторые машины между неиспользованными бизнес-подразделениями могут не связаны с сетью, поэтому они должны получить доступ к услугам, если они хотят , Существует роль для доступа к услугам в средах, поэтому мы предлагаем роль EdgeeideCar на основе концепции Sidecar. Его технические детали реализации на самом деле очень похожи на SideCar, развернутые с приложением, но этот состав в качестве роли «края» , чтобы нести ответственность за поперечные проблемы со службой связи.
Таким образом, SOFA Mesh, вероятно, выглядит так в общей картине. Мы разработали Golang Sidecar и включили Mixer в Sidecar, чтобы предотвратить проблемы с производительностью, подобные Istio. В Pilot и Auth Role мы решили использовать Istio напрямую, а затем определенная степень адаптации, чтобы адаптироваться к внутренней среде муравьев, а затем мы добавляем роль EdgeSidecar ко всему развертыванию, чтобы решить проблему вызова межсредовых служб.
Я знаю, что все должны быть очень заинтересованы в реализации SOFA Mesh в муравьях.В настоящее время реализованные нами сценарии в основном являются многоязычными сценариями.Для решения проблем связи между другими языками и SOFA существует около 20 или 30 систем. Затем мы пытаемся использовать SOFA Mesh для лучшего решения проблемы безопасности вызовов между сервисами и проблемы сине-зеленого выпуска.Мы также попробуем использовать SOFA Mesh для решения проблемы гетерогенной системной связи в ближайшем будущем.
Конечно, посадка SOFA Mesh внутри Ant на самом деле неотделима от сообщества открытого исходного кода.Поэтому в ближайшие два-три месяца мы также откроем исходный код SOFA Mesh и откроем исходный код результатов внутренней практики муравья в Service Mesh., чтобы дать вам больше ссылок в этом отношении.
对于未来，其实我觉得中间件作为基础设施未来和云平台融合是一个不可阻挡地趋势，除了 Service Mesh，未来还可能会出现 Message Mesh，DB Mesh 等等产品，我知道业界有些同学已经开始做这方面的努力了。最后总结一下我今天演讲的内容，一个是 Service Mesh 给蚂蚁金服解决的问题，包括多语言，遗留系统以及基础设施团队和业务团队耦合的问题。在 ServiceMesh 的选型上，我们主要考量和当前架构的可融合性，以及框架的高可用，稳定性。未来除了 ServiceMesh，可能还会出现其他的 Mesh，中间件和底层云平台进一步融合的趋势不可挡。 Спасибо вам всем!
Ниже приведены вопросы и ответы между старшими техническими экспертами Ant Financial и участниками на месте о Service Mesh на конференции GIAC Мы выбрали несколько наиболее популярных вопросов и ответов, чтобы поделиться с вами.
1. Можете ли вы подробно объяснить высокую доступность и безопасность Mesh?
О: В последнее время мы работаем над безопасностью. Безопасность включает в себя два аспекта. Один аспект — это надежность всего вызова службы RPC. Это можно сделать непосредственно в Mesh и реализовать напрямую с помощью RBAC Istio. Взаимная аутентификация TLS между Mesh и Mesh. На самом деле в Istio есть несколько готовых решений, он очень хорошо интегрируется с K8S, эти вещи можно использовать напрямую.
2. Как решить проблему многоверсионной маршрутизации сервисов и многоверсионной маршрутизации блоков данных?
A: ServiceMesh в основном связан с вызовом службы.Позвольте мне объяснить мультиверсионную маршрутизацию.На самом деле, если мы внутри, версия службы будет использоваться меньше, и она будет использоваться больше для разных реализаций одного и того же сервиса. Но на самом деле, многоверсионная маршрутизация, если знать Label K8S, то можно позаимствовать его дизайн во всю Mesh, а потом различать по разным меткам, а потом будет какой-то обмен этим аспектом. .
3. Решает ли Service Mesh в основном проблему надежной передачи запросов и управления услугами?
A: Следует сказать, что Service Mesh предлагает лучший способ решения проблем надежной передачи запросов и управления услугами. На самом деле, представьте, что если вам нужен полный набор архитектуры управления сервисами, то все ваши бизнес-системы верхнего уровня должны быть подключены к соответствующим компонентам управления сервисами. , в этом Sidecar может осуществляться управление услугами. Он не решает новые проблемы, он просто лучше решает некоторые старые проблемы.
4. Почему Control Plane важен для Mesh?
О: На самом деле это включает в себя интеграцию всей облачной платформы и всей нашей сервисной системы. На самом деле, как вы можете видеть в настоящее время, часть Pilot очень сильна в оригинальном дизайне Istio и интегрирована с K8S.Если у вас нет этого набора вещей, это все еще очень высокий уровень для Mesh. Промежуточное ПО или что-то в этом роде. Конечно, можно сказать, что слой Control Plane не нужен, только Sidecar, который подключается к оригинальному набору системы управления сервисом, и это тоже можно сделать без особых проблем. Но со слоем Control Plane он определяет очень общий API, а сама архитектура тесно связана со всей архитектурой облачной платформы и имеет лучшую степень интеграции. Таким образом, мы чувствуем, что весь контроль Слой Plane очень важен.
Кроме того, Istio предложил Control Plane, что на самом деле является большим шагом вперед в стандартизации микросервисов. Он содержит множество стандартов обнаружения сервисов и стандартов управления.Хотя он смело предложил такие концепции и предположения, мы также увидели некоторые его недостатки, поэтому мы надеемся работать с сообществом для продвижения стандартизации этого уровня. Как я уже говорил в начале, инфраструктура упакована слой за слоем. Например, мы думаем, что все больше и больше компонентов промежуточного программного обеспечения будет размещаться в инфраструктуре. Сейчас есть и облачные нативные языки, мы его скомпилировали и обнаружили, что он очень медленный и имеет много проблем, но мы думаем, что это направление. Когда вы пишете, вы можете писать на этом языке, и многие способности будут улучшены. Мы хотим продвинуть инфраструктуру немного выше, чтобы играть такую роль. Это также то, что мы думаем Самая большая ценность Control Plane.