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

Question

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

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

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

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

Answer 1

我尝试了三种口味

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

Answer 2

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

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

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

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