Эта статья составлена на основе информации, предоставленной Глобальной конференцией по архитектуре Интернета GIAC (GLOBAL INTERNET ARCHITECTURE CONFERENCE) и Ши Цзяньвэй (цветочное имя: Zhuo Yu), техническим экспертом бизнес-группы Ant Financial Platform Data Technology Business Group. Разделяя концепцию, основанную на Service Mesh, в сочетании с реальными внутренними сценариями Ant Financial, промежуточное ПО, уровень данных, уровень безопасности и другие возможности отделяются от приложения и затем погружаются в независимый SOFAMosn Sidecar. системы, он предоставляет приложения без необходимости для обновления возможностей уровня инфраструктуры с осознанием.
Этот обмен будет осуществляться в следующем порядке:
Текущее состояние сервисизации Ant Financial
Прежде чем рассматривать сервис-ориентированную архитектуру Ant Financial, давайте начнем с простого примера сервис-ориентированного вызова.На следующем рисунке показан основной принцип SOFARPC:
Рисунок 1. Основной принцип SOFARPC
Из приведенного выше рисунка видно, что для создания сервис-ориентированной инфраструктуры требуется реестр служб и определение службы.Вызывающий и поставщик службы используют одно и то же определение службы для связи друг с другом. Через реестр услуг вызывающий абонент может напрямую подписаться на адрес поставщика услуг и напрямую инициировать запрос в режиме «точка-точка». Клиент может реализовать обнаружение служб, адресацию маршрутизации, балансировку нагрузки, ограничение тока и предохранители, а также другие возможности для расширения возможностей связи службы. Благодаря нашим открытым исходным кодам SOFARPC, SOFARegistry и SOFABoot пользователи могут напрямую создавать систему микросервисов, помогающую развитию бизнеса.
С момента разработки Ant Financial количество транзакций, с которыми приходится иметь дело системе Double 11, увеличивалось из года в год:
Рисунок 2. Объем транзакций Double 11 и пиковые данные за годы
265 000 транзакций в секунду — это пиковые данные Double 11 в 2017 г. Эти данные поддерживаются очень сложной архитектурой.Унифицированная архитектура LDC — это основная архитектура, которую Ant Financial накапливала в течение многих лет, полагаясь на эту архитектуру для достижения быстрого роста. ежегодного пикового объема транзакций Система по-прежнему может плавно переходить. Давайте кратко рассмотрим архитектуру LDC:
Рисунок 3. Пример архитектуры LDC
Приведенный выше рисунок взят из распределенной архитектуры финансового класса вЮнитизация эскизовЭта статья не является подробной здесь. Унифицированная архитектура LDC привносит больше спецификаций и абстракций в обслуживание приложений.При маршрутизации обслуживания необходимо учитывать больше сценариев, таких как вызовы между устройствами и вызовы между компьютерными комнатами. Основная надежда здесь заключается в том, что архитектура LDC делает вызовы RPC более сложными.
Болевые точки сервиса
Обновление версии промежуточного ПО
Когда я представил предысторию выше, я рассказал о сложности вызовов службы в текущей архитектуре LDC, которая в настоящее время напрямую отражается в коде приложения. Для студентов, изучающих бизнес, основное внимание в приложении уделяется реализации бизнес-логики, а высокая доступность, аварийное восстановление и другие возможности — это скорее рассмотрение на уровне общей архитектуры. Внедрив в приложение пакет RPC jar, можно получить поддержку различных возможностей вызова службы в архитектуре LDC, что приносит удобство, а также видит недостатки этого режима:
Рис. 4. Бизнес-приложение и компоненты SDK
В дополнение к бизнес-логике в приложении SDK промежуточного программного обеспечения вводит большое количество внешних зависимостей для полного обнаружения служб, маршрутизации, балансировки нагрузки, ограничения тока и предохранителей, сериализации, связи и т. д. Внедрение каждого компонента может принести Риски стабильности и более высокие затраты на обновление.
Рисунок 5. Зависимости, соответствующие различным возможностям в SDK
Согласно текущей внутренней версии SOFARPC, обнаружение служб зависит от клиентов SOFARegistry для обнаружения служб в IDC и Antvip для обнаружения служб между IDC.Рассчитайте текущую зону, а затем определите вызывающую цель.Предохранитель, ограничивающий ток, зависит от компонента Guardian , Протокол связи и протокол сериализации относительно стабильны с небольшими изменениями. Для выполнения сервисного вызова в приложении необходимо дополнительно внедрить клиентский пакет 7+.
Каждый год двойное 11 требует структурной корректировки: например, для поддержки эластичной архитектуры необходимо выполнить множество обновлений клиентских версий промежуточного программного обеспечения для поддержки лучшей архитектуры.Для студентов-бизнесменов эти обновления очень трудоемки, так как требуют 200 основных приложений. , Например, требуется 5 человеко-дней для обновления промежуточного программного обеспечения каждого приложения после НИОКР, тестирования, развертывания, предварительного выпуска, полутонового, производственного и других сред, и 1000 человеко-дней для обновления 200 базовых промежуточного программного обеспечения приложения. ежегодное обновление структуры может сэкономить много человеческих ресурсов.
межъязыковое общение
Ant Financial до сих пор развивалась, и ее внутренний бизнес процветал.Стек технологий, используемый в различных сферах деятельности, таких как рекомендации по поиску, искусственный интеллект и безопасность, очень разнообразен.Возможности межъязыкового общения службы также очень важны. Еще несколько лет назад крупнейшим приложением за пределами Java был NodeJS. Чтобы повторно использовать различное промежуточное программное обеспечение и инфраструктуру внутри Ant Financial между приложениями Java и NodeJS, фронтенд-группа использовала NodeJS для постепенного переписывания различных приложений.Клиент промежуточного программного обеспечения позволяет все системы NodeJS и Java для идеального взаимодействия.
Рисунок 6. Интермодуляция Java и NodeJS
Межъязыковое переписывание SDK промежуточного программного обеспечения и высокие затраты на обслуживание, с увеличением количества языков межъязыковое общение требует все больше и больше.
Рисунок 7. Многоязычный сценарий
Java, NodeJS, Go, Python, C++ и т. д., 5+ языков, связующее ПО SDK — все затраты на переписывание чрезвычайно высоки. Эти проблемы должны мотивировать нас на поиск лучших решений.
Решить болевые точки
Утечка возможностей SDK
Рис. 8. SDK сокращается и передает возможности Sidecar
Все еще взяв в качестве примера приведенный выше RPC SDK, мы можем посмотреть на возможности в SDK по характеристикам стабильности и неотслаиваемости, которые можно извлечь из приложения, постараться сделать SDK как можно тоньше, и сделать он достаточно стабилен без изменения стоимости апгрейда.перестанет существовать.
Рисунок 9. Зависимости, соответствующие SDK и Sidecar
Такие функции, как обнаружение сервисов, адресация маршрутизации, ограничение тока и предохранитель в RPC SDK, изменить проще.Мы погружаем эту часть возможностей в независимый Sidecar, который можно реализовать Самый простой протокол сериализации и связи, и эти возможности очень легки и просты в реализации. Мы надеемся, что sidecar здесь существует как независимый процесс, отделенный от процесса бизнес-приложений и отделенный от обновления бизнес-приложений, чтобы реализовать концепцию параллельного развития бизнеса и инфраструктуры, не мешая друг другу.
Рис. 10. Приемник сообщений RPC и возможностей источника данных
В дополнение к RPC-коммуникациям мы также можем поместить сообщения, источник данных и другие возможности в Sidecar, бизнес-приложения могут становиться все тоньше и тоньше, затраты на внедрение SDK могут быть снижены до приемлемого уровня, уровень инфраструктуры и бизнес разделены, и обе стороны может развиваться независимо.
посадочная конструкция
Общая структура
Рисунок 11. Архитектура приземления сетки
В отличие от системы Istio с открытым исходным кодом, внутренняя версия Service Mesh от Ant Financial отдает приоритет внедрению и внедрению плоскости данных. внутренние сервисы промежуточного ПО. Как видно из приведенного выше рисунка, мы располагаем разные сайдкары и бизнес-приложения в одном и том же поде, приложение взаимодействует напрямую с Mosn, а Mosn отвечает за обнаружение сервисов и маршрутизацию целевого интерфейса, и это делается встроенной в модуле безопасности Мосн.Зашифрованная аутентификация для звонков между приложениями. Sidecar DBMesh используется для реализации погружения уровня данных. Приложению не нужно устанавливать соединения с несколькими источниками данных. Для завершения вызова уровня данных ему нужно только подключиться к DBMesh в модуле. Имя пользователя базы данных , пароль и правила базы данных и таблиц и т. д. больше не нужно заботиться.
Анализ имени существительного на рисунке:
- ConfigServer: центр конфигурации, отвечающий за различные конфигурации метаданных, динамические переключения и т. д.
- Реестр: Реестр сервисов, отвечающий за обнаружение сервисов в IDC.
- AntVip: продукт, аналогичный разрешению DNS, который разрешает набор целевых адресов через доменные имена для обнаружения служб между IDC.
- MQ: сервер центра сообщений, используемый для отправки и получения сообщений.
данные посадки
Рисунок 12. Пол данных CPU
В настоящее время эта архитектура была опробована в основной платежной ссылке.По сравнению с несетевым приложением, потребление ЦП в ячеистом приложении продвижения 618 увеличилось на 1,7%, а общее время, затрачиваемое на одну транзакцию, увеличилось на 5 мс. Рост ЦП происходит за счет еще одного процесса, после добавления одного запроса RT будет стабильно и незначительно расти, но эти затраты ничтожны по сравнению с дивидендами, приносимыми общей архитектурой, а постоянная оптимизация всей плоскости данных, как ожидается, постепенно сокращать ресурсы Занимайте и улучшайте использование ресурсов.
сократить перерывы
Способность промежуточного программного обеспечения тонуть возможна с точки зрения архитектуры.Как поменять колеса в движущемся поезде без остановки — очень важное соображение. С помощью лучших практик Kubernetes разумно размещать бизнес-контейнеры и сайдкар-контейнеры в одном Pod. .
Рисунок 13. Способ посадки
Чтобы сделать обновление бизнес-приложения как можно более плавным, мы в основном разработали следующие планы оптимизации:
1. Нечувствительное зеркалирование
В Ant Financial все еще есть приложения, которые не завершили зеркалирование или используют зеркалирование в многофункциональном контейнере. Система исследований и разработок активно помогает пользователям завершить процесс зеркального отображения процесса упаковки приложений, автоматически создавая Dockerfile. Добейтесь сознательного зеркального преобразования.
2. Низкочувствительная сетка
После завершения зеркалирования, если мы хотим развернуть контейнер приложения и контейнер Mosn вместе с помощью модели Pod, нам необходимо заменить все базовое управление ресурсами и планирование на систему Kubernetes. Затем добавьте идентификаторы к ячеистым приложениям в PAAS, идентифицируйте эти идентификаторы через Kubernetes и активно внедряйте сайдкары Mosn для завершения ячеистого доступа приложений.
3. Модернизация бесчувственной коляски
После того, как коляска становится независимой от бизнес-процесса, еще одним основным требованием является надежда на то, что коляска может быть обновлена независимо.Чтобы сделать обновление коляски как можно более ненарушенным для производства, мы внедрили оператор плавного обновления Mosn, который можно мигрировать через миграцию соединения работающего мосна., приложение совершенно не в курсе всего процесса апгрейда. Конечно, здесь есть много проблем, о которых мы подробно поговорим позже.
вызов на посадку
Плавное обновление коляски
В настоящее время мы реализовали возможность плавного обновления Mosn.Основной возможностью Mosn является коммуникационный агент RPC и сообщений.Целью плавного обновления является завершение обновления версии Mosn без перезапуска процесса бизнес-приложения и прерывания бизнес-запросов. .
Рисунок 14. Плавное обновление Mosn
Так как Mosn и приложение являются независимыми контейнерами, как показано на рисунке выше, для обновления Mosn требуется горячая замена образа в Pod.Эта возможность горячей замены должна обеспечивать следующие моменты:
- Поды не перестраиваются, процессы приложений всегда работают нормально
- Замена зеркала не влияет на работающий трафик
- Все описание пода необходимо обновить после замены изображения.
Для достижения вышеуказанных целей мы завершаем переработку вышеупомянутого обновления через трансформацию Kubernetes и Custom Customer. Поток обработки выглядит следующим образом:
Рис. 15. Процесс плавного обновления Mosn
В сценарии, где гладкое обновление между несколькими зеркалами не рассматривается, процесс ветвления может наследовать FD родительского процесса, чтобы завершить миграцию долгосрочных подключений и обеспечить горячее обновление без потерь. После того, как Mosn работает в зеркальном режиме, сложность плавного обновления значительно возрастает. Сложность всего плавного обновления заключается в том, как заставить процессы Mosn в разных контейнерах узнавать друг о друге и завершить миграцию соединений.
Давайте посмотрим, как обеспечить потерю трафика в процессе обновления Mosn:
Рисунок 16. Нормальное направление движения
Обычный трафик, обрабатываемый Mosn, делится на входящий и исходящий трафик.Клиент может рассматриваться как приложение, развернутое в том же модуле, что и Mosn.Сервер может быть целевым поставщиком услуг для вызова запроса, либо приложением, либо вызываемым приложением. Мосн. Когда запрос отправляется от клиента к серверу, в середине будет два длинных соединения: TCP1 и TCP2, и Mosn запишет ConnectionID, соответствующий запросу, чтобы завершить инициацию и ответ на запрос.
Рисунок 16. Прямая миграция трафика
При запуске нового контейнера Mosn Mosn попытается отправить запрос на основе локального сокета домена.Если существует другой процесс Mosn, Mosn V1 и Mosn V2 перейдут в режим горячего обновления, а Mosn V1 отправит существующий подключенный FD и существующий Mosn V2 в режим горячего обновления.Прочитанные пакеты данных отправляются в Mosn V2 через Domain Socket, а V1 больше не будет считывать данные из перенесенного FD.После завершения миграции FD весь трафик будет напрямую обрабатываться Mosn V2.
Рисунок 17. Обратная миграция трафика
После перехода Mosn V1 и Mosn V2 в режим горячего обновления может возникнуть ситуация, когда сервер не успел ответить после того, как Mosn V1 отправил запрос на сервер.В этом сценарии, когда Mosn V1 мигрирует FD на Mosn V2, Mosn V2 заменит FD.После этого ConnectionID возвращается в Mosn V1.Когда Mosn V1 получает ответ, возвращенный сервером, он отправляет запрос в Mosn V2 через доменный сокет, после чего Mosn V2 может найти подключение TCP1 в соответствии с ConnectionId, а затем ответить клиенту.
Экстремальная оптимизация производительности
Рисунок 18. Запрос на запись слиянием
Модель базовой сети Mosn полностью реализована самостоятельно. Мы провели множество оптимизаций на всем сетевом уровне. Благодаря функции записи golang мы объединяем несколько запросов в одну запись, сокращаем количество вызовов sys.call и улучшаем общую производительность и пропускную способность. В то же время, в процессе использования writev было обнаружено, что реализация writev в golang имеет ошибки, из-за которых часть памяти не восстанавливается, мы отправили PR в golang для исправления этой проблемы, которая была принята:GitHub.com/go wave/go/fear…
Есть много других моментов оптимизации, которые подробно описывать не буду, а только для справки, такие как:
- Журналы Mosn являются асинхронными, чтобы избежать влияния проблем с диском на производительность пересылки Mosn.
- Кэш результатов маршрутизации маршрутизации, пространство для времени, повышение пропускной способности
- Почти 90% повторного использования памяти, старайтесь избегать копирования байтов
- Отложенная загрузка кластера для повышения скорости запуска Mosn
- Оптимизация уровня протокола связи, целевое обновление протоколов с более низкими версиями, снижение затрат на распаковку
Направление эволюции
Рис. 19. Комбинация плоскостей управления направлением эволюции
Мы также постепенно продвигаем построение плоскости управления Service Mesh в планировании, надеясь унифицировать модель взаимодействия плоскости данных и плоскости управления.Стабильность, снизить частоту изменений и использовать более общую модель для описания сценариев. таких как обнаружение служб и управление службами.DBMesh также будет распространять конфигурацию на основе XDS, а также унифицировать и контролировать канал распределения данных плоскости управления. Прямая связь между плоскостью управления и серверной частью промежуточного программного обеспечения основана на соображениях производительности и емкости.Данные обнаружения служб в Ant Financial достигают десятков миллионов в одном компьютерном зале.ETCD, использующий Kubernetes, не может нести такое огромное количество данных. данные, а плоскость управления должна использоваться как мост, а шард — для обслуживания разных плоскостей данных.
Рисунок 20. Модель производства
Далее будет построение полного слоя продукта.С помощью идеи Mesh-архитектуры больше возможностей надеются получить дивиденды, принесенные обновлением архитектуры, опускаясь на Sidecar. Уровень продукта Mesh будет включать в себя различные формы сбора метрик плоскости данных Mesh, панель мониторинга, унифицированный внешний подход к плоскости управления, защиту от сложности взаимодействия между внешними системами и Mesh, унифицированный протокол взаимодействия плоскости управления и плоскости данных, посредством идеального Конструкция размерной системы улучшает возможности обновления в градациях серого для Sidecar в режиме Mesh, так что обновление версии может быть выполнено без нарушения работы приложения, стабильно и без вмешательства оператора.
Суммировать
Подводя итог практике реализации полного текста в области Service Mesh, ее можно свести к следующим шести пунктам:
- Разделение прикладного уровня и уровня инфраструктуры
- Базовый слой настроек записывается за один раз и повторно используется в нескольких местах.
- Плоскость данных имеет приоритет посредством преобразования возможностей
- Уменьшите помехи и повысьте эффективность посадки
- Модель конфигурации единой плоскости данных построения плоскости управления
- Непрерывная оптимизация производительности, стабильности и наблюдаемости
В этой статье представлен процесс эволюции реализации сервисной сетки Ant Financial и решения связанных проблем.Мы надеемся, что благодаря нашему реальному опыту мы сможем донести до читателей эволюционное мышление, отличное от основных решений в сообществе.
Адрес загрузки Activity PPT:Дай мне, Али боится, что там objects.com/OS/basement…
На KubeCon&CloudNativeCon&Open Source Summit компания SOFAStack провела полнодневный воркшоп, на котором была представлена демонстрация практики Service Mesh, синхронизируем в ближайшее время, обратите внимание на официальный аккаунт.
Официальная учетная запись: распределенная архитектура финансового уровня (Antfin_SOFA)