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

Question

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

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

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

那么，是什么反对将API网关也用于整个内部通信呢？

Answer 1

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

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

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

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

Answer 2

我试过三种口味

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