Эта статья составлена Цзя Дао, старшим техническим экспертом Ant Financial, который поделился информацией на площадке Service Mesh Meetup Station в Ханчжоу 28 декабря.
MOSN завершает инкубацию и позволяет независимой Группе
2020.2019.12.18, Хан Чанг, руководитель проекта MOSN и руководитель сетевой группы приложений Ant Financial, объявил, что MOSN завершил инкубацию SOFAStack и создаст независимую группу для последующих операций.Приглашаем всех создать сообщество вместе.
MOSN — это программное обеспечение сетевого прокси, разработанное на языке Go. Как облачная плоскость сетевых данных, оно направлено на предоставление многопротокольных, модульных, интеллектуальных и безопасных возможностей прокси для сервисов. MOSN — это аббревиатура от Modular Open Smart Network-proxy.Он может быть интегрирован с любой сервисной сеткой, поддерживающей xDS API, а также может использоваться в качестве независимой балансировки нагрузки уровней 4 и 7, шлюза API, облачного Ingress и т. д.
адрес проекта:github.com/mosn/mosn
Введение
В микросервисной архитектуре сервисной сетки мы часто слышим термины «трафик с востока на запад» и «трафик с севера на юг». Service Mesh Sidecar с открытым исходным кодом от Ant Financial: MOSN (Modular Observable Smart Network) встречался и общался с вами много раз. В прошлом основное внимание уделялось обнаружению сервисов и маршрутизации трафика с востока на запад. -южный трафик??
В этом обмене с точки зрения процесса разработки API-шлюза Ant Financial, что такое архитектура ячеистого шлюза, какие проблемы были решены, практическая эффективность Double Eleven и наши мысли о будущем.
Сегодняшний обмен разделен на три части:
- Определение API Gateway Mesh: я искал слово API Gateway Mesh в Google, и все, что я нашел, это API Gateway vs Service Mesh, Всем, наверное, любопытно: каково конкретное определение этого слова? Итак, ниже мы сравним API Gateway и Service Mesh, а затем поговорим о моем личном понимании и размышлениях об этом слове.
- Практика API Gateway Mesh в Ant Financial: в этом году основная система Alibaba на 100 % является облачной, поддерживая пик трафика мирового класса Double 11. Среди них ярко сияет Service Mesh от Ant Financial, и все основные каналы работают. , Mesh, с масштабом в десятки тысяч контейнеров, наш API-шлюз также берет на себя 100% запросов на ссылки на некоторые кошельки и платежные ссылки. В этой главе я рассмотрю процесс разработки шлюза API Ant Financial, почему мы используем сетку шлюза API, какова наша архитектура, а также некоторые риски и тесты в процессе.
- Думая об API-шлюзе в облаке: сейчас все говорят об облаке, но в процессе практического применения облачных технологий возникнут различные проблемы. Какое решение и форма API-шлюза наиболее подходят для вашего бизнеса? В облачной архитектуре Service Mesh и API Gateway являются одними из основных компонентов.Как мы думаем о расположении API Gateway в облачной архитектуре в архитектуре Service Mesh? Кроме того, какие у нас планы на будущее? Я поделюсь ею с вами в этой главе.
Определение сетки шлюза API
На приведенном выше рисунке показана облачная схема архитектуры трафика север-юг + восток-запад, которая включает в себя некоторые основные компоненты.Позвольте мне кратко представить:
- LB\ingress: отвечает за разгрузку ssl и балансировку нагрузки входящего трафика, обычно выполняя простую маршрутизацию;
- Шлюз API: отвечает за более ориентированную на бизнес проверку подписи API, ограничение тока, преобразование протоколов, сеансы пользователей, балансировку нагрузки и другую логику;
- Sidecar в POD: Sidecar в бизнес-системе, который перенаправляет трафик с востока на запад в комнату прокси, обычно через внутренний RPC (например, SOFARPC \ Dubbo \ Thrift \ SpringCloud). Весь трафик в этом передается через Sidecar Proxy of Service Mesh Этот Sidecar отвечает за маршрутизацию (unitization\grayscale\canary), балансировку нагрузки, сервисную аутентификацию и т.д.;
- Плоскость управления: «большая экономка» в управлении трафиком.Наиболее распространенным решением в облачных технологиях является Istio, который отвечает за выдачу и контроль политик маршрутизации, безопасности, аутентификации и т. д.;
Приведенная выше архитектура всем знакома, и из вышеприведенного описания видно, что API Gateway и Service Mesh Sidecar имеют схожие возможности и возможности аутентификации. Ниже мы сравним API Gateway и Service Mesh.
API Gateway vs Service Mesh
По сути, API Gateway можно описать одним предложением: «Представляет ваши службы как управляемые API», что делает внутренние службы более контролируемыми и управляемыми. Ключевые слова здесь — «открытость» и «контролируемый» . Service Mesh можно охарактеризовать одним предложением: «Инфраструктура для отделения сети приложений от вашего кода службы», инфраструктура, которая отделяет код службы от сети приложений. Ключевое слово здесь — «отделение».
Что касается трафика, API Gateway управляет трафиком север-юг, а Sidecar в Servcie Mesh обычно является прокси-сервером, используемым для загрузки трафика восток-запад. Оба могут отвечать за балансировку.API Gateway, как правило, представляет собой балансировщик нагрузки, централизованный через lvs и nginx, который мы называем жесткой нагрузкой; в то время как Service Mesh, как правило, осуществляется через обнаружение сервисов, а sidecars являются двухточечными. мы называем мягкой нагрузкой.
Что касается протоколов связи, шлюз API обычно получает открытые протоколы связи, обычно HTTP, gRPC и т. д., и может включать преобразование протоколов, преобразование HTTP во внутренний протокол RPC, в то время как внутренний трафик прокси-сервера Service Mesh обычно является внутренним частным. (WebService, Dubbo, SOFABolt, Thrift и т. д.). На уровне аутентификации, управления потоком, безопасностью и другим трафиком управления он сильно зависит от шлюза API, что отражает характеристики «контролируемого», а внутренний трафик прокси-сетки Service Mesh обычно находится в среде интрасети. обычно слабо зависимы.
Наше истинное понимание Service Mesh
Как видите, API Gateway и Service Mesh на самом деле имеют много общего и много различий. Так как же определяется API Gateway Mesh? Тогда давайте представим наше истинное понимание Service Mesh!
Коляска в Service Mesh — это такой мотоцикл с коляской.Коляска разделяет сервисный код и внутреннюю коммуникационную логику RPC. Но на сиденье коляски можно не только сидеть на "RPC для внутренней связи", но и ставить в эту коляску другое промежуточное ПО, API Gateway + Sidecar = API Gateway Mesh, мы также можем поместить Клиент MessageQueue в Sidecar, это это сетка сообщений.
Итак, давайте посмотрим, на самом деле Service Mesh — это шаблон и архитектура, а ключевое слово — «развязка» вашего кода службы и вашего «промежуточного программного обеспечения».
Определение сетки шлюза API
Таким образом, определение API Gateway Mesh: Инфраструктура для предоставления ваших услуг в качестве управляемых API в форме отделенного прокси-сервера sidecar, в форме отделенного sidecar, для предоставления кода вашего сервиса в качестве управляемой инфраструктуры API.
Итак, определение API Gateway Mesh ясно объяснено, но почему мы так структурируем наш API Gateway? Какую проблему это решает? Чтобы объяснить эти проблемы, мы должны взглянуть на историю разработки шлюза API Alipay.
Практика создания сетки Ant Financial API Gateway
Предшественник мобильного шлюза Alipay
Первая версия приложения Alipay была выпущена в 2009 г. В 2009 г. это был еще мир кнопочных телефонов (Nokia Symbian).Мобильный терминал приложения не является основным входом трафика, поэтому архитектура сервера приложения также очень просто.В системе Мобайл https restful сервисы предоставляются извне.Преимущество этой архитектуры в том, что она проста и груба. С задержкой времени, появлением мобильного Интернета в 2013 году, популяризацией смартфонов (Android и iOS), все больше и больше бизнеса компании обращалось к мобильному терминалу, мобильная система стала узким местом исследований и разработок, и стабильность единой системы тоже стала проблемой.
В 2013 году компания предложила беспроводную стратегию «ALL IN». Тогда же был создан мобильный микросервисный шлюз (дядя Мартин предложил концепцию микросервисов в 2014 году), в основном для решения проблемы совместной работы нескольких бизнес-команд.
Архитектура микросервисного шлюза
В этой архитектуре шлюза мы разработали беспроводной RPC-протокол Ant Financial (аналогичный gRPC), который поддерживает клиентские возможности генерации многоязычного кода RPC для iOS и Android, скрывает детали сетевого взаимодействия и добавляет больше безопасности, аутентификации, возможности монитор. Так как многопоточная модель традиционных сервлетов очень чувствительна к серверной системе RT, мы изменили всю связь API Gateway на асинхронную Netty. Чтобы решить проблему недружественности HTTP-связи в слабой мобильной сети, мы разработали частный протокол длинных соединений на основе TCP. Такая структура поддерживает быстрое развитие бизнеса на протяжении 3-4 лет.
Но в конце 2016 года централизованный шлюз выявил множество проблем, таких как:
- Проблема риска смены шлюза: как только возникнет проблема с выпуском логического изменения шлюза, это повлияет на все предприятия;
- Проблема классификации и изоляции бизнеса: ожидается, что API-интерфейсы основных видов деятельности будут отделены от интерфейсов неосновных видов деятельности;
- Проблема масштабной оценки потенциала продвижения: ежегодные мероприятия в красных конвертах Double 11 и китайский Новый год, трудно оценить количество запросов в секунду десятков тысяч API-интерфейсов.Влияние RT, BodySize и QPS различных API на Производительность шлюза отличается.Для стабильности входа в шлюз, при нормальных обстоятельствах, он будет сильно расширяться;
Децентрализованный шлюз
Основываясь на вышеуказанных проблемах, мы намерены отказаться от формального шлюза, тем самым представив архитектуру шлюза следующего поколения: децентрализованный шлюз.
Мы разделили централизованный шлюз, перенесли модуль маршрутизации с простой логикой в балансировщик нагрузки Spanner, абстрагировали сложную аутентификацию, маршрутизацию LDC, безопасность и другую логику шлюза в файл gateway.jar, а также бизнес-интеграцию этого пакета Jar. способность шлюзов, чтобы бизнес-системы были изолированы, и риск централизованных изменений шлюза не коснулся этих систем.Эти системы сами по себе являются «шлюзами», и проблема продвижения большой емкости больше не является проблемой.
Новая архитектура решает некоторые проблемы, но также создает и новые проблемы.
Децентрализованная архитектура работает бесперебойно уже 2 года, подключено более 30 систем (полная система исчисляется сотнями) и несет 60%-80% трафика, почему подключено только 30 систем? Поскольку текущая архитектура децентрализованного шлюза имеет много проблем, ее трудно импортировать и продвигать:
- Сложность в доступе: gateway.jar зависит от десятков Jars, а еще есть конфигурации, и в новых версиях постоянно добавляются новые зависимости;
- Конфликт пакета Jar: в одном случае gateway.jar зависит от более ранней версии Netty, а обновление промежуточного программного обеспечения косвенно обновляет эту версию Netty, что приводит к ненормальной работе Jar шлюза;
- Сложность обновления: В начале мы думали, что централизованный шлюз имеет много версий и его сложно обновлять, но в то время мы наивно полагали, что шлюз разрабатывался столько лет, и он очень стабилен и не нуждается в обновлении. меняться часто, и даже если измениться, пусть система, которую необходимо обновить, обновит ее. Но вещи всегда слишком хороши, чтобы их можно было представить: после обновления бизнес-сторона должна сказать: интеграция разработки, регрессионное тестирование, нет времени! Новые функции нельзя популяризировать, а апгрейд всей сети стоит очень дорого;
- Поддержка разнородных систем: некоторые из бизнесов Alipay основаны на технологическом стеке Node.js. Команда промежуточного программного обеспечения Node.js очень хороша. На перевод Java-кода шлюза с помощью JavaScript ушло 1-2 месяца, но позже он отказался от этого. был обновлен, невозможно скопировать все новые функции, стоимость слишком высока, а у студентов, занимающихся исследованиями и разработками, нет чувства выполненного долга...
Видя это, чувствуете ли вы, что это похоже на проблему, решаемую Service Mesh: разделение кода шлюза и бизнес-кода, независимое обновление и поддержка гетерогенных систем. Поэтому мы интегрировали Jar децентрализованного шлюза в вспомогательную часть Service Mesh и представили архитектуру шлюза следующего поколения: архитектуру Mesh-шлюза.
Архитектура ячеистого шлюза
В заключение:
- Архитектура шлюза микросервисов: разделение бизнеса и шлюза;
- Архитектура децентрализованного шлюза: решение таких проблем, как стабильность, бизнес-классификация и изоляция, а также оценка возможностей крупномасштабного продвижения;
- Архитектура Mesh-шлюза: решает такие проблемы, как сложность децентрализованного обновления и поддержки гетерогенных систем;
Сетчатая архитектура шлюза API службы Ant Jin
Далее представлена архитектура API Gateway Mesh от Ant Financial и проблемы в процессе посадки.
На приведенном выше рисунке показана архитектурная схема API Gateway Mesh, которая имеет 3 потока:
- Поток данных: бизнес-данные напрямую пересылаются в sidecar POD в системе через Spanner, а через различные логики проверки в шлюзе локальные запросы или запросы на пересылку отправляются в бизнес-логику SOFA;
- Поток управления: как правило, плоскостью управления в Service Mesh является компонент Pilot в Istio, но поскольку собственный компонент Pilot не работает должным образом в условиях больших объемов, мы в настоящее время не используем Pilot, а напрямую подключаемся к фоновому управлению и контролю шлюза. ;
- Поток операций: это канал для эксплуатации и обслуживания.Благодаря внедрению коляски оператора K8s бизнес имеет возможность шлюзовой сетки;
Основой API Gateway Mesh является прокси-сервер MOSN Sidecar, исходный код которого предоставлен Ant Financial.Основываясь на возможностях модульного расширения MOSN, мы обновили уровень основного модуля шлюза, включая основной сервер, маршрутизатор, конвейер, службу, конфигурацию. и другие базовые модели.Динамические скрипты, такие как Lua и JavaScript, расширяют динамические возможности шлюза.Основываясь на возможностях расширения протокола MOSN, частный протокол MMTP компании Ant Financial легко реализуется. При запуске Gateway Core путем подключения и отключения различных фильтров и конфигураций расширяются продукты шлюза для различных сценариев, такие как беспроводной шлюз Ant Financial, шлюз открытой платформы, финансовый облачный шлюз и т. д. На уровне управления мы поддерживаем различные формы каналов распространения конфигурации, включая XDS Istio, Amdin RestAPI, K8s ConfigMap и т. д.
МОСН:github.com/mosn/mosn
Запуск новых технологий — дело точно не из простых!
- Функция: поскольку MOSN разработан на основе языка Go, мы должны превратить стек технологии Java в Go, но не только скопировать код Java, но и в соответствии с языковыми характеристиками Go не только хорошо выполнять функции, но и лучше представление;
- Производительность: в финальном онлайн-нагрузочном тесте мы обнаружили, что версия Mesh имеет некоторое улучшение производительности по сравнению с исходной версией Java. Причина в том, что мы изменили метод сериализации с Hessian на Protobuf. Кроме того, режим потока Java был переключен на Горутина Go.Наступило некоторое улучшение производительности;
- O&M: O&M больше склоняется к облачному направлению K8;
- Риск: Известные риски не являются рисками, как уменьшить неизвестные риски?
Самая большая разница между интернет-компаниями и традиционными компаниями-разработчиками программного обеспечения заключается в гибкости, и мы больше сосредоточимся на реализации тройного топора. Обычно мы можем потратить 30% работы на то, чтобы сделать функцию, но нам нужно потратить 70% работы на построение оттенков серого, откат и мониторинг.
В процессе подключения API Gateway Mesh к сети, как мы можем реализовать оттенки серого и быстрый откат?
Здесь я привожу пример процесса резки Spanner для Xinwang Sidecar. Мы поддерживаем потоковую передачу в процентах, что позволяет добиться медленных оттенков серого и быстрого отката. Кроме того, инъекция sidecar MOSN не является одноразовым доступом ко всему кластеру, мы поддерживаем сквозную проверку интегрированного MOSN с одной машиной в кластере посредством маркировки меток.
Думая о шлюзе API в Cloud Native
Облачное решение для трафика с севера на юг
Вышеизложенный опыт Ant Financial в применении API Gateway Mesh.Далее я хотел бы поделиться с вами подборкой некоторых стандартных решений для трафика север-юг в облаке.
На приведенном выше рисунке показаны три основных решения для север-юг в отрасли: первое — K8s Ingress с относительно простыми функциями, второе — Istio Gateway с большим количеством функций маршрутизации и других функций, чем Ingress, третье — API с более мощными функциями. функций шлюза, который может более точно управлять интерфейсами и трафиком, а также может выбирать продукт трафика север-юг, который подходит вам в соответствии с характеристиками вашего бизнеса.
Многогранный характер MOSN в облачной среде
Далее мы представим многогранный характер MOSN.
Как упоминалось ранее, sidecar Service Mesh используется не только для RPC трафика север-юг, фактически его можно использовать как sidecar для всего трафика.
В будущем MOSN позиционируется как облачный полнофункциональный сетевой прокси, который можно развернуть с LB в качестве LB Sidecar; можно развернуть независимо как централизованный шлюз; можно развернуть с бизнес-подсистемой POD в качестве децентрализованного шлюза или MessageQueue Client, а также может использоваться в качестве межоблачного коммуникационного шлюза.
Service Mesh уже здесь, так что поторопитесь и садитесь в автобус! Выше представлен весь контент, опубликованный в этом выпуске.
об авторе
Цзинь Вэньсян (цветочное имя Цзя Дао), старший технический эксперт Ant Financial, Цзя Дао, присоединился к команде беспроводной связи Alipay после выпуска в 2011 году. Он занимался исследованиями и разработками, связанными с доступом к мобильным сетям, шлюзом API и микро- В настоящее время он отвечает за разработку и оптимизацию архитектуры доступа к мобильной сети Ant Financial.
Просмотрите видео в этом выпуске и поделитесь адресом просмотра PPT.
specialty.ant fin.com/community/ ах…
Официальная учетная запись: распределенная архитектура финансового уровня (Antfin_SOFA)