En

JazzTeam Software Development Company

Agile Java Development

Обзор архитектуры межсервисного взаимодействия, основанного на обмене сообщениями

В данной статье собраны базовые принципы и эволюция межсервисного взаимодействия с использованием специализированного ПО – Message oriented middleware (МОМ), в частности RabbitMQ.

Message oriented middleware (MOM) – это специализированное программное обеспечение, нацеленное на работу в окружении нескольких сервисов и для интеграции этих сервисов путем обмена асинхронными сообщениями. В данной статье будет рассмотрено:

Для того чтобы понять плюсы и минусы MOM, произведем сравнение некоторых подходов в построении ПО:

Двухзвенная архитектура

Некоторые свойства двухзвенной архитектуры:

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

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

  1. Клиент напрямую отправлял запросы о создании записи лишь в одной таблице.
  2. После доработок сервера появилась необходимость записывать также еще одну запись в другую таблицу с foreign key (внешний ключ). Следовательно, клиент обязан знать об изменениях на сервере.

Трехзвенная архитектура

Некоторые свойства трехзвенной архитектуры:


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

В данной архитектуре имеется возможность добавлять экземпляры (клоны) серверов для увеличения и распараллеливания нагрузки, т. е. производить горизонтальное масштабирование. Также нужно учитывать чуть более сложную разработку и тестирование – нужно проектировать и разрабатывать так, чтобы была возможность горизонтального масштабирования.

Рано или поздно монолитное приложение начинает обрастать столь сложным функционалом, что его нужно делить на более мелкие логические модули/сервисы, облегчая тем самым поддержку и разработку этих мелких модулей/сервисов. К тому же длительность работы разной логики, находящейся на разных серверах, может отличаться на несколько порядков (10, 100 и выше раз). Это связано с логикой, которая находится в этих вызовах.

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

Message oriented middleware (MOM)

Некоторые свойства Message oriented middleware (MOM):

Message oriented middleware – это ПО, предназначенное для объединения различных модулей/сервисов в единую сеть.

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

Последующие изменения в инфраструктуре и/или сети никак не влекут изменений  в приложениях. Пожалуй, придется поменять лишь сетевой адрес сервера Middleware (если он, конечно, переедет).

Middleware обеспечивает очень прозрачный, открытый доступ к сетевому сервису.

Middleware не зависит от других сетевых сервисов. Middleware архитектура очень легко поддается масштабированию – достаточно поднять клон необходимого сервиса.

Главная сущность этого ПО – это сообщения, которые используются вместо привычного HTTP. Сообщение – это байтовая информация, которая должна подходить под API сервера, как правило в JSON формате. В реализации RabbitMQ сообщения передаются с помощью AMQP протокола (Advanced Message Queuing Protocol). В нашей статье сообщения и AMQP будут рассмотрены ниже.

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

Стоит отметить, что RabbitMQ представляет собой базу данных, которая может хранить сообщения в себе. Эта фича позволяет хранить факты запроса от сервиса к сервису, даже если конечный получатель (сервис) отсутствует, выключен, неисправен и т. д. Хранение сообщений внутри осуществляется также и при отключении самого RabbitMQ.

На нашем проекте используется именно такая схема общения сервисов между собой по нескольким причинам:

Сообщение, AMQP

Особенности общения по протоколу AMQP:

Работу Message Broker, представителем которого является RabbitMQ, можно представить как работу почтового отделения.

Отправитель-клиент создает сообщение (письмо) с определенным телом и с ключом маршрутизации (адресат). Далее клиент отправляет это сообщение на точку обмена (exchange), которую можно представить как ящик для исходящих писем. После этого Message Broker производит маршрутизацию этого входящего сообщения в соответствии с ключом маршрутизации и кладёт это сообщение в ту очередь (queue), которая настроена на получение сообщений с данным ключом маршрутизации. Очередь (queue) можно представить как почтовый ящик для входящих писем, откуда клиент извлекает входящие письма.

Масштабирование

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

Синхронное и асинхронное взаимодействие

Одно из главных отличий архитектуры, использующей Message oriented middleware, является тот факт, что взаимодействие между сервисами является асинхронным, в отличие от двух- и трехзвенных систем, где общение как правило синхронное и осуществляется по HTTP. Для сравнения особенностей синхронного и асинхронного взаимодействия приведена таблица:

Синхронное взаимодействие:

Асинхронное взаимодействие:

Заключение

Данная статья не является призывом к использованию RabbitMQ повсеместно, наоборот, цель статьи – преподнести читателю плюсы и минусы некоторых подходов в проектировании и разработке ПО. Взвешенный выбор подхода должен осуществляться индивидуально для каждого из разрабатываемых продуктов.

Используемые ресурсы


, , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *