微服务如何使组件之间避免过于紧密的耦合变得更容易？

Question

我读过M. Fowler关于微服务体系结构的在本文中：

使用服务作为组件的另一个结果是一个更加显式的组件接口。大多数语言都没有一个很好的机制来定义显式发布的接口。通常，只有文档和规程才能防止客户端破坏组件的封装，从而导致组件之间的耦合过于紧密。通过使用显式的远程调用机制，服务可以更容易地避免这种情况。

我甚至不知道该怎么问。在执行接口契约方面，微服务如何比库更好？REST端点如何比Java函数更好？谁能详细说明一下，或者举个例子？

Answer 1

我认为在“强制执行接口契约”方面，微服务架构并不比库更好，但它们更善于定义契约。Fowler说，代码库通常有很多公共成员，但其中只有一部分是为了形成已发布的接口--这是两个或多个组件之间达成的协议。

据推测，这是因为他认为公众成员的创建成本很低，所以纪律常常使我们无法限制他们。

服务端点(REST、消息传递等)更显式，创建成本更高。他们会更多地考虑兼容性、安全性和性能问题。正因为如此，您可能会在服务上拥有更少但定义更好的接口，从而使将来更容易分离和重新实现服务。

Answer 2

微服务如何更好地执行接口契约？

你不能打电话进入他们的内部。您只能通过他们公开的任何接口来调用他们。

对于库，即使不是有意调用，也可以调用未标记为私有的成员或类。或者即使有记录表明用户不应该这样做。当用户调用意味着“在”库中的东西时，客户端代码就会与库的内部实现紧密耦合。即使库有私有或内部成员，许多语言也提供反射功能，允许您(不明智地)访问或调用它们。

对于(微观)服务，内部部件的隔离是完全的。调用它们的唯一方法是通过公共接口。

Answer 3

在执行接口契约方面，微服务如何比库更好？

事实上，可以说，它们更糟糕。

微服务和库都有API。有了库，您通常可以拥有接口契约的编译/单元测试保证。

微型服务已经(或应该.)相同的接口契约。但是，验证这一点的能力被转移到集成测试或更糟的生产环境验证中。

这一问题的结果是：

1. 繁琐的集成测试
2. 缺乏测试，希望产品在生产环境中能正常工作。

请注意，这个问题是合同测试旨在解决的问题。我鼓励您阅读Pact.io，因为它们或多或少地解决了这里的核心问题。