Паттерны коммуникации микросервисов
В списке архитектурных шаблонов по коммуникации микросервисов представлены способы обеспечения внешних взаимодействий. Речь идет о взаимодействиях микросервисов с удаленными сервисами, клиентскими приложениями и т. п.
API Gateway
Как известно, самый очевидный вариант обращения к микросервисам заключается в прямом обращении от клиента к сервису, причем такое решение вполне себя оправдывает в небольших проектах. Однако когда разговор заходит о приложениях корпоративного масштаба, где существует большое количество микросервисов, то тут пригодится шаблон API Gateway («API-шлюз»).
Данный паттерн основывается на использовании шлюза, находящегося между микросервисами и клиентским приложением. Таким образом обеспечивается единая точка входа для клиента.
С учетом конкретной цели применения этого шаблона, разделяют ряд его разновидностей:
- Gateway Routing. В этой ситуации шлюз применяется в качестве обратного Proxy, который перенаправляет запросы клиента на определенный сервис.
- Gateway Offloading. Этот шлюз решает сквозные задачи, являющиеся общими для таких сервисов, как авторизация, аутентификация, SSL, ведение журналов и т. д.
- Gateway Aggregation. Шлюз применяется в целях разветвления запроса клиента на несколько микросервисов с последующим возвращением агрегированных ответов клиенту.
Использование паттерна API Gateway сокращает количество вызовов, что обеспечивает независимость клиента от протоколов, которые применяются в сервисах: AMQP, gRPC, REST и т. д. Таким образом обеспечивается централизованное управление сквозной функциональностью. Но тут следует понимать, что шлюз способен стать единой точкой отказа, то есть он требует тщательного мониторинга. К тому же, в случае отсутствия масштабирования шлюз нередко бывает узким местом системы.
Backends for Frontends
Паттерн «Бэкенды для фронтендов» (BFF) -- это, по сути, другой способ реализации шаблона API Gateway. Он тоже обеспечивает дополнительный уровень между клиентами и микросервисами с той лишь разницей, что вместо одной точки входа он вводит несколько шлюзов для каждого типа клиента: Mobile, Web, Desktop и пр.
Посредством этого паттерна появляется возможность добавлять API, адаптированные к потребностям практически каждого клиента, то есть мы избавляемся от необходимости хранения большого числа ненужных настроек в одном месте. Однако этот шаблон не стоит использовать в случаях, когда различия в требованиях к API у разных клиентских типов незначительны или программное приложение является небольшим само по себе -- вы получите неоправданное дублирование кода и увеличение числа компонентов.
По материалам https://mcs.mail.ru/blog/.
