Эта статья выбрана из серии статей «Практика инфраструктуры Byte Beat».

Серия статей «ByteDance Infrastructure Practice» представляет собой техническую галантерею, созданную техническими командами и экспертами отдела инфраструктуры ByteDance, в которой мы делимся с вами практическим опытом и уроками команды в процессе развития и эволюции инфраструктуры, а также всеми техническими студентами. общаться и расти вместе.

Перенаправление онлайн-трафика в офлайн-среду является распространенным требованием, которое широко используется в функциональном тестировании, стресс-тестировании и других сценариях. Эта статья знакомит с процессом разработки и проектированием дренажной системы в ByteDance, надеясь дать вам новые идеи и достижения.

1. Предпосылки

AB Test (тест сравнения) – широко используемый метод проверки в интернет-индустрии. Например, Google использует эксперименты AB для проверки эффективности рекламы и рекомендаций. Twitter разработал Diffy, который применяет возможность проверки различий для обеспечения качества API. интерфейсы. Обычно существует две формы тестирования AB. Одна из них — несколько версий онлайн-сервиса, а эксперимент проводится путем шунтирования AB на стороне доступа. Однако для таких сценариев, как реклама, если у определенной модели возникают проблемы, это приведет к потерям капитала. Еще один режим — копирование и воспроизведение онлайн-трафика во внутреннюю среду, этот метод абсолютно безопасен для продакшена, например, сервис верификации AB от Twitter использует этот режим. Сегодня байтовая внутренняя рекомендация, реклама и многие другие направления бизнеса проводят эксперименты АБ через режим воспроизведения онлайн-трафика в реальном времени. Чтобы удовлетворить потребности бизнеса, мы разработали систему записи и воспроизведения онлайн-трафика ByteCopy для поддержки высокой пропускной способности бизнеса и новых постоянно возникающих требований к записи и воспроизведению трафика.

В этой статье будет представлена ​​эволюция системы ByteCopy с точки зрения бизнес-сценариев, системной архитектуры и анализа проблем.

2. Построить дренажную систему первого поколения на основе TCPCopy.

2.1 Бизнес-требования

В начале бизнеса требования относительно просты.Есть надежда, что после того, как бизнес-сторона развернет целевые сервисы (HTTP и RPC), система отвода трафика сможет копировать и пересылать соответствующий рабочий онлайн-трафик, а весь отвод трафика процесс может быть гибким.Контролируйте, включайте только тогда, когда трафик необходим.

2.2 Выбор системы

С точки зрения самого дренажа, он в основном делится на два типа: репликация основного пути и репликация обхода.Давайте проанализируем преимущества и недостатки этих двух режимов соответственно.

2.2.1 Репликация главной дороги

Репликация основного маршрута относится к репликации трафика в цепочке вызовов: одна — для репликации трафика в бизнес-логике.Например, в процессе вызова API/RPC бизнес-сторона пишет логику кода и записывает содержимое информации о запросе/ответе; другой — реплицировать трафик в бизнес-логике, он копируется в логике обработки фреймворка (например, при использовании Dubbo, Service Mesh и других сетевых фреймворков).

преимущество

• Его можно тесно интегрировать с бизнес-логикой для реализации мелкомасштабной репликации трафика, например, он может реплицировать только трафик с определенными характеристиками, что может максимизировать эффективный коэффициент сбора трафика на источнике трафика.

недостаток

• Бизнес-логика и логика дренажа сильно связаны и функционально влияют друг на друга.
• Каждый запрос требует дополнительной обработки перенаправления, что влияет на производительность бизнес-процесса.

Применимая сцена

• Для трафика, который имеет требования тонкой фильтрации или связан с бизнес-логикой, вы можете выбрать репликацию основного пути; например, в Service Mesh репликация трафика выполняется на основе цветовой маркировки.

2.2.2 Обход репликации

По сравнению с основной репликацией обходная репликация подчеркивает особенность неосведомленности службы.Как правило, сторонняя служба отслеживает трафик репликации в стеке сетевых протоколов.

преимущество

• Отделенный от бизнеса модуль перенаправления трафика может быть развернут и обновлен независимо, и бизнес-стороне не нужно обращать внимание на реализацию функции перенаправления трафика; выполняя репликацию трафика на нижнем уровне стека протоколов, производительность это лучше.

недостаток

• После того, как сетевой пакет захвачен на уровне сетевой карты 4 уровня, ему все еще необходимо реорганизовать и проанализировать пакет данных, что требует дополнительного потребления вычислительных ресурсов.
• Часто перед скринингом необходимо захватить и проанализировать весь объем пакетов, а выполнить индивидуальную выборку в сочетании с бизнес-логикой невозможно.

Решение с открытым исходным кодом

Хотя Linux предоставляет низкоуровневую библиотеку захвата пакетов, такую ​​как libpcap, с целью быстрого выполнения бизнес-требований мы выбрали TCPCopy с открытым исходным кодом в качестве основной основы всей дренажной системы. TCPCopy не будет здесь представлен, ниже приведена простая схема архитектуры. Среди них TCPCopy и Intercept являются двумя компонентами TCPCopy. Студенты, которые заинтересованы в соответствующих деталях, могут найти информацию самостоятельно.

Основные преимущества TCPCopy:

• Независимость от протокола, прозрачная переадресация и возможность поддержки любого протокола прикладного уровня на основе TCP, например MySQL, Kafka, Redis и т. д.
• Переадресация в реальном времени, низкая задержка
• Информацию об IP-порте исходного запроса можно сохранить, а тестовый сервер можно использовать для статистики.

В то же время он также имеет следующие недостатки:

• Невозможно динамически добавить несколько подчиненных серверов
• Благодаря прозрачной пересылке и отсутствию анализа протокола невозможно найти аномалии данных, например, при потере некоторых TCP-пакетов тестовый сервер получит неполные данные, кроме того, невозможно фильтровать и модифицировать данные прикладного уровня.
• Основные компоненты не предназначены для многопоточности, и существует узкое место в вычислительной мощности.
• Необходимо изменить iptables, чтобы отбрасывать возвращаемые пакеты нижестоящих служб, поскольку в производственных или общедоступных тестовых средах существует больший риск.

Чтобы удовлетворить потребность в байтах, мы вводим некоторые другие компоненты в общую архитектуру, чтобы компенсировать недостатки самого TCPCopy.

2.3 Архитектура системы

Чтобы устранить недостатки TCPCopy, мы сделали некоторые оптимизации, основанные на схеме прямой переадресации трафика через TCPCopy.

Во-первых, между TCPCopy и тестируемой службой для пересылки данных вводится дополнительный семиуровневый прокси. Сам семиуровневый прокси-сервер может проверить целостность запроса, чтобы избежать перенаправления неполного запроса в тестовую службу, чтобы помешать тесту помех.

Кроме того, мы развертываем семиуровневый прокси и компонент перехвата TCPCopy на группе серверов, предназначенных для переадресации трафика, при выполнении задач переадресации нам нужно только изменить iptables этой партии серверов и только тестируемого сервиса. должен нормально работать на тестовой машине.Требуется дополнительная настройка, поэтому можно максимально избежать риска модификации iptables.

Чтобы лучше интегрироваться в технологическую экосистему компании и поддерживать более богатые сценарии тестирования, мы также специально внедрили семиуровневый агент для тестирования. В частности, были добавлены следующие возможности:

• Имея доступ к платформе обнаружения сервисов компании, тестируемому экземпляру нужно только зарегистрировать указанное имя сервиса, чтобы получать трафик, отправляемый прокси-сервером. Таким образом, трафик можно перенаправлять на несколько тестируемых экземпляров одновременно, а тестируемые экземпляры можно динамически добавлять или удалять.
• Поддерживается фильтрация трафика. Отфильтровать трафик указанного метода из полученного трафика и перенаправить его. Например, трафик, содержащий операции записи в трафике пересылки, можно отфильтровать, чтобы избежать загрязнения хранилища.
• Внедрить механизм управления потоком. Поддерживает ограничение скорости пересылаемого трафика, а давление достигается за счет многократной отправки полученных запросов, что поддерживает простые сценарии стресс-тестирования.

Наконец, чтобы упростить использование функции отвода трафика, мы инкапсулировали два компонента TCPCopy и наш семиуровневый прокси-сервер и упаковали их в платформу для пользователей. Пользователям нужно только указать IP и порт источника трафика и тестируемой услуги, а также продолжительность задачи перенаправления трафика, после чего может быть выполнен тест перенаправления трафика.

Общая архитектура сети примерно такая, как показано на рисунке ниже.После того, как пользователь отправит задачу, мы будем нести ответственность за планирование, настройку и развертывание каждого компонента, а также перенаправим трафик из сети на экземпляр пользователя. проверено.

2.5 Существующие проблемы

С постепенным увеличением масштаба и введением большего количества пользовательских сценариев эта архитектура постепенно выявила некоторые проблемы.

2.5.1 TCPCopy имеет проблемы с производительностью

TCPCopy не предназначен для реализации многопоточности, поэтому фактическая пропускная способность пересылки относительно ограничена, и он не может поддерживать некоторые сценарии тестирования с высокой пропускной способностью.

2.5.2 Существующая реализация не может поддерживать больше сценариев, таких как запись ответа

Позиционирование TCPCopy — это только инструмент переадресации копии запроса, будет скопирована только часть запроса онлайн-трафика, но ответ онлайн-трафика не будет скопирован. Мы получили несколько запросов от пользователей, которые хотят анализировать онлайн-трафик. Они хотят одновременно собирать запросы и ответы онлайн-трафика. TCPCopy не поддерживает такие сценарии.

3. ByteCopy собственной разработки, обеспечивающий поддержку большого трафика и сложных бизнес-сценариев.

Как упоминалось выше, в системе отвода трафика первого поколения есть некоторые проблемы с производительностью и гибкостью.В то же время бизнес также выдвинул некоторые новые требования, такие как поддержка протокола MySQL, а также поддержка хранения и воспроизведения исторических данных. движение. Учитывая, что существующую архитектуру TCPCopy сложно расширить, мы рассматриваем возможность отказа от существующей архитектуры и перестройки системы ByteDrainage нового поколения — ByteCopy (что означает копирование каждого байта в строке).

На основе описанной выше эволюции мы можем грубо разделить семиуровневую репликацию трафика на следующие три модуля в соответствии с обязанностями.

• Сбор трафика
• Анализ трафика
• Приложение трафика

Мы представим 3 модуля отдельно

3.1 Сбор трафика

Модуль сбора трафика будет подтягиваться по-разному в зависимости от платформы, на которой развернут сервис, например, в Kubernetes он будет вызываться Mesh Agent, использовать libpcap для мониторинга трафика на конкретном порту, реорганизовать пакеты уровня TCP. в пользовательском режиме и отправлять пакеты в Kafka.

По умолчанию модуль сбора трафика будет захватывать пакеты только на тех IP-адресах и портах, которые отслеживаются собираемыми службами. Кроме того, чтобы обеспечить возможность сбора исходящего трафика (то есть сбора вызовов, сделанных службой к ее нижестоящим зависимостям), модуль сбора трафика также подключается к инфраструктуре обнаружения служб компании. Когда необходимо собрать исходящий трафик, модуль сбора трафика запросит IP-адреса и порты всех экземпляров нижестоящей зависимой службы, а также соберет эту часть трафика. (Есть определенные проблемы с этой схемой, которые будут подробно представлены позже)

Поскольку процесс сбора трафика и процесс приложения развертываются в одном и том же экземпляре Docker или на физическом компьютере, бизнес чувствителен к использованию ресурсов модуля сбора трафика.Помимо оптимизации уровня кода, мы также используем контрольные группы для наложения жестких ограничений. по использованию ресурсов.

Кроме того, платформа сбора трафика является многопользовательской. Для службы может одновременно существовать несколько пользователей с разными требованиями к сбору. Например, пользователь А хочет собирать 5 % трафика экземпляра в среде env1. , а пользователь Б хочет собрать трафик одного инстанса в окружении env1 и env2.Для трафика 1 инстанса окружения, если запросы пользователей А и Б просто обрабатывать независимо друг от друга, будет избыточное развертывание env1 развертывание среды 5% + 1 экземпляр развертывание env2 1 экземпляр. Наш подход заключается в том, чтобы отделить спецификацию запроса пользователя от фактического развертывания модуля сбора данных.После того как пользователь отправит запрос спецификации, он будет объединен с существующей спецификацией для получения минимального решения для развертывания, а затем будет обновлен статус развертывания.

3.2 Анализ трафика

Исходный трафик, собранный источником трафика, по-прежнему является протоколом четвертого уровня.Для поддержки некоторых более сложных функций, таких как фильтрация, множественный вывод, хранение истории трафика, запрос трафика и визуализация трафика и т. д., нам необходимо проанализировать четыре трафик слоя к седьмому слою. Протоколы, которые чаще всего используются внутренними службами ByteDance, — это Thrift и HTTP, которые хорошо анализируются в соответствии со спецификациями протокола.

Одной из трудностей при анализе трафика является оценка границы трафика.В отличие от мультиплексной формы передачи конвейерного соединения, такие как HTTP/2, Thrift и HTTP/1.X, передаются строго в соответствии с парой запрос-ответ на одно соединение, поэтому их можно передавать через переключатель запроса и ответа, чтобы отделить полный трафик запроса или ответа.

3.3 Приложение для трафика

Что касается трафика, собранного в Интернете, у разных пользователей разные бизнес-цели. Например, платформа тестирования давления может сначала захотеть сохранить трафик на Kafka, а затем использовать высокую пропускную способность Kafka для создания давления; некоторые студенты R&D просто цитируют копию из Интернет Трафик направляется в их собственную среду разработки для тестирования новых функций; некоторые учащиеся надеются, что количество пересылаемых запросов в секунду может достичь определенного уровня воды для достижения цели стресс-тестирования; определенный трафик вызовет онлайн-дамп ядра, и они надеются записать этот трафик для оффлайн отладки и т.д. Подождите. Для разных сценариев мы реализовали несколько форм вывода трафика.

Далее мы сосредоточимся на пересылке и хранении.

3.3.1 Пересылка

Структура показана выше, эмиттер регистрируется в zookeeper, планировщик получает информацию об узле эмиттера, фильтрует/оценивает задачи в соответствии с метками и статистикой каждого узла эмиттера, а затем назначает их наиболее подходящему узлу. Вопрос здесь в том, почему бы напрямую не использовать сервисы без сохранения состояния, которые одинаково пересылаются каждым экземпляром эмиттера, и использовать схему сегментирования, в основном исходя из следующих соображений:

1. Если каждая задача равномерно выполняется на всех инстансах, то каждый инстанс должен устанавливать соединение со всеми нижестоящими конечными точками, а потребление ресурсов, таких как горутина, соединение, память и т.д., при массивных задачах неприемлемо.

2. За счет сведения обработки одной задачи к нескольким экземплярам плотность запросов для одной конечной точки увеличивается, чтобы избежать закрытия одноранговым узлом из-за слишком длительного времени простоя соединения, и соединение используется повторно.

Поскольку эмиттер более чувствителен к производительности, мы также сделали много оптимизаций для него, например, использовали пул горутин fasthttp, чтобы избежать частого применения горутин, объединяя в пул подключенные объекты чтения/записи и динамически настраивая количество рабочих потоков. для каждой конечной точки для адаптации Пользователи указывают QPS, чтобы избежать ненужной траты горутин и простоя длинных соединений, вырождающихся в короткие соединения.Весь процесс не блокируется, а синхронизация потоков и передача данных выполняются через канал + выбор.

3.3.2 Хранение

Хранилище разделено на два уровня, уровень данных и уровень индекса.Принята модель двойной записи, и есть временные задачи для исправления ошибок на уровне данных и уровне индекса, чтобы обеспечить окончательную согласованность двух. Хранилище должно поддерживать как воспроизведение, так и семантику запросов. Уровень данных абстрагируется в модель хранения, которая поддерживает запросы KV, упорядоченные по ключу, и модель хранения большой емкости. удовлетворены этими двумя уровнями: запрос трафика + требования к воспроизведению. Таким образом, базовая реализация уровня данных и индексного уровня является модульной и должна только соответствовать вышеуказанным моделям и реализовывать API определения модели.

Идеальной структурой данных уровня данных является LSM-дерево, которое обладает отличной производительностью записи.Для сценариев воспроизведения трафика записи трафика необходимо сканировать в порядке по ключу, поскольку LSM удовлетворяет локальности и порядку по ключу и может в полной мере использовать кэш страниц. и порядок дисков.Прочитайте, чтобы добиться высокой производительности воспроизведения. Относительно зрелым продуктом с открытым исходным кодом в индустрии распределенных LSM-деревьев является HBase, а у ByteDance также есть эталонный продукт Bytable. Мы одновременно внедрили уровень данных на основе этих двух движков. После серии тестов производительности мы выбрали Bytable. как реализация уровня данных.

Индексный уровень использует возможности ES, поэтому он может поддерживать составной условный запрос пользователя.Мы заранее создадим некоторые индексы запросов, такие как исходная служба, целевая служба, имя метода, трассировка и т. д. Один из текущих сценариев использования запрос трафика является макетом службы. Он может блокировать ненужные внешние зависимости в функциональных тестах или различиях. Еще одна функция — визуализация трафика. Пользователи могут просматривать содержимое конкретных запросов через время запроса, трассировку и т. д. Другие функции сцены еще предстоит изучить.

3.4 Поддержка бизнес-сценариев

3.4.1 Поддержка общих возможностей сравнения

Верификация Diff — это мощный инструмент для интернет-компаний, позволяющий поддерживать качество продукта при быстрой итерации.Подобно проекту Twtiter Diffy, это достигается за счет записи и воспроизведения онлайн-трафика. Однако его применимые сценарии также очень ограничены, поскольку он воспроизводится непосредственно в производственной среде через среду AB и не может поддерживать трафик записи. Хотя платформа Alibaba doom может решить проблему изоляции воспроизведения при написании сценариев, она реализована через АОП в приложении и тесно связана с экосистемой Java.

Благодаря возможностям ненавязчивого слива, хранения и воспроизведения трафика ByteCopy в сочетании с нашим самостоятельно разработанным компонентом ByteMock мы предоставляем ориентированное на бизнес ненавязчивое решение для сравнения и решаем проблему изоляции записи.

В канале (A, B, C) в производственной среде сбор каждого перехода (запроса, ответа) осуществляется через ByteCopy. При выполнении проверки различий A запрос на обслуживание для A реализуется через ByteCopy. В то же время макет для службы B реализован на основе ByteMock, и поддерживается воспроизведение ответа для трассировки (для достижения точного воспроизведения используется хранилище трафика в ByteCopy). Поскольку B имитируется, даже запрос на запись может быть выполнен без какого-либо воздействия на строку.

4. Перспективы будущего

4.1 Более точный сбор трафика

Как упоминалось ранее, при сборе исходящего трафика будут захвачены IP:Port всех экземпляров, которые зависят от нижестоящих служб. В реальной производственной среде на одном сервере может быть развернуто несколько сервисов с одинаковыми нисходящими зависимостями, полагающимися только на четыре уровня данных, и невозможно определить, из какого сервиса поступают захваченные данные, что приведет к захвату пакетов, обработка и пересылка.В этом процессе всегда происходит растрата ресурсов. В настоящее время решение, основанное на перехвате пакетов сетевой карты, не должно хорошо решать эту проблему.Мы также пытаемся изучить некоторые другие решения по сбору трафика, такие как изучение использования ebpf для сбора трафика на уровне процессов.

4.2 Новое определение системы воспроизведения дренажа

На данном этапе наша система воспроизведения слива только пассивно собирает трафик в соответствии с пользовательской конфигурацией.Чтобы вовремя получить трафик для тестирования, пользователи обычно выбирают для тестирования слив в реальном времени. На самом деле, не во всех сценариях обязательно нужен трафик в реальном времени для тестирования, мы планируем постепенно трансформировать систему отвода и воспроизведения трафика из инструмента, который выполняет пересылку и воспроизведение трафика в соответствии с требованиями пользователя, в платформу для доступа к онлайн-копированию трафика.

Основываясь на емкости хранилища трафика, для услуг с тестовыми требованиями платформа активно распределяет пик и регулярно инициирует задачи записи трафика, чтобы поддерживать постоянно обновляемый пул трафика.Когда пользователям нужен трафик, они могут напрямую использовать его из Пул трафика Таким образом, можно не только избежать вытеснения вычислительных ресурсов парами операций перенаправления трафика и онлайн-сервисами, но и повысить доступность трафика.

4.3 Оптимизация хранения трафика в конкретных сценариях

С улучшением приложений верхнего уровня, основанных на записи и воспроизведении трафика, мы рассматриваем эволюцию в сторону нормализованного оттока трафика для удобства доступа и пробного использования большего количества услуг. Это обязательно вызовет новые проблемы для нашего хранилища трафика, будь то масштаб данных, форма хранения и производительность запросов. Мы надеемся, что сможем построить решение для хранения трафика на основе системы хранения существующей архитектуры, которая сможет поддерживать различные сложные высокопроизводительные методы запросов, такие как проверка точек (на основе TraceId) и сканирование временного диапазона, при этом поддерживая массивные данные. пропускная способность. Кроме того, мы также активно сотрудничаем с командой безопасности, чтобы гарантировать, что соответствующие основные данные трафика могут быть десенсибилизированы при хранении, и в то же время мы постоянно усиливаем аудит безопасности использования хранилища трафика.

5. Резюме

На сегодняшний день система ByteCopy поддерживает различные потребности в отводе трафика для большинства бизнес-направлений Byte в различных сценариях. Мы прилагаем все усилия, чтобы обогатить функциональные сценарии ByteCopy и постоянно улучшать стабильность системы и пропускную способность. Кроме того, мы также активно Создавайте самостоятельно разработанные компоненты для исследований и разработок, такие как ByteMock, и, формируя комбинацию с ByteCopy, открывайте больше сценариев использования производственного трафика в деятельности по исследованиям и разработкам и помогайте бизнес-группам лучше создавать различные интересные продукты.

поделиться больше

Транзакции в магазине таблиц ByteDance

Расшифровка iOS: таинственный и таинственный KVO

Сегодняшний заголовок Оптимизация скорости компиляции Android «второго уровня»

Эволюция системы хранения распределенных таблиц ByteDance

Команда инфраструктуры ByteDance

Команда инфраструктуры ByteDance — это важная команда, которая поддерживает бесперебойную работу множества пользовательских продуктов ByteDance, включая Douyin, Today's Toutiao, Xigua Video и Volcano Small Video.Стабильная разработка обеспечивает гарантию и импульс.

В компании команда инфраструктуры в основном отвечает за построение частного облака ByteDance, управление кластерами из десятков тысяч серверов и отвечает за десятки тысяч гибридных развертываний вычислений/хранилищ и гибридных развертываний онлайн/офлайн, поддерживая стабильное хранилище. нескольких массивных данных ЭП.

В культурном плане команда активно использует открытый исходный код и инновационные аппаратные и программные архитектуры. Мы давно набираем студентов по направлению инфраструктура.Подробности смотрите на job.bytedance.com ("Читать исходный текст" в конце статьи).Если вам интересно, вы можете обратиться к своему адрес электронной почты.guoxinyu.0372@bytedance.com.