659,57
Рейтинг
OTUS. Онлайн-образование
Цифровые навыки от ведущих экспертов
20 марта

Использование API Gateway в качестве единой точки входа для веб-приложений и API

Блог компании OTUS. Онлайн-образованиеAPIМикросервисы
Перевод
Автор оригинала: Anandprasanna Gaitonde, Mohit Malik
Перевод статьи подготовлен специально для студентов курса «Архитектор высоких нагрузок».




Введение


Преимущества AWS, такие как высокая доступность, масштабируемость и эластичность, уже доказали свою эффективность для SaaS-провайдеров (Software-as-a-Service). При модернизации SaaS-приложений, AWS помогает плавно перейти на микросервисную архитектуру с предоставлением API-доступа внешним приложениям.

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

API Gateway помогает в создании мультитенантной микросервисной архитектуры. В такой архитектуре для обслуживания разных клиентов используется один экземпляр микросервиса, что позволяет более оптимально использовать ресурсы и оптимизировать затраты. В такой конфигурации для обслуживания своих клиентов от провайдеров требуется поддержка “white-label”-доменов, а также возможность идентификации клиентского домена для привязки специфичной бизнес-логики к конкретному клиенту в бэкенде.

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

Amazon API Gateway — единая точка входа


Построение архитектуры с использованием единого API Gateway для множества веб-приложений и микросервисов является важным фактором для повторного использования компонент и оптимизации затрат.

Amazon API Gateway предоставляет высокомасштабируемое решение для создания и публикации RESTful API и WebSocket API. Для бэкенда можно выбрать различные технологии: функции AWS Lambda, конечные автоматы AWS Step Functions или вызов конечных точек HTTP, размещенных на AWS Elastic Beanstalk, Amazon EC2 или вне AWS.

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

Создать описанную здесь архитектуру, помимо вышеперечисленного, помогают следующие ключевые функции API Gateway.

1. Поддержка пользовательских доменных имен:


При развертывании API с использованием API Gateway, доменное имя конечной точки API по умолчанию не очень удобно для конечного пользователя:

https://api-id.execute-api.region.amazonaws.com/stage

  • api-id генерируется API Gateway;
  • region указывается вами при создании API;
  • stage указывается вами при развертывании API.

С конечной точкой API по умолчанию может быть трудно работать. Но благодаря интеграции с AWS Certificate Manager, который позволяет выполнять проверку поддоменов на основе SSL-сертификатов, можно предоставить пользователям вашего API более простой и интуитивно понятный URL, например, customer1.example.com. API Gateway позволяет сопоставить несколько поддоменов с одной конечной точкой API, что позволяет использовать “white label”-имена в соответствии с требованиями внешних клиентов.

2. Модификация запросов/ответов API


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

Преимущества такой архитектуры


Описанные в этой статье возможности показаны на диаграмме ниже.



Здесь приведена архитектура для типичного SaaS-провайдера, который предлагает свои услуги другим организациям и должен поддерживать “white-label”-домены для веб- и API — инфраструктуры. Подобная архитектура достигается с помощью следующих шагов:

  1. Домен example.com может быть зарегистрирован у регистратора доменов, а вы можете создавать поддомены через CNAME-записи, например, customer1.example.com, customer2.example.com. Это можно сделать в AWS с помощью сервиса Amazon Route 53 или через любого стороннего DNS-провайдера.
  2. После этого можно воспользоваться AWS Certificate Manager (ACM) для создания сертификата доменов example.com и *.example.com. Что необходимо для возможности обслуживания поддоменов ACM-сертификатом, примененным к API Gateway.
  3. Используя сертификат, созданный в ACM, можно создать свой домен для конечной точки API. В нашем примере конечная точка API обслуживает два поддомена у разных клиентов с настройкой необходимых сопоставлений. Для этого создаются два поддомена: customer1.example.com и customer2.example.com.

Примечание: не забудьте добавить CNAME-записи для customer1 и customer2 в DNS, чтобы указать эти имена в настройках API Gateway.



4. API Endpoint настраивается следующим образом


  • /service1 — integration type HTTP, маршрутизация трафика на конечную точку микросервиса ELB, размещенного в кластере ECS
  • /service2 — integration type HTTP, маршрутизация трафика на конечную точку веб-приложения ELB, размещенного в кластере EC2
  • /docs — integration type AWS S3, для статических документов



5. API Gateway может обрабатывать полное доменное имя (FQDN) в URL-адресе и сопоставлять его с пользовательскими заголовками или параметрами в строке запроса для отправки на соответствующий бэкенд.

Например, мы можем создать пользовательский заголовок “Customer” для перенаправления customer1 или customer2 в специфичное для клиента бэкэнд-приложение. Это делается с помощью параметров Method Request и Integration Request в API Gateway.

Итог


Как видите, это только один из примеров использования API Gateway в качестве единой точки входа для микросервисов, основанных на API, и статических ресурсов веб-приложений. API Gateway позволяет более эффективно использовать инфраструктуру без потери масштабирования при увеличении нагрузки на ваши приложения. Подробнее о работе с API Gateway и Route 53 DNS можно прочитать в документации AWS и использовать эти возможности для создания архитектур, соответствующих вашим требованиям.
Теги:amazon api gatewayapplication load balanceraws lambdacertificationmicroservicesRoute 53
Хабы: Блог компании OTUS. Онлайн-образование API Микросервисы
+8
8,2k 33
Комментарии 5
Похожие публикации
Лучшие публикации за сутки
Информация
Дата основания

1 мая 2017

Местоположение

Россия

Сайт

otus.ru

Численность

31–50 человек

Дата регистрации

22 марта 2017

Блог на Хабре