【发布时间】：2017-02-20 20:02:24
【问题描述】：
作为一种将微服务连接在一起并使其工作的机制，通常建议使用 API 和服务发现。但它们通常作为自己的微服务工作，但这些微服务显然应该“硬编码”到其他微服务中，因为每个微服务都应该向它们注册并查询其他微服务的位置。这是否打破了松散耦合的想法，因为发现服务的丢失意味着其他人无法通信？
【问题讨论】：
标签： microservices service-discovery
【发布时间】：2017-02-20 20:02:24
【问题描述】：
几乎是的。如果一个微服务“知道”另一个微服务 - 这意味着它们是高度耦合的。关于其他服务的这些知识具体来自哪里并不重要：硬编码、配置文件或某些服务发现，它仍然会导致高耦合。
需要了解的重要一点是，许多微服务传播者只是在宣传如何在 Web API 之上构建单体应用。他们中的一些人可能认为他们使用的流行词越多越好……不太清楚为什么会发生这种情况。通过使用流行语沙拉而不是真正构建容错和水平可扩展的应用程序，可能更容易伪造一种语言并成为“专家”。
但是还有另一种看待服务发现的方法：当它被 SPA 应用程序或API Gateway 等服务客户端使用时，它可能非常有用。客户端和网关应该了解服务 API，否则整个事情就没有意义。但他们可以使用注册表使其更加灵活/动态。
所以，总结一下：
- 如果服务使用发现来获取更多关于彼此的信息 - 这可能是一件坏事和设计缺陷（很确定在某些极端情况下这可能是一个有效的场景，如果你知道的话，请发表评论）
- 如果应用的其他部分（如 SPA 或 API 网关）使用发现，这可能有用，但不一定总是如此。
PS：为避免高耦合，请考虑阅读series of articles by Jeppe Cramon，它很好地说明了问题和可能的解决方案。
【讨论】：
-
如果没有任何紧密耦合，您建议如何工作？
-
对不起，差点忘了最重要的事情！ ...刚刚更新了我的答案，提供了一篇可能有帮助的文章的链接。
-
但是你仍然应该有消息队列，哪些服务应该知道，这有点打破了这个想法。
-
我认为这不是因为松散耦合仍然假设某种程度的耦合。使用消息队列和异步通信，您的服务将暂时解耦，这意味着一个服务的故障不会导致其他服务的级联故障。
在分布式系统中，总会有一定程度的耦合，你要做的就是将各方面的耦合降到最低。
我认为这对您如何设计服务位置很重要。如果您的代码知道其他服务，即OrderService.Send(SubmitOrderMessage);（其中“OrderService”是其他服务代理的实例）
与transportAgent.Send(SubmitOrderMessage);（其中“transportAgent”是传输代理的一个实例，即排队服务/代理和队列的实际地址可以在您的配置中）相反，这减少了耦合和您的业务逻辑代码（服务）并将路由委托给您的基础架构。
有意义吗？
【讨论】：
每个微服务都应在功能上独立。对于与其他微服务的交互，它应该只依赖于 rest api 调用。服务发现的作用是使服务之间保持相当松散的耦合。同样由于服务 url 的动态特性，硬依赖被删除。希望这会有所帮助
【讨论】：
减少耦合或相当松散的耦合仍然有一个共同点；耦合。在我看来，任何程度的耦合都会产生僵化的通信模式，随着平台成长为大型分布式平台，这些模式难以维护和排除故障。微服务背后的理念不就是让消费者参与“无许可创新”吗？我建议这只能通过分解为具有高内聚和低耦合的微服务，然后让消费者决定如何路由、编排或聚合来实现。
【讨论】：