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

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

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

‍

Принципиальное устройство любой интеграции

Вне зависимости от типа интеграции, в любой из интеграций есть:

• система-источник;
• система – получатель информации
• ETL-слой (extract, transform, load, то есть извлечение, преобразование и загрузка)
• хранилище данных — пространство, в которое записывается информация, переданная через интеграции.

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

«Точка–точка»

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

А это значит, что в интеграции «точка–точка» и ETL-функция, и хранилище находятся внутри самих систем. Система-источник извлекает из своих баз информацию и преобразует её в вид, удобный для потребления. Система-получатель складывает информацию в свои внутренние хранилища, чтобы потом обработать и использовать её.

Плюсы интеграции «точка – точка»

Поскольку в интеграции не участвуют никакие дополнительные системы и базы, «точка–точка» — самый быстрый в смысле разработки и самый простой в управлении тип интеграции.

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

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

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

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

И… На деле, плюсы на этом заканчиваются.

Минусы интеграции «точка–точка»

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

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

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

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

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

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

Чем плох такой подход? Актуальность данных об остатках, которая отображается в интернет-магазине, теперь зависит от работоспособности сразу двух систем. 1С (ну или любая система-посредник) оказывается перегружена непрофильными данными. Мы на практике видели и более длинные цепочки обогащения данных, это не такое редкое явление. И если что-то идет не так в конечной системе, приходится устраивать расследование: где передача данных не случилась, по какой причине и как избежать повторений.

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

При этом компания становится заложником разработчиков, которые много знают про существующую логику. Оказаться от них или переключить команду на другие задачи становится почти невозможно. Сами разработчики тоже становятся заложниками своих знаний: им приходится даже в отпуске всегда быть на телефоне, потому что — мало ли что может пойти не так?

Интеграция через брокер

В такой интеграции помимо системы-источника и системы-получателя появляется промежуточный слой — брокер сообщений. Системы не взаимодействуют друг с другом — только с Apache Kafka, RabbitMQ или любым аналогичным сервисом. При этом инициаторами отправки и получения информации по-прежнему остаются IT-системы.

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

Плюсы интеграции через брокер

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

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

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

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

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

Минусы интеграции через брокер

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

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

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

Теперь представим, что вашей системе не нужен весь объем каких-то данных. Например, 1С, которая работает в вашем филиале в Уфе, не нужны данные по клиентам и заказам из всех ваших 20 филиалов. Но система не может «попросить» у брокера отфильтрованные сведения. Ей приходится получать через интеграции всё, что отдают CRM и OMS (Order Management System), сохранять это в свои базы данных и за счет внутренней логики отделять 5% нужных данных от 95% лишних.

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

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

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

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

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

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

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

Интеграция через шину данных (ESB-слой)

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

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

Плюсы использования шины

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

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

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

Нагрузка на каждую систему становится контролируемой. В ETL-слое вы можете регулировать нагрузку системы и менять настройки: например, днём не нагружать 1С и производить актуализацию данных только вечером. Более того, вы можете управлять количеством запросов: сколько пакетов в единицу времени доставлять до сервиса.

Шина берет на себя фильтрацию информации. В предыдущем разделе мы рассматривали пример с 1С филиала, которой приходится забирать в 20 раз больше информации, чем это необходимо для работы. В интеграции через ESB такого не происходит. Шина отправляет сервису только те данные, которые ему реально нужны — достаточно заложить такую логику в коннектор.

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

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

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

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

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

Минусы использовании шины

Главный минус — трудоёмкость на старте. Чтобы сделать интеграции правильно, нужно остановиться и подумать над IT-архитектурой: выделить зоны ответственности каждой системы; понять, какую информацию и откуда она получает, что отдаёт, что из этого необходимо, а что избыточно. Здесь важно не усложнить общий подход и мыслить стратегически, чтобы выбранная модель показала свою жизнеспособность на долгие годы.

Трудозатраты при подготовке к запуску шины отражаются и на внешней дороговизне интеграций. Вам придётся уже на старте заплатить и за бизнес-анализ, и за продумывание логики интеграции, и за внедрение инструментов шины — ETL-слоя, DWH и т. д. По нашему опыту, это примерно 90 % от стоимости внедрения и владения ESB. Оставшиеся 10 % — это поддержка уже готовых интеграций.

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

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

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

‍

Узнайте об опыте KT.Team по разработке интеграций через ESB

• Внедрили масштабируемую сервисную шину для АТИМО→
• Обеспечили Polaris возможность легко выводить новые товары на маркетплейсы→
• Разработали целевую схему интеграции систем для производственного предприятия. Внедрили технологию ESB и запустили 48 потоков→