amazon-web-services - 使用 AWS API Gateway + Lambda/ECS 开发的微服务应该怎么讲？

Question

我正在开发一个“微服务”应用程序，使用 AWS API Gateway 和 Lambda 或 ECS 进行计算。现在的问题是服务之间的通信是通过 API 网关通过 API 调用进行的。这让人感觉效率低下且安全性低于实际情况。有没有办法让我的微服务以更高性能和更安全的方式相互通信？就像以某种方式直接在专用网络内交谈？

我想到的一种方法是多级 API 网关。

1 个公共(public) API 网关

每个微服务 1 个私有(private) API 网关。并且每个微服务都可以在私网内“直接”调用另一个微服务

但是通过这种方式，我需要在 2 级 API 中“复制”我的路线……这似乎并不理想。我在想也许可以使用 {proxy+} .所以任何事情 /payment/{proxy+}转到支付 API 网关等等 - 还有 2 级 API 网关......但这似乎是我能去的最好的？

也许有更好的方法？

Answer 1

构建微服务的方法有很多种。我将首先熟悉 AWS 发布的白皮书:Microservices on AWS , Whitepaper - PDF version .
在您的问题中，您说:“现在的问题是服务之间的通信是通过 API 网关通过 API 调用进行的。这感觉效率低下，安全性也比它低。有没有办法让我的微服务以更高的性能相互通信和安全的方式？”
是的 - 事实上，AWS 白皮书和 API Gateway FAQ将 API Gateway 称为应用程序的“前门”。 API Gateway 的目的是用于与您的 AWS 服务通信的外部服务......而不是 AWS 服务相互通信。
AWS 资源可以通过多种方式相互通信以调用微服务。白皮书中概述了一些，这是我使用的另一个资源:Better Together: Amazon ECS and AWS Lambda .您使用的服务将基于您的要求。

By breaking monolithic applications into small microservices, the communication overhead increases because microservices have to talk to each other. In many implementations, REST over HTTP is used as a communication protocol. It is a light-weight protocol, but high volumes can cause issues. In some cases, it might make sense to think about consolidating services that send a lot of messages back and forth. If you find yourself in a situation where you consolidate more and more of your services just to reduce chattiness, you should review your problem domains and your domain model.

据我了解，您问题的根源是将请求路由到微服务。要维护“ Characteristics of Microservices”，您应该选择单一解决方案来管理路由。
API 网关
您提到使用 API Gateway 作为路由解决方案。 API Gateway 可用于路由...但是，如果您选择使用 API Gateway 进行路由，您应该在一个级别中明确定义您的路由。为什么？

使用 {proxy+} 会增加攻击面，因为它需要在另一个微服务中正确处理路由。

在 API Gateway 中定义路由的优点之一是您的 API 是自记录的。如果您有多个 API 网关，它将被勾结。

这样做的缺点是需要时间，并且您可能必须更改已经定义的现有 API。但是，您可能已经在对现有代码库进行更改以遵循微服务最佳实践。
Lambda 或其他计算资源
尽管上面列出了使用 API Gateway 进行路由的原因，但如果配置正确，另一个资源可以正确处理路由。您可以将 API 网关代理到定义了所有微服务路由的 Lambda 函数或 another resource within your VPC定义了路线。
结果
你做什么取决于你的要求和时间。如果您已经在某处定义了 API，并且只是希望 API Gateway 用于限制、监控、保护和记录请求，那么您将 API Gateway 作为代理。如果您想充分受益于 API Gateway，请在其中明确定义每个路由。两种方法都可以遵循微服务最佳实践，但是，这是我的 意见在 API Gateway 中定义每个公共(public) API 是与微服务架构保持一致的最佳方式。其他答案也很好地解释了每种方法的权衡。