在API网关中实现聚合微服务和使用服务发现的最佳实践

Question

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

我有一个例子，其中有三个微服务：

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

根据附加的图像，任何客户端都可以向API网关发送请求，指定除了HTTP方法和请求正文等所有请求选项外，他还希望从哪个微服务检索信息。

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

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

这里似乎发生了大量的通信流量，我是不是错过了什么，或者这是实现这种情况的正确方式。

​

​

Answer 1

在您的情况下，最简单的方法是进行服务编排。域服务不会相互通信，而聚合服务将是调用这两个域服务、组合结果并将其返回给客户端的协调器。网关应该只联系编排器，而编排器也是一个外观，它会向客户端隐藏内部服务的复杂性。

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