使用 AWS API Gateway Lambda/ECS 开发的微服务应该如何讨论？

Question

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

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

• 1个公共API网关
• 每个微服务1个私有API网关。每个微服务都可以在私有网络内“直接”html" target="_blank">调用另一个微服务

但是这样，我需要在2个级别的API中“复制”我的路由……这似乎并不理想。我在想也许可以使用{代理}。所以任何/支付/{代理}都进入支付API网关等等——还有2个级别的API网关……但这似乎是我能去的最好的地方？

也许有更好的方法？

Answer 1

除了绑定到当前设置和基础结构之外，还有多种方式和方法可以做到这一点，而不排除实现/修改现有代码库的灵活性。

当使用HTTP在服务之间进行通信时，通常会看到流量从当前基础架构中流出，然后通过同一个API网关返回，这可以通过直接进入其他服务来避免。

例如，在上一张图中，当服务B需要与服务A通信时，建议通过内部（ELB）endpoint进行通信，而不是通过API网关外出和返回。

另一种方法是在 API 网关中“仅”使用 HTTP，并使用其他协议在服务中进行通信，例如 gRPC。（在某些情况下不是最佳选择，因为取决于您的架构和修改/调整现有代码的灵活性）

在有些情况下，您的基础架构更加复杂，您可能无法在容器内按需通信，或者endpoint无法到达，在这种情况下，您可以尝试实现事件驱动的架构(SQS和AWS Lambda)

我喜欢在可能的情况下通过使用事件/队列进行异步，从我的角度来看，“规模”更好，服务必须成为消费者/工作者，除了不需要侦听传入请求（不需要HTTP）之外，这里有一篇文章，解释了如何使用Rabbitmq为此目的在docker中通信微服务

这些只是一些想法，希望可以帮助你找到自己的“最佳”方式，因为这是一件变化太多，每个场景都是独一无二的事情。

Answer 2

我将假设 Lambda 作为解决方案，但它们也可以是 ECS 实例或 ELB。

在进入解决方案之前，要理解lambdas的一个重要概念是应用程序代码和< code>event_source的解耦。

事件源是调用应用程序代码的另一种方式。您提到了 API 网关，这只是调用 lambda 的一种方法（HTTP 请求）。与解决方案相关的其他有趣的事件源包括：

• API 网关（如前所述，对服务间通信无效）
• 直接调用（通过 AWS 开发工具包，可以是同步或异步）
• SNS （pub/sub， eventbus）
调用
• lambda 有 20 多种不同的方式。 文档

因此，如果您的HTTP_RESPONSE依赖于一个lambda调用另一个lampda以及第二个lambdas结果。直接调用可能是一个足够好的解决方案，这样您可以以同步方式调用lambda。这也意味着，lambda应该订阅API网关作为事件源，并具有规范化两种不同类型事件的代码。（这就是为什么lambda文档通常将事件作为参数之一）

如果你的HTTP响应不依赖于其他微服务(lambdas)的执行。对于这个用例，我强烈推荐SNS，因为您的原始lambda发布了一个事件，您可以让多个lambda订阅并行执行的事件。

对于更复杂的用例：

< li >批处理，扇出模式示例#1示例#2 < li >并发执行(一个lambda调用next，调用next...etc) AWS步骤功能

Answer 3

将会有许多方法来建立微服务。我首先会让你熟悉AWS发布的白皮书:AWS上的微服务，白皮书- PDF版本。

在你的问题中，你说:“现在的问题是服务之间的通信是通过API网关的API调用。这让人感觉效率低下，而且不太安全。有没有办法让我的微服务以更高性能、更安全的方式相互对话？”

是 - 事实上，AWS 白皮书和 API 网关常见问题解答将 API 网关称为应用程序的“前门”。API Gateway 的目的是用于与您的 AWS 服务通信的外部服务。不是 AWS 服务相互通信。

AWS资源可以通过多种方式相互通信以调用微服务。白皮书中概述了其中一些，这是我使用的另一个资源：Better Together：Amazon ECS和AWS Lambda。您使用的服务将基于您的需求。

通过将单片应用程序拆分为小型微服务，通信开销会增加，因为微服务必须相互通信。在许多实现中，REST over HTTP被用作通信协议。这是一个轻量级的协议，但高容量可能会导致问题。在某些情况下，考虑合并来回发送大量消息的服务可能是有意义的。如果您发现自己正处于这样一种情况，即您整合了越来越多的服务，只是为了减少闲聊，那么您应该检查您的问题域和域模型。

据我所知，您的问题的根源是将请求路由到微服务。为了维护“微服务的特性”，您应该选择单一的解决方案来管理路由。

您提到使用API Gateway作为路由解决方案。API Gateway可用于路由…但是，如果您选择使用API Gateway进行路由，您应该在一个级别中显式定义您的路由。为什么？

1. 使用{代理}会增加攻击面，因为它需要在另一个微服务中正确处理路由。
2. 在API网关中定义路由的优势之一是您的API是自文档的。如果您有多个API网关，它将成为合谋。

这样做的缺点是需要时间，并且您可能必须更改已经定义的现有API。但是，您可能已经对现有代码库进行了更改，以遵循微服务最佳实践。

尽管上面列出了使用 API 网关进行路由的原因，但如果配置正确，另一个资源可以正确处理路由。您可以将 API 网关代理到定义了所有微服务路由的 Lambda 函数，或者将 VPC 中定义了路由的其他资源代理。

你做什么取决于你的要求和时间。如果您已经在某个地方定义了一个API，并且只是希望使用API Gateway来限制、监视、保护和记录请求，那么您将使用API Gateway作为代理。如果您想充分受益于API Gateway，请明确定义其中的每条路由。这两种方法都可以遵循微服务最佳实践，然而，我认为在API Gateway中定义每个公共API是符合微服务架构的最佳方式。其他答案也很好地解释了每种方法的利弊。