Привет, Хабр! Меня зовут Александр Бардаш. Я CTO в MWS Octapi — это интеграционная платформа МТС Web Services, которая объединяет все возможные способы взаимодействия между системами в экосистеме компании. В ней используется подход Event Mesh — технология, которая позволяет обрабатывать данные в реальном времени и обеспечивает безопасность, производительность и управляемость. Сегодня предлагаю посмотреть, как все это работает.
Этот текст — переработка моего доклада с HighLoad++. Устраивайтесь поудобнее, читайте и задавайте вопросы в комментариях, на все постараюсь ответить.
Архитектура Octapi: два мира — design-time и run-time
Посмотрите на иллюстрацию выше — и давайте разбираться, что тут происходит. Смотрим сверху вниз.
Этап подготовки: Design-Time
В режиме design-time (этап разработки) происходит подготовка всех процессов интеграции. Это начальный этап, где формируются основы для работы системы: от подхода API First (интеграция начинается с создания API) до доставки данных в изолированные контуры (отдельные зоны, где данные обрабатываются безопасно).
В этом этапе участвуют клиенты и пользователи, которые взаимодействуют через API-сервер. Но это не просто API — это полноценный слой, на котором строится интерфейс GUI (графический интерфейс пользователя).
GUI как DiscoveryPortal
GUI — это единый каталог интеграций, на схеме он называется DiscoveryPortal. Тут собраны все интеграции внутри экосистемы. Они могут находиться:
на федеративном уровне — общедоступные интеграции;
в изоляции — например, в On-Prem-среде (локальных системах).
Для поиска нужных интеграций используется поисковый движок, который работает на основе ИИ. Он анализирует спецификации (то же самое, что описание интеграций) и помогает быстро находить нужные решения.
В DiscoveryPortal также встроены Permission Engine — система управления правами доступа, Low-code UI — интерфейс с минимальным кодом для упрощенной настройки.
Чтобы было понятнее, давайте в качестве примера возьмем бытовую ситуацию. Представьте, что ищете товар в огромном магазине. DiscoveryPortal — это как каталог товаров, где можно найти все: от общедоступных товаров, которые размещаются на полках в центре, до скрытых, которые лежат в закрытых залах. Тогда поисковый движок — это как ассистент, который знает, где находится товар, даже если он скрыт. Permission Engine будет доступом к определенным зонам магазина — например, к закрытым залам с товаром для бизнеса.
Control Plane: зона доставки информации
Следующий блок — Control Plane, или контрольная плоскость. Это зона, отвечающая за доставку информации. Здесь реализованы согласованные процессы:
Government Deploy — развертывание систем в соответствии с регламентами;
подготовка данных;
передача данных в обособленный контур — изолированную зону.
Тут тоже нужна аналогия из жизни. Control Plane — это как логистика доставки посылок. Допустим, вы заказываете товар в интернет-магазине, и он должен быть доставлен в ваш дом. Government Deploy — это подготовка посылки (проверка документов, упаковка), а передача данных — отправка посылки в нужное место. Если посылка должна попасть в другую страну, она проходит через изолированную зону (например, таможню).
Data Plane: изолированные интеграции
Последняя зона — Data Plane, или данные. Здесь «крутятся» различные изолированные интеграции, которые взаимодействуют между собой: OpenAPI, GraphQL, Service Mesh, Event Mesh (о нем мы и поговорим сегодня), Low Code и другие технологии.
Еще в этой зоне есть:
модуль трафик-аккаунта (управление сетевым трафиком);
observability (мониторинг работы системы);
DevOps-инструменты (автоматизация разработки и управления);
выход в интернет;
компоненты безопасности: WAF (система фильтрации веб-трафика), антибот (защита от автоматизированных атак), анти-DDoS (защита от распределенных атак).
Давайте тоже к аналогии. Пусть Data Plane будет многоуровневой сетью доставки, где каждый уровень отвечает за определенную задачу. Тогда Event Mesh — это система уведомлений, которая отправляет уведомления о новых посылках в разных зонах. WAF — это дополнительный контроль на границе, который проверяет, что в посылке нет опасных предметов. А DevOps-инструменты — автоматизированные линии сборки, которые ускоряют процесс доставки и минимизируют ошибки.
С архитектурой, надеюсь, более-менее понятно. Теперь давайте смотреть, как работает Event Mesh.
Что такое Event Mesh
Интеграции бывают разные — по уровням абстракции, зрелости и реализации. В одном месте могут использовать современные API, в другом — 15-летнюю IBM-шину, в третьем — асинхронную очередь на Kafka. Получается, ландшафт может быть очень разнородным, и командам нужно в нем взаимодействовать.
И тут ключевая задача — дать командам возможность интегрироваться быстро и просто. Конечно, под каждую интеграцию можно написать микросервис, но для этого нужны ресурсы, плюс это приведет к перекладыванию ответственности. Чтобы этого избежать, мы и решили внедрить Event Mesh — универсальную прослойку, способную работать с любыми источниками и потребителями данных.
Бизнес-сценарии
Event Mesh — это решение для объединения сложной филиальной организации:
минимизация влияния систем друг на друга;
обмен данными между разными ДЗО, филиалами организации с абсолютно разным техстеком, форматом данных;
асинхронные и событийные взаимодействия с возможностью валидации, формированием DLQ, трансформинга данных.
Как работает Event Mesh
Тут можно выделить четыре основных шага. Сначала опишу их верхнеуровнево, а потом посмотрим все то же самое с технической стороны и с точки зрения пользователя.
Шаг 1. Получение данных. Сначала мы получаем информацию из разных источников — RabbitMQ, Kafka, база данных, очередь Microsoft или IBM.
Уже на этом этапе мы можем разбить данные на потоки по JSON-схеме или AsyncAPI-спецификации, провалидировать данные, сформировать несколько потоков и разграничить их по capability.
Шаг 2. Преобразование в стандартный формат. Данные отправляются в инструмент, который превращает их в единый, понятный формат — например, JSON или XML. Это важно, чтобы они выглядели одинаково и были готовы к дальнейшей обработке.
Шаг 3. Отправка в Kafka. После преобразования данные отправляются в промежуточный буфер — Kafka. Это как временная «площадка», где данные ждут, пока их получат нужные сервисы или системы.
Данные в Kafka разделяются на изолированные потоки — например, по типу или региону. В этих потоках есть DLQ (Dead Letter Queue) — это «бункер» для неправильных или необработанных данных, чтобы они не терялись.
Kafka обеспечивает надежную доставку, даже если в процессе возникнут какие-то проблемы. Это как если бы вы отправили письмо в почтовый ящик — оно не исчезнет, пока не будет прочитано получателем.
Шаг 4. Фильтрация и трансформация. На этом этапе потребитель применяет фильтрацию — например, выбирает только данные с определенным атрибутом. Допустим, это может быть регион. Здесь же он применяет трансформацию, например переводит данные в нужный формат. Это как если бы вы сортировали письма по теме и переводили их на нужный язык.
Результат — отфильтрованные данные. На выходе получается только нужная информация, отфильтрованная по заданному критерию. Например, из потока с данными по региону вы получите только те, где атрибут IMSID соответствует определенному региону.
Посмотрим на то же самое с технической стороны
Итак, система начинает работать с манифеста — это как инструкция в виде файла, где описаны параметры потока данных. Например, где взять данные, как их обработать, куда отправить. Манифест отправляется в платформу Event Mesh.
После получения манифеста платформа запускает настроенный адаптер — это специальный модуль, который реализует логику обработки данных. Например, фильтрация, преобразование, отправка в нужное место.
Rate limits (лимиты на количество запросов) позволяют решить несколько важных задач, в том числе управление «шумным соседом». Если другие сервисы по ошибке посылают ненужный трафик, мы настраиваем лимиты на количество запросов, чтобы не перегружать систему.
Вся логика обработки данных записана в манифесте, поэтому интеграции легко настраивать и проверять.
Пользовательский путь
Давайте разбираться, что мы видим на этом слайде.
1. Формирование манифеста
Клиент заходит в Discovery Portal (платформу управления потоками данных) и через интерфейс (UI) создает манифест — это как «инструкция», которая описывает, какие данные нужно собирать, как их обрабатывать и куда отправлять. Например, можно указать: «Собирать данные из системы A, фильтровать по региону и отправлять в систему B».
2. Преобразование манифеста
Полученный манифест отправляется в Provisioner — это инструмент, который превращает его в технический манифест, понятный для Apache Flink — системы, которая выполняет обработку данных. Теперь манифест готов к запуску.
3. Хранение и управление в GitLab
Манифест сохраняется в GitLab — это как общий «склад» с файлами, где можно хранить и управлять инструкциями. Все данные в GitLab изолированы, чтобы защитить их от случайного доступа.
4. Доставка в Kubernetes через ArgoCD
Затем манифест попадает в ArgoCD — это система, которая автоматически доставляет файлы (в нашем случае манифест) в Kubernetes — платформу для запуска приложений. Важно: Kubernetes находится в отдельном сетевом контуре (Data Plane), чтобы избежать утечек данных.
Почему у нас два сетевых контура?
На слайде выше видно, что у нас как будто две разные зоны:
Control Plane — это как «контрольная зона», где живут настройки и управления;
Data Plane как «рабочая зона», где обрабатываются данные.
Персональные данные или банковская информация не могут быть в «рабочей зоне» без проверок — это слишком опасно. Поэтому взаимодействие происходит через GitLab. Так мы можем изолировать данные и убедиться, что они не попадают в неподходящие места.
До того как манифест попадет в Kubernetes, он проходит через pipeline — цепочку проверок:
валидация безопасниками — специалисты по ИБ проверяют, соответствует ли манифест требованиям;
пентесты — тестирование на уязвимости;
SAST-сканирование — анализ кода на наличие ошибок;
ручной апрув — финальная проверка от ответственных лиц.
Только после этого манифест попадает в Kubernetes и запускает интеграцию в Data Plane.
Доступ есть, контроль — строгий
Доступ к Git есть, но интеграция не включается автоматически. Все шаги требуют обязательной валидации, чтобы исключить ошибки и угрозы. Это как в лаборатории: перед выпуском продукта он проходит проверки, и только после них можно использовать его в реальных условиях.
Что ж, давайте пример из жизни. Представьте, что вы хотите отправить письма в почтовый ящик, но в нем есть зона для конфиденциальной почты. Вы формируете инструкцию (манифест) через интерфейс. Инструкция попадает в «склад» (GitLab), где ее проверяют на ошибки. Только после одобрения она отправляется в «рабочую зону» (Kubernetes), где письма обрабатываются.
Если в инструкции есть утечки данных, она не попадает в рабочую зону.
Безопасность подключения в Event Mesh
Авторизация и аутентификация
Event Mesh поддерживает современные методы аутентификации:
OAuth 2.0 — для управления доступом к ресурсам;
SASL — для безопасного взаимодействия между сервисами;
mTLS (mutual TLS) — для шифрования и проверки идентичности сторон.
Это обеспечивает защиту данных на всех этапах передачи.
Хранение секретов и сертификатов
Secrets (пароли, ключи) и сертификаты хранятся в HashiCorp Vault — централизованном хранилище, где данные защищены от несанкционированного доступа. Secrets-менеджер доставляет эти секреты в Kubernetes — это обеспечивает безопасное и автоматизированное распределение.
Ротация и перевыпуск
Секреты ротируются (переустанавливаются) регулярно, чтобы минимизировать риски утечки. Сертификаты перевыпускаются, чтобы избежать истечения их срока действия или уязвимостей. Это гарантирует, что данные защищены даже при смене ключей или устаревании сертификатов.
Автоматическое обновление ядром платформы
Ядро платформы Octapi (основная часть системы) перечитывает секреты и сертификаты при каждом запуске или при сбое интеграции. Например, если сервер изменяет пароль или происходит нарушение, допустим, утечка данных, ядро автоматически обновляет секреты, не требуя ручного вмешательства.
Нет локального хранения — только безопасность
Все данные хранятся в Vault и доставляются в Kubernetes, а не локально. Это исключает риски утечки секретов и соответствует требованиям безопасности. В результате система работает так, чтобы никакая информация не оставалась незащищенной.
Давайте и тут пример — сегодня их получилось много! Представьте, что вы хотите отправить письмо в банковский сейф, но доступ к нему строго контролируется. Вы формируете «ключ» (секрет) через безопасный интерфейс. Этот ключ хранится в «банковском сейфе» (Vault), а не на вашем компьютере. Когда вы готовы отправить письмо, система автоматически доставляет ключ в нужное место (Kubernetes), шифрует его и проверяет безопасность.
Если ключ устарел или изменился, система автоматически обновляет его, не требуя вашего вмешательства.
Маршрутизация
Платформа поддерживает Content-Based Routing (CBR) — маршрутизацию по содержимому сообщений. Мы можем разбивать потоки по JSON- или XML-схемам — это позволяет на лету разносить данные по разным потокам.
На этот раз — кейс из рабочих будней. Одна команда не умела забирать сообщения из Kafka, другая могла только класть их туда. За три минуты мы составили манифест, забрали нужные сообщения из Kafka, отфильтровали по метаданным и передали через REST. То, что не получалось месяцы, у нас заработало за минуты.
Как работает масштабируемость и производительность платформы
Платформа работает в Kubernetes и масштабируется линейно и горизонтально. Это значит, что вы можете добавлять новые узлы (виртуальные машины или контейнеры) по мере роста нагрузки, а не увеличивать ресурсы одного узла.
Используя Apache Flink, мы знаем кейсы обработки до 1 миллиарда сообщений в секунду в реальных сценариях. Но мы остановились на 300 тыс. RPS (запросов в секунду) — этого достаточно для большинства задач. Теперь нам не нужно перегружать систему избыточными ресурсами.
Горизонтальное масштабирование компонентов
Task Manager — это основной компонент Flink, отвечающий за обработку данных. Он масштабируется горизонтально, так что можно распределять нагрузку между множественными узлами. Еще он обеспечивает быструю связь между компонентами — это позволяет минимизировать задержки и улучшать производительность при обработке больших объемов данных.
GSLB (Global Server Load Balancing) обеспечивает балансировку нагрузки между ЦОДами (дата-центрами). Так мы можем распределять трафик и избегать перегрузки отдельных узлов.
Rate limit (лимит на скорость) работает распределенно, то есть не привязан к одному узлу. Это повышает отказоустойчивость и позволяет системе адаптироваться к колебаниям нагрузки.
Доработки Apache Flink включают усиленные настройки безопасности (например, шифрование, аутентификация) и валидаторы, которые проверяют данные перед обработкой. Эти изменения обеспечивают устойчивость системы и защиту от аномалий, таких как неправильные данные или атаки.
Все компоненты — Task Manager, GSLB, rate limit, Flink — работают автоматически, без необходимости вмешательства пользователя. Это позволяет реализовывать масштабные сценарии, например обработку миллионов сообщений в секунду, без ручного управления ресурсами или настройки.
Приведу пример. Представьте, что управляете транспортной системой, где каждый автобус (узел) может перевозить определенное количество пассажиров. При увеличении пассажиропотока вы добавляете больше автобусов — это горизонтальное масштабирование. Система автоматически распределяет пассажиров между автобусами (GSLB) и устанавливает лимит на количество пассажиров в каждом автобусе (rate limit). Если автобус сбивается, система перераспределяет пассажиров на другие автобусы — автоматическая перезагрузка.
Все это работает без вашего вмешательства — система сама адаптируется к изменяющимся условиям.
Генерируем манифесты с AI-ассистентом
Чтобы упростить генерацию манифестов, мы сделали AI-ассистента. Он может собрать поток данных по задаче: получить сообщения из Kafka, трансформировать в XML, отправить JSON по REST. Ассистент сам уточняет детали: bootstrap-сервер, авторизацию и так далее. Даже если клиент не знает терминов — не страшно. Ассистент подскажет.
Он ведет пользователя, предлагает схему, показывает интерфейс. Бизнес-аналитик может сказать: «Хочу получать балансы и отправлять их в продукт», — AI найдет подходящие API, поймет, что нужно, даже если слово «баланс» не указано явно, и предложит нужный поток. Выбирается точка отправки, атрибут — готово!
AI-ассистент предоставляет ссылки на документацию, подгружает актуальные данные, генерирует примеры манифестов и поддерживает диалог, помогая тем, кто не знаком с техническими терминами.
Система «дружит» с AsyncApi-спецификациями, работает с ключевыми словами, анализирует информацию.
Мы двигаемся к тому, чтобы ассистент умел «общаться» с другими агентами, подгружал актуальные данные, не просто показывал документацию, а давал готовые примеры. В перспективе планируем реализовать взаимодействие между агентами, чтобы автоматизировать еще больше процессов создания интеграций.
Что дальше
Сейчас мы продолжаем развивать платформу: хотим сделать ее доступной не только для системных, но и для бизнес-аналитиков. Уже сейчас пилотные внедрения АИ-ассистентов показывают, что наши гипотезы работают. Пользователи довольны. Впереди — расширение возможностей AI, больше автоматизации, улучшения интерфейса и новые кейсы. Все для того, чтобы интеграции делались не за месяцы, а за минуты.
Если есть вопросы или комментарии по теме статьи — пишите, пообщаемся.