Лямбда-архитектура на AWS и API Gateway - PullRequest
Новая
       34

Лямбда-архитектура на AWS и API Gateway

0 голосов
/ 29 января 2019

Я использую Lambda Architecture.Слои Batch & Speed ​​находятся на AWS EMR.Обслуживающий уровень находится на AWS ECS, простом и очень тонком REST-сервере, который объединяет представления уровней Batch / Speed ​​и возвращает их клиенту.Обслуживающие слои располагаются за AWS ALB и AWS WAF.

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

Мое понимание сценариев использования шлюза API:

  1. Межсекторальные вопросы, например, авторизация, безопасность, управление трафиком API.
  2. Снижайте трафик, т. Е. Платите пользователям задержку в сети (или медленно инернет) только один раз при вызове API-шлюза, все остальные внутренние запросы должны выполняться быстро.+ Завершение SSL.
  3. Внутренние URI скрыты за шлюзом API.Это подходящее место для управления версиями API.

Но в архитектуре Lambda все скрыто за обслуживающим уровнем.Означает, что все сквозные проблемы будут внутри одного сервиса.Я говорю об авторизации, безопасности и управлении версиями.Для управления версиями я создам отдельную конечную точку для каждого клиента, если это необходимо (Web, Android и iOS). Это правильно?

Некоторая часть управления безопасностью и трафиком может быть выполнена на AWS WAF и AWS ELB.

Для каких случаев мне следует использовать API Gatewayв моем случае?

1 Ответ

0 голосов
/ 29 января 2019

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

...