是否应该在微服务体系结构中将内部请求发送到API-GATEWAY？
我正在创建微服务架构。
假设我有三个服务：Alpha，Beta，Gamma
，并假设最终用户向Alpha发送请求，并且该结构的结构使Alpha需要向Beta和Beta发送请求到Gamma。
用户＆lt; ===＆gt; alpha＆lt; ===＆gt; beta＆lt; ===＆gt;伽马
一世也有一个Kong API网关，因此，用户将请求发送给Kong和Kong将其发送给用户要求的服务。
问题是，内部请求也应该通过Kong吗？
用户＆lt; ===＆gt; kong ＆lt; ===＆gt; alpha＆lt; ===＆gt; beta＆lt; ===＆gt;伽马
或
用户＆lt; ===＆gt; kong ＆lt; ===＆gt; alpha＆lt; ===＆gt; kong ＆lt; ===＆gt; beta＆lt; ===＆gt; kong ＆lt; ===＆gt;伽玛
指出，使用Kong的好处之一是其插件。例如，如果我想使用correlation-id或zipkin插件>插件以及所有内部服务的跟踪请求和延迟，则需要通过Kong与它们联系。但是我担心的是，这不是为整个系统增加延迟吗？是否在微服务体系结构中是推荐的做法？
I am creating a microservice architecture.
Suppose I have three services: alpha, beta, gamma
and suppose the end-user sends a request to alpha and the structure is such that the alpha needs to send a request to beta and beta to gamma.
user <===> alpha <===> beta <===> gamma
I also have a kong API gateway so actually, the user sends the request to kong and kong dispatches it the service requested by the user.
The question is, should the internal requests also go through kong or not?
user <===> kong <===> alpha <===> beta <===> gamma
OR
user <===> kong <===> alpha <===> kong <===> beta <===> kong <===> gamma
Note that one of the benefits of using kong is its plugins. For example, if I want to use the correlation-id or Zipkin plugin and trace requests and latency in all the internal services, I need to reach them through kong. But my concern is, doesn't it add latency to the whole system? Is it a recommended practice in microservices architecture or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您应该避免强耦合。请投入一些时间以良好的API设计，而不是考虑后端。对我来说，体系结构的想法看起来像是一个带有API网关的工作流程。您还可以考虑一项组成服务，在该服务中，网关在此服务中呼叫其他几个API，并且“魔术”在此服务中发生。在这种情况下，您不会将网关用作ESB。您真正需要的唯一插件是相关ID。
You should avoid strong coupling. Please invest some time in good API design , not with the backend in mind. For me the architecture idea looks somehow like a workflow with an Api gateway in it. You can also think about a compositioning service where the gateway knows this upstream and "the magic" with calling several other apis happens in this service. In this case you won't use the gateway as an esb. The only plugin you will really need is correlation-id.