通过 API 网关的内部通信微服务

Question

在微服务架构中，有一种常见的模式叫做API网关。

我知道来自 API 网关外部的所有通信都用作单个入口点。

但我还希望从微服务到微服务的内部通信通过 API 网关？我的意思是它比建立点对点连接更容易处理。

那么，为什么要在整个内部通信中也使用 API 网关呢？

Answer 1

我试过三种口味

1. 所有通信都通过 API 网关 它使服务发现变得容易，所有通信都可以在一个点上被跟踪，但它增加了网关后面服务的延迟（不是很多，而是多了一跳）。您也可以去除身份验证，这意味着所有服务，即使是网关后面的服务也需要获得正确的身份验证（这对某些应用程序可能不是缺点，但对其他应用程序来说可能是）
2. 通过网关的外部服务 它可以帮助您在网关处去除身份验证。您可以对传入请求强制执行更严格的检查，您的服务直接相互通信（但这意味着它们需要以某种方式发现服务，我们使用基于 route53 的 dns，因此它们访问的端点保持不变）。服务相互信任，这些通信不需要身份验证。
3. External/Internal 网关 我们还有一个场景，我们必须获得两个 api 网关，一个原因是两组网关需要不同类型的检查，并且每个网关都必须承受不同的负载集。

Answer 2

您可能需要考虑第一种方法（API 内部和外部调用的网关）的两个问题：

1. 网关服务的负载会变高。如果内部服务平均对任何其他内部服务进行一次调用，则网关服务的负载将增加一倍。这可能会导致额外的延迟，不仅仅是因为额外的跃点，而且每个请求都必须经过网关服务实例上的额外负载。这将迫使您增加网关服务硬件（水平或垂直），但没有实际好处。

2. 一旦负载增加并触及网关服务实例的峰值容量，这些实例可能会 运行 耗尽其工作线程和内存等资源。一般来说，这种情况可以通过减载或节流一些新请求来处理。这可能意味着在负载下降之前，我们可能只会处理一定比例的请求。然而，在我们的例子中，不仅新请求受到影响，而且所有那些等待网关服务资源被释放用于内部调用的 in-flight 旧请求也被阻止 for-ever 直到它们超时，因为这些 in-flight 请求正在等待原始请求（它们自己）完成。因此，我们最终会得到一个死锁系统，在负载下降之前根本不会为任何请求提供服务。如果没有正确实现超时，系统甚至可能会永久死锁，直到死锁的网关服务实例被回收。

对于内部服务可以直接与其他内部服务通信的第二种方法，我们可以使用 client-side 负载均衡器以及通过发现服务或 DNS 进行的服务发现。与第一种方法相比，这不仅性能更好，而且需要的硬件更少。