问题描述
微服务是否可以通过本地主机源与下游服务交互，因为我的所有服务都在同一服务器上运行，这是正确的方法吗？我发现与 localhost 相比，与域名交互的下游服务需要很多时间。我很想知道我们是否可以这样做？
解决方法
你是对的，你可以与在同一个主机上运行的其他服务与本地主机通信。完全没问题，考虑到网络往返时，这是有益的。
但是，
- 如果您想扩展服务怎么办？
- 如果您想将任何服务移动到不同的主机怎么办？
至少考虑到这些情况，绑定到特定主机是不值得的。如果您使用的是主机的 IP，这适用。
*I found that interacting a downstream service with domain name takes much time when compared to localhost.*。
我明白你在说什么。
微服务架构不是软件开发设计的灵丹妙药，总是需要权衡取舍
关于您的部署策略每个主机的多个服务实例模式。
- 如果您的服务有不同的资源需求，您将如何处理？
- 假设您的一项服务正在使用所有主机资源会怎样？
- 如果您需要扩展一项独立服务怎么办？
- 您将如何确保服务的可用性？
- ...
- ...
因此，在采用微服务模式之前，您必须考虑很多问题。这完全取决于您的要求。
,如果您的服务在同一台服务器上，您应该使用消息代理或 grcp 之类的机制在您的服务之间进行通信，因此您的源是否在同一台服务器上并不重要。如果您在微服务之间使用 HTTP 进行通信，那么它完全无法获得微服务架构的任何优势，并且您的架构存在缺陷。
,微服务是一个概念，它不会强迫您部署应用程序的位置以及它们可能如何相互调用。您可以在托管在同一物理服务器上的不同虚拟机上部署微服务。重点是你需要为你决定用你的架构做的每一件事都有一个理由。 第一个问题是为什么您将应用程序拆分为不同的微服务？只是为了在你的架构上承载微服务这个词，还是对项目的业务逻辑、可扩展性和可维护性有更好的控制？ 这些是您在设计应用程序时需要注意的重要事项。画出你的产品的大图，如何使用它。客户主要使用哪个服务/组件，将其与同一服务器上的其他微服务一起使用是否会导致性能问题？如果服务器发生任何问题并且整个应用程序将无法访问怎么办。