Хотя выбор конкретной технологии интеграции информационных систем, как и любое проектное решение, является областью ответственности ИТ-архитектора, оно основывается на требованиях. Сегодня рассмотрим, какие требования к взаимодействию компонентов распределенных систем и межсистемной интеграции должен определить системный аналитик, чтобы ИТ-архитектор сформировал подходящее решение.
Что определяет выбор технологии интеграции информационных систем?
Прежде всего, аналитик должен задать стейкхолдерам проекта базовые вопросы про необходимость и ожидаемые результаты межсистемной интеграции, о чем я писала здесь. Также рекомендуется пройтись по некоторому чек-листу требований, чтобы облегчить ИТ-архитектору и другим коллегам из команды реализации перевод ТЗ в проектное решение. Следующий чек-лист не претендует на абсолютную полноту и, наверняка, будет дополняться на ваших проектах, однако, его вполне можно взять за основу. Итак, ключевыми факторами для выбора технологии интеграции информационных систем являются следующие:
- периодичность и характер межсистемного взаимодействия;
- количество и объем передаваемых данных;
- допустимая задержка обработки данных;
- жесткость/изменчивость схемы данных и самого API;
- масштабируемость;
- сложность бизнес-логики;
- кэширование.
Сравним по этим параметрам наиболее популярные технологии межсистемной интеграции по API: REST, SOAP, GraphQL и gRPC. Дополнительно рассмотрим с точки зрения этих критериев Apache Kafka и Rabbit MQ, хотя они представляют собой принципиально другой способ интеграции систем, работая не по принципу запрос-ответ, а выступают в качестве промежуточного хранилища данных при обмене между источниками и приемниками. Более того, распределенная платформа потоковой передачи событий Apache Kafka фактически использует технологии запрос-ответ, позволяя приложениям-продюсерам и потребителям делать запросы к топикам с данными, используя все ранее указанные API: REST, gRPC, GraphQL и SOAP. Rabbit MQ и многие другие JMS-брокеры используют RPC-вызовы поверх открытого протокола прикладного уровня AMQP (Advanced Message Queuing Protocol) для передачи сообщений между компонентами системы. AMQP позволяет системам обмениваться произвольным образом сообщениями через AMQP-брокер, который осуществляет маршрутизацию, гарантирует доставку, распределение потоков данных и подписку на нужные типы сообщений.
Поэтому выбор между Apache Kafka и Rabbit MQ также включает вопросы долговременности хранения сообщений. В частности, топики Kafka могут выступать в качестве долговременного хранилища данных, а очереди JMS-брокера – нет. Более подробно о том, что такое Apache Kafka и что аналитику надо знать об этой платформе потоковой передачи событий, мы рассмотрим в следующий раз, а пока разберем смысл ключевых требований к интеграционному решению.
Периодичность и характер межсистемного взаимодействия
Интегрируемые системы могут взаимодействовать по-разному. Например, система Б получает сведения из системы А по расписанию раз в какой-то период времени (минута, час, сутки и пр.) или передача данных и удаленные вызовы функций выполняются по какому-то событию. Причем степень автоматизации тоже важна: по явному запросу пользователя, по факту наступления какого-либо события в одной из связываемых систем или внешнем мире. Здесь же следует продумать вопросы синхронности/асинхронности вызовов. К примеру, в случае синхронных вызовов отправитель запроса, т.е. клиент, блокируется до тех пор, пока не получит ответ от сервера. В асинхронном взаимодействии такой блокировки нет. Чаще всего SOAP и REST используются для синхронного взаимодействия, а gRPC, GraphQL, Apache Kafka и Rabbit MQ — для асинхронного. Хотя справедливости ради стоит отметить, что gRPC имеет и синхронный API.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 января, 2025
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Количество и объем передаваемых данных
В этом случае нас интересует не только фактический размер сообщения, передаваемый по сети, но и его объем относительно первоначального источника. В частности, предполагается ли полная передача пакета информации из системы-источника в систему-приемник или только тех данных, которые были изменены. Этот прием называется CDC (Change Data Capture), захват измененных данных и часто используется в сообщениях с большим объемом. Такой паттерн отлично реализует Debezium – платформа отслеживания изменений в различных СУБД и их отправки в другие системы.
Возвращаясь к вопросу объема передаваемых данных, отмечу, что он может ограничивать выбор технологии межсистемной интеграции. В частности, распределенная платформа потоковой передачи событий Apache Kafka, которая часто используется в качестве шины обмена сообщениями при интеграции нескольких систем, отлично работает с огромным количеством сообщений, но они должны быть небольшого размера. Из-за своих архитектурных особенностей Kafka не предназначена для работы с сообщениями большого объема, что мы рассмотрим в следующий раз. А пока отмечу, что максимальный размер пакета сообщений, отправленных в топик Kafka, определяется конфигурацией message.max.bytes и по умолчанию не превышает 1 МБ.
А что касается используемых протоколов транспорта данных, в частности, HTTP 2, который используют API REST, SOAP, GraphQL и gRPC, он позволяет передавать сообщения практически любого размера. Поэтому размер передаваемого пакета данных не является единственным и жестким ограничением на выбор технологии интеграции.
Наконец, чтобы разговор про передаваемые данные был полным, аналитику в ТЗ на интеграции следует привести примеры сообщений с передаваемыми/принимаемыми данными, чтобы была понятна их структура, в частности, типы данных и количество уровни вложенностей простых структур в более сложные.
Допустимая задержка обработки данных
Этот критерий обычно важен в случае так называемой потоковой передачи – технологии обработки данных в реальном времени или с каким-то незначительном отставанием порядка нескольких миллисекунд. На задержку обработки данных влияет не только пропускная способность (производительность) технологии. Используемый протокол передачи данных (транспорт) и формат их сериализации/десериализации также вносят свою лепту в задержку обработки данных.
В частности, для gRPC API характерна очень высокая производительность и низкая задержка благодаря поддержке двунаправленной потоковой передачи, эффективному протоколу HTTP 2, который поддерживает обмен данными в рамках одного TCP-соединения вместо множества в HTTP 1.1 и маловесному бинарному формату сериализации сообщений Protobuf. Аналогичным образом, «тяжеловесность» XML-формата, используемого в SOAP, увеличивает время передачи данных по сети и их парсинга на стороне системы-приемника.
Жесткость/изменчивость схемы данных и самого API
Схема данных – это структура, которой должны следовать сообщения, передаваемые в рамках интеграции. Не все технологии одинаково хорошо поддерживают версионирование схем данных и самого API. Например, GraphQL, который устраняет некоторые недостатки REST, связанные со множеством конечных точек и неэффективными сетевыми запросами, не очень хорошо работает с динамическими схемами данных и версиями API. А у REST с этим нет проблем, как и у ранее упомянутой платформы Apache Kafka, в которой есть реестр схем (Schema Registry). Однако, если необходима жесткая фиксация схемы данных с автоматической проверкой типов передаваемых и получаемых значений, с этим отлично справляются SOAP и GraphQL.
Масштабируемость
Масштабируемость означает способность системы к росту путем увеличения количества вычислительных узлов (серверов). Этот критерий сильно связан с балансировкой нагрузки и пропускной способностью. Здесь Kafka на порядок опережает Rabbit MQ и другие JMS-брокеры (Java Message Service) типа Apache ActiveMQ и IBM MQ, обеспечивая передачу миллионов событий в секунду и ежедневный обмен миллиардами сообщений. Также балансировка нагрузки в Kafka выполняется автоматически, в отличие от ручной установки максимально допустимого предела количества скопившихся неподтвержденных сообщений в Rabbit MQ.
Если рассматривать технологии интеграции с точки зрения количества клиентов, то Kafka и JMS-брокеры успешно справляются со множеством приемников и источников данных. В GraphQL, по сравнению с REST API также упрощена агрегация данных из нескольких источников.
Сложность бизнес-логики
Если на бэкэнде предполагается не просто выполнение элементарных CRUDL-операций, которые отлично реализуются в терминах HTTP-глаголов REST API, а более сложная бизнес-логика работы с данными вместо управления ресурсами, целесообразен выбор RPC-технологий интеграции (SOAP, gRPC).
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
MODP
Ближайшая дата курса
23 декабря, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Кэширование данных на клиенте
Когда клиент может кэшировать ответы сервера, что есть в REST API, это снижает число запросов и объем данных, передаваемых по сети. Однако, если клиенту всегда нужны самые свежие данные, в кэшировании нет смысла. В этом случае рекомендуется задать таймаут, по истечении которого данные, полученные клиентом, могут стать неактуальными. Все рассмотренные технологии успешно реализуют это ограничение, например, за счет ограниченного времени жизни токена аутентификации и продолжительности клиентской сессии.
Чтобы свести все рассмотренные аспекты интеграции информационных систем воедино, сравнив наиболее популярные для этого технологии (gRPC, SOAP, REST, GraphQL, Apache Kafka и Rabbit MQ), сформируем таблицу.
Разумеется, это далеко не исчерпывающий список факторов, которые обусловливают выбор проектного решения. Чтобы ИТ-архитектор мог выбрать наиболее подходящую технологию интеграции информационных систем, аналитику следует подробно сформулировать требования к подсистеме интеграции, оформив их в техническое задание. Как применить эти знания при проектировании веб-API, читайте в моей новой статье.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Проверить, как вы усвоили материал этой статьи, вам поможет наш интерактивный открытый тест.
А подробнее познакомиться с основами архитектуры и интеграции информационных систем вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- Разработка ТЗ на информационную систему по ГОСТ и SRS
