УДК 004.75

Виды коммуникации между сервисами в приложениях на базе микросервисной архитектуры

Макаров Дмитрий Андреевич – кандидат технических наук, доцент кафедры информатики, вычислительной техники и прикладной математики Забайкальского государственного университета

Ковалёв Владимир Сергеевич – магистрант Забайкальского государственного университета

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

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

Введение

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

Один-ко-одному

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

image001

Рисунок 1. Пример связи вида «один-ко-одному».

В реализации данного вида взаимодействия, как правило, определен общий контракт или интерфейс. Он выражается в виде единого для двух сервисов формата данных и протокола, которые будут использоваться для обмена и обработки информации. На практике данный вид реализуется с помощью синхронных протоколов, например, TCP, HTTP или WebSocket [1].

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

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

Один-ко-многим

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

image002

Рисунок 2. Пример связи вида «один-ко-многим».

На практике вид «один-ко-многим» реализуется с помощью удаленного вызова процедур (gRPC или Crossbar.io RPC) или модели «издатель/подписчик» (Redis Pub/Sub или Crossbar.io Pub/Sub) [2]. При конкретной реализации данного вида взаимодействия необходимо учитывать следующие факторы, которые могут повлиять на работоспособность приложения [3]:

  1. Механизм маршрутизации сообщений должен быть разработан таким образом, чтобы гарантировать доставку сообщений всем предполагаемым получающим сервисам.
  2. Возникает необходимость в фильтрации сообщений на основе их содержания, чтобы гарантировать, что те или иные сообщения получат только соответствующие службы. Этого можно достичь с помощью фильтров сообщений или правил маршрутизации.
  3. Данный вид подвержен потере или дублированию сообщений. Для обеспечения надежности сообщений необходимо реализовать такие механизмы, как подтверждение сообщений и повторные попытки их отправки.

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

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

Многие-ко-одному

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

Данный вид обладает следующими характеристиками:

  1. Существует один сервис, обеспечивающий централизованную функциональность или хранение данных, доступ к которым могут получить несколько сервисов.
  2. Может быть много экземпляров отправляющих сервисов, которые взаимодействуют с одним экземпляром получающего сервиса.
  3. Различные части приложения могут использовать общие ресурсы и функциональность без дублирования кода или данных в нескольких сервисах.
  4. Данный вид отношений способствует свободному соединению между сервисами, позволяя им работать независимо, но при этом иметь доступ к общим ресурсам через центральную точку.

image003

Рисунок 3. Пример связи вида «многие-ко-одному».

На практике вид «многий-ко-одному» реализуется с помощью модели «издатель/подписчик» (Redis Pub/Sub) или очереди сообщений. При конкретной реализации данного вида взаимодействия необходимо учитывать следующие факторы, которые могут повлиять на работоспособность приложения:

  1. Центральный сервис, принимающий сообщения, должен быть спроектирован таким образом, чтобы обрабатывать большой объем входящих запросов от множества других сервисов. Это требует тщательного рассмотрения возможностей и производительности системы, а также использования соответствующих механизмов балансировки нагрузки и отказоустойчивости [4].
  2. Центральный сервис должен быть рассчитан на обработку различных типов сообщений и форматов данных. Для этого необходима гибкая и расширяемая архитектура, способная учитывать изменения в схеме данных и форматах сообщений с течением времени.
  3. Необходимо внедрить механизмы безопасности и аутентификации, чтобы гарантировать, что только авторизованные службы могут отправлять сообщения в центральную службу. Это может помочь предотвратить несанкционированный доступ и утечку данных в системе.

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

Многие-ко-многим

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

При использовании данного вида коммуникации важно определить круг задач, в которых данный вид буден уместен. Чаще всего, после декомпозиции одной крупной задачи на более мелкие будут более эффективно проявлять себя уже описанные ранее виды коммуникаций [5].

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

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

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

image004

Рисунок 4. Пример связи вида «многие-ко-многим».

Учитывая всё вышеописанное, вид «многие-ко-многим» является составным и комплексным из более простых видом коммуникации. Этот вид проявляется в сценариях работы приложения, где необходимо сотрудничество и координация между несколькими сервисами при решении комплексных, нетипичных задач. Тем не менее, их совместная работа в конечном итоге будет влиять за отзывчивость и производительность всей системы.

Заключение

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

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

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

Список литературы

  1. Newman S. Building Microservices, 2nd Edition. – Sebastopol: O’Reilly, 2021. – С. 89-177.
  2. Pattern: Messaging [Электронный ресурс]. URL: https://microservices.io/patterns/communication-style/messaging.html (дата обращения 02.05.2023).
  3. Design interservice communication for microservices – Azure Design Center [Электронный ресурс]. URL: https://learn.microsoft.com/en-us/azure/architecture/microservices/design/interservice-communication (дата обращения 04.05.2023).
  4. Малюга К.В., Перл И.А. Особенности коммуникации микросервисов при использовании шаблона сага // Журнал «Инфокоммуникационные технологии», 2021, Т. 19, № 4, С. 425-435.
  5. How to break a Monolith into Microservices [Электронный ресурс]. URL: https://www.martinfowler.com/articles/break-monolith-into-microservices.html (дата обращения 06.05.2023).

Интересная статья? Поделись ей с другими: