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

Cloudflare использует Kafka в производственной среде с 2014 года. С тех пор мы прошли долгий путь и в настоящее время используем 14 отдельных кластеров Kafka в нескольких центрах обработки данных с примерно 330 узлами. Между ними за последние восемь лет было обработано более триллиона сообщений.

Cloudflare использует Kafka для разделения микросервисов и отказоустойчивого сообщения о создании, изменении или удалении различных ресурсов через общий формат данных. Это разъединение является одним из многих факторов, позволяющих командам инженеров Cloudflare работать над несколькими функциями и продуктами одновременно.

Мы многое узнали о Kafka на пути к одному триллиону сообщений и создали несколько интересных внутренних инструментов для упрощения внедрения, которые будут рассмотрены в этой статье блога. В этом сообщении блога основное внимание уделяется только вариантам использования связи между приложениями, а не ведению журналов (у нас есть другие кластеры Kafka, которые обеспечивают работу информационных панелей, где клиенты просматривают статистику, обрабатывающую более одного триллиона сообщений). каждый день). Я работаю инженером в группе Application Services, и у нашей команды есть устав предоставлять инструменты/услуги группам разработчиков, чтобы они могли сосредоточиться на своей основной компетенции, которая приносит пользу нашим клиентам.

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

Инструменты

Один из наших кластеров Kafka творчески назван Messagebus. Это кластер наиболее общего назначения, который мы используем, и он был создан для:

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

Чтобы сделать его максимально простым в использовании и поощрить внедрение, команда Application Services создала два внутренних проекта. Первый невообразимо назван Messagebus-Client. Messagebus-Client — это библиотека Go, включающая в себя фантастическую библиотеку Shopify Sarama с продуманным набором параметров конфигурации и возможностью управлять ротацией сертификатов mTLS.

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

Один из таких примеров привел к перекосу разделов (большая часть сообщений направлялась в один раздел, что означало, что мы не обрабатывали сообщения в режиме реального времени; см. диаграмму ниже). Одним из недостатков Kafka является то, что вы можете иметь только одного потребителя на раздел, поэтому, когда происходят инциденты, вы не можете тривиально масштабировать свой путь к более высокой пропускной способности.

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

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

Соединители

Платформа соединителя основана на соединителях Kafka и позволяет нашим инженерам легко запускать службу, которая может считывать данные из системы записи и передавать ее куда-то еще (например, в Kafka или даже в собственный Quicksilver от Cloudflare). Чтобы сделать это как можно проще, мы используем шаблоны Cookiecutter, чтобы позволить инженерам ввести несколько параметров в CLI и взамен получить готовый к развертыванию сервис.

Мы предоставляем возможность настраивать конвейеры данных через переменные среды. Для простых случаев использования мы предоставляем функциональность из коробки. Однако расширить возможности чтения, записи и преобразования так же просто, как удовлетворить интерфейс и «зарегистрировать» новую запись.

Например, добавление переменных среды:

READER=kafka
TRANSFORMATIONS=topic_router:topic1,topic2|pf_edge
WRITER=quicksilver

будут:

Читать сообщения из топиков Kafka «topic1» и «topic2»;
Преобразуйте сообщение, используя функцию преобразования под названием «pf_edge», которая сопоставляет запрос из protobuf Kafka с запросом Quicksilver;
Напишите результат в Quicksilver.

Коннекторы поставляются с готовыми базовыми метриками и оповещениями, поэтому команды знают, что они могут быстро, но уверенно перейти к работе.

Ниже представлена диаграмма того, как одна команда использовала нашу структуру коннектора для чтения из кластера Messagebus и записи в различные другие системы. Это управляется системой, которую запускает команда Application Service, которая называется Communication Preferences Service (CPS). Всякий раз, когда пользователь разрешает/отключает маркетинговые электронные письма или меняет свои языковые настройки на cloudflare.com, он звонит в CPS, что обеспечивает отражение этих настроек во всех соответствующих системах.

Строгие схемы

Наряду с библиотекой Messagebus-Client мы также предоставляем репозиторий под названием Messagebus Schema. Это реестр схем для всех типов сообщений, которые будут отправляться через наш кластер Messagebus. Для формата сообщений мы используем protobuf и очень довольны этим решением. Ранее наша команда использовала JSON для некоторых наших схем kafka, но нам было гораздо сложнее обеспечить прямую и обратную совместимость, а также размеры сообщений были значительно больше, чем у эквивалента protobuf. Protobuf обеспечивает строгие схемы сообщений (включая безопасность типов), желаемую прямую и обратную совместимость, возможность генерировать код на нескольких языках, а также файлы, которые легко читаются человеком.

Мы поощряем обширные комментарии перед утверждением слияния. После слияния мы используем prototool для обнаружения критических изменений, соблюдения некоторых стилистических правил и генерации кода для различных языков (на момент написания это просто Go и Rust, но добавить больше несложно).

Пример сообщения Protobuf в нашей схеме

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

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

Наблюдаемость

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

Мы используем Salt для управления конфигурацией нашей инфраструктуры и следуем модели в стиле Gitops, где наш репозиторий содержит источник достоверной информации о состоянии нашей инфраструктуры. Чтобы добавить новую тему Kafka, наши инженеры делают запрос на включение в этот репозиторий и добавляют пару строк YAML. При слиянии будет создана тема и предупреждение о высокой задержке (где задержка определяется как разница во времени между последним считанным зафиксированным смещением и последним произведенным смещением). Другие оповещения могут (и должны) создаваться, но это остается на усмотрение прикладных групп. Причина, по которой мы автоматически генерируем оповещения о высокой задержке, заключается в том, что это простое оповещение является отличным прокси для обнаружения большого количества проблем, включая:

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

Для метрик мы используем Prometheus и отображаем их с помощью Grafana. Для каждой новой созданной темы мы автоматически предоставляем представление о скорости производства, скорости потребления и перекосе разделения по производителю/потребителю. Если вызвана команда инженеров, в предупреждающем сообщении будет ссылка на это представление Grafana.

В нашем Messagebus-Client мы автоматически предоставляем некоторые метрики, и пользователи получают возможность расширять их дальше. Метрики, которые мы предоставляем по умолчанию:

Для производителей:

Сообщения успешно доставлены.
Сообщение не доставлено.

Для потребителя:

Сообщения успешно обработаны.
Ошибки потребления сообщений.

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

Практический пример

Наряду с предоставлением платформы Messagebus команда Application Services ищет общие проблемы в рамках разработки и пытается решить их масштабируемым и расширяемым способом, что означает, что другие группы разработчиков могут использовать систему и не должны создавать свои собственные (таким образом, это означает, что мы не создавать множество разрозненных систем, которые лишь немного отличаются друг от друга).

Одним из примеров является система оповещения о тревоге (ANS). ANS — это серверная служба для вкладки «Уведомления» на панели инструментов Cloudflare. Возможно, вы заметили, что за последние 12 месяцев клиентам очень регулярно стали доступны новые типы предупреждений и политик. Это потому, что мы сделали это очень простым для других команд. Подход таков:

Создайте новую запись в конфигурации ANS YAML (мы используем язык CUE для проверки конфигурации в рамках нашего процесса непрерывной интеграции);
Импортируйте наш Messagebus-Client в свою кодовую базу;
Отправляйте сообщение в нашу тему оповещения, когда происходит интересующее вас событие.

Вот и все! У команды разработчиков теперь есть средства, с помощью которых клиенты могут настраивать детализированные политики оповещения для своих новых оповещений, включая возможность отправки их через Slack, Google Chat или настраиваемый веб-перехватчик, PagerDuty или по электронной почте (как с помощью API, так и с помощью панели инструментов). Для них управляются повторные попытки и недоставленные сообщения, и становится доступным целый ряд метрик, и все это путем внесения очень небольших изменений.

Что дальше?

Использование Kafka (и наших инструментов Messagebus) в Cloudflare будет только расти по мере того, как мы продолжаем расти, и как команда мы стремимся сделать инструменты для Messagebus простыми в использовании, настраиваемыми при необходимости и (возможно, самое главное) простыми в использовании. наблюдать. Мы регулярно получаем отзывы от других инженеров, чтобы помочь улучшить Messagebus-Client (сейчас у нас пятая версия), и в настоящее время экспериментируем с полным абстрагированием сложностей Kafka и предоставлением командам возможности использовать gRPC для потоковой передачи сообщений в Kafka. Сообщение в блоге об успехе/неуспехе этого следовать!

Если вы заинтересованы в создании масштабируемых сервисов и решении интересных технических задач, мы нанимаем инженеров в нашу команду в Остин и удаленные США.

Заказать сайт визитку

Использование Apache Kafka для обработки 1 триллиона межсервисных сообщений