# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Solution Design (Проектное решение) 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 Document DDD Микросервисы и service mesh ESB HTTP/REST RPC
Другие разделы:
# АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Корпоративная сервисная шина (КСШ)
last update: 06-10-2020, 06:53
Немного мудрости

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

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

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

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

Примеры решений ESB
  • Облачные решения ESB:
    • Azure Service Bus
    • Amazon Simple Queue Service
  • On-premise решения ESB:
    • 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. Читать логи транзакций БД
Плюсы 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)