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

Question

在微服务架构中，有一个称为API网关的通用模式。

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

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

那么，反对在整个内部通信中使用API​​网关又是什么呢？

Answer 1

我尝试过三种口味

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

Answer 2

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

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

2. 一旦负载升高并达到网关服务实例的峰值容量，这些实例可能会开始耗尽工作线程和内存等资源。一般来说，这种情况可以通过减载或限制一些新请求来处理。这可能意味着我们可能只处理一部分请求，直到负载下降。然而，在我们的例子中，不仅新请求受到影响，而且所有正在等待网关服务资源被释放用于内部调用的正在进行的旧请求也会被永远阻止，直到超时，因为这些请求航班请求正在等待原始请求（本身）完成。因此，我们最终会得到一个死锁的系统，在负载下降之前根本不会服务任何请求。如果超时没有正确实现，系统甚至可能会永久死锁，直到死锁的网关服务实例被回收。

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