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

Question

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

Answer 1

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

Answer 2

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

但是，

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

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