Как выбрать подходящий тип интеграции для своей IT-архитектуры

точка - точка, брокер, ESB 24.4.2024

Рассматриваем особенности, плюсы и минусы трёх типов интеграции: точка - точка, через брокер и через ESB .

Как правило, они концентрируются или на технических нюансах построения интеграций, или на явных плюсах и минусах каждого из подходов. В этой статье эксперты KT.Team предлагают взглянуть на все три типа интеграции с точки зрения внутреннего устройства - это позволяет подсветить не только явные, но и неявные преимущества и недостатки каждого из них.

Удобнее изучить материал в формате подкаста?

Первый и самый крупный минус такой интеграции - сильная взаимная зависимость систем.

Продолжим наш пример с 1С и интернет-магазином.

Чтобы пользователь оформил заказ, интернет-магазин должен получить от 1С информацию о статусе в программе лояльности и адресе пользователя.

Стоит 1С «упасть» или замедлиться из-за высокой нагрузки - и критичная информация перестанет поступать в интернет-магазин.

Покупатели не смогут оформлять заказы, пока 1С не восстановится.

Чтобы обезопасить бизнес от таких рисков, команда разработки будет постоянно изобретать какие-то предохранители: расставлять флаги, придумывать очереди, переизобретать асинхронную отправку сообщений между системами… В итоге «недорогая» прямая интеграция догонит и перегонит по стоимости «дорогую» шину.

Всё это приходится учитывать в логике интеграции.

Третий минус: интеграции перегружают систему-источник, даже если изначально она работает с небольшим количеством данных. Например, в CRM лежат данные о клиентах, к которым постоянно обращаются интернет-магазин, доставка, маркетинговые приложения и т. д.

Результат - нагрузка на CRM кратно растёт из-за постоянных обращений от других систем.

Четвертый минус: изменение в любой системе запускает каскад доработок во всех связанных интеграциях и системах.

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

Чтобы не перегружать складскую программу и не передавать одно и то же несколько раз, разработчики могут предложить вам «изящное решение»: пусть WMS передаёт всё только в 1С. А 1С, в свою очередь, отдаёт в интернет-магазин не только свой участок данных о товарах и заказах, но и остатки.

Актуальность данных об остатках, которая отображается в интернет-магазине, теперь зависит от работоспособности сразу двух систем. 1С (ну или любая система-посредник) оказывается перегружена непрофильными данными.

Мы на практике видели и более длинные цепочки обогащения данных, это не такое редкое явление. И если что-то идет не так в конечной системе, приходится устраивать расследование: где передача данных не случилась, по какой причине и как избежать повторений. Последний, но на наш взгляд самый критичный минус - интеграции «точка - точка» блокируют или существенно замедляют обновление IT-систем.

Если вы через три года захотите заменить ту же CRM, вам придётся заново разрабатывать и воспроизводить логику десятков интеграций, причем не только тех, которые непосредственно связаны с CRM.

При этом компания становится заложником разработчиков, которые много знают про существующую логику.

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

Сами разработчики тоже становятся заложниками своих знаний: им приходится даже в отпуске всегда быть на телефоне, потому что - мало ли что может пойти не так?

Обмен данными становится более контролируемым.

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

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

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

Стоит отметить и то, что передача данных через брокер - быстрая, в этом брокер почти не уступает самому быстрому типу интеграций «точка - точка».

Первый важный минус - использование брокера даёт нагрузку на сервис, который передаёт сообщение.

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

Эта логика дополнительно нагружает систему, поэтому есть соблазн от неё отказаться.

Но в этом случае недоставленные сообщения рано или поздно отразятся на критичных бизнес-процессах.

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

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

Но система не может «попросить» у брокера отфильтрованные сведения.

Ей приходится получать через интеграции всё, что отдают CRM и OMS (Order Management System), сохранять это в свои базы данных и за счет внутренней логики отделять 5% нужных данных от 95% лишних.

Третий значимый минус - это цементирование контракта.

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

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

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

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

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

Этот недостаток тянет за собой другой существенный минус - невозможность качественной сверки.

Системы прогружают из брокера и старые, и новые сообщения, не делая между ними разницы.

При повторной прогрузке возможны ситуации, когда более новое сообщение оказывается затёртым: например, вместо статуса «доставлен» заказ получает статус «создан».

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

Поэтому чтение данных происходит гораздо медленнее.

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

Чтобы все системы в контуре не получали избыточные данные, «проще» пропустить их через одну систему, там нормализовать и уже нормализованные данные передать дальше. К чему это приводит, мы описывали выше.

Есть и неявный минус управленческого порядка. У каждой системы есть свой продакт-оунер.

Но кто является владельцем брокера и связанных с ним интеграций?

Чаще всего, им становится технический отдел.

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

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

Это единственный способ интеграций, в котором все три составляющих разделены и выполняют строго свою функцию: система генерирует и потребляет данные, ETL-слой передаёт по назначению и в нужном виде, хранилища (что логично) хранят данные.

Результатом этого является, например, уменьшение нагрузки на сервисы за счет отсутствия в них интеграционной логики.

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

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

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

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

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

Шина отправляет сервису только те данные, которые ему реально нужны - достаточно заложить такую логику в коннектор.

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

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

Данные по бонусным баллам и персональным скидкам интернет-магазин получит из хранилища.

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

Если вы выбрали тип интеграций «точка - точка», вам придётся, во-первых, заново разработать интеграции «точка - точка» между CRM и другими системами, а во-вторых, внести изменения в интеграции других систем, которые используют данные CRM. В случае с ESB вам достаточно разработать только потоки из CRM и в CRM.

Потоки систем-потребителей останутся без изменений.

Может показаться, что использование промежуточного слоя снижает скорость.

Но на практике скорость обмена очень высока: десятки, сотни, тысячи сообщений доставляются за 400-500 миллисекунд! Плюс, который будет более очевиден компаниям со множеством потоков данных: стандартизация разработки. ETL-слой использует типовую логику на получение и отправку данных.

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

Внедрили масштабируемую сервисную шину для АТИМО→

Обеспечили Polaris возможность легко выводить новые товары на маркетплейсы→

Разработали целевую схему интеграции систем для производственного предприятия.

Внедрили технологию ESB и запустили 48 потоков→