В разных источниках можно встретить утверждения, что брокер сообщений обязательно входит в контур ESB→ (сервисной шины предприятия). Некоторые даже считают, что брокер — это основная часть ESB или эти понятия совпадают.
В этой статье мы разберемся, возможна ли шина без брокера и в каких случаях именно такой подход лучше для IT-архитектуры.
Перечитывал логи, много думал
Обратимся (как бывало не раз) к простому и понятному примеру с интернет-магазином.
Представьте себе крупную компанию, которая торгует автокомпонентами в интернет-магазине. Можно примерно смоделировать, какие системы входят в ее контур:
- PIM-система, в которой хранится информация о товарам;
- WMS-система для управления складами;
- сам интернет-магазин;
- система CRM, в которой хранятся данные по клиентам и скидкам;
- OMS-система для управления заказами.
Они с некоторой частотой обмениваются между собой информацией через ESB-слой. Например, интернет-магазин отправляет заказы со статусами раз в минуту или раз в секунду.
Нужна ли информация по заказам из интернет-магазина в OMS-системе? Конечно, нужна. И брокер будет отправлять всю очередь сообщений из интернет-магазина в OMS.
Но наша с вами компания крупная и торгует на всей территории России, не только в розницу, но и мелким оптом. Поэтому в её контуре есть несколько OMS, чтобы прозрачно управлять заказами из разных регионов: Дальний Восток и Калининградская область, например, – а также оптовыми и розничными заказами.
Схема усложнилась? А вместе с ней усложнилась и логика. Одной OMS нужны только заказы из Центральной России, другой — только мелкооптовые заказы по Сибири, третьей — только заказы в определенном статусе. Четвёртой — только заказы на шины с предыдущим статусом «оплачен» и дополнительным флажком, который должен проставить ETL-коннектор при обработке…
А брокер по-прежнему один раз в минуту передаёт в каждую OMS всю очередь из новых, отмененных и неподтверждённых заказов из интернет-магазина. А это может быть как 3 записи, так и 10 тысяч.
Что получается?
Каждой OMS-системе нужно получить все сообщения по всем заказам, прочитать их, понять, нужен ли ей этот конкретный заказ или у него не тот статус или не тот регион. Это дополнительная логика, которую приходится прописывать внутри системы кодом, утяжеляя эту систему и замедляя её.
Что будет, если использовать базу данных
В этом случае один ETL-коннектор забирает из интернет-магазина все статусы заказа и складывает их в базу→. Вся логика, вне зависимости от сложности условий, находится в слое коннекторов — они сортируют и передают только те записи, которые нужны «их» OMS-системам. Лишняя инфформация не перегружает систамы-получатели — более того, она даже не попадает в коннектор.
Понял с первого раза
Другой кейс — реальный, из опыта одного из наших клиентов→.
Компания онлайн и офлайн торгует бытовой химией, пищевыми добавками, товарами для здоровья. Некоторые заказы оформляются через интернет-магазин, другие — через продавцов или торговых представителей в филиалах.
Бонусная система для офлайн-покупателей привязана к сочетанию ФИО и контактных данных. Но случались такие ситуации: когда кнопка «подтвердить» нажата, покупатель мог вспомнить, что с последнего визита у него изменился номер телефона. Приходилось переоформлять заказ с тем же составом продуктов, тем же ФИО покупателя, но новым телефоном. В итоге брокер передавал в CRM-систему оба заказа, вычищать дубликаты из каждой системы приходилось вручную.
Кейс, который мы описали, — не единственный известный нам подобный случай. При использовании брокера дубликаты сообщений приходят в конечные системы достаточно часто. И чтобы от них избавляться, приходится или вычищать дубликаты вручную, или прописывать в системе-получателе дополнительную логику. Например, система должна находить дубликаты по ключевым параметрам, сверять время отправки, убирать более ранние записи и оставлять только более новые сообщения.
Что будет, если использовать базу данных
Если вы используете в ESB-контуре базу данных + ETL-слой, вы можете переложить на них логику сверки сообщений. В систему-получатель в этом случае будет попадать уже «чистая» информация, и не придется задействовать дополнительные ресурсы системы на обработку дубликатов.
С чистого листа
Теперь представим ситуацию: вы решили подключить к контуру новую систему. Например, BI, чтобы отслеживать метрики и анализировать гипотезы.
Как это выглядит в контуре с брокером сообщений?
У вас появляется еще одна система, которая начинает «слушать» очереди сообщений по карточкам товаров, по просмотрам, по заказам и т. д. Этого достаточно, чтобы получить свежие данные. Но для каких-то выводов этого недостаточно: нужны ещё ретроспективные данные. А значит, придётся запрашивать у систем-источников перевыгрузку данных.
Казалось бы, через брокер можно получить эту выгрузку максимально оперативно?
Да, но нет. Во-первых, если у вас много дублирующих сообщений в системе-источнике, это однозначно замедлит выгрузку и обработку. Во-вторых, учитывайте ещё и асинхронность работы: задержки в 10–15 секунд абсолютно допустимы даже на высоких нагрузках и в очень больших контурах. Предсказать, сколько записей не попадёт в выгрузку при таких раскладах, невозможно.
Подробнее об этом мы писали в одной из предыдущих статей, в которой сравнивали подходы к интеграции→.
Что будет, если использовать базу данных
Если в вашей шине вместо брокера сообщений используются базы данных, у вас уже есть готовая, очищенная от дубликатов выгрузка данных из всех нужных систем. Есть заказы, карточки товаров, которые можно соотнести с заказами, статусы доставок — всё, что может понадобиться для бизнес-аналитики (как в нашем примере) или любой другой новой системы, нового процесса. Не придется ничего заново пересобирать, перевыгружать из систем-источников, убирать дубликаты и т. д.
Где логика?
А ведь иногда вам нужно делать сложную выборку для внешних потребителей, и тут брокер почти бесполезен.
Снова представим кейс. В вашей PIM-системе хранятся карточки товаров: тех, которые есть у вас в ассортименте сейчас, и тех, которые временно не продаются. Не продаются, потому что вы только их закупаете, или это сезонные товары, или пока нет поставок — вариантов множество.
Но маркетплейсу нужно от вас получать те товары, которые есть в наличии на складе, с пометкой «есть в наличии». И отдельно те, которые поступят в ближайшее время — тоже с соответствующей пометкой. Те, которые скоро кончатся и вы не планируете их докупать, должны получать статус «скоро закончатся». Чтобы сделать такие потоки данных, надо прочитать несколько источников, сравнить их, объединить и только потом отправить.
Чтобы реализовать такую логику с брокером, придётся на стороне PIM-системы, WMS-системы, системы управления закупками (и, возможно, еще пары систем, которые связаны с продажами) кодом прописать ограничения для выгрузки на маркетплейс. При большом ассортименте и сложном каталоге вам придётся или подстраивать время выгрузки на неактивные часы пользования системами, или мириться с «тормозами», которые захватят ключевые части вашей ИТ-архитектуры.
При использовании связки из базы данных + ETL вся логика переходит на слой коннекторов, не замедляя ни одну из систем-источников.
Кажется, что брокер может подойти в процессах, в которых нет сложной логики и важна максимальная скорость передачи. Но и в этих случаях не всегда именно брокер является лучшим решением. Например, на одном из наших проектов скорость была ключевой метрикой: записей было не так много, но их статус постоянно менялся. Мы обеспечили постоянное обновление статусов с помощью брокера, но системы-получатели просто не успевали обрабатывать поток поступающих сообщений с обновлениями.
Как это ни парадоксально, именно обновления (то, что менялось чаще всего) системам-потребителям не были нужны. Их интересовали только сами записи. Как результат, лучшую скорость обеспечила пакетная обработка из реляционной базы данных: она не перегружала системы-получатели и доставляла в них все необходимые данные.
В портфеле KT.Team десятки кейсов по интеграциям с разной бизнес-логикой. На своих проектах мы видели разную логику, запросы, проблемы в обработке данных. И знаем, в каких случаях лучше предложить брокер, а в каких — базу данных. Если у вас есть сомнения — запишитесь на консультацию, наши эксперты помогут определиться с инструментом и правильно построить интеграции.
