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

Enterprise Service Bus (ESB) / Корпоративная сервисная шина (КСШ) = ПО, обеспечивающее централизованный и унифицированный обмен сообщениями между различными ИС предприятия. Подробнее в wikipedia

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

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

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

Примеры решений ESB
  • Облачные решения:
    • Azure Service Bus
    • Amazon Simple Queue Service
  • On-premise решения:
    • RabbitMQ, очень популярно
    • Kafka, очень популярно
    • IBM Integration Bus (IBM)
    • Oracle Service Bus (Oracle)
    • BizTalk (Microsoft)
    • ActiveMatrix Service Bus (TIBCO)
    • MuleESB (MuleSoft)
    • JBoss Fuse ESB (Red Hat)
Плюсы ESB
  1. Асинхронные развязки при обработке команд
  2. Маршрутизация данных, брокер очереди сообщений (Message Queue, MQ)
  3. Гарантированная доставка информационных сообщений
  4. Преобразование: обогащение/фильтрация сообщений, преобразование протоколов (нормализация)
  5. Синхронизация изменений
  6. Протоколирование (логирование) Бизнес-операций
  7. (в современных 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)