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

在微服务体系结构中，有一种称为API网关的通用模式

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

但是我也希望从微服务到微服务的内部通信是通过API网关进行的？我的意思是，这比建立点对点连接要容易得多

那么，在整个内部通信中使用API网关又有什么不利之处呢

---

我试过三种口味

通过API网关进行的所有通信 它使服务发现变得容易，所有通信都可以在一个点上跟踪，但它增加了网关后面服务的延迟（不是很大，而是一个额外的跃点）。此外，您还可以取消身份验证，这意味着所有服务（即使是网关后面的服务）都需要获得正确的身份验证（这可能不是某些应用程序的缺点，但对于其他应用程序，这很可能是缺点）

通过网关的外部服务 它可以帮助您在网关上剥离身份验证。您可以强制对传入请求进行更严格的检查，您的服务直接相互通信（但这意味着他们需要发现服务，我们使用基于route53的dns，因此他们访问的端点保持不变）。服务相互信任，这些通信不需要身份验证

外部/内部网关 我们还有一个场景，我们必须获得两个api网关，其中一个原因是两组网关上需要进行不同类型的检查，并且每个网关都必须承受不同的负载

---

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

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

2） 一旦负载增加并达到网关服务实例的峰值容量，这些实例可能会开始耗尽其资源，特别是正在进行调用的处理线程。通常，这种情况可以通过减少负载或限制一些新请求来处理。这可能意味着，在负载下降之前，我们可能只提供一定百分比的请求。但是，在我们的例子中，不仅新请求受到影响，而且所有正在等待网关服务资源释放以进行内部调用的正在运行的旧请求也会被永久阻止，直到超时为止，因为这些请求正在等待自己完成。我们最终会遇到一个死锁的系统，在负载下降之前，该系统不会提供任何请求。如果超时没有正确实现，它甚至可能会永久性地陷入死锁，需要回收实例

---

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

只是想知道第二个选项：您是否使用ELB/ALB进行服务-2-服务通信？是的，我们使用了ELB。