Apache Kafka и ESB в архитектуре слабой связанности: как снизить издержки, гарантировать доставку и обеспечить чистоту данных в ИТ-системах крупного бизнеса

Внедрение брокера сообщений - частично уменьшает потерю данных но не исключает в некоторых сценариях!

Брокер это транспорт но не мозги - вся логика контроля и получения находится внутри связанных систем.

Но интеграции только через брокер не ГАРАНТИРУЮТ передачу если: если получатель не готов, формат не совпадает, логика не отработана, время хранения истекло или просто нет подтверждения приёма

Отдельно отмечу что брокер вообще ни имеет отношения к разбору причин ошибок или причины перегрузок в пиковые дни “черной пятницы”, есть у вас брокер или нет - часто такие ошибки или перегрузки приходят и их причина остается без понимания.

Снижается пиковая нагрузка на системы

Асинхрон - системы не должны быть постоянно в онлайне для общения ESB c Kafka в составе исключается потеря данных значительно снижается нагрузка на системы облегчается бизнес аналитика ( BI )

Слабая связанность через ESB c Kafka в составе можно менять системы по щелчку

Значительно сокращаются затраты на IT

Отчуждаемость - легко передать другой IT команде

Высокое качество данных = простая бизнес аналитика

ESB - это корпоративная сервисная шина.

Часто путают наличие брокера сообщений с ней.

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

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

По сути, ESB — это переводчик, который очень качественно передаёт суть без потери смысла и с учётом культурного контекста.

Системы — это «граждане» разных стран.

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

Более того, переводчик всегда помнит, всё к чему говорили и что имелось в виду — любые конфликтные ситуации или недопонимания всегда можно разобрать, «вытащив» из памяти переводчика нужные диалоги.

Высокое качество данных — естественное следствие выстроенной слабой связанности через ESB .

Оно обеспечивается за счёт строгой трансформационной логики и чёткого протокольного взаимодействия между системами.

Здесь системы не знают о существовании друг друга — их задача: принять и передать данные.

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

Здесь можно легко поменять одну систему на другую или подключить и ввести в эксплуатацию новую — без супергероев с титаническими усилиями и ресурсами. IT начинает работать на бизнес, а не наоборот!

Можно обмениваться данными напрямую и трансформировать их внутри систем.

Важно учитывать логику трансформации: если что-то поменяется в одной системе — нужно «подстроиться» в другой. В начале это выглядит эффективно: быстро подключились по API — полетели данные, красота!

Но без единого интеграционного слоя и общих стандартов, без подхода слабой связанности со временем это начинает разваливаться.

Много ИТ- систем В каждой — собственная логика доставки и трансформации

Системы могут быть источником десятков или даже сотен сущностей с некачественными данными — это порождает новые ошибки и ещё больше некачественных сущностей

Внедряются инструменты, которые должны «почистить» данные — MDM, PIM.

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

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

Возникает эффект “замкнутой инфраструктуры”, где любая доработка — мини-проект.

Поэтому просто внедрить брокер сообщений вроде Kafka или даже ESB без архитектуры слабой связанности — это как выпить цитрамон с дикого похмелья.

Чуть полегчает — но корень проблемы так и останется не тронут.

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

Через ESB можно легко выстроить трансформацию данных адаптированную для каждой системы.

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

Данные хранятся в разобранном виде в DWH и в изначальном виде в Data Lake.

Здесь все прозрачно и разложено по полочкам.

Система бизнес аналитики( BI ) - легко может собрать любой нужный отчет. А саму систему( BI ) - подключить просто через единый слой интеграции ESB .

ESB сам контролирует доступность сети и систем.

Сам забирает и обеспечивает доставку данных.

Сам преобразует в нужный формат для каждой системы.

Здесь единый ETL слой это мозги а Kafka или другой брокер - обеспечивают доставку и получение.

Кафка в частности без слабой связанности не даст желаемый результат?

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

Только в такой архитектуре будет простая, точная и доступная бизнес-аналитика.

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

Здесь неэффективно просто внедрять “решения” на уровне IT-контура, потому что цифровая копия бизнеса всё сильнее расходится с реальностью.

Возникает разрыв между тем, как устроены настоящие процессы с тем, что отражается в IT.

Можно бесконечно перебирать подрядчиков, внедрять новые инструменты и модные подходы.

Но пока нет идентичности между реальными и цифровыми процессами, всё это будет порождать ошибки и нестыковки.

Решения будут ложиться поверх этих искажений, образуя рубцовую ткань с предыдущими “решениями”. И эта цифровая эрозия будет сама себя наращивать: цифровая копия бизнеса будет становиться всё менее соответствующей реальности.

Итог всегда один: слабая связанность — не абстрактная идея, а реальный фактор, влияющий на себестоимость.

Ниже — график, наглядно показывающий, как растут издержки содержания IT-контура без слабой связанности. *

Эффект ИКЕА (IKEA Effect) — это когнитивное искажение, при котором человек переоценивает ценность вещей, сделанных своими руками, даже если они объективно хуже.

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

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

Без единого куратора, который держит в голове архитектуру и управляет связанностью, ИТ-ландшафт превращается в спутанный свитер: тёплый, но неудобный, перегретый и с дырами.

Это как хороший спортсмен, который тренируется сам — он добьётся прогресса.

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

Так и в интеграциях: слабая связанность не возникает сама по себе — она достигается через системную работу и архитектурное сопровождение.

Обычно запуск проекта по внедрению ESB начинается не с попытки перестроить весь IT-контур сразу, а с самого болезненного места в бизнесе. Например, если отдел заказов перегружен, заказы теряются, сотрудники тонут в ручной обработке — именно туда первым делом и направляется внимание.

Через ESB выстраивается слабосвязанная интеграция между системами: автоматизируется приём, трансформация и передача заказов.

Спустя 2–3 месяца то, что раньше было хаосом, становится стабильным, масштабируемым потоком. И бизнес видит: “работает!” — без полной переделки, без глобального рефакторинга, просто за счёт грамотной архитектуры.

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

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

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

Напишите в комментариях — обсудим. ESB - преимущества для управления бизнесом ESB - преимущества для построения IT-контура бизнеса