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

/ АНАЛИЗ АРХИТЕКТУРА: - АРХИТЕКТУРА - Solution Design - ESB | Немного мудрости | Примеры решений ESB | Плюсы ESB | Минусы ESB - Микросервисы и service mesh - HTTP/REST - RPC - DDD ДАННЫЕ DevOps GAMING БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Корпоративная сервисная шина (КСШ)
last update: 10-10-2021, 06:56 UTC
Немного мудрости

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

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

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

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

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

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

  1. Заклинаю, не надо совать в Шину бизнес-логику, проблем потом не оберётесь. Использовать Шину следует только как транспорт.
    Да и вообще идея вставлять бизнес-логику в вендорные решения и фреймворки -- нарушение принципов DDD и заключение вашего предприятия в т.н. vendor-lock;
  2. ESB могут стать "узким горлышком", когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей --> больше общий TTM (time to market).
    Всё это может значительно усугубиться в ситуации, когда в вашей компании количество специалистов, знающих Шину -- стремится к нулю.
  3. На Шину со множеством адаптеров обязательно нужны автотесты, руками регресс десятков-сотен кейсов адаптеров не покроется, особенно если необходимость в регрессе возникает раз в несколько дней или чаще, ведь на Шине с большой связанностью постоянно будет что-то меняться. Вопрос: стоит ли "вешать" разработку и тестирование на вендора?
    Автотесты требуют всегда актуальных артефактов п.4;
  4. Должен быть выстроен процесс сохранения и актуализации артефактов проектирования, разработки, тестирования Шины и всех ИС, работающих с Шиной. Нужны Архитекторы, и они должны быть "пишущие".
В основном это касается крупных ESB, на которые "нацеплены" большая часть ИС предприятия.
Если мы говорим о "небольших" шинах типа Kafka и RabbitMQ, то с ними всё гораздо проще, кроме того, они часто задействованы в микросервисной и service-mesh архитектуре, а также в смешаной архитектуре.

Примеры решений 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)