Как выбрать технологию для back-to-back интеграций

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

Технологии для синхронного взаимодействия

Есть три популярных способа для реализации синхронного взаимодействия. Это REST, GraphQL и gRPC.
Логика выбора здесь очень похожа на Client Pull во front-to-back интеграциях:
  • REST — это выбор по умолчанию. Он подходит для решения большинства задач, поэтому большинство инженеров хорошо знакомы и работали с ним.
  • GraphQL рекомендуется использовать для решения задач композиции API, а также для решения проблемы вариативности запросов на уровне API одного сервиса.
  • gRPC — это ещё одно возможное решение. О нём поговорим подробнее.

gRPC

✏️ gRPC — это высокопроизводительный протокол удалённого вызова процедур (RPC) с открытым исходным кодом.
gRPC можно использовать с разными форматами данных, но обычно по умолчанию используются Protocol Buffers (protobuf). Это независимый от языка двоичный формат файла для сериализации данных. Он имеет поддержку обратной и прямой совместимости и отличается крайне высокой производительностью. Сам gRPC «под капотом» использует HTTP 2.0, что также помогает достигать высокой производительности при обмене сообщениями.
Если вам нужно повысить производительность при взаимодействии между сервисами, gRPC — это отличное решение.
Ещё gRPC предоставляет возможность стриминга данных. Это дополнительная особенность, которая, однако, тоже может стать решающим аргументом при выборе способа взаимодействия. Представьте, что вам нужно запросить данные из сервиса, причём данных может быть достаточно много. При взаимодействии по HTTP классическим решением было бы использовать пагинацию. gRPC позволяет стримить данные в ответе, в рамках одного подключения. Это значительно экономит ресурсы, поскольку так не нужно делать несколько запросов, которые происходят в рамках отдельных подключений, между приложениями. Во многом это возможно благодаря использованию HTTP 2.0.
Теперь перейдём к технологиям для асинхронного взаимодействия.

Технологии для асинхронного взаимодействия

При выборе технологии для асинхронного взаимодействия важную роль играет характер взаимодействия: «точка-точка» или «публикация-подписка».
«Точка-точка» предполагает взаимодействие между двумя конкретными системами. При этом сообщение должно быть получено конкретной системой, другим системам оно не должно быть доступно. Для таких взаимодействий принято использовать очереди. Они как раз обеспечивают такое поведение: после того как сообщение прочитано получателем, оно удаляется из очереди.
Альтернативой очередям является топик. Это название пришло из терминологии Kafka. Топик предполагает, что сообщение не удаляется, если его прочитал какой-либо из потребителей. Напротив: как правило, сообщения в топике хранятся до тех пор, пока они не устарели или пока не закончился заданный объём хранения данных на диске. До тех пор сообщения могут быть прочитаны разными потребителями по несколько раз.
Самые популярные решения для обмена сообщениями на рынке — это Kafka и Apache ActiveMQ Artemis.
Kafka и её топики являются классическим выбором для обмена событиями, а Artemis и её очереди — для обмена командами и запросами. Но не будем принимать это на веру. Самостоятельно сравним эти технологии и определим, когда что лучше использовать.
💡Но прежде обратите внимание: Artemis, в отличие от Kafka, предлагает для обмена сообщениями как очереди, так и топики. А Kafka — только топики.
Теперь вы видите общую картину. Осталось разобраться, для каких задач подходит каждое из решений.
ActiveMQ — это традиционная система обмена сообщениями. Она отлично подходит для следующих задач:
  • Реализация взаимодействия «точка-точка». Artemis можно использовать и как очередь сообщений, и как топик. Однако в первую очередь рекомендуем рассматривать её для передачи запросов и команд, поскольку это решение позволяет использовать разные шаблоны интеграции. Например, фильтрацию сообщений, маршрутизацию сообщений (через селектор сообщений JMS API), Dead Letter Queue и повторную отправку.
  • Специфичные протоколы. ActiveMQ поддерживает несколько транспортных протоколов и языков программирования. Поэтому он может выступать в качестве моста связи для приложений, которые написаны на разных языках и используют разные протоколы.
Kafka является отличным выбором для следующих вариантов использования:
  • Для обмена событиями. Структура журнала Kafka неизменяемая, она допускает только добавление. За счёт этого структура журнала обеспечивает надёжную, упорядоченную и воспроизводимую запись событий. Он позволяет сохранять и запрашивать полную историческую последовательность изменений состояния.
  • При крайне высоких нагрузках. Как правило, в современных распределённых системах количество публикуемых событий значительно превосходит количество отправляемых запросов и команд. Поэтому требуются высокопроизводительные и масштабируемые конвейеры данных, такие как Kafka. У Kafka распределённая архитектура, есть возможность горизонтального масштабирования и эффективной обработки больших объёмов данных в реальном времени между несколькими производителями и потребителями. Kafka достигает высоких показателей не только за счёт своей модели работы с файловой системой, но и за счёт подхода «глупый брокер, умный потребитель». В том время как Artemis осуществляет дополнительную обработку сообщений, Kafka оставляет все эти функции потребителю, в том числе — фильтрацию сообщений и обработку ошибок.
  • Для потоковой обработки данных. У Kafka есть встроенные возможности потоковой обработки (Kafka Streams). Кроме того, Kafka интегрируется с внешними фреймворками потоковой обработки, такими как Apache Spark, Apache Flink и Apache Storm. И это лишь некоторые из них.
Пример. Вернёмся к примеру с сервисами приложения «ОнлиСхемы». В основном сервисы приложения обмениваются событиями для повышения независимости и гибкости масштабирования. Количество одновременных пользователей и их действий на доске постоянно растёт. Если опираться на нагрузку, с которой сталкивается основной конкурент, ушедший из России, то количество действий на доске в пиковые моменты может достигать 200 тысяч в секунду. Использование Kafka позволит проще адаптироваться под растущую нагрузку, а также является оптимальным выбором для взаимодействия типа «публикация-подписка».

Как выбрать систему очередей сообщений

Помимо Artemis на рынке есть множество других решений для обмена сообщениями посредством очередей. Одна из самых популярных альтернатив — RabbitMQ. Но для высоконагруженных сред, где требуется высокая пропускная способность, масштабируемость и низкая задержка, Apache ActiveMQ Artemis всё ещё выделяется как наиболее подходящий выбор.
Сравним Apache ActiveMQ Artemis и RabbitMQ по ключевым параметрам и попробуем разобраться, почему так.
  • Если ваши требования к высокой нагрузке находятся в верхнем диапазоне возможностей RabbitMQ и вы отдаёте приоритет простоте использования и богатой экосистеме.
  • Если вы ведёте разработку в условиях, где используется множество разных языков программирования и вам требуется множество клиентских библиотек. У RabbitMQ более развитое комьюнити, что поможет вам решить эту задачу быстрее и проще.
И RabbitMQ, и Apache ActiveMQ Artemis — это надёжные брокеры сообщений. Но Artemis лучше подходит для сред, которые требуют высокой производительности, гибкой масштабируемости и низкой задержки.
💡 В любом случае советуем вам относиться к общим рекомендациям критически. Лучше проверить этот выбор с учётом характеристик вашей рабочей нагрузки, проведя индивидуальное тестирование производительности. Также принимайте во внимание опыт вашей команды в работе с технологиями.

Облачные решения

Если ваше приложение развёрнуто в облаке, то реализовать асинхронное взаимодействие также не составит проблем. На рынке облачных сервисов существует множество решений для реализации асинхронного взаимодействия. По сути, каждый облачный провайдер предлагает как минимум одно.
Вот некоторые из наиболее популярных облачных решений:
  • Amazon Simple Queue Service (Amazon SQS). Amazon SQS — это управляемый сервис очередей сообщений. SQS предлагает два типа очередей: стандартные и FIFO. Стандартные очереди подходят для максимальной пропускной способности, хотя при этом не исключено дублирование сообщений. FIFO — менее производительное решение, но полностью устраняет дублирование сообщений.
  • Amazon Simple Notification Service (SNS). Amazon SNS — это управляемый сервис публикации-подписки. SNS поддерживает несколько каналов доставки, такие как прямая отправка в очередь SQS, электронная почта, SMS-уведомления и HTTP-запросы.
  • Google Cloud Pub/Sub. Это платформа для обмена событиями. Она даёт высокие гарантии надёжности и имеет интеграции с внутренними инструментами облачной платформы.
  • Microsoft Azure Service Bus. Azure Service Bus предлагает широкий набор возможностей для обмена сообщениями в облаке, включая надёжные очереди и передачу сообщений через модель публикации-подписки. Сервис также предоставляет расширенные функции, такие как Dead Letter Queue и отложенная доставка сообщений.
  • Yandex Message Queue. Это решение для обмена сообщениями посредством очередей. Предлагает высокие гарантии доставки, а также интегрирован «из коробки» с Cloud Functions для обработки сообщений в рамках функции.

Передача файлов

Отдельное внимание стоит уделить ситуациям, когда нужно передать файл или неструктурированные данные.
Напомним: неструктурированные данные не могут быть переданы в структуре, которую может десериализовать приложение. Примерами таких данных могут быть видео- или аудиофайлы. Их нельзя разложить по конкретным атрибутам в JSON или XML. Иными словами, такой файл представляет из себя BLOB.
Если файл будут использовать несколько компонентов приложения или несколько приложений, рекомендуем рассмотреть использование объектных S3-хранилищ. Предполагается, что система размещает файл в объектное хранилище, которое должно быть также доступно системам, которые этот файл будут использовать. Далее при интеграциях передаётся не сам файл, а ссылка на него.
Такое решение зачастую позволяет повысить производительность взаимодействия и его надёжность. Ещё это косвенно поможет сэкономить ресурсы диска. Их потребуется меньше, чем если бы каждая система-потребитель хранила нужный файл в своей БД.
Теперь вы знаете, какие технологии для back-to-back интеграций есть на рынке и чем руководствоваться при выборе. Чтобы закрепить знания, решите несколько заданий.

Задание 1

Представьте, что вам нужно реализовать оповещение нескольких систем контроля (комплаенс, противодействия мошенничеству и так далее). Нужно сообщать обо всех действиях пользователей в приложении.
Какую технологию обмена сообщениями лучше использовать для этой задачи?

Задание 2

Соотнесите технологию с её характеристикой, исходя из использования WebSockets и SSE во front-to-back интеграциях и асинхронных интеграций в back-to-back интеграциях.
Из коробки предоставляет различные шаблоны интеграции — например, фильтрацию сообщений, маршрутизацию и DLQ
ActiveMQ Artemis
Поддерживает высокоэффективную передачу сообщений в бинарном формате с возможностью стриминга данных
gRPC
Подходит для реализации простых операций CRUD
REST
Подходит для высоконагруженных систем, представляет из себя распределённый лог событий
Kafka
Можете изучить результаты открытого теста производительности различных инструментов, в том числе там представлены Kafka, Artemis ActiveMQ и RabbitMQ.

Итоги

  • Для реализации синхронного взаимодействия есть три популярных способа — это REST, GraphQL и gRPC. REST — это выбор по умолчанию. Он подходит для решения большинства задач. GraphQL рекомендуется использовать для решения задач композиции API, а также для решения проблемы вариативности запросов на уровне API одного сервиса. gRPC отличается крайне высокой производительностью.
  • При выборе технологии для асинхронного взаимодействия важную роль играет характер взаимодействия: «точка-точка» или «публикация-подписка». Kafka и её топики являются классическим выбором для обмена событиями, а Artemis и её очереди — для обмена командами и запросами. Ещё при взаимодействиях «точка-точка» можно рассмотреть использование RabbitMQ. В целом Artemis больше подходит для высоконагруженных приложений, но RabbitMQ может подойти, если требования к нагрузке не слишком высокие и вам важна простота, богатая экосистема или поддержка комьюнити.
  • На рынке облачных сервисов существует множество решений для реализации асинхронного взаимодействия. Каждый облачный провайдер предлагает как минимум одно.
  • Если вам нужно передать файл или неструктурированные данные, рекомендуем рассмотреть использование объектных S3-хранилищ. Такое решение позволяет повысить производительность взаимодействия и его надёжность. Ещё это косвенно поможет сэкономить ресурсы диска.
Следующий урок — последний в теме. Там разберём сложности и типовые ошибки проектирований высоконагруженных приложений.