我们目前正在研究将现有的整体应用程序转换为沿着API网关运行的细粒度微服务以进行协调的可能性。
我有这种情况，有三个微服务：
1- Product Microservice：产品的REST API服务。 2-类别微服务：用于类别的REST API服务。 3-聚合微服务：一种REST API服务，它连接在一个类别列表及其产品之间，然后将它们返回到一个模型中。
根据附图，任何客户端都可以向API网关发送请求，指定除了HTTP方法和请求正文等所有请求选项之外，还要从哪个微服务中检索信息。
API网关将接收客户端的请求，并使用服务发现将其重新路由到指定的微服务。
我的问题是，如果客户端尝试联系聚合微服务怎么办？这将导致对API网关的请求，然后API网关将重新路由到聚合服务。但是，聚合服务需要联系类别和产品服务，以便使用统一模型回复客户端。这要求聚合微服务再次联系API网关，以便将其请求重新路由到类别和产品微服务。
这里似乎发生了很多通信流量，我在这里遗漏了一些东西，或者这是实现这种情况的正确方法。
由于
答案 0 :(得分：0)
在您的情况下，最简单的方法是进行服务编排。 域服务不会相互通信，聚合服务将是调用两个域服务的协调器，将结果组合并将它们返回给客户端。网关应该只与orchestrator联系，orchestrator也是一个可以向客户隐藏内部服务复杂性的外观。
另一种选择是服务编排，其中通信是分散的，每个服务决定它应该联系哪些其他服务。然而，它要复杂得多，只有当你拥有大量的微服务时它才有价值。例如，您必须防止循环，单独部署更加困难，因为您必须考虑依赖性...
