Объясняю просто зачем нужна шина данных компании или ESB.
Что это такое?
Сервисная шина предприятия, enterprise service bus (ESB) она же корпоративная сервисная шина,
она же шина данных предприятия - это архитектурное решение, которое позволяет упросить обмен данными между разными сервисами.
Чтобы понять зачем она нужна, вам нужно понимать как ИТ системы (сервисы) обмениваются данными по API.
Для примера будем считать что используется REST API.
Шина данных - это название подхода. В качестве технического решения может использоваться что угодно. Например, реляционная БД
или брокер сообщений, например Apache Kafka.
Примеры архитектуры
Давайте посмотрим как усложняется архитектура с ростом количества сервисов внутри компании. От спагетти подхода
к использованию шины.
Когда сервисов мало обмен строиться на API. Например, 1С обращается к сайту за данными о заказе
используя GET метод для получения данных и POST, PUT для обновления:
flowchart LR
1C-- PUT, POST -->Сайт
Сайт-- GET -->1C
Если сервисов много, то и обменов будет много. Причем вероятна ситуация, когда один сервис выгружает
данные в несколько. Например, 1С выгружает данные на сайт и в сервис аналитики.
flowchart LR
1С-- PUT,POST -->Сайт
Сайт-- GET -->1С
1С-- PUT,POST -->Аналитика
Сайт-- PUT,POST -->Аналитика
С ростом количества сервисов картина усложняется.
flowchart LR
1С-- PUT,POST -->Сайт
1С-- PUT,POST -->Аналитика
Сайт-- PUT,POST -->Аналитика
Склад-- PUT,POST -->Сайт
1С-- PUT,POST -->Склад
Логистика-- PUT,POST -->Сайт
Логистика-- PUT,POST-->1С
Логистика-- PUT,POST-->Аналитика
1С-- PUT,POST -->Логистика
Растет количество сервисов, растет количество связей и сложность. Шина помогает уменьшить количество связей.
Особенность сервисной шины данных - хранение данных. То есть, сайт один раз записывает данные
о заказе в ESB, все другие сервисы прочитают эти данные.
Архитектура с использованием шины данных.
flowchart LR
1С<-->ESB
Сайт-- GET* -->1С
Сайт<-->ESB
Склад<-->ESB
Логистика<-->ESB
ESB-->Аналитика
- Где-то останется чтение из API других сервисов, об этом позже.
Проблемы и решения
Вот какие проблемы решает подход с использованием шины.
Добавление нового сервиса
Пусть добавили новый сервис “партнерская программа” — ПП.
- Спагетти: в каждый сервис который пишет данные в ПП добавляется логика работы с ПП.
- Шина: ПП читает данные из ESB, в логике работы других сервисов изменений нет.
Сбой в одном из сервисов
На сайте произошел сбой и данные отправляемые со стороны логистики и 1С записались неверно.
- Спагетти: разработчик сайта исправляет баг, и просит разработчиков других сервисов
заново выгрузить данные. Трудозатраты с трех сторон.
- Шина: разработчик сайта исправляет баг и самостоятельно перечитывает данные из ESB.
Распределение нагрузки
Пусть ПП необходимо масштабировать.
- Спагетти: Добавляем инстанс сервиса, добавляем в сервис логику по которой входящие
данные делятся между инстансами сервиса.
- Шина: Добавляем инстанс сервиса, используем встроенный в шину механизм деления данных между потребителями.
Что и как писать в сервисную шину данных
Пишут события, а не команды. Например, заказ создан - это событие, а отправь письмо - это команда.
События несут в себе некую полезную информацию. Создан заказ — номер, время и пользователь.
Проведена оплата — номер транзакции, сумма.
Не все данные о событии пишут в шину. Если попытаться запихнуть в шину все связанное с событием,
то по шине начнут летать терабайты данных. Да и сервис создающий событие, часто не знает все о нем.
На практике в шину пишут основные данные связанные с событием. Получатели события в случае если
недостаточности данных использую GET запросы к API других сервисов.
Резюме
- Шина данных предприятия — это архитектурный паттерн, конкретная реализация может быть любой.
- Применяют когда есть много сервисов обменивающихся данными.
- Решает некоторые проблемы (очевидно не все) в сервис-ориентированной архитектуре.
- Внедрение шины не отменяет использования API.
Вопросы можно написать в telegram, дополню в случае необходимости.