Управлять взаимодействием микросервисных приложений в облаке можно с помощью API-шлюза или service mesh.

Какую из технологий лучше выбрать, чтобы конечный пользователь успешно вызывал наш API? По сути, они выполняют одну задачу, но по-разному. 

В этой статье мы рассмотрим обнаружение сервисов в микросервисной архитектуре, сходства и различия между service mesh и API-шлюзом, а также варианты их применения.

Введение

В микросервисной архитектуре нам нужна какая-то технология, например service mesh или API-шлюз, чтобы получать клиентские запросы API и передавать их в бэкенд. Время от времени порты бэкенд-сервисов могут меняться, например из-за сбоя нод, добавления новых нод в сеть и т. д.

API-шлюз сам по себе не умеет определять бэкенд сервис, запрашиваемый клиентом, — он пересылает запрос другому решению, которое отвечает за обнаружение сервисов (например, ZooKeeper, HashiCorp Consul, Eureka или SkyDNS), и спрашивает, где найти сервис с таким именем. Получая ответ, шлюз перенаправляет запрос по этому адресу.

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

Что такое реестр сервисов?

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

Каждый сервис регистрируется в реестре и сообщает свои координаты: хост, порт, имя ноды и другие важные метаданные.

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

Что такое обнаружение сервисов?

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

Обнаружение сервисов (service discovery) позволяет приложениям и микросервисам находить друг друга. Микросервис сообщает данные о себе серверу обнаружения, чтобы все знали, где его можно найти.

Типы обнаружения сервисов

Есть два паттерна обнаружения сервисов: на стороне сервера и на стороне клиента:

• Обнаружение на стороне сервера. Этот паттерн разрешает клиентским приложениям запрашивать сервис через балансировщик нагрузки, который обращается к реестру сервисов, прежде чем перенаправить клиентский запрос. Представьте, что звоните в организацию, и вам отвечает секретарь (балансировщик нагрузки). Он спрашивает, кому вы звоните, и соединяет вас с нужным человеком.

• Обнаружение на стороне клиента. В этом случае клиент сам должен выбрать сервис, запросив реестр сервисов. Он использует алгоритм балансировки нагрузки, чтобы выбрать доступные экземпляры сервиса и сделать запрос. Это похоже на использование поисковых систем — мы вбиваем поисковой запрос в браузере, а браузер (реестр сервисов) ищет ответ и возвращает список URL и номеров портов. Мы просматриваем сайты с ответами и выбираем тот, который отвечает нашим требованиям.

Давайте теперь посмотрим, что такое API-шлюз и service mesh и какой вариант лучше для микросервисной архитектуры.

Что такое API-шлюз

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

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

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

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

Примеры API-шлюзов в нативной облачной экосистеме: Ambassador Edge Stack, Apigee, Amazon API Gateway, MuleSoft, Kong, Tyk.io, Nginx и т. д.

Что такое service mesh?

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

По сути, service mesh берет на себя управление микросервисами и взаимодействием между ними.

Обычно она реализуется через прокси, которые называются sidecar’ами. 

Вернёмся к нашему примеру с интернет-магазином и представим себе, что пользователь начинает оформлять заказ в корзине. Микросервис, которые извлекает данные из корзины для оплаты, должен обратиться к микросервису, который хранит данные профиля пользователя, чтобы подтвердить его личность. И здесь на помощь приходит service mesh. Она обеспечивает взаимодействие между двумя микросервисами, помогая им выполнять свои задачи.

Как и в случае с API-шлюзом, функции service mesh можно закодировать в самом приложении, но это очень трудоёмкий процесс, потому что придётся менять код или конфигурацию приложения, когда изменятся сетевые адреса.

Примеры service mesh в нативной облачной экосистеме: Linkerd, Kuma, Consul, Istio и т. д.

Сходства и различия между service mesh и API-шлюзом

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

В этой части мы рассмотрим сходства и различия между ними.

В чём service mesh и API-шлюз похожи друг на друга:

• Устойчивость. Обе технологии помогают приложению быстро восстановиться после сбоев.

• Управление трафиком. Без service mesh или API-шлюза было бы сложно управлять трафиком клиентских вызовов API, что приводило бы к задержкам при обработке и ответе.

• Обнаружение на стороне клиента. При использовании обеих технологий за запрос и выбор доступных сетевых сервисов отвечает клиент.

• Обнаружение сервисов. Обе технологии помогают приложениям и микросервисам автоматически находить друг друга.

• Наблюдаемость системы. Обе технологии управляют сервисами, доступными для клиентов. Кроме того, они ведут логи клиентов, обращавшихся к тем или иным сервисам. Это помогает отслеживать работоспособность каждого вызова API к микросервису.

Чем service mesh и API-шлюз отличаются друг от друга

• Возможности. API-шлюз служит периферийным микросервисом и выполняет задачи, связанные с бизнес-логикой микросервисов, например преобразование запросов, сложная маршрутизация или обработка полезной нагрузки, тогда как service mesh отвечает только за некоторые аспекты взаимодействия между сервисами.

• Внешняя и внутренняя коммуникации. API-шлюз и service mesh работают на разных уровнях. API-шлюз — на уровне приложения, а service mesh — на уровне инфраструктуры. API-шлюз находится между пользователем и внутренней логикой приложения, а service mesh — между внутренними микросервисами. Как мы уже видели, API-шлюз направлен на бизнес-логику, а service mesh управляет взаимодействием между сервисами.

• Мониторинг и наблюдаемость. API-шлюз помогает отслеживать общую работоспособность приложения по метрикам, которые позволяют выявить проблемные API. Метрики service mesh помогают обнаружить проблемы с различными микросервисами и компонентами в бэкенде приложения, а не во всей программе. Service mesh позволяет определить причину проблем с производительностью приложения.

• Инструменты и поддержка. API-шлюз работает почти с любым приложением или архитектурой, даже монолитными приложениями. Service mesh предназначена только для некоторых решений, например Kubernetes. Кроме того, у API-шлюза есть автоматизированные политики безопасности, и начать работу с ним можно без особого опыта и знаний. Чтобы освоить сложные конфигурации и процессы service mesh, напротив, понадобится немало времени и сил.

• Зрелость. API-шлюзы уже давно успели себя зарекомендовать, и на рынке мы видим много решений от разных вендоров. Service mesh, с другой стороны, пока относительно новая опенсорс-технология, ещё особо не освоенная вендорами.

Могут ли API-шлюз и service mesh сосуществовать?

У этих технологий много общего, но работают они по-разному. API-шлюз — это централизованная control plane на уровне приложения, которая управляет трафиком от клиента к сервисам. Service mesh работает на уровне инфраструктуры, разделяя функционал приложения на микросервисы и управляя коммуникации между внутренними сервисами.

В связке с service mesh API-шлюз может работать как посредник. Такое сочетание повышает безопасность, скорость, доступность и устойчивость приложения, а также упрощает доступ к нему. Это позволят добавлять в стек приложения дополнительный функционал.

Заключение

В каком-то смысле функции API-шлюза и service mesh повторяют друг друга, но в сочетании они предлагают комплексный подход к управлению коммуникациями.

Используйте service mesh вместе с API-шлюзом, чтобы повысить гибкость приложения и упростить жизнь разработчикам.

Упрощённое управление Kubernetes с API-шлюзом Ambassador Edge Stack

Маршрутизация трафика в Kubernetes требует современных инструментов по управлению. Поэтому мы создали Ambassador Edge Stack, который предлагает современный контроллер ingress Kubernetes, поддерживающий широкий ряд протоколов, включая HTTP/3, gRPC, gRPC-Web и терминацию TLS.

Ambassador Edge Stack управляет трафиком, повышая доступность ресурсов.