微服务能否通过localhost origin与下游服务交互

Question

微服务可以通过本地主机源与下游服务交互，因为我的所有服务都在同一台服务器上运行，这是正确的方法吗？我发现与 localhost 相比，与域名交互下游服务需要很多时间。我很想知道我们是否可以这样做？

Answer 1

微服务是一个概念，它不会强迫您在哪里部署应用程序以及它们如何相互调用。您可以将微服务部署在托管在同一物理服务器上的不同虚拟机上。关键是你需要为你决定用你的架构做的每件事有一个理由。 第一个问题是为什么您将应用程序拆分为不同的微服务？只是为了在你的架构上携带微服务这个词，还是对项目的业务逻辑、可扩展性和可维护性有更好的控制？ 这些是您在设计应用程序时需要注意的重要事项。画出你的产品的大图，它是如何被使用的。客户主要使用哪个服务/组件，将其与同一服务器上的其他微服务保持一致是否会产生性能问题？如果服务器发生任何问题并且整个应用程序将无法访问怎么办。

Answer 2

你是对的，你可以通过 localhost 与在同一主机上运行的其他服务进行通信。这完全没问题，在考虑网络往返时，它是有益的。

但是，

1. 如果您想扩展服务怎么办？
2. 如果您想将任何服务移至其他主机怎么办？

至少考虑到这些场景，绑定到特定主机是不值得的。如果您使用的是主机的 IP，这适用。

*I found that interacting a downstream service with domain name takes much time when compared to localhost.*.

我明白你在说什么。

微服务架构并不是软件开发设计的灵丹妙药，总是需要权衡取舍

关于您的部署策略每个主机模式多个服务实例。

1. 如果您的服务有不同的资源需求，您将如何处理？
2. 如果您的一项服务正在使用所有主机资源怎么办？
3. 如果您需要横向扩展一项独立服务怎么办？
4. 您将如何确保服务的可用性？
5. ..
6. ..

因此，在采用微服务模式之前，您必须考虑很多问题。这完全取决于您的要求。

Answer 3

如果您的服务在同一台服务器上，您应该使用消息代理或 grcp 之类的机制在您的服务之间进行通信，因此您的来源是否无关紧要。如果您使用 HTTP 在微服务之间进行通信，那么它完全没有获得微服务架构的任何优势，并且您的架构存在缺陷。