Интеграция корпоративных систем через событийную архитектуру (Kafka)
Крупная организация редко работает в одной системе. ERP, CRM, биллинг, складской учёт, кадры, портал госуслуг – каждый контур живёт своей жизнью, и все они должны обмениваться данными. Классический подход – точечные интеграции «каждый с каждым» через REST или файловый обмен. Число связей растёт квадратично, любое изменение в одной системе ломает цепочку, а сбой получателя останавливает отправителя. Событийная архитектура снимает эти проблемы: системы не вызывают друг друга напрямую, а публикуют события в общую шину. Apache Kafka – рабочий инструмент для такой шины в нагруженных корпоративных контурах.
Почему события, а не вызовы
В синхронной интеграции отправитель ждёт ответа получателя. Если получатель недоступен или медленный, проблема распространяется по всей цепочке. В событийной модели система фиксирует факт – «заказ создан», «платёж проведён», «договор подписан» и публикует его в Kafka. Дальше событие читают все, кому оно нужно: один сервис обновит склад, второй отправит уведомление, третий запишет проводку в учёт. Отправитель ничего не знает о потребителях и не зависит от их доступности.
Это даёт слабую связность. Новый потребитель подключается к существующему топику без изменений на стороне источника. Kafka хранит события в логе с заданным сроком удержания, поэтому потребитель, который был в простое или только что развернут, дочитывает историю с нужной позиции. Для госсектора важен ещё один эффект: лог событий – это естественный аудитируемый след всех изменений, который не нужно собирать отдельно.
Где Kafka даёт результат
Kafka разворачивается на собственной инфраструктуре, работает в закрытом контуре и не тянет за собой зависимость от внешних облаков – это совпадает с требованиями к импортозамещению прикладного ПО и хранению данных внутри периметра. Кластер из трёх и более брокеров с репликацией переживает отказ узла без потери сообщений.
Несколько сценариев, где событийная шина оправдывает себя:
- Синхронизация справочников и мастер-данных между десятком систем – единый источник публикует изменения, остальные подписываются.
- Разнесение пиковой нагрузки – Kafka принимает всплеск событий и отдаёт их потребителям в комфортном для них темпе, без отказов на стороне приёма.
- Подача данных в аналитику и ML – те же события из продуктивного контура питают платформу MLOps без отдельных выгрузок и ночных ETL-окон.
При этом Kafka – не серебряная пуля. Транзакции «всё или ничего» между системами она не заменяет: согласованность здесь конечная, и приложения должны проектироваться под идемпотентную обработку и повторную доставку. Это требует дисциплины в схемах событий и версионировании – для этого используют реестр схем и обратносовместимые контракты.
Что учесть на старте
Событийная шина становится критичным узлом: через неё идёт обмен всей организации. Поэтому она требует того же уровня надёжности, что и базы данных, – мониторинга лагов потребителей, ёмкости дисков под лог и проработанного плана резервного копирования и восстановления для кластера и его метаданных. Схемы событий стоит фиксировать с первого дня: переименование поля без версии контракта тихо ломает потребителей.
Каждый из этих шагов – от выбора топологии топиков до эксплуатации кластера в закрытом контуре – определяется конкретным ландшафтом заказчика, и собирается всё это в рамках интеграции корпоративных систем под этот ландшафт.
Вывод
Событийная архитектура на Kafka заменяет хрупкую сеть прямых вызовов устойчивой шиной с слабой связностью, аудируемым логом и предсказуемым поведением под нагрузкой. Это не отменяет требований к надёжности и дисциплине схем – но даёт интеграции запас прочности, которого точечные связи не обеспечивают.
