# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА: + АРХИТЕКТУРА + Vision + Solution Design - ESB | Немного мудрости | Примеры решений ESB | Плюсы ESB | Минусы ESB + Микросервисы и service mesh + HTTP/REST + RPC + DDD ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Корпоративная сервисная шина (КСШ)
latest update of the page: 27-01-2024, 09:53 UTC
Немного мудрости

Enterprise Service Bus (ESB) / Корпоративная сервисная шина (КСШ) = ПО, обеспечивающее централизованный и унифицированный обмен сообщениями между различными ИС предприятия. Подробнее в wikipedia.
Если в "дошинную" эпоху общепринятой концепцией была интеграция различных систем друг с другом напрямую, т.н. соединение "точка-точка", то с появлением шины — она становится главным транспортным узлом в интеграционной архитектуре предприятия, в определённом смысле объединяя в себе все API предприятия:

скачать схему в формате diagrams.net (бывший draw.io)

Всё сказанное ниже в основном касается крупных ESB (типа IBM Integration Bus), на которые "нацеплены" большая часть ИС (информационных систем) предприятия.
Если же мы говорим о продукта типа Apache Kafka и RabbitMQ, использующихся в качестве КСШ, то с ними всё гораздо проще, кроме того, они часто задействованы в микросервисной и service-mesh архитектуре, а также в смешаной архитектуре.

Общая концепция КСШ:

скачать схему в формате diagrams.net (бывший draw.io)

КСШ на определённом этапе истории являли собой эволюционный виток архитектурной мысли в рамках сервисно-ориентированной архитектуры в "домикросервисную эпоху". Хорошо подходит для средних размеров предприятий с относительно небольшим количеством ИС (десятки).

Оглянувшись на свой и чужой опыт, можно извлечь несколько уроков использования КСШ:

  1. ESB с высокой вероятностью становится единой точкой отказа (single point of failure, SPOF), сиречь, если рушится она, то рушится взаимодействие всех систем, которые "общаются" через неё.
  2. ESB могут стать "узким горлышком" ещё в том смысле, что множество команд разработки других ваших систем будут вынуждены ждать выхода в ПРОМ доработок от команды ESB. Больше зависимостей --> больше общий TTM (time to market).
    Всё это может значительно усугубиться в ситуации, когда в вашей компании количество специалистов, "знающих Шину" — близко к нулю.
  3. Обязательно д.б. выстроен процесс сохранения и актуализации артефактов проектирования, разработки, тестирования Шины и всех систем, работающих с оной. Нужны Архитекторы, и они должны быть "пишущие".
  4. Заклинаю, НЕ надо совать в Шину бизнес-логику, проблем потом не оберётесь. Использовать Шину следует ТОЛЬКО как ТРАНСПОРТ.
    Да и вообще идея вставлять бизнес-логику в вендорные решения и фреймворки — нарушение принципов DDD и заключение вашего предприятия в т.н. vendor-lock.
  5. На Шину со множеством адаптеров обязательно нужны автотесты, руками регресс десятков-сотен кейсов адаптеров не покроется, особенно если необходимость в регрессе возникает раз в несколько дней или чаще, ведь на Шине с большой связанностью постоянно будет что-то меняться. Вопрос: стоит ли "вешать" разработку и тестирование на вендора?
    Автотесты требуют всегда актуальных артефактов п.4.

Примеры решений ESB
Плюсы ESB
  1. Асинхронные развязки при обработке команд
  2. Брокер очереди сообщений (Message Queue, MQ), маршрутизация сообщений в соответствии с заданными правилами, настройка приоритетов обработки
  3. Преобразование сообщений: обогащение сообщений данными, фильтрация по правилам, трансформация протоколов (нормализация) и форматов (XML, JSON, CSV, ...)
  4. Гарантированная доставка сообщений: контроль над доставкой, переотправка при необходимости
  5. Протоколирование (логирование) бизнес-операций
  6. (в современных ESB) MFT = Managed file transfer
Минусы ESB
  1. Добавляется ещё одна ИС, которую надо обслуживать
  2. Потребуется закупать мощности для развёртывания и включения в текущие тестовые контуры ещё одной ИС
  3. ESB может стать "узким горлышком", когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей --> больше общий TTM.
    Всё это усугубляется, если количество специалистов, знающих вашу Шину, стремится к нулю;

Что Шина НЕ даёт

  1. Описание и прототипирование API (как умеет Swagger, Postman et cetera)
    Это может быть размещено в CoreAPI.
  2. Stream processing (как умеет Kafka)
  3. Интеграция данных (ETL, ...)
  4. Средства управления сервисами (circuit breaker)