【发布时间】：2021-04-29 18:56:03
【问题描述】：
我们目前正在研究将现有的单体应用程序转换为沿 API 网关运行以进行协调的细粒度微服务的可能性。
我有这种情况，其中有三个微服务：
1- 产品微服务：产品的 REST API 服务。 2- 类别微服务：类别的 REST API 服务。 3- 聚合微服务：一种 REST API 服务，它连接一系列类别及其产品，然后将它们返回到一个模型中。
根据附图，除了 HTTP 方法和请求正文等所有请求选项外，任何客户端都可以向 API 网关发送请求，指定他想从哪个微服务检索信息。
API 网关会接收到客户端的请求并使用服务发现将其重新路由到指定的微服务。
我的问题是，如果客户端尝试联系聚合微服务怎么办？这将导致对 API 网关的请求，然后 API 网关将重新路由到聚合服务。但是，聚合服务需要联系类别服务和产品服务，以便以统一的模型回复客户端。这要求聚合微服务也再次联系 API 网关，以便将其请求重新路由到类别和产品微服务。
这里似乎发生了很多通信流量，我是否在这里遗漏了什么或者这是实现这种情况的正确方法。
【问题讨论】：
-
客户端应该针对 API 网关发出请求，而不是针对特定服务。 API 网关从其他服务获取所需的数据，将其聚合并将数据返回给客户端。服务发现不应该对客户端可见。
-
您好 Hector，我知道服务发现不应该对客户端可见。但是，我的问题是关于微服务之间的内部通信。如果微服务 A 想要与微服务 B 进行通信，这应该直接发生还是通过 API 网关发生。此外，哪种方法是最佳实践，创建用于聚合数据的微服务还是仅在 API 网关内执行聚合？谢谢
标签： microservices service-discovery api-gateway