Всегда ли нужен брокер сообщений?

Обратимся (как бывало не раз) к простому и понятному примеру с интернет-магазином.

Представьте себе крупную компанию, которая торгует автокомпонентами в интернет-магазине.

Можно примерно смоделировать, какие системы входят в ее контур: PIM-система, в которой хранится информация о товарам; WMS-система для управления складами; сам интернет-магазин; система CRM, в которой хранятся данные по клиентам и скидкам; OMS-система для управления заказами.

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

Но наша с вами компания крупная и торгует на всей территории России, не только в розницу, но и мелким оптом.

Поэтому в её контуре есть несколько OMS, чтобы прозрачно управлять заказами из разных регионов:

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

Схема усложнилась? А вместе с ней усложнилась и логика.

Центральной России; другой - только мелкооптовые заказы по Сибири; третьей - только заказы в определенном статусе; четвёртой - только заказы на шины с предыдущим статусом «оплачен» и дополнительным флажком, который должен проставить ETL-коннектор при обработке… А брокер по-прежнему один раз в минуту передаёт в каждую OMS всю очередь из новых, отмененных и неподтверждённых заказов из интернет-магазина. А это может быть как 3 записи, так и 10 тысяч.

Каждой OMS-системе нужно получить все сообщения по всем заказам, прочитать их, понять, нужен ли ей этот конкретный заказ или у него не тот статус или не тот регион.

Это дополнительная логика, которую приходится прописывать внутри системы кодом, утяжеляя эту систему и замедляя её.

Теперь представим ситуацию: вы решили подключить к контуру новую систему. Например, BI, чтобы отслеживать метрики и анализировать гипотезы.

Этого достаточно, чтобы получить свежие данные.

Но для каких-то выводов этого недостаточно: нужны ещё ретроспективные данные. А значит, придётся запрашивать у систем-источников перевыгрузку данных.

Казалось бы, через брокер можно получить эту выгрузку максимально оперативно? Да, но нет. Во-первых, если у вас много дублирующих сообщений в системе-источнике, это однозначно замедлит выгрузку и обработку. Во-вторых, учитывайте ещё и асинхронность работы: задержки в 10-15 секунд абсолютно допустимы даже на высоких нагрузках и в очень больших контурах. Предсказать, сколько записей не попадёт в выгрузку при таких раскладах, невозможно.

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

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

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

Чтобы сделать такие потоки данных, надо прочитать несколько источников, сравнить их, объединить и только потом отправить.

Чтобы реализовать такую логику с брокером, придётся на стороне PIM-системы, WMS-системы, системы управления закупками (и, возможно, еще пары систем, которые связаны с продажами) кодом прописать ограничения для выгрузки на маркетплейс.

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

При использовании связки из базы данных + ETL вся логика переходит на слой коннекторов, не замедляя ни одну из систем-источников.

Кажется, что брокер может подойти в процессах, в которых нет сложной логики и важна максимальная скорость передачи.

Мы обеспечили постоянное обновление статусов с помощью брокера, но системы-получатели просто не успевали обрабатывать поток поступающих сообщений с обновлениями.

Как это ни парадоксально, именно обновления (то, что менялось чаще всего) системам-потребителям не были нужны.

Их интересовали только сами записи.

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