«Точка-точка», брокер, ESB: какие интеграции помогут построить слабо связанную ИТ-архитектуру

25.7.2024 В статье рассматриваем, какой их видов интеграций поможет построить слабо связанную ИТ-архитектуру, а какой приведет к образованию монолита.

Каждый из типов интеграции точка-точка, брокер ( Kafka ) и сервисная шина предприятия оцениваем по пяти параметрам.

Слабая связанность→ - основа гибкой ИТ-инфраструктуры.

При этом сам факт наличия интеграций в контуре - не индикатор монолита или его отсутствия.

Главное - как эти интеграции реализованы.

Один способ может привести к нагромождению сложно поддерживаемых связей и как результат - сложному масштабированию бизнеса.

Мы уже ранее касались подходов к интеграциям в одной из наших статей→, сегодня посмотрим на эту тему именно с позиции выстраивания слабо связанной архитектуры и гибкости бизнеса.

Никаких посредников, дополнительных хранилищ или общего контекста.

Самый быстрый в смысле разработки тип интеграции: достаточно коробочных API и небольших доработок.

Об их логике использования договариваются команды разработки разных сервисов.

Настраивается такая интеграция быстро, особенно при небольшом количестве сервисов внутри контура.

Создание прямой интеграции с простой логикой - недорогая задача.

Брокеры сообщений обычно поддерживают контракты, то есть проверяют сообщения на базовые правила (например, наличие определенного поля в нужном формате).

Такая интеграция делает разработку более стандартизированной.

Брокер как и «точка-точка» поддерживает высокую скорость передачи данных между сервисами.

Брокер перегружает систему-источник лишними действиями.

Если брокер некоторое время был недоступен, то в этот период никакие новые сообщения в очередь не добавлялись.

Брокер перегружает систему-получателя лишними данными.

Брокер не может выбрать, какие сообщения передавать, он отдаёт всю очередь. Например, всю информацию по ассортименту или данные из WMS по остаткам на складах, даже если их большая часть не нужна системе-получателю.

Но последняя все равно сохраняет их свои базы данных и за счет внутренней логики отделяет 5% нужных данных от 95% лишних.

Использование брокера приводит к «цементированию» контракта.

Все участники процесса должны договориться о том, в каком формате будет передаваться сообщение.

Это лишает гибкости и приводит к росту трудозатрат на поддержку единого формата.

Никаких выборок по актуальным статусам сделать невозможно.

Проблема стоит наиболее остро в тех случаях, когда нужно обменяться историей с другой командой или осуществить миграцию.

Для остальных подразделений - это плюс (меньше ответственности), но в итоге ни у кого из заинтересованных подразделений нет ощущения контроля за инфраструктурой.

Легкость и скорость доработки интеграций/сервисов:

Обмен данными стандартизирован, но необходимость поддержания единого формата данных может ограничить гибкость.

Выдерживание пиковых нагрузок и работа без задержек:

Интеграция поддерживает высокую скорость передачи данных, но возможна перегрузка системы-источника из-за избыточных действий и данных.

Запуск нового потока данных без доработки сервисов:

Новый поток данных требует проверки и возможно доработок для соответствия контрактам брокера.

Отсутствие проблем в других сервисах при ошибке в одном:

Легкость мониторинга и возможность делегирования техподдержке:

Брокер позволяет мониторить данные и логи, но сложность ретроспективы и детализации событий может затруднять полное делегирование техподдержке. Итого: 2 балла слабой связанности из

Нагрузка на каждую систему становится контролируемой.

Задача сервиса - предоставить доступ к данным по API (если речь идет о современном сервисе), FTP или любым другим доступным способом. ETL-слой сам заберёт данные и передаст дальше, в хранилище.

Сервис «думает» лишь о том, чтобы вся информация, за которую он отвечает, была актуальной и полной в момент передачи.

Можно быстро подключать в контур любые системы или дорабатывать их в произвольном порядке.

Этот аспект - главное условие эффективной масштабируемости бизнеса.

Вот пример, как мы решали проблему масштабируемости с помощью внедрения ESB-слоя в компании-производителе электрооборудования и комплексных энергоэффективных решений.

Интеграции унифицированы, логика сервисов становится проще. ETL-слой использует типовую логику на получение и отправку данных.

Разработка новых коннекторов сводится к воспроизводству уже разработанной логики с поправками на конкретный тип данных или особенности системы.

Разработку и мониторинг можно делегировать.

Разработка упрощается, а обязанности по мониторингу можно снять с разработчиков и делегировать техподдержке.

Правильная интеграция через ESB предполагает отказоустойчивость всей IT-архитектуры.

Сервисы обмениваются данными не напрямую: ETL-слой сохраняет их в специальные хранилища и по необходимости забирает актуальную версию оттуда же.

Легкость и скорость доработки интеграций/сервисов: Соответствует.

Сервисы можно легко дорабатывать или подключать новые, благодаря разделению ETL-слоя и хранилища данных.

Запуск нового потока данных без доработки сервисов: Соответствует.

Новый поток данных можно запустить без доработок сервисов, поскольку логика передачи данных управляется в ETL-слое.

Отсутствие проблем в других сервисах при ошибке в одном: Соответствует.

Ошибка в одном сервисе не влияет на другие благодаря изоляции данных в ETL-слое и хранилище.

Легкость мониторинга и возможность делегирования техподдержке: Соответствует.

Мониторинг интеграций можно делегировать техподдержке, так как ESB предоставляет необходимые инструменты для наблюдения и управления. Итого: 5 баллов слабой связанности из