Перевод статьи подготовлен специально для студентов курса «Архитектор высоких нагрузок».
![](https://habrastorage.org/webt/di/rs/bc/dirsbcrebdyww6pq5uacvb1nk7o.png)
Преимущества AWS, такие как высокая доступность, масштабируемость и эластичность, уже доказали свою эффективность для SaaS-провайдеров (Software-as-a-Service). При модернизации SaaS-приложений, AWS помогает плавно перейти на микросервисную архитектуру с предоставлением API-доступа внешним приложениям.
Инструменты управления API, такие как Amazon API Gateway — это естественный выбор для предоставления безопасного и масштабируемого внешнего API. Однако, при переводе своих приложений в облака, SaaS-провайдеры часто сталкиваются с необходимостью быстрого развертывания своих сервисов для нескольких разных клиентов. И, конечно, со специфическими требованиями каждого из них.
API Gateway помогает в создании мультитенантной микросервисной архитектуры. В такой архитектуре для обслуживания разных клиентов используется один экземпляр микросервиса, что позволяет более оптимально использовать ресурсы и оптимизировать затраты. В такой конфигурации для обслуживания своих клиентов от провайдеров требуется поддержка “white-label”-доменов, а также возможность идентификации клиентского домена для привязки специфичной бизнес-логики к конкретному клиенту в бэкенде.
В этой статье рассказывается об эталонной архитектуре, которая позволяет использовать API Gateway как единую точку входа для веб-приложений и микросервисов, основанных на API, с несколькими внешними клиентами, используя для каждого из них разные поддомены.
Построение архитектуры с использованием единого 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.
При развертывании API с использованием API Gateway, доменное имя конечной точки API по умолчанию не очень удобно для конечного пользователя:
С конечной точкой API по умолчанию может быть трудно работать. Но благодаря интеграции с AWS Certificate Manager, который позволяет выполнять проверку поддоменов на основе SSL-сертификатов, можно предоставить пользователям вашего API более простой и интуитивно понятный URL, например,
API Gateway позволяет для каждой части адреса конечной точки API настроить отдельную обработку. Благодаря этому можно маршрутизировать запросы API в отдельные конечные точки бэкэнда, а также одновременно с этим изменять заголовки в запросе/ответе для более гибкой обработки API-запросов.
Описанные в этой статье возможности показаны на диаграмме ниже.
![](https://habrastorage.org/webt/rk/it/jm/rkitjm-npyu_3zwq7wccli8spcg.png)
Здесь приведена архитектура для типичного SaaS-провайдера, который предлагает свои услуги другим организациям и должен поддерживать “white-label”-домены для веб- и API — инфраструктуры. Подобная архитектура достигается с помощью следующих шагов:
Примечание: не забудьте добавить CNAME-записи для customer1 и customer2 в DNS, чтобы указать эти имена в настройках API Gateway.
![](https://habrastorage.org/webt/gu/83/qr/gu83qry13r5dogz6rxj0wvtekhi.png)
![](https://habrastorage.org/webt/fr/f6/q_/frf6q_io-v5bojoxt42ptvdiqxg.png)
Как видите, это только один из примеров использования API Gateway в качестве единой точки входа для микросервисов, основанных на API, и статических ресурсов веб-приложений. API Gateway позволяет более эффективно использовать инфраструктуру без потери масштабирования при увеличении нагрузки на ваши приложения. Подробнее о работе с API Gateway и Route 53 DNS можно прочитать в документации AWS и использовать эти возможности для создания архитектур, соответствующих вашим требованиям.
![](https://habrastorage.org/webt/di/rs/bc/dirsbcrebdyww6pq5uacvb1nk7o.png)
Введение
Преимущества 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-запросов.
Преимущества такой архитектуры
Описанные в этой статье возможности показаны на диаграмме ниже.
![](https://habrastorage.org/webt/rk/it/jm/rkitjm-npyu_3zwq7wccli8spcg.png)
Здесь приведена архитектура для типичного SaaS-провайдера, который предлагает свои услуги другим организациям и должен поддерживать “white-label”-домены для веб- и API — инфраструктуры. Подобная архитектура достигается с помощью следующих шагов:
- Домен
example.com
может быть зарегистрирован у регистратора доменов, а вы можете создавать поддомены через CNAME-записи, например,customer1.example.com
,customer2.example.com
. Это можно сделать в AWS с помощью сервиса Amazon Route 53 или через любого стороннего DNS-провайдера. - После этого можно воспользоваться AWS Certificate Manager (ACM) для создания сертификата доменов
example.com
и*.example.com
. Что необходимо для возможности обслуживания поддоменов ACM-сертификатом, примененным к API Gateway. - Используя сертификат, созданный в ACM, можно создать свой домен для конечной точки API. В нашем примере конечная точка API обслуживает два поддомена у разных клиентов с настройкой необходимых сопоставлений. Для этого создаются два поддомена:
customer1.example.com
иcustomer2.example.com
.
Примечание: не забудьте добавить CNAME-записи для customer1 и customer2 в DNS, чтобы указать эти имена в настройках API Gateway.
![](https://habrastorage.org/webt/gu/83/qr/gu83qry13r5dogz6rxj0wvtekhi.png)
4. API Endpoint настраивается следующим образом
/service1
— integration type HTTP, маршрутизация трафика на конечную точку микросервиса ELB, размещенного в кластере ECS/service2
— integration type HTTP, маршрутизация трафика на конечную точку веб-приложения ELB, размещенного в кластере EC2/docs
— integration type AWS S3, для статических документов
![](https://habrastorage.org/webt/fr/f6/q_/frf6q_io-v5bojoxt42ptvdiqxg.png)
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 и использовать эти возможности для создания архитектур, соответствующих вашим требованиям.
mr_tron
Я не очень больший специалист по ценообразованию амазона, но вроде же api gateway существенно удорожает обработку каждого запроса.
habr.com/ru/post/481664
или вот официальный сайт
aws.amazon.com/api-gateway/pricing
Причём сферическая в вакууме приложуха на го на инстансе за 30 баксов в месяц без проблем справится с такой нагрузкой.
В теории можно было бы экономить на персонале, но мой опыт конфигурирования апи гейтвея показывает, что проще обучиться писать на го.
VolCh
То, что в посте описано можно и на голом nginx сделать