在API网关内实现Aggregation微服务并使用服务发现的最佳实践

Question

我们目前正在研究将我们现有的monolith应用程序转换为沿着一个API网关运行的细粒度微服务的可能性，以便进行协调。

我有这样一个案例，其中有三个微服务：

1-产品微服务：面向产品的REST API服务。2-Category微服务：一个针对类别的REST API服务。3-聚合微服务：一个REST API服务，它连接类别列表和它们的产品，然后将它们返回到一个模型中。

根据附上的图像，任何客户端都可以向API网关发送请求，指定除了像HTTP方法和请求体这样的所有请求选项之外，他想要从哪个微服务中检索信息。

API网关将接收客户端的请求，并使用服务发现将其重新路由到指定的微服务。

我的问题是，如果客户端尝试联系聚合微服务怎么办？这将导致对API网关的请求，然后API网关将重新路由到聚合服务。然而，聚合服务需要同时联系类别和产品服务，以便用统一的模型回复客户端。这要求聚合微服务也再次联系API网关，以便它可以将其请求重新路由到类别和产品微服务。

这里似乎有很多通信流量发生，是我遗漏了什么，还是这是实现这种场景的正确方法。

谢谢

API网关示例

Answer 1

在您的情况下，最简单的方法是进行服务编排。域服务不会彼此进行对话，聚合服务将是协调器，它将调用两个域服务，合并结果并将它们返回给客户机。网关应该只与orchestrator联系，而orchestrator也是向客户端隐藏内部服务复杂性的门面。

另一种方法是服务编排，其中通信是分散的，每个服务决定它应该联系哪些其他服务。然而，它要复杂得多，只有当你拥有大量的微服务时，它才是有价值的。例如，您必须防止循环，单独部署更困难，因为您必须考虑依赖关系...