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

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

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

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

  1. не совать в Шину бизнес-логику. Использовать только как транспорт, оркестровку (синхроника), хореографию (асинхроника).
    Это помимо того, что совать бизнес-логику в вендорные решения и фреймворки -- нарушение принципов DDD и постановка предприятия в зависимость от вендора/фреймворка;
  2. ESB может стать "узким горлышком", когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей --> больше общий TTM. Всё это усугубляется при стремящемся к нулю кол-ве специалистов, знающих Шину;
  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)