Эта статья представляет собой сборник выступлений на мероприятии Hangzhou Station, посвященных передовым методам работы с облачными приложениями. На мероприятии станции в Ханчжоу были приглашены Вэнь Мин, вице-президент проекта Apache APISIX, Мо Хунбо, старший инженер отдела разработки облачных платформ, Ван Факан, технический эксперт Ant Financial, и Чжан Чао, инженер по разработке промежуточного программного обеспечения Youzan, чтобы поделиться опытом облачных вычислений. Нативное приложение, как показано ниже.
Ван Факан (Йи Сун), технический эксперт отдела доверенных нативных технологий компании Ant Financial, занимается исследованиями и разработками высокопроизводительных сетевых серверов, является основным участником проектов с открытым исходным кодом MOSN и Tengine, а в настоящее время занимается облачными технологиями. -native ServiceMesh, Nginx, Istio и другие смежные области.
Сегодня я в основном делюсь крупномасштабной реализацией MOSN Service Mesh от Ant Financial и встраиваю ее в одну из плоскостей данных Istio путем стыковки с UDPA.Я начну со следующих трех аспектов:
-
Введение в МОСН
-
Облачная эволюция
-
Резюме и перспективы
Введение в МОСН
Позвольте мне сначала представить MOSN с точки зрения рождения MOSN, истории развития MOSN в Ant Group, анализа структуры и реализации MOSN и других аспектов.
История рождения MOSN
Когда дело доходит до того, почему появляется Service Mesh, нам нужно проанализировать процесс развития сервиса, который обычно проходит следующие этапы:
**Единая служба: **На начальном этапе веб-сайт был небольшим, трафик невелик, а бизнес был простым, и все развертывания можно было выполнить в одной службе;
**Распределенный:** Когда количество пользователей достигает определенного масштаба и растет, сервисы необходимо разделить;
**Микрослужбы.** В связи с постоянным увеличением количества служб возникают требования к управлению службами, такие как ограничение тока, проверка подлинности и автоматические выключатели, поэтому некоторые компоненты управления интегрируются в различные приложения в виде подключаемых модулей SDK. входы;
**Service Mesh:** из-за многоязычного SDK для управления услугами, высокой стоимости разработки и адаптации компонентов промежуточного программного обеспечения и собственных слабых возможностей управления услугами компания начала пытаться отделить SDK от бизнеса и отделить отдельный Sidecar, чтобы решить многоязычную разработку, бизнес-итерацию и другие проблемы.
В целом, у деловой стороны есть следующие болевые точки:
-
Многоязычность, высокая стоимость разработки и адаптации компонентов промежуточного программного обеспечения
-
Сложность обновления SDK
-
Слабые возможности управления услугами
-
Технология не универсальна и не может быть использована повторно
Существующие отраслевые решения:
-
Envoy (C++)
-
Линкерд (менее активный)
-
NginxMesh (низкая активность)
Основываясь на болевых точках вышеперечисленного бизнеса и оценив соответствующие решения в отрасли, мы, наконец, приняли решение о самостоятельной разработке MOSN. MOSN (ModularOpen Smart Network) — это программное обеспечение сетевого прокси-сервера, разработанное на языке GoLang. Как облачная сетевая плоскость данных оно предназначено для предоставления услуг с многопротокольными, модульными, интеллектуальными и безопасными возможностями прокси-сервера.
История развития МОСН
MOSN начала исследование технологии Service Mesh в декабре 2017 года, преодолела множество трудностей при инкубации продукта и, наконец, прошла широкомасштабную проверку Double 11 в 2019 году, реализовав охват основных платежных каналов Ant Group. После внутреннего внедрения MOSN мы считаем, что использование открытого исходного кода также должно подпитывать открытый исходный код, поэтому мы начали проводить экологическую интеграцию CloudNative и совместно идти по пути стандартизации с различными стандартными компонентами с открытым исходным кодом в отрасли, чтобы достичь делиться и максимизировать выпуск своих технических дивидендов.
На следующем рисунке показано глобальное функциональное представление MOSN.Как плоскость сетевых данных, MOSN теперь имеет несколько функций, таких как поддержка маршрутизации, балансировки нагрузки и многопротокольности, а также возможность наблюдения и административного управления.
Анализ архитектуры MOSN
Общая структура MOSN использует архитектурную идею «разделяй и властвуй».Как показано на рисунке, вся структура MOSN разделена на четыре уровня:
-Сеть: нижний уровень — это сетевой уровень, отвечающий за прием пакетов, Listener_filter (original_dst), network_filter (tcp, faultinject)
-
Протокол: многопротокольные уровни (система HTTP, SOFARPC, Dubbo), предоставляющие возможности настраиваемого протокола (Xprotocol)
-
Поток: Stream_filter(health_check, faultinject)
-
Прокси: Предоставление прокси-фреймворка (поэтапная обработка, маршрутизатор, балансировщик нагрузки, пул соединений)
Каждый слой предоставляет свой интерфейс через режим фабричного проектирования, что удобно для пользователей, чтобы гибко регистрировать свои собственные потребности.Использование пула сопрограмм позволяет пользователям реализовывать асинхронные функции в стиле синхронного кодирования. Поскольку MOSN использует язык GoLang и поддерживает выражение асинхронных действий синхронным способом, MOSN может легко реализовать два типа сопрограмм, чтение и прокси.Для конкретного процесса см. Схематическое изображение режима пула сопрограмм MOSN:
Благодаря описанной выше структуре конкурентное преимущество MOSN было значительно улучшено, и его основные возможности заключаются в следующем:
-
Thermal Effective: Конфигурация Thermal Effective (xDS); плавное бинарное обновление (миграция подключения) является основным конкурентным преимуществом
-
Мультипротокол (Xprotocol): поддержка системы HTTP, SOFARPC, Dubbo
-
Управление трафиком и маршрутизация: разгрузка заголовков/URI, пул подключений, проверка работоспособности, защита автоматических выключателей, внесение ошибок, TLS/национальная тайна
-
Возможность пересылки: уровень 4 и уровень 7; SWRR, Random, EDF, Maglev и т. д.
-
Наблюдаемость: соединения, запросы, трафик
Память MOSN и пул соединений
Чтобы уменьшить задержку, вызванную сборщиком мусора во время выполнения, MOSN инкапсулировал собственный пул памяти, что удобно для эффективного повторного использования памяти несколькими объектами. Чтобы улучшить возможности соединения между сервисными сетками, мы разрабатываем пул соединений, который инкапсулирует несколько протоколов, чтобы упростить мультиплексирование соединений и управление ими.
Ситуация с посадкой МОСН
В 2019 году MOSN был широко проверен во время Double 11, что позволило полностью охватить основные платежные ссылки Ant Group с потрясающими результатами. Конечно, у вас могут возникнуть вопросы: после внедрения Service Mesh на одну ссылку больше, чем на предыдущую, будет ли это создавать новые накладные расходы? Ответ не обязательно. В процессе внедрения MOSN копирует бизнес-логику SDK в MOSN, что равносильно переливанию из левой руки в правую, а также оптимизирует ее. Фактически, мы также обнаружили, что некоторые предприятия потребляют меньше памяти после внедрения Service Mesh.
Облачная эволюция
Ранее мы узнали о реализации MOSN на плоскости данных Ant Group, На самом деле у нас всегда была маленькая мечта — мы надеемся, что больше людей будет использовать MOSN, поэтому мы стандартизировали облачную эволюцию и открыли окружающую экологическое сотрудничество, которое будет подробно описано ниже.
Could Native Arch
Как показано на рисунке ниже, во всей облачной архитектуре нижний уровень — это инфраструктура (включая оборудование, сетевые ресурсы, компьютерные залы и т. д.), верхний уровень основан на абстрагированном аппаратном обеспечении Kubernetes для управления планированием ресурсов контейнера. , а верхний уровень — это Service Mesh, Serverless, функция Istio на этом уровне, а MOSN эквивалентен исполнению роли плоскости данных в Istio.
Введение в Истио
Любая технология рождается с проблемами бизнеса.Прежде чем представить Istio, давайте посмотрим, почему появился Istio. Если раньше ресурсы управлялись физическими машинами, позже благодаря разделению микросервисов появился Docker, то любая технология, решающая проблему, обязательно принесет новые проблемы, конечно, новые проблемы ускорят появление новых технологий, поэтому Docker Затем появился Кубернетес. Kubernetes прекрасно решает проблемы Docker с управлением, планированием и оркестровкой, но управляет только машинными ресурсами. Как бизнес-писатели, мы также ожидаем, что приложения смогут осуществлять управление микросервисами, поэтому на свет появился Istio.
У Istio есть такие функции, как взаимосвязь сервисов, безопасность трафика, контроль трафика и возможность наблюдения. Его появление компенсирует недостатки Kubernetes в управлении сервисами. Они могут работать в тесном сотрудничестве друг с другом, чтобы в полной мере использовать его функциональные преимущества, тем самым реализуя сетку микросервисов. .управлять.
MOSN with Istio
После непрерывных усилий сообщества MOSN в последние месяцы MOSN успешно адаптировался к Istio. 28 июля Istio официально опубликовал мою подписанную статью "Другой выбор для Istio Data Plane — MOSN", в которой указано, что MOSN можно выбрать и использовать в качестве плоскости данных. Если вам интересно, вы можете нажать, чтобы просмотреть ее.это TiO.IO/последний/блог…В области сервисной сетки использование Istio в качестве уровня управления стало основным.Как показано на рисунке ниже, мы видим, что в архитектуре Istio мы используем MOSN в качестве уровня данных Istio и реализуем управление услугами. с помощью Истио.
Наша цель для MOSN — стать облачным стандартом Sidecar.По этой причине мы создали рабочие группы, связанные с Istio, MOSN и Dubbo, чтобы позволить большему количеству разработчиков участвовать в сообществе.
На рисунке ниже показан весь список функций, которые MOSN адаптирует к Istio, стоит отметить, что довольно много функций внесено сторонними разработчиками.
В настоящее время MOSN адаптирован к версии Istio1.5.X, которую можно внедрить для управления услугами. Но прежде чем использовать его, мы должны сначала понять, как виртуальный сервис в Istio сопоставляется с элементом конфигурации маршрутизатора MOSN. Как показано на рисунке ниже, виртуальная служба Istio маршрутизируется на основе заголовков запроса. MOSN получает соответствующие ресурсы от Istio по протоколу xDS для выполнения соответствующих преобразований конфигурации, а затем, когда MOSN фактически получает запрос на службу, он сопоставляет запрос с заголовок и выполняет соответствующую обработку переадресации маршрутизации.
После первоначальной адаптации к Istio мы также протестировали экземпляр Bookinfo. Как показано на рисунке, это классический случай многоязычного обслуживания. В первые дни Service Mesh не существовало, и необходимо было использовать SDK для написания на нескольких языках. Стоимость разработки была высокой, а обновление — сложным. Но когда управление услугами осуществляется через Istio, MOSN (коричневая область на рисунке) может быть не только входным шлюзом, но и Sidecar, эффективно решая предыдущие технические проблемы.
Фактически, после запуска экземпляра Bookinfo через MOSN в качестве плоскости данных Istio были реализованы следующие общие возможности управления услугами:
-
Возможность маршрутизации по версии
-
Возможность маршрутизации по весу
-
Возможность маршрутизации по конкретному заголовку
-
Возможность внедрения ошибок
-
Возможность самозащиты сервисного предохранителя
-
Возможность прозрачного захвата
-
Механизм повтора тайм-аута
-
etc
Если вам интересно, вы можете пройти демо-учебник "MOSN с Istio"woohoo.kata coda.com/touch you/course…Узнать больше о.
Экологическое строительство с открытым исходным кодом
Осуществив адаптацию MOSN к Istio, мы не зацикливаемся на Istio, а общаемся и сотрудничаем со многими проектами в сообществе, такими как Dubbo, Sentinel, Skywalking.
MOSN with Dubbo
MOSN может решить проблему управления сервисом Dubbo в системе Kubernetes и в системе, отличной от Kubernetes. Как показано на рисунке, в сценарии управления системными службами, отличными от Kubernetes, в схеме 1 можно ввести MOSN для интеграции Dubbo-go для поддержки pub/sub, а исходный реестр служб можно повторно использовать для обеспечения управления; схема 2 предназначена для сервисную систему на основе Kubernetes.Scenario, поддерживая маршрутизацию Dubbo в Istio, чтобы обеспечить управление сервисом.
MOSN with Sentinel
Ограничение тока — одна из важных функций в управлении услугами, а Sentinel — это компонент Alibaba для ограничения тока с открытым исходным кодом, который прошел тестирование Double Eleven, поэтому мы решили интегрировать Sentinel с MOSN, чтобы повторно использовать его базовые возможности ограничения тока для достижение ограничения на одной машине Потоковая передача (комбинация бакетов маркеров и бакетов с дырками), защита сервисных предохранителей (скорость успешного обслуживания), адаптивное ограничение тока (в зависимости от загрузки машины) и другие функции. На следующем этапе мы обогатим текущий алгоритм ограничения и сформулируем новые правила совместно с Istio и UDPA.
MOSN with Skywalking
Зависимость вызовов и статус вызовов между сервисами и сервисами являются важными показателями в управлении микросервисами.MOSN сотрудничает со Skywalking и интегрирует базовый SDK Skywalking для реализации отображения топологии канала вызова, мониторинга QPS и детального отображения RT. В будущем мы также продолжим развивать поддержку Dubbo Tracing.
эволюция стандартизации
В дополнение к экологической адаптации с открытым исходным кодом, MOSN также пытается стандартизировать. Всем известно, что «стандарты» и «спецификации» очень важны. Например, Google предложила спецификацию UDPA, слой стандартного API на плоскости данных, чтобы отделить связь между плоскостью управления и плоскостью данных, в то время как Microsoft предложила ServiceMesh. Интерфейс, который находится над плоскостью управления. Уровень стандартной API-интерфейса, разъединяющий поверхность управления и приложения/инструменты верхнего уровня, лежащие в основе этих спецификаций, должны соответствовать принципу «предотвращения блокировки и облегчения гибкого переключения пользователей». .
Поэтому после того, как MOSN будет адаптирован к Istio, Dubbo, Skywalking и другим компонентам, мы считаем, что он должен не только адаптироваться к другим, но и стандартам, что требует от нас внимания и активного участия в построении open source сообществ. По сути, в процессе адаптации к Istio мы уже находимся в официальном общении с Istio, участвуя не только в разработке Istio, но и в обсуждениях UDPA и формулировании стандартов.
После обобщения официальных дискуссий между MOSN и Istio сообщество MOSN возглавляет и участвует в разделении плоскости данных в Istio (например, наборы тестов, построение образов и т. д.), что упрощает для Istio интеграцию сторонних данных. Это означает, что пользователям сообщества MOSN будет проще интегрировать Istio. Следующие пункты были добавлены в дорожную карту для MOSN с Istio:
-
Продвижение построения образов Istio и разделения плоскости данных
-
Продвижение тестовой среды Istio и разделение плоскости данных
Что касается первого вопроса, мы вносим свой вклад в сообщество Istio, чтобы помочь отделить зеркальную структуру плоскости данных Istio и плоскости управления, упрощая интеграцию сторонних плоскостей данных. 14 июля @Shriram Rajagopalan, член Istio TOC (Технический комитет Istio), также ответил нам, что «он также поддерживает решение по поддержке нескольких плоскостей данных в Istio, а также рекомендует включить MOSN в Istio в качестве экспериментальный сторонний дата-плоскость. В официальном блоге пользователям удобно его попробовать», что свидетельствует о том, что MOSN полностью официально признан Istio.
В процессе развития стандартизации мы вели переговоры с официальными лицами Istio и выдвигали предложения по разработке спецификаций на основе поля UDPA:
-
Прототип ограничения тока: определение ключа ограничения тока, режима наблюдателя и абстракции действия после ограничения тока;
-
Universal Router Proto: не ограничивается системой HTTP, поддержкой иерархической маршрутизации и улучшенной масштабируемостью условий маршрутизации;
Резюме и перспективы
Сообщество MOSN с открытым исходным кодом в настоящее время развивается с высокой скоростью, используя открытый исходный код, повторяющийся открытый исходный код повсюду и шаг за шагом эволюционируя по пути практики. ** В среде с открытым исходным кодом MOSN, как показано на рисунке, на верхнем уровне MOSN есть Fasthttp, Istio и UDPA. MOSN разрабатывает для них новые функции при их использовании и возвращает их обратно.
В будущем облачная эволюция MOSN будет осуществляться по следующим четырем направлениям:
-
Программируемый: DSL для бизнес-уровня, гибкое и удобное управление поведением при обработке запросов
-
ОС микросервисной среды выполнения: шаблон Dapr, программирование для MOSN делает сервисы легче, меньше и быстрее для запуска
-
Интегрировано: соответствует спецификации UDPA, может быть удалено с помощью Istio, встроенной общей цепочки инструментов Kuma, удобно для повторного использования в других проектах.
-
Поддержка дополнительных форм: Cache Mesh, Message Mesh, Block-chain Mesh
Вышеизложенное — это все, чем я делюсь сегодня, больше информации о MOSN и последних разработках можно узнать по следующим каналам:
официальный сайт МОСНmosn.io
MOSN Github github.com/mosn/mosn
Service Mesh www.servicemesher.com