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

В торговой сети "Бубль-Гум" десяток взаимодействующих информационных систем, а в качестве шины данных у нас 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-топиками, независимо от того, есть у этой системы собственное готовое интеграционное решение или нет. Минус: проблемная, сложная и дорогая интеграция, т.к. при внедрении подрядчик будет настаивать на имеющемся готовом решении, будет нуждаться в прояснении детальных требований и повышать цену за кастомную интеграцию. Плюс: каждая система подключается, по сути, к единой модели данных (логической и физической), реализованной на шине данных, и от шины данных не требуется каких-либо трансформаций или перенаправлений данных из топика в топик, такой логический слой просто отсутствует.

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

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

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