Service Discovery微服务是否打破了松散耦合的想法？

Question

作为将微服务连接在一起并使其工作的机制，通常建议使用API​​和服务发现。但它们通常作为自己的微服务工作，但这些应该显然是硬编码的＃34;因为每个微服务都应该向他们注册并查询其他微服务＆＃39;位置。这是不是打破了松耦合的想法，因为失去发现服务意味着其他人无法沟通？

Answer 1

非常好。如果一个微服务“知道”另一个微服务 - 这意味着它们是高度耦合的。有关其他服务的具体知识来自哪里无关紧要：硬编码，配置文件或某些服务发现，它仍会导致高耦合。

重要的是要理解的是，许多微服务传播者只是在讲述如何在Web API之上构建整体应用程序。他们中的一些人可能认为他们使用的词语越多越好......不太确定为什么会这样。通过使用流行语沙拉而不是真正构建容错和水平可扩展的应用程序，伪造一种语言并成为“专家”可能更容易。

但是还有另一种方式来查看服务发现：当服务客户端（如SPA应用程序或API Gateway）使用它时，它可能非常有用。客户端和网关应该了解服务API，否则，整个事情都没有意义。但他们可以使用注册表使其更灵活/更动态。

所以，总结一下：

• 如果服务使用发现来获取关于彼此的更多信息 - 这可能是一件坏事和设计缺陷（非常确定存在可能是有效方案的极端情况，如果您知道某些情况，请发表评论）< / LI>
• 如果应用程序的其他部分（如SPA或API网关）使用了发现，这可能很有用，但不一定总是如此。

PS：为避免高耦合，请考虑阅读series of articles by Jeppe Cramon，以便很好地说明问题和可能的解决方案。

Answer 2

在分布式系统中，您总是会有一些耦合，您要做的是将耦合的所有方面减少到最小。

我认为你设计服务地点的方式很重要。如果您的代码知道其他服务，即OrderService.Send(SubmitOrderMessage);（其中＆＃39; OrderService＆＃39;是其他服务代理的实例） 而不是transportAgent.Send(SubmitOrderMessage);（其中＆＃39; transportAgent＆＃39;是传输代理的实例，即排队服务/代理和队列的实际地址可以在您的配置中），减少耦合和业务逻辑代码（服务）并将路由委派给您的基础架构。

有意义吗？

Answer 3

每个微服务都应该在功能上独立。为了与其他微服务交互，它应该仅依赖于rest api调用。服务发现起着保持服务相互松散的作用。此外，由于服务URL的动态特性，将删除硬依赖项。希望这有帮助

Answer 4

减少耦合或相当松散的耦合仍然有一个共同点;耦合。在我看来，随着平台发展成为一个大型的分布式平台，耦合到任何程度都会产生难以维护且难以排除故障的僵化通信模式。微服务背后的想法不是允许消费者参与“无可比拟的创新吗？”我建议只有通过分解到具有高内聚力和低耦合度的微服务才能实现这一点，然后让消费者决定如何路由，编排或聚合。