AWS API Gateway Lambda 作为微服务的代理答案

【问题标题】：AWS API Gateway Lambda as a proxy for microservicesAWS API Gateway Lambda 作为微服务的代理
【发布时间】：2018-01-11 21:40:45
【问题描述】：

由于我的项目将部署在 AWS 上，我们开始考虑将 AWS API Gateway 作为一种为所有微服务提供一个主要入口点的方式（坦率地说，我们也希望出于安全等其他一些原因使用）。我在玩 API Gateway REST API，我觉得如果我们必须在那里注册我们拥有的每个 REST 服务，这有点不合时宜。

我发现使用 AWS API Gateway 和 lambda 函数 作为代理是一个很好的选择。这里有描述：

我想知道您对这种方法的看法。您是否还可以分享一些其他可以简化 REST API 的 API 网关配置的方法？

【问题讨论】：

使用脚本自动化而不是在控制台中构建您的 API，也许吧？

标签： amazon-web-services aws-lambda microservices aws-api-gateway api-gateway

【解决方案1】：

当您通过 API Gateway 代理现有服务时，需要注意的事项很少。

如果您的后端不是公开的，那么您需要设置一个 VPC 和一个从 VPC 到您的后端网络的站点到站点 VPN 连接，并使用 Lambda 代理您的服务。
如果您需要进行任何数据转换或聚合，则需要使用 Lambda（内部 VPC 是可选的，除非需要 VPN 连接）。
如果您的服务在 API 网关后面有复杂的集成，您可以考虑在您的本地或 AWS 中运行 ESB 或消息中间件，然后代理到 API 网关。
您可以将数据模型架构验证移至 API Gateway。
您可以通过编写自定义授权方 Lambda 将服务身份验证移至 API 网关。
如果您碰巧将用户池和身份服务迁移到 AWS，您可以迁移到 AWS Cognito Manage Service 并使用 API Gateway 中的 AWS Cognito Authorizer 进行身份验证。

【讨论】：

【解决方案2】：

对于采用哑管道的用例（如martinfowler.com 所述），AWS API Gateway 是一个合理的选择。对于 AWS API Gateway，我建议先使用 RAML 或 OpenAPI/Swagger 描述/设计您的 API，然后使用 AWS API Importer 导入 AWS。

一旦您计划在其中移动逻辑，例如动态路由、详细监控、警报等，我建议您考虑其他方法，例如：

Apigee
Mulesoft
WSO2

您还可以将它们托管在您的 VPC 内的 EC2 上，或者选择加入托管版本。（在某些情况下确实有很高的价格标签）

要描述 API，您可以使用 RAML（用于 Mulesoft）或 OpenAPI（前 Swagger，用于 Apigee 和 WSO2）。您还可以使用 APIMATIC 在它们之间进行转换，这使您能够跨各种 API 网关（甚至 AWS）迁移您的规范。

【讨论】：