В архитектуре микрослужб клиент может взаимодействовать с несколькими интерфейсными службами. Учитывая этот факт, как клиент знает, какие конечные точки следует вызывать? Что происходит при появлении новых служб или рефакторинг существующих служб? Как службы обрабатывают завершение SSL, взаимную проверку подлинности, проверку подлинности и другие проблемы? Шлюз API может помочь решить эти проблемы.
схема
Скачайте файл Visio этой архитектуры.
Что такое шлюз API?
Шлюз API предоставляет централизованную точку входа для управления взаимодействием между клиентами и службами приложений. Он выступает в качестве обратного прокси-сервера и направляет клиентам запросы к соответствующим службам. Кроме того, он может выполнять различные межсессовые задачи, такие как проверка подлинности, завершение SSL, взаимное tls и ограничение скорости.
Зачем использовать шлюз API?
Шлюз API упрощает обмен данными, улучшает взаимодействие с клиентом и центрирует управление общими обязанностями уровня обслуживания. Он выступает в качестве посредника и предотвращает прямое воздействие служб приложений клиентам. Без шлюза API клиенты должны напрямую взаимодействовать с отдельными службами приложений, что может привести к следующим проблемам:
сложный код клиента. Это может привести к сложному клиентскому коду. Клиенты должны отслеживать несколько конечных точек и обрабатывать сбои устойчиво.
Жесткое связывание: создает связь между клиентом и серверной частью. Клиентам необходимо понимать декомпозицию отдельных служб, усложняя обслуживание служб и рефакторинг.
увеличение задержки. Для одной операции может потребоваться вызовы нескольких служб. Результатом может быть несколько обходов по сети между клиентом и сервером, что приводит к значительной задержке.
избыточность обработки проблем. Каждая общедоступная служба должна обрабатывать такие проблемы, как проверка подлинности, SSL и ограничение скорости клиента.
ограничения протокола: службы должны предоставлять удобный для клиента протокол, например HTTP или WebSocket. Это ограничение протоколов связи.
расширенная область атак: общедоступные конечные точки увеличивают потенциальную область атаки и требуют ужесточения.
Использование шлюза API
Шлюз API можно адаптировать к требованиям приложения с помощью определенных шаблонов проектирования. Эти шаблоны проектирования касаются основных функций, таких как маршрутизация, агрегирование запросов и перекрестные проблемы:
маршрутизации шлюза. Шлюз API можно использовать в качестве обратного прокси-сервера для маршрутизации клиентских запросов в разные службы приложений. Шлюз API использует маршрутизацию уровня 7 и предоставляет одну конечную точку для использования клиентами. Используйте маршрутизацию шлюза API, если вы хотите отделить клиентов от служб приложений.
агрегирование шлюза. Шлюз API можно использовать для объединения нескольких клиентских запросов в один запрос. Используйте этот шаблон, если для одной операции требуется несколько вызовов служб приложений. В агрегации API клиент отправляет один запрос в шлюз API. Затем шлюз API направляет запросы к различным службам, необходимым для операций. Наконец, шлюз API объединяет результаты и отправляет их клиенту. Агрегирование помогает уменьшить взаимодействие между клиентом и службами приложений.
разгрузка шлюза. Шлюз API можно использовать для предоставления перекрестной функциональности, поэтому отдельные службы не должны предоставлять его. Это может быть полезно для консолидации перекрестной функциональности в одном месте, а не для каждой службы ответственности. Ниже приведены примеры функций, которые можно выгрузить в шлюз API:
- Завершение SSL
- Взаимное TLS
- Аутентификация
- Список разрешенных IP-адресов или список блокировок
- Ограничение скорости клиента (регулирование)
- Ведение журнала и мониторинг
- Кэширование ответов
- Брандмауэр веб-приложения
- Сжатие GZIP
- Обслуживание статического содержимого
Параметры шлюза API
Ниже приведены некоторые варианты реализации шлюза API в приложении.
сервер обратного прокси-сервера. Nginx и HAProxy — это предложения обратного прокси-сервера с открытым исходным кодом. Они поддерживают такие функции, как балансировка нагрузки, завершение SSL и маршрутизация уровня 7. У них есть бесплатные версии и платные выпуски, которые предоставляют дополнительные функции и варианты поддержки. Эти продукты зрелы с богатыми наборами функций, высокой производительностью и расширяемыми.
контроллер входящего трафикасетки службы. Если вы используете сетку службы, оцените функции контроллера входящего трафика, относящиеся к этой сетке службы. Проверьте поддерживаемые AKS надстройки, такие как Istio и Open Service Mesh. Найдите сторонние проекты с открытым кодом, такие как Компоновщик или Consul Connect. Например, контроллер Istio ingress поддерживает маршрутизацию уровня 7, перенаправления HTTP, повторные попытки и другие функции.
шлюз приложений Azure. Шлюз приложений — это управляемая служба балансировки нагрузки. Он обеспечивает маршрутизацию уровня 7, завершение SSL и брандмауэр веб-приложения (WAF).
Azure Front Door. Azure Front Door — это сеть доставки содержимого (CDN). Он использует глобальные и локальные точки присутствия (PoPs) для обеспечения быстрого, надежного и безопасного доступа к статическому и динамическому веб-контенту приложений глобально.
управление API Azure. Управление API — это управляемое решение для публикации API для внешних и внутренних клиентов. Он предоставляет функции для управления общедоступными API, включая ограничение скорости, ограничения IP-адресов и проверку подлинности с помощью идентификатора Microsoft Entra или других поставщиков удостоверений. Управление API не выполняет балансировку нагрузки, поэтому ее следует использовать с подсистемой балансировки нагрузки, например шлюзом приложений Azure или обратным прокси-сервером. Дополнительные сведения см. в статье Управление API с помощью шлюза приложений Azure.
Выбор технологии шлюза API
При выборе шлюза API учитывайте следующие факторы:
Поддержка всех требований. Выберите шлюз API, поддерживающий необходимые функции. Все предыдущие параметры шлюза API поддерживают маршрутизацию уровня 7. Но их поддержка других функций, таких как проверка подлинности, ограничение скорости и завершение SSL, могут отличаться. Оцените, соответствует ли один шлюз вашим потребностям или требуется ли несколько шлюзов.
Предпочитайте встроенные предложения. Используйте встроенный шлюз API и решения для входящего трафика, предоставляемые вашей платформой, например приложения контейнеров Azure и AKS, когда они соответствуют вашим требованиям к безопасности и контролю. Используйте только настраиваемый шлюз, если встроенные параметры не имеют необходимой гибкости. Пользовательские решения требуют модели управления, например GitOps, для эффективного управления жизненным циклом.
Выберите нужную модель развертывания. Используйте управляемые службы, такие как Шлюз приложений Azure и управление API Azure, для снижения рабочих накладных расходов. Если вы используете обратные прокси-серверы общего назначения или подсистемы балансировки нагрузки, разверните их таким образом, чтобы выровнять архитектуру. Шлюзы API общего назначения можно развернуть на выделенных виртуальных машинах или в кластере AKS в предложениях контроллера входящего трафика. Чтобы изолировать шлюз API от рабочей нагрузки, их можно развернуть за пределами кластера, но это развертывание повышает сложность управления.
Управление изменениями. При обновлении служб или добавлении новых служб может потребоваться обновить правила маршрутизации шлюза. Реализуйте процессы или рабочие процессы для управления правилами маршрутизации при добавлении или изменении служб, SSL-сертификатов, списков разрешений IP-адресов и конфигураций безопасности. Используйте средства инфраструктуры как кода и автоматизации для упрощения управления шлюзом API.
Дальнейшие действия
В предыдущих статьях рассматриваются интерфейсы, между микрослужбами и между микрослужбами и клиентскими приложениями. Эти интерфейсы рассматривают каждую службу как автономную непрозрачную единицу. Критически важным принципом архитектуры микрослужб является то, что службы никогда не должны предоставлять внутренние сведения о том, как они управляют данными. Этот подход имеет значительные последствия для поддержания целостности и согласованности данных, который является предметом следующей статьи.
рекомендации по данных для микрослужб