通过 API 网关进行内部通信微服务

Question

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

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

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

那么，在整个内部通信中也使用 API 网关有什么反对意见？

Answer 1

我试过三种口味

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

Answer 2

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

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

2) 一旦负载变高并触及网关服务实例的峰值容量，这些实例可能会开始耗尽其资源，尤其是处理线程或正在调用的线程。一般来说，这种情况可以通过减载或限制一些新请求来处理。这可能意味着在负载下降之前，我们可能只服务一部分请求。然而，在我们的例子中，不仅新请求受到影响，而且所有那些等待网关服务资源被释放以进行内部调用的正在运行的旧请求也被永远阻塞，直到它们超时，因为这些请求是等待自己完成。我们最终得到了一个死锁的系统，在负载下降之前根本不会提供任何请求。如果超时没有正确实现，它甚至可能会永久死锁并且需要回收实例。

无论如何，这些都是我们在设计微服务时需要解决的一些挑战，但在这种情况下，我们可以避免这些问题。