8 сентября 2021 года ByteDance анонсировала официальный CloudWeGo с открытым исходным кодом. CloudWeGo — это набор внутреннего промежуточного программного обеспечения ByteDance для микросервисов, отличающийся высокой производительностью, сильной масштабируемостью и стабильностью, ориентированный на решение проблем связи и управления микросервисами, а также на удовлетворение потребностей различных предприятий в различных сценариях. CloudWeGo впервые открыл исходный код четырех проектов: Kitex, Netpoll, Thriftgo и netpoll-http2, в основном RPC-фреймворк Kitex и сетевую библиотеку Netpoll.
Несколько дней назад команда фреймворка сервиса ByteDanceОфициально открытый исходный код CloudWeGo, Kitex, микросервисная RPC-инфраструктура Golang, которая широко применялась в Douyin и Toutiao, также включена.
Цель этой статьи — поделиться сценариями и техническими проблемами, которые разработчики должны понимать при стресс-тестировании Kitex. Эти предложения помогут пользователям лучше настроить Kitex в сочетании с реальными сценариями RPC, что сделает его более подходящим для нужд бизнеса и обеспечит наилучшую производительность. Пользователи также могут обратиться к официальному проекту по стресс-тестированию kitex-benchmark[4] для получения более подробной информации.
Характеристики сценариев микросервисов
Kitex родился из практики крупномасштабной микросервисной архитектуры ByteDance, и ориентированный сценарий, естественно, является микросервисным сценарием, поэтому сначала будут представлены характеристики микросервисов, чтобы разработчики могли глубоко понять дизайнерское мышление Kitex.
- Модель связи RPC
В связи между микросервисами обычно преобладает модель PingPong, поэтому в дополнение к обычным показателям производительности пропускной способности средняя задержка каждого RPC также является моментом, который необходимо учитывать разработчикам.
- сложная цепочка вызовов
Вызов RPC часто требует взаимодействия нескольких микросервисов для завершения, а нижестоящие сервисы будут иметь свои собственные зависимости, поэтому вся цепочка вызовов будет представлять собой сложную ячеистую структуру.
В этом сложном отношении вызова флуктуация задержки промежуточного узла может передаваться по всей линии связи, что приводит к общему тайм-ауту. Когда на канале достаточно узлов, даже если вероятность флуктуации каждого узла очень низка, вероятность тайм-аута, окончательно сошедшегося на канале, будет увеличена. Таким образом, флуктуация задержки одного сервиса — показатель задержки P99 — также является ключевым показателем, который может оказать существенное влияние на онлайн-сервисы.
- Размер посылки
Хотя размер пакета служебной связи зависит от фактического бизнес-сценария, во внутренней статистике ByteDance мы обнаружили, что большинство онлайн-запросов в основном представляют собой небольшие пакеты (
Стресс-тестирование сценариев микросервисов
Определить объект испытания давлением
Измерение производительности инфраструктуры RPC требует рассмотрения с двух точек зрения: с точки зрения клиента и с точки зрения сервера. В крупномасштабной бизнес-архитектуре вышестоящий клиент не обязательно использует нижестоящий фреймворк, и то же самое верно для нижестоящих сервисов, вызываемых разработчиком.Если рассматривать сетку сервисов, ситуация более сложная.
Некоторые проекты стресс-тестирования обычно объединяют клиентские и серверные процессы для проведения стресс-тестирования, а затем получают данные о производительности всего фреймворка, которые могут не соответствовать фактической онлайн-операции.
Если вы хотите провести стресс-тестирование сервера, вы должны предоставить клиенту как можно больше ресурсов, чтобы довести сервер до предела, и наоборот. Если и клиент, и сервер используют только 4-ядерный процессор для стресс-тестирования, разработчики не смогут определить, с какой точки зрения получены окончательные данные о производительности, не говоря уже о том, чтобы предоставить реальную ссылку для онлайн-сервисов.
Выравнивание моделей подключения
Существует три основных модели подключения для обычного RPC:
- короткое соединение: для каждого запроса создается новое соединение, и соединение закрывается сразу после его возврата.
- пул длинных соединений: одно соединение может обрабатывать только полный запрос и возвращать его одновременно.
- мультиплексирование соединения: одно соединение может обрабатывать несколько запросов и одновременно возвращать их асинхронно.
Каждый тип модели подключения не является абсолютно хорошим или плохим, в зависимости от фактического сценария использования. Хотя мультиплексирование соединений обычно обеспечивает наилучшую производительность, приложения должны полагаться на протокол для поддержки порядковых номеров пакетов, а некоторые старые службы инфраструктуры могут не поддерживать вызовы мультиплексирования.
Чтобы обеспечить максимальную совместимость, Kitex по умолчанию использовал короткие соединения на стороне клиента, в то время как другие основные платформы с открытым исходным кодом по умолчанию использовали мультиплексирование соединений, в результате чего некоторые пользователи испытывали относительно высокую производительность при использовании конфигурации по умолчанию для стресс-тестирования. .
Позже, чтобы соответствовать обычным сценариям использования пользователями с открытым исходным кодом, Kitex также добавил параметр длинного соединения по умолчанию в v0.0.2.
Выровнять сериализацию
Для инфраструктуры RPC, независимо от управления службами, вычислительные затраты в основном сосредоточены на сериализации и десериализации.
Kitex использует официальную библиотеку Protobuf [6] для сериализации Protobuf.Для сериализации Thrift специально оптимизирована производительность.Содержание этого аспекта представлено в блоге официального сайта.
Большинство современных фреймворков с открытым исходным кодом отдают приоритет поддержке Protobuf, а встроенный Protobuf, используемый некоторыми фреймворками, на самом деле является версией gogo/protobuf со многими оптимизациями производительности. Ради ремонтопригодности мы все же решили использовать только официальную библиотеку Protobuf, конечно, мы также планируем оптимизировать Protobuf в будущем.
Использовать эксклюзивный ЦП
Хотя онлайн-приложения обычно делят ЦП с несколькими процессами, в сценарии стресс-тестирования и клиентский, и серверный процессы чрезвычайно загружены. отсутствие ссылок на данные, и легко произвести большие колебания до и после.
Поэтому мы предлагаем изолировать клиентские и серверные процессы на разных процессорах или разных эксклюзивных машинах. Если вы хотите еще больше избежать влияния других процессов, вы можете добавить команду nice -n -20 для настройки приоритета планирования процесса измерения давления.
Кроме того, если позволяют условия, использование реальных физических возможностей делает результаты тестирования более строгими и воспроизводимыми по сравнению с виртуальными машинами облачной платформы.
Справочник по производительности
Исходя из соблюдения вышеуказанных требований, мы сравнили несколько фреймворков, использующих Protobuf для стресс-тестирования, и код стресс-тестирования находится в репозитории kitex-benchmark. С целью полного заполнения сервера Kitex имеет самую низкую задержку P99 в режиме пула соединений среди всех фреймворков. В режиме мультиплексирования у Kitex также более очевидные преимущества по различным показателям.
Конфигурация:
- Клиент 16 процессоров, сервер 4 процессора
- Размер запроса 1 КБ, эхо-сцена
Справочные данные:
- KITEX: режим пула соединений (режим по умолчанию)
- KITEX-MUX: режим мультиплексирования
- Другие фреймворки используют режим мультиплексирования.
Эпилог
В текущих основных RPC-фреймворках с открытым исходным кодом Golang каждая инфраструктура на самом деле имеет свои собственные цели проектирования: некоторые фреймворки ориентированы на универсальность, некоторые — на сценарии с легкой бизнес-логикой, такой как Redis, некоторые — на пропускную способность, а некоторые больше ориентированы на P99. задерживать.
В ежедневной итерации бизнеса ByteDance часто возникает ситуация, когда один показатель увеличивается, а другой уменьшается из-за какой-то фичи, поэтому Kitex более склонен решать различные задачи в масштабных микросервисных сценариях в начале своего проектирования.
После выпуска Kitex мы получили большое количество данных для самопроверки от пользователей.Мы благодарим сообщество за их внимание и поддержку.Мы также приглашаем разработчиков выбирать подходящие инструменты для своих реальных сценариев на основе рекомендаций по тестированию, представленных в этом статья. Если у вас есть дополнительные вопросы, отправьте сообщение о проблеме на GitHub.
Ссылки по теме
- [1] Официальный сайт CloudWeGo:www.cloudwego.io
- [2] Kitex: GitHub.com/cloudmeego/can…
- [3] Netpoll: GitHub.com/cloud i ego/you…
- [4] kitex-benchmark: GitHub.com/cloudmeego/can…
- [5] netpoll-benchmark: GitHub.com/cloud i ego/you…
- [6] Официальная библиотека Protobuf:GitHub.com/golang/pro Т…
- [7] Бережливость:GitHub.com/cloud i ego/he…