Введение

Эта статья ー вторая часть большого материала об интеграции информационных систем (ИС) и самых распространённых паттернах и технологиях интеграции. 

В первой части мы рассказали:

• о том, что такое интеграция ИС;

• какие бывают паттерны интеграции;

• подробно о трёх паттернах интеграции, в каких случаях их применять и как спроектировать:

  • файловый обмен;

  • общую базу данных;

  • удалённый вызов процедур (SOAP, REST).

В этой статье:

•  подробно о паттернах и технологиях интеграции:

  • GraphQL;

  • gRPC;

  • Webhook;

  • WebSocket;

  • брокеры сообщений.

• алгоритм выбора паттерна интеграции;

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

Паттерны интеграции ИТ-систем

GraphQL

Что такое GraphQL

GraphQL ー технология обработки запросов к приложению с помощью API. GraphQL как технология объединяет в себе язык запросов, среду обработки запросов и архитектуру клиент-серверного взаимодействия. 

GraphQL был разработан в 2012 году компанией Facebook* на основе REST, чтобы нивелировать его недостатки. 

Архитектура REST-приложений строится вокруг ресурсов, поэтому количество запросов к приложению может быть избыточным. Если клиенту (браузеру или внешней системе) нужно получить информацию о разных объектах одновременно, скорее всего нужно будет сделать несколько запросов к разным ресурсам. Также избыточным может быть и набор информации, которую вернёт сервер. Клиенту необходимо будет самостоятельно отобрать из ответа нужные данные.

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

Для реализации запросов требуется организовать подключение  GraphQL-сервера к источнику данных и определить на сервере схему данных источника. Это обеспечивает гибкость построения запросов, а также позволяет одним запросом получать данные из разных таблиц и даже из разных баз данных. Получается, что GraphQL выступает в качестве API Gateway при запросе к источникам данных.

GraphQL позволяет совершать два вида операций.

1. Запрос (Query) ー запрос на получение данных.

2. Мутация (Mutation) ー запрос на добавление/изменение данных.

Например, запрос такого вида 

query NewQuery{
    user {
       firstName
       lastName
       birthDate
   }
}

вернёт только имя, фамилию и дату рождения пользователя.

В качестве транспорта GraphQL использует протокол HTTP, при этом все запросы реализуются посредством метода POST (как запись, так и чтение, обновление и удаление).

Также GraphQL поддерживает механизм Pub/Sub ー подписку клиента на публикацию событий сервера. Это позволяет реализовывать интерактивное клиент-серверное взаимодействие. 

Как спроектировать интеграцию с помощью GraphQL

При проектировании интеграции с помощью GraphQL важно определить ряд параметров интеграции.

1. Набор конечных точек ー маршрутов и HTTP-вызовов к ним. Чаще всего в GraphQ только одна конечная точка ー точка входа в приложение, а все необходимые действия описываются уже в теле запроса. При этом GraphQL позволяет реализовать и несколько конечных точек. 

2. Для каждой конечной точки ー вид запроса (запрос, мутация, подписка на события) и JSON-схема полезной нагрузки запроса клиента. 

3. Для каждой конечной точки ー методы аутентификации клиента (будет в заголовке запроса).

4. Для каждой конечной точки ー статусы ответа сервера, в том числе для ошибок (будет в заголовке ответа).

Возможности и ограничения GraphQL

Когда использовать GraphQL

GraphQL хорошо подходит для интеграции ИС, когда:

• нужно собирать данные из разных источников;

• нужно сократить число запросов от клиента к серверу, передав в ответ только те данные, что запрашивает клиент;

• в OLTP-системе (транзакционные системы) нужно добавить аналитику (OLAP-запросы) без денормализации базы данных или реализации витрины/отдельной системы и т.д.

GraphQL применяется чаще всего для:

• систем с микросервисной архитектурой;

• мобильных приложений;

• систем, агрегирующих данные из разных источников;

• реализации паттерна API Composition (паттерн заключается в опросе разных сервисов, агрегации результатов в памяти и передаче клиенту агрегированного результата).

Аналогия с мостами

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

gRPC

Что такое gRPC

gRPC ー фреймворк реализации удаленного вызова процедур (RPC), разработанный компанией Google в 2015 году. gRPC предназначен для использования в высокопроизводительных распределенных системах и микросервисах.

Фреймворк gRPC позволяет реализовать различные механики взаимодействия систем или сервисов.

1. Механика «Запрос-Ответ» (Request-Response): синхронный запрос клиента и ответ сервера.

2. Потоковая передача потока данных с сервера на клиент при подключении клиента.

3. Потоковая передача потока данных с клиента на сервер при подключении клиента.

4. Двунаправленная передача потока данных с сервера на клиент и наоборот.

В качестве транспортного протокола gRPS использует HTTP/2. Использование именно второй версии протокола обеспечивает производительность выполнения запросов и передачи данных за счёт реализации в HTTP/2 мультиплексирования и эффективных механизмов сжатия.

Также высокая производительность gRPC достигается за счёт особого формата передачи данных ー бинарного формата Protobuf (Protocol Buffers) со встроенной схемой данных. В protobuf данные передаются в закодированном виде, а декодирование производится на стороне получателя данных.

Как спроектировать интеграцию с помощью gRPC

При проектировании интеграции с использованием gRPC важно определить ряд параметров интеграции.

1. Механика обмена данными: синхронный запрос-ответ или потоковая передача данных.

2. Название удалённой функции, которую необходимо вызывать. Это описывается в protobuf-документе.

3. Методы аутентификации клиента.

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

Возможности и ограничения gRPC

Когда использовать gRPC

gRPC хорошо подходит для интеграции ИС, когда:

• нужны разные варианты обмена данными (по запросу сервера, по запросу клиента, потоковая передача данных и т.д.);

• требуется реализовать высокое быстродействие в реальном времени;

• разные технологии у интегрируемых ИС и стек может расширяться;

• важна безопасность.

gRPC чаще всего применяется для:

• микросервисов;

• мобильных приложений;

• IoT (Internet Of Things)-устройств;

• машинного обучения;

• веб-приложений;

• стриминговых сервисов.

Аналогия с мостами

Возвращаясь к нашей аналогии с мостами, gRPC можно сравнить с комплексным мостом, предназначенным для разных видов транспорта. По такому мосту могут ехать как машины, так и другие виды транспорта. gRPC позволяет реализовать различные механизмы обмена данными. Транспорт на таком мосту должен следовать с высокой скоростью, в gRPC реализуется высокая скорость передачи данных благодаря HTTP/2 и protobuf.

Webhook

Что такое webhook

Webhook (вебхук) ー технология взаимодействия веб-приложений или сервисов в реальном времени.  

Вебхук позволяет настроить автоматическую отправку запроса из системы-источника к системе-приемнику при наступлении какого-то события-триггера. По своей сути вебхук ー это HTTP-запрос, только сформированный и отправленный автоматически при наступлении события. 

Использование вебхука позволяет избежать непрерывного опроса API сервера клиентом при реализации асинхронных процессов (это ещё называют longpooling).

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

1. Реализовать с нуля собственный обработчик, который будет отслеживать события и формировать HTTP-запросы.

2. Использовать специализированные инструменты или платформы, поддерживающие Webhook API «из коробки».  Такие платформы подключаются как к системе-источнику, так и к системе-приёмнику. На стороне системы-источника можно выбрать события-триггеры, а на стороне системы-приёмника можно задать конечную точку.

Как спроектировать интеграцию с помощью webhook

При работе с webhook важно определить ряд параметров интеграции.

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

2. Определить состав событий-триггеров.

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

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

5. Настроить Webhook API или реализовать приёмник вебхуков на стороне системы-приёмника для обработки входящих запросов. 

Возможности и ограничения webhook

Когда использовать webhook

Вебхук хорошо подходит для решения задач:

• когда характер обмена событийный (не периодический);

• когда клиент не знает, когда на сервере будут новые данные, но должен получить их, когда они появятся;

• когда нужно избежать периодических и безрезультатных обращений клиента к серверу, например, для экономии трафика;

• асинхронной интеграции.

Вебхук часто используется в системах:

• с событийно-ориентированной архитектурой (Event-Driven Architecture, EDA);

• с уведомлениями в реальном времени.

Аналогия с мостами

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

1. Низкая грузоподъёмность. Канатная дорога переводит небольшой по объёму груз; запрос может содержать не очень большой объём информации, например, уведомления.

2. Движение по триггеру. Канатная дорога начинает движение, когда кто-то садится в кабину и нажимает на кнопку. Вебхук-запрос отправляется по триггеру.

3. Конкретный маршрут доставки. Канатная дорога доставляет пассажиров из одной точки в другую по заранее определённому маршруту. Вебхук-запрос отправляется на конкретную конечную точку (URL).

4. Асинхронность. Канатная дорога продолжает движение, даже если пассажир уже вышел. Webhook отправляет данные без ожидания ответа получателя

5. Экономия ресурсов. Канатная дорога работает только тогда, когда пассажир сел. Вебхук-запрос экономит ресурсы, отправляя данные только при наступлении события вместо постоянного опроса сервера. 

WebSocket

Что такое WebSocket

WebSocket ー протокол связи между клиентом и сервером. Протокол позволяет устанавливать двунаправленное постоянное соединение в реальном времени благодаря механизму keep alive, введенному в рамках HTTP 1.1.

Установка websocket-соединения осуществляется с помощью handshake.  Handshake ー это приветственное сообщение (рукопожатие), которое отправляется клиентом на сервер. Оно сигнализирует, что необходимо перейти с использования протокола HTTP на протокол WebSocket. 

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

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

На транспортном уровне WebSocket использует сетевой протокол TCP, что позволяет организовать передачу данных разных схем и размеров. Протокол TCP разбивает данные на фреймы, обеспечивая их целостность через отправку закрывающего бита, который маркирует завершение передачи. 

Как спроектировать интеграцию с помощью WebSocket

При проектировании WebSocket-интеграции необходимо определить ряд параметров.

1. Определить сценарии, при которых будет отправляться сообщение от клиента к серверу или наоборот.

2. Определить передаваемые сообщения: пример данных, включая его формат и схему.

3. Сформировать требования по безопасности, чтобы разработчик мог выбрать между wss (WebSocket Secure) и ws (WebSocket) протоколами. В публичных сетях существует риск перехвата чувствительных данных, поэтому лучше использовать wss с TLS (Transport Layer Security) для шифрования полезной нагрузки.

Возможности и ограничения WebSocket

Когда использовать WebSocket

WebSocket хорошо подходит для решения задач, в которых:

• нужна интеграции в реальном времени;

• нужна двусторонняя связь клиента с сервером;

• нужно долговечное решение.

WebSocket часто используется в:

• онлайн-играх;

• чатах и мессенджерах;

• системах мониторинга в реальном времени;

• IoT-сфере.

Аналогия с мостами

Websocket можно сравнить с автомобильным мостом.

1. Автомобильный мост позволяет машинам ехать в два направления. Websocket обеспечивает двунаправленное клиент-серверное взаимодействие.

2. По автомобильному мосту могут ехать сразу много машин. Websocket позволяет передать много данных благодаря использованию транспортного протокола TCP.

3. Пока мост стоит, по нему можно ехать. Пока открыто websocket-соединение, клиент и сервер могут обмениваться данными.

4. Автомобильный мост сложно и дорого построить. Websocket-интеграцию сложно разрабатывать и настраивать как на стороне клиента, так и на стороне сервера.

5. И автомобильный мост и websocket-интеграцию можно использовать долговечно.

Брокеры сообщений

Что такое брокеры сообщений

Брокер сообщений ー архитектурный паттерн и программное обеспечение, предназначенные для реализации асинхронного взаимодействия элементов распределённой системы. 

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

1. Отправитель или producer ー подсистема или сервис, который публикует данные в брокер.

2. Потребитель или consumer ー подсистема или сервис, который подписывается на получение сообщений из брокера и потребляет полученные данные.

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

Взаимодействие между отправителем и потребителем асинхронное, то есть отправитель не знает какие потребители и в каком объёме получили из брокера данные. 

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

Самые популярные брокеры сообщений ー RabbitMQ и Apache Kafka. Хотя они реализуют общий паттерн брокера сообщений, между ними довольно много различий.

Как спроектировать интеграцию с помощью брокеров сообщений

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

1. Как будет называться канал связи, в который будут публиковаться данные. В RabbitMQ это топик, в Apache Kafka ー очередь.

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

3. Какова надёжность потребителя. Если потребитель ненадёжный, то стоит использовать Kafka, который сохраняет данные на диске длительное время, в отличие от RabbitMQ, который удаляет данные после доставки сообщения. 

4. Фактор репликации ー количество копий сообщения ー в кластере брокера. Это нужно для обеспечения надёжности доставки сообщений.

5. Производительность потока данных в части публикации и потребления. 

6. Требуется ли настраивать разделы (партиции) в Kafka (разделение топика на несколько разделов) или предел очереди в RabbitMQ (максимальное количество сообщений в очередь), чтобы предотвратить переполнение очереди.

7. Стратегия разделения в Kafka, если разделение используется; тип обменника (маршрутизатор сообщений) в RabbitMQ.

8. Размер очереди и время жизни сообщения для RabbitMQ; максимальное время хранения сообщений для Kafka.

9. Схема потокового обмена, на которой будут отображены все топики/очереди, отправители и потребители данных. Удобно проектировать такую схему через DFD-диаграмму. 

10. Также описать интеграцию через брокер можно с помощью спецификации стандарта AsyncAPI. Спецификация в формате yaml (похожая на Open API спецификацию) содержит состав топиков, схему аутентификации, формат данных полезной нагрузки и т.д.

Возможности и ограничения брокеров сообщений

Когда использовать брокеры сообщений

Брокеры сообщений как технология интеграции отлично подходят для решения задач, когда:

• нужна асинхронная интеграция, в том числе сразу нескольких систем;

• нужна передача данных в реальном времени или низкая задержка;

• много данных, но размер каждого сообщения небольшой;

• событийный характер обмена (EDA-архитектура);

• нужны высокая производительность и масштабирование;

• есть ресурсы на развёртывание и поддержку дополнительной инфраструктуры для брокера.

Брокеры сообщений успешно используются в системах:

• с микросервисной событийно-ориентированной архитектурой;

• платформы IoT;

• с уведомлениями в реальном времени;

• с межсервисными транзакциями.

Аналогия с мостами

Брокер сообщений можно сравнить с конвейером.

1. Конвейер передаёт предметы в упорядоченном виде. Брокер сообщений передаёт данные по мере их публикации в упорядоченном виде. 

2. Объекты перемещаются по конвейеру в реальном времени. Брокер передаёт данные в реальном времени.

3. Конвейер может быть масштабирован за счет добавления новых лент. Брокеры также успешно масштабируются: например, топик можно разделить на разделы.

4. Конвейер полностью автоматизирован, как и брокер сообщений.

5. Для обеспечения работы конвейера нужна мощная инфраструктура, как и для брокера сообщений.

6. Формат обмена асинхронный: тот, кто поставил предмет на конвейер не зависит от того, кто заберёт; отправитель данных в брокер не зависит от получателя.

Алгоритм проектирования интеграции ИС

Выбор паттерна

Первый шаг ー выбрать паттерн интеграции среди тех, которые мы рассмотрели в рамках этого материала. 

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

• какими данными должны обмениваться системы? 

• с какой скоростью и в каком объёме системы обмениваются данными? 

• как долго и как часто системы будут обмениваться данными? 

• какие ограничения и особенности есть у интегрируемых систем? 

• сколько временных и финансовых ресурсов есть на интеграцию?

Небольшой алгоритм по выбору технологии интеграции.

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

Проектирование интеграции

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

1. Кто инициирует обмен данными? 

   1. клиент обращается к серверу;

   2. сервер обращается к клиенту;

   3. обмен данными двунаправленный: и клиент, и сервер могут инициировать взаимодействие.

2. Какова периодичность передачи данных. 

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

4. Характер передачи данных: пакетная или потоковая.

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

6. Необходима ли транзакционность, то есть нужно ли откатывать изменения, если на каком-то шаге возникла ошибка.

7. Надёжность системы-приемника и сети.

8. Пропускная способность системы-источника, системы-приёмника и сети.

9. Требования к безопасности: нужно ли шифрование данных, как осуществляется аутентификация клиента.

10. Текущие возможности системы-источника и системы-приемника, есть ли у них какие-то API?

Резюме

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

2. gRPC как технология интеграции подходит в случаях, когда нужны разные варианты обмена данными (по запросу сервера, по запросу клиента, потоковая передача данных и т.д.); требуется реализовать высокое быстродействие в реальном времени; разные технологии у интегрируемых ИС и стек может расширяться; важна безопасность.

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

4. WebSocket используется, когда нужна интеграции в реальном времени; когда нужна двусторонняя связь клиента с сервером; когда нужно долговечное решение.

5. Брокер сообщений применяется для асинхронного взаимодействия; когда нужна передача данных в реальном времени; когда архитектура событийная и данные генерируются в большом количестве.

6. На выбор технологии интеграции влияют разные факторы: 

   1. какими данными должны обмениваться системы? 

   2. с какой скоростью и в каком объёме системы обмениваются данными? 

   3. как долго и как часто системы будут обмениваться данными? 

   4. какие ограничения и особенности есть у интегрируемых систем? 

   5. сколько временных и финансовых ресурсов есть на интеграцию?

Ответы на вопросы

Существует ли формат «сервер-сервер»?

В термине «клиент-сервер» под клиентом обычно понимается любой компонент, который инициирует взаимодействие. Это может быть и веб-клиент, и мобильное приложение, и серверное приложение. Под сервером понимается компонент, который отвечает на запрос.

Какова надёжность webhook? Можно ли пропустить сообщение? 

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

Подходит ли WebSocket для видеотрансляций?

Теоретически ー да, можно организовать длительное соединение через WebSocket и реализовать передачу видео или аудио-потока. Но в реальных системах, где нужна передача медиаданных (стриминговые платформы, в онлайн-кинотеатры и т.д.) для этой цели websocket не используют. Для этого существуют специальные технологии, например протоколы SRT, RTMP, HLS, WebRTC.

Что из рассмотренных паттернов интеграции можно сочетать между собой?

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

Есть ли смысл делать видеостриминг через брокер сообщений?

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

WebSocket не использует в качестве транспорта HTTP?

Да, WebSocket использует HTTP для «рукопожатия» (handshake) ー отправки самого первого сообщения для установки соединения. После успешного рукопожатия происходит переключение протокола с HTTP на TCP для транспорта.

Автор статьи — Анна Вичугова