Интеграции через Apache Kafka для КРУПНОГО бизнеса. Какие преимущества и ограничения?
И какие решения можно внедрить совместно с Kafka чтобы снять всю головную боль касаемо интеграций?
Действительно, в крупном бизнесе есть много проблем в слое интеграций между ИТ-системами, которые могут решать такие инструменты, как Apache Kafka или другие брокеры сообщений.
В этой статье разберемся, в какой конфигурации, применяя эти инструменты, можно получить решение проблем и какие уровни проблем уходят соответственно.
ИТ-контур любого крупного бизнеса — это как огромный мегаполис. Как и у городов, здесь нет похожих, но всегда города объединяют схожие элементы, а также проблемы. Как и города — это совокупность систем, подходов, конфигураций, стоимости услуг, инфраструктур и т.д., так и ИТ: в одном городе хорошее метро, но огромное количество пробок, в другом — мало преступности, но магазины закрыты, сиеста и т.п.
Хочется, чтобы был идеальный город, где магазины работают 24/7, нет преступности, а добраться без пробок можно в любую точку — не только человеку, но и товарам и услугам.
В интеграциях между ИТ-системами так же: одна система допилена до такого состояния, что выдаёт очень качественные данные, но вот беда — есть гетто в виде других систем или их компонентов, где всё работает нестабильно: постоянные ошибки, данные дублируются друг с другом в этой системе и соседних, и в итоге весь этот трафик создаёт пробки на дорогах и магистралях. Люди не успевают на важные встречи, товары не доставляются вовремя или вообще не довозятся и т.д. и т.п.
Когда происходит какой-то глобальный катаклизм и весь город встаёт в пробки — нужен супергерой, который возьмет ситуацию в могучие руки и разрулит весь этот хаос… до следующего раза.
И так наш супергерой сегодня — это брокер сообщений Apache Kafka.
{{cta}}
На примере одного из таких решений рассмотрим типичную ситуацию. В бизнесе есть вышеуказанные проблемы, и принимается решение сделать интеграцию через брокер сообщений, такой как Kafka.
На уровне выгоды это выглядит вполне рациональным решением.
Да, действительно, брокер сообщений помогает снизить пиковую нагрузку на системы, уменьшить потери данных. Системы не будут напрямую контролировать доставку и получение сообщений.
Внедрение брокера сообщений - частично уменьшает потерю данных но не исключает в некоторых сценариях! Брокер это транспорт но не мозги - вся логика контроля и получения находится внутри связанных систем.
Но интеграции только через брокер не ГАРАНТИРУЮТ передачу если:
- если получатель не готов, формат не совпадает, логика не отработана, время хранения истекло или просто нет подтверждения приёма
Отдельно отмечу что брокер вообще ни имеет отношения к разбору причин ошибок или причины перегрузок в пиковые дни “черной пятницы”, есть у вас брокер или нет - часто такие ошибки или перегрузки приходят и их причина остается без понимания.
Какие решения можно внедрить совместно с Kafka чтобы снять всю головную боль касаемо интеграций?
- Kafka
- Снижается пиковая нагрузка на системы
- Уменьшается потеря данных
- Асинхрон - системы не должны быть постоянно в онлайне для общения
- ESB c Kafka в составе
- исключается потеря данных
- значительно снижается нагрузка на системы
- облегчается бизнес аналитика (BI)
- Слабая связанность через ESB c Kafka в составе
- можно менять системы по щелчку
- Значительно сокращаются затраты на IT
- Отчуждаемость - легко передать другой IT команде
- Высокое качество данных = простая бизнес аналитика
2. ESB c Kafka в составе
Чтобы получить вышеизложенные преимущества важно понимать что каждая матрешка не может существовать без других
Что есть ESB?
ESB - это корпоративная сервисная шина. Часто путают наличие брокера сообщений с ней. Брокер - это транспортная шина. В случае с ESB же - это набор компонентов которые создают идеальный слой интеграций. Который обеспечивает: логику трансформации, маршрутизацию, выявление ошибок, расследование инцидентов и все это храниться на выделенном хостинге который обеспечит отказоустойчивость.
По сути, ESB — это переводчик, который очень качественно передаёт суть без потери смысла и с учётом культурного контекста. Системы — это «граждане» разных стран. При этом ESB может общаться хоть с автобусом туристов, и каждый будет говорить на своём языке — только с одним переводчиком, который «передаёт» все сообщения, и в автобусе будет атмосфера полного взаимопонимания. Более того, переводчик всегда помнит, всё к чему говорили и что имелось в виду — любые конфликтные ситуации или недопонимания всегда можно разобрать, «вытащив» из памяти переводчика нужные диалоги.
Высокое качество данных — естественное следствие выстроенной слабой связанности через ESB. Оно обеспечивается за счёт строгой трансформационной логики и чёткого протокольного взаимодействия между системами.
Здесь системы не знают о существовании друг друга — их задача: принять и передать данные. Вся логика передачи и трансформации находится не в системах, а в ETL, и чётко разделена архитектурно и организационно: клубок связей логики распутан, убрано лишнее, а те «нити», что остались, лежат строго там, где нужны, не затрагивая остального. Здесь можно легко поменять одну систему на другую или подключить и ввести в эксплуатацию новую — без супергероев с титаническими усилиями и ресурсами.
IT начинает работать на бизнес, а не наоборот!
Чем подход слабой связанности отличается от прямых интеграций или через брокера? И почему данные становятся некачественными:
Можно обмениваться данными напрямую и трансформировать их внутри систем.
Важно учитывать логику трансформации: если что-то поменяется в одной системе — нужно «подстроиться» в другой. В начале это выглядит эффективно: быстро подключились по API — полетели данные, красота!
Но без единого интеграционного слоя и общих стандартов, без подхода слабой связанности со временем это начинает разваливаться. Типичная картина выглядит так:
- Много ИТ- систем
- В каждой — собственная логика доставки и трансформации
- Системы могут быть источником десятков или даже сотен сущностей с некачественными данными — это порождает новые ошибки и ещё больше некачественных сущностей
- Внедряются инструменты, которые должны «почистить» данные — MDM, PIM. Но они глушат последствия, не устраняя причин
В итоге одна система должна учитывать логику трансформации и связей всех остальных.
Это и есть сильная связанность: клубок зависимостей, в котором трудно разобраться даже внутри команды, не говоря уже о внешних участниках. Возникает эффект “замкнутой инфраструктуры”, где любая доработка — мини-проект.
Поэтому просто внедрить брокер сообщений вроде Kafka или даже ESB без архитектуры слабой связанности — это как выпить цитрамон с дикого похмелья. Чуть полегчает — но корень проблемы так и останется не тронут.
{{cta}}
ESB - это качественные данные и легкая бизнес аналитика(BI)!
Для двух систем сущность типа карточки товара может быть разным набором данных. Через ESB можно легко выстроить трансформацию данных адаптированную для каждой системы. Что так же снизит нагрузку. И исключит ошибку передачи изза неправильного формата данных.
Данные хранятся в разобранном виде в DWH и в изначальном виде в Data Lake. Здесь все прозрачно и разложено по полочкам. Система бизнес аналитики(BI) - легко может собрать любой нужный отчет. А саму систему(BI) - подключить просто через единый слой интеграции ESB.
ESB - это гарантия доставки сообщений
ESB сам контролирует доступность сети и систем. Сам забирает и обеспечивает доставку данных. Сам преобразует в нужный формат для каждой системы. Здесь единый ETL слой это мозги а Kafka или другой брокер - обеспечивают доставку и получение.
ESB - это выявление ошибок в момент их возникновения
В ESB-подходе проактивный мониторинг позволяет сразу получить уведомление при возникновении ошибки, быстро увидеть лог и оперативно устранить причину. В отличие от прямых интеграций, где о проблемах часто узнают лишь по косвенным признакам — когда системы начинают сбоить одна за другой, как домино, или, что еще хуже, когда об этом сообщают клиенты, потерявшие заказы.
ESB - нагрузка на системы значительно снижается
ESB снижает нагрузку на системы, потому что берёт на себя не только передачу, буферизацию и преобразование данных, но и маршрутизацию и оркестрацию потоков. Вместо того чтобы одна система напрямую спрашивала другую (и “висела” в ожидании ответа), ESB принимает данные, временно сохраняет их, трансформирует в нужный формат и передаёт дальше, когда принимающая сторона готова.
Более того, ESB знает, куда, когда и в каком порядке передавать данные — благодаря встроенной маршрутизации. А если поток данных должен пройти через несколько этапов (например, валидацию, enrich, логирование, запись в хранилище) — оркестрация в ESB управляет этой последовательностью, без необходимости прописывать это в каждой системе по отдельности.
В результате системы становятся менее зависимыми друг от друга и работают в своём ритме — без перегрузок, таймаутов и ручного контроля. Архитектура становится гибче, а процессы — стабильнее и масштабируемее.
3. Слабая связанность через ESB c Kafka в составе
Почему применять ESB в целом или Кафка в частности без слабой связанности не даст желаемый результат?
Всё вышесказанное хорошо, но чтобы действительно выстроить IT-контур, в котором можно менять системы «по щелчку», существенно сокращать затраты на IT и легко передавать сопровождение другой команде, нужна слабая связанность. Только в такой архитектуре будет простая, точная и доступная бизнес-аналитика. Этого можно достичь, выстраивая слабую связанность как на архитектурном, так и на организационном уровне — через продуманную корпоративную сервисную шину (ESB), в составе которой может использоваться Kafka как транспорт.
Здесь неэффективно просто внедрять “решения” на уровне IT-контура, потому что цифровая копия бизнеса всё сильнее расходится с реальностью. Возникает разрыв между тем, как устроены настоящие процессы с тем, что отражается в IT.
Можно бесконечно перебирать подрядчиков, внедрять новые инструменты и модные подходы. Но пока нет идентичности между реальными и цифровыми процессами, всё это будет порождать ошибки и нестыковки. Решения будут ложиться поверх этих искажений, образуя рубцовую ткань с предыдущими “решениями”. И эта цифровая эрозия будет сама себя наращивать: цифровая копия бизнеса будет становиться всё менее соответствующей реальности.
Итог всегда один: слабая связанность — не абстрактная идея, а реальный фактор, влияющий на себестоимость. Ниже — график, наглядно показывающий, как растут издержки содержания IT-контура без слабой связанности.
* Эффект ИКЕА (IKEA Effect) — это когнитивное искажение, при котором человек переоценивает ценность вещей, сделанных своими руками, даже если они объективно хуже.
Мы постоянно видим одну и ту же картину: сначала интеграции запускаются быстро, через прямые соединения — это даёт быстрый результат и ощущение эффективности. Но со временем архитектура начинает рассыпаться: каждое новое соединение добавляет хрупкости, дублирование, зависимость от конкретных систем и людей.
Без единого куратора, который держит в голове архитектуру и управляет связанностью, ИТ-ландшафт превращается в спутанный свитер: тёплый, но неудобный, перегретый и с дырами. Это как хороший спортсмен, который тренируется сам — он добьётся прогресса. Но когда появляется опытный тренер, который видит со стороны, корректирует технику и управляет нагрузкой — появляются значимые результаты и рекорды.
Так и в интеграциях: слабая связанность не возникает сама по себе — она достигается через системную работу и архитектурное сопровождение.
Есть хорошие новости!
Обычно запуск проекта по внедрению ESB начинается не с попытки перестроить весь IT-контур сразу, а с самого болезненного места в бизнесе. Например, если отдел заказов перегружен, заказы теряются, сотрудники тонут в ручной обработке — именно туда первым делом и направляется внимание. Через ESB выстраивается слабосвязанная интеграция между системами: автоматизируется приём, трансформация и передача заказов. Спустя 2–3 месяца то, что раньше было хаосом, становится стабильным, масштабируемым потоком. И бизнес видит: “работает!” — без полной переделки, без глобального рефакторинга, просто за счёт грамотной архитектуры. Появляется островок слабой связанности - как тихая гавань у бурном океане интеграций, где корабль всегда найдет пристанище и не будет биться бортами с другими жаждущими. Его быстро разгрузят и загрузят не потеряв ничего, разложат по полочкам провизию, а задача капитана корабля - дальше идти по своему курсу не отвлекаясь на всю эту текучку.
Если в этом материале вы узнали себя или свою команду — буду рад услышать, как вы видите решение подобных задач. Возможно, у вас уже есть опыт, которым стоит поделиться, или взгляд, который добавит ещё один ценный слой к этой теме. Напишите в комментариях — обсудим.
ESB - преимущества для управления бизнесом
ESB - преимущества для построения IT-контура бизнеса
{{cta}}
