Как мы интегрировали системы через шину данных

В торговой сети "Бубль-Гум" десяток взаимодействующих информационных систем, а в качестве шины данных у нас Apache Kafka.

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

Названия модельных топиков формируются из названия сущности предметной области и _evt (для событий) или _snp (для снэпшотов). Например, sale_evt - событие продажи, stock_snp - снэпшот остатков. Если системы, при наличии шины данных, реализуют продакшн обмен данными минуя модельные топики шины данных, это идет вразрез с архитектурой и должно быть исправлено.

Форматом сообщений на шине данных был выбран Avro, что позволило описывать структуру сообщений с помощью Avro-схем и контролировать соответствие пересылаемых сообщений Avro-схеме.

Затем нам пришлось внедрять новую систему, назовем ее AXT, которую нужно было интегрировать с существующими. У AXT есть собственный интерфейс для интеграции с другими системами, а именно, готовые сообщения для обмена в формате JSON. В этом случае (и в подобных ему других случаях) адекватным решением стало

1. реализовать отправку и получение данных AXT через специальные топики шины данных в родном для AXT формате и
2. поместить на шине данных посредника между AXT и остальными системами, который преобразовывает и перенаправляет сообщения между специальными топиками AXT и другими топиками (модельными и специальными других систем).

Названия специальных топиков начинаются с кода системы плюс буква "i" для входящих, и плюс буква "o" для исходящих, например: axti_trip — входящие сообщения о рейсах, axto_ship — исходящие сообщения об отгрузках. Исходящие из системы специальные топики читает только посредник, входящие в систему специальные топики пишет только посредник. Таким образом, посредник, или агент системы, изолирует всю специфику системы, а другие системы продолжают пользоваться модельными топиками. Если некая система напрямую работает со специальными топиками другой системы, то это идет вразрез с архитектурой и должно быть исправлено.

Агенты систем реализуются на базе хранилища оперативных данных (ODS), куда загружаются сообщения из модельных и специальных топиков.

Представьте себе интеграцию всех систем только через модельные топики.

От каждой системы при этом требуется реализовать интеграцию с модельными Avro-топиками, независимо от того, есть у этой системы собственное готовое интеграционное решение или нет. Минус: проблемная, сложная и дорогая интеграция, т.к. подрядчик будет настаивать на имеющемся готовом решении, будет нуждаться в прояснении детальных требований и повышать цену за кастомную интеграцию. Плюс: каждая система подключается, по сути, к единой модели данных (логической и физической), реализованной на шине данных, и от шины данных не требуется каких-либо трансформаций или перенаправлений данных из топика в топик, такой логический слой просто отсутствует.

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

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

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