Демистификация двойного одиннадцатого национального экзамена Service Mesh 2019 года
Ant Financial очень рано начала уделять внимание Service Mesh и запустила сообщество ServiceMesher в 2018 году. В настоящее время в сообществе активно участвуют более 4000 разработчиков. На уровне технических приложений сцена сервисной сетки прошла период исследования и в этом году полностью вошла в глубоководную зону для исследования.
Double Eleven в 2019 году был для нас важным моментом, и мы провели масштабный лендинг. Мне, как техническому специалисту, очень нервно и волнительно сталкиваться с проблемами дорожного движения мирового уровня. Какие искры произведет Service Mesh, когда столкнется с Double Eleven? Поскольку архитектура LDC Ant Financial продолжает развиваться, какие обязанности возьмет на себя Service Mesh? Давайте раскроем секреты Service Mesh Double Eleven от Ant Financial.
Основные понятия Service Mesh
Istio четко описывает две основные концепции Service Mesh: плоскость данных и плоскость управления. Плоскость данных отвечает за действие в качестве сетевого прокси, выполняя уровень перехвата и пересылки по ссылке запросов на обслуживание, а также может выполнять маршрутизацию службы, шифрование ссылки, аутентификацию службы и т. д. в ссылке, в то время как плоскость управления отвечает для обнаружения сервисов, управления маршрутизацией сервисов, метрик запросов (спорных на уровне управления) и т. д.
Преимущества, обеспечиваемые Service Mesh, больше не повторятся Давайте взглянем на продукты плоскости данных и плоскости управления Ant Financial:
-
**Плоскость данных: SOFAMosn. ** Ant Financial Services использует высокопроизводительный сетевой прокси-сервер, разработанный Golang, в качестве плоскости данных Service Mesh, которая передает массивный трафик основных приложений Ant Financial Services Double Eleven.
-
**Контрольная поверхность: SOFAMesh. ** Модифицированная версия Istio упрощена до Pilot и Citadel во время процесса посадки, а Mixer напрямую интегрирован в плоскость данных, чтобы избежать накладных расходов на еще один переход.
Обзор ситуации приземления Double Eleven
В этом году основные приложения Ant Financial были полностью интегрированы в SOFAMosn, в результате чего были созданы сотни тысяч Mesh-контейнеров. Во время пика Double Eleven SOFAMosn может передавать данные в десятки миллионов запросов в секунду. Среднее время обработки пересылки SOFAMosn составляет 0,2 мс.
В таком крупномасштабном сценарии доступа мы сталкиваемся с чрезвычайно сложными сценариями.В то же время нам необходимо сотрудничать со всеми сторонами, и мы должны обеспечить производительность и стабильность уровня данных, чтобы удовлетворить требования большого продвижения. , Весь процесс чрезвычайно сложен.
В то же время внедрение Service Mesh также является типичным случаем межгруппового сотрудничества, которое объединяет искреннее сотрудничество ядра, RPC, обмена сообщениями, беспроводного шлюза, плоскости управления, безопасности, эксплуатации и обслуживания, тестирования и других команд. , Далее мы будем следовать вышеуказанным модулям.Давайте проанализируем ситуацию с посадкой Double Eleven для Service Mesh и уделим больше внимания этому числу для дальнейшего анализа.
Эта статья является первой частью серии «Практика посадки сетки Ant Financial Service» — основной статьи, автор: Тянь Ян (имя цветка: Ли Юань), технический эксперт Ant Financial, специализирующийся на исследованиях и разработках высокопроизводительной сети. серверы, основной участник проекта с открытым исходным кодом Tengine, основной участник проекта SOFAMosn с открытым исходным кодом Ant Financial.
наращивание базового потенциала
Общая картина возможностей SOFAMosn
SOFAMosn в основном разделен на следующие модули, включая базовые возможности сетевых агентов и облачные возможности, такие как XDS.
Бизнес поддержка
SOFAMosn, базовый высокопроизводительный сетевой прокси-сервер безопасности, поддерживает RPC, MSG, GATEWAY и другие бизнес-сценарии.
Модель ввода-вывода
SOFAMosn поддерживает две модели ввода-вывода, одна из которых — классическая модель Golang, горутина для каждого соединения; другая — модель RawEpoll, которая представляет собой режим Reactor, мультиплексирование ввода-вывода (мультиплексирование ввода-вывода) + неблокирующий ввод-вывод ( неблокирующий ввод-вывод (non-blocking I/O) — блокирующий ввод-вывод).
В сцене лендинга внутри Ant Financial количество подключений не является узким местом, оно порядка тысяч или десятков тысяч, мы выбрали классическую модель Golang. Для сценариев с большим количеством длинных ссылок между уровнем доступа и шлюзом больше подходит модель RawEpoll.
Сопрограммная модель
- Соединение TCP соответствует протоколу чтения, который выполняет прием пакетов и анализ протокола;
- Запрос соответствует рабочей сопрограмме, которая выполняет бизнес-обработку, прокси и логику записи;
В обычной модели TCP-соединение будет иметь две сопрограммы, Чтение/Запись Мы отменяем отдельную сопрограмму записи и заменяем ее рабочей сопрограммой рабочего пула, что уменьшает задержку планирования и использование памяти.
Расширение возможностей
Расширение протокола
SOFAMosn предоставляет механизм подключаемых модулей для протокола, используя тот же механизм кодека и интерфейс ядра кодека, включая поддержку:
- ГНФАРПК;
- HTTP1.x/HTTP2.0;
- Дуббо;
Расширение сетевого фильтра
SOFAMosn реализует механизм расширения сетевого фильтра, предоставляя механизм регистрации сетевого фильтра и унифицированный интерфейс фильтра чтения/записи пакетов.В настоящее время он поддерживает:
- TCP-прокси;
- впрыск неисправности;
Расширение StreamFilter
SOFAMosn реализует механизм расширения фильтра потока, предоставляя механизм регистрации фильтра потока и унифицированный интерфейс фильтра отправки/получения потока, включая поддержку:
- зеркалирование трафика;
- Rbac аутентификация;
Защищенная ссылка TLS
Как компания, занимающаяся финансовыми технологиями, безопасность капитала является наиболее важной частью, а шифрование ссылок - одной из самых основных возможностей.Мы провели много исследований и испытаний безопасных ссылок TLS.
В ходе тестирования собственный Go TLS претерпел значительную оптимизацию сборки, и его производительность составляет 80% от производительности Nginx (OpenSSL).Скучная версия Go (использующая cgo для вызова BoringSSL) не является доминирующей из-за проблем с производительностью. из cgo, поэтому мы, наконец, выбираем нативный Go TLS. Я считаю, что команда Go Runtime проведет больше оптимизаций в будущем, и у нас также будут некоторые планы по оптимизации.
- у go не очень много оптимизации по RSA, а способность go-boring (CGO) в 1 раз больше, чем у go;
- у p256 есть оптимизация сборки на ходу, ECDSA лучше, чем на ходу;
- При симметричном шифровании AES-GCM go в 20 раз мощнее, чем go-boring;
- Существуют также соответствующие оптимизации сборки в алгоритмах HASH, таких как SHA и MD;
Чтобы обеспечить безопасность и соответствие финансовым сценариям, мы также поддерживаем разработку внутренних паролей, которые недоступны в Go Runtime. Хотя текущая производительность все еще имеет некоторые пробелы по сравнению с международным стандартом AES-GCM, она составляет около 50%, но у нас уже есть некоторые последующие планы по оптимизации, так что следите за обновлениями.
Возможность плавного обновления
Чтобы выпуск SOFAMosn не знал о приложении, мы исследовали и разработали решение для плавного обновления, которое аналогично бинарному горячему обновлению Nginx, но самая большая разница заключается в том, что соединение старого процесса SOFAMosn будет не будет прерван, а будет перенесен в новый процесс, включая базовый сокет FD и данные приложения верхнего уровня, чтобы гарантировать, что бизнес не будет поврежден в течение всего процесса публикации двоичных файлов, и бизнес не будет знать об этом. Помимо поддержки протоколов SOFARPC, Dubbo, message и других, мы также поддерживаем миграцию зашифрованных каналов TLS.
Обновление контейнера
Плавное обновление SOFAMosn на основе контейнера поставило перед нами много задач.Сначала мы введем новый SOFAMosn, а затем он проверит, существует ли старый SOFAMosn через UnixSocket общего тома.SOFAMosn выходит. В этом разделе много подробностей, касающихся взаимодействия между самой SOFAMosn и Оператором.
Миграция подключения для SOFAMosn
Ядром миграции соединения является миграция сокета ядра и миграция данных приложения.Соединение является непрерывным, и пользователь не знает об этом.
миграция метрик для SOFAMosn
Мы используем общую память для совместного использования данных метрик старого и нового процессов, чтобы гарантировать правильность данных метрик в процессе миграции.
Механизм повторного использования памяти
- На основе sync.Pool;
- Повторное использование фрагментов использует мелкозернистую структуру плиты для повышения скорости повторного использования;
- Повторное использование общей структуры;
Коэффициент повторного использования в сети может достигать более 90%.Конечно, sync.Pool не панацея и имеет свои проблемы.Однако при постоянной оптимизации sync.Pool by Runtime, например, go1.13 использует блокировку -свободная структура для уменьшения количества блокировок Конкуренция и увеличенный механизм кеша жертвы будут становиться все более и более совершенными в будущем.
XDS (УДФА)
Поддержка облачного API унифицированной плоскости данных, полностью динамическое обновление конфигурации.
Предварительная подготовка
Стресс-тестирование и оптимизация производительности
В процессе подготовки перед запуском мы провели множество стресс-тестов и оптимизаций основного приложения кассира в среде оттенков серого, что заложило прочную основу для последующего внедрения.
От автономной среды до среды с оттенками серого мы столкнулись со многими крупномасштабными сценариями, которые недоступны в автономном режиме, такими как десятки тысяч серверных узлов для одного экземпляра и тысячи правил маршрутизации, которые не только занимают память, но и также оказывают большое влияние на эффективность сопоставления маршрутов, например, массовая регистрация выпусков высокочастотных услуг также создает большие проблемы для производительности и стабильности.
Весь процесс оптимизации стресс-теста длился пять месяцев.Начиная с начального увеличения ЦП на 20%, RT увеличилось на 0,8 мс на переход, и, наконец, ЦП увеличилось на 6%, RT увеличилось на 0,2 мс на переход и пиковое использование памяти был оптимизирован до предыдущей версии 1./10.
| Общее увеличение процессора | RT на переход | пиковое использование памяти | |
|---|---|---|---|
| До оптимизации | 20% | 0.8ms | 2365M |
| Оптимизировано | 6% | 0.2ms | 253M |
- Некоторые меры по оптимизации
Во время акции 618 мы запустили некоторые приложения с ядром, и потребление ЦП увеличилось на 1,7%, за счет логического переноса некоторых приложений с Java на Go потребление ЦП также сократилось примерно на 8%. С точки зрения задержки средний переход увеличивается на 0,17 мс, а полное соединение двух комбинированных систем развертывания увеличивается на 5–6 мс с потерей около 7%.
SOFAMosn запускается в одном компьютерном зале сзади.В условиях стресс-теста с полной связью общая производительность SOFAMosn лучше.Например, оплата транзакции с SOFAMosn на 7,5% ниже, чем RT без SOFAMosn.
SOFAMosn выполнила большую оптимизацию ядра и оптимизацию бизнес-логики, такую как Route Cache, которая быстрее приносит дивиденды архитектуры.
Перейти к выбору версии
Для обновления версии требуется серия тестов, а новые версии не всегда подходят для вашего сценария. В начале нашего проекта использовался Go 1.9.2.После года итераций мы начали исследовать последнюю на тот момент версию Go 1.12.6.Мы протестировали и проверили много хороших оптимизаций в новой версии, а также доработали Стратегия утилизации памяти по умолчанию. Хорошо подходит для нужд нашего проекта.
- Оптимизация GC для уменьшения длинных хвостовых запросов
Новая версия механизма самовытеснения прерывает трудоемкий процесс маркировки GC в обмен на более плавную производительность GC и снижает влияние на задержки в бизнесе.go-review.Google source.com/from/go/+/6857… go-review.Google source.com/from/go/+/6857…
Go 1.9.2
Go 1.12.6
- стратегия восстановления памяти
В Go1.12 стратегия восстановления памяти была изменена с MADV_DONTNEED по умолчанию на MADV_FREE.Хотя это оптимизация производительности, при фактическом использовании в тесте нет большого улучшения производительности, но он занимает больше памяти.Есть много помех между мониторингом и суждением о проблеме.Мы восстанавливаем предыдущую стратегию через GODEBUG=madvdontneed=1, а потом в выдаче есть соответствующие обсуждения, и последующие версии тоже могут изменить это значение.
runtime: use MADV_FREE on Linux if available
Используя политику MADV_FREE по умолчанию для Go1.12, Inuse 43M, но Idle имеет 600M, которые никогда не выпускались.
Исправления ошибок Go Runtime
При ранней проверке оттенков серого произошла серьезная утечка памяти в строке SOFAMosn, и за один день был утерян 1 Г памяти.Окончательное расследование заключалось в том, что реализация Go Runtime на Writev была дефектной, в результате чего адрес памяти слайса был на который ссылается нижний слой, и сборщик мусора не смог его освободить.
Мы отправили официальному представителю Go исправление, которое было включено в последнюю версию Go 1.13.internal/poll: avoid memory leak in Writev
пост-заказ
SOFAMosn сдал экзамен Double Eleven в Ant Financial. В будущем у нас будет больше технической эволюции и вспомогательных сценариев. Заинтересованные студенты могут присоединиться к нам.
SOFAMosn:GitHub.com/sopoststack/is…
Для более подробного анализа ситуации с двойной одиннадцатью посадками Ant Financial Service Mesh, пожалуйста, продолжайте обращать внимание на эту учетную запись~
Официальная учетная запись: распределенная архитектура финансового уровня (Antfin_SOFA)