如何避免微服务设计中的耦合问题

Distributed monolith (分布一体式)是一个幽默的词，用来暗指那些设计欠佳的架构。如果忽略了微服务设计实践，不仅会无法克服一体式带来的缺点，也会导致出现新的、复杂的问题或恶化已存在的问题。当你在自豪地称之为微服务架构的同时，由于设计上缺少足够目的性的，最终的架构与随机爆破而成的碎片没有什么区别。

避免分布一体式的第一步非常简单：避免同时实现微服务。一体式是简单的，因为无需考虑分布式系统存在的复杂性。一个数据库，一个日志存储位置，一个监控系统，更简单的问题定位，以及端到端测试等等。除非你有充分的理由去使用微服务，否则最好采用同样的理念。

本文将主要关注微服务设计中的松耦合的重要性。我将给出一些简单的、可以避免耦合和导致分布一体式架构设计的例子。

微服务中的松耦合？

两个系统中，如果修改任意一方的设计、实现或行为不会对另一方造成影响，则称两个服务是松耦合的。当涉及到微服务时有可能会发生耦合，即对一个微服务的修改，会立即直接或间接地影响到与其他所有微服务的协作。

下面看一些设计中存在耦合的场景。

数据库共享

数据库共享是实现耦合的一种常见方式。当一个服务修改其实现时，会导致修改另外一个服务的实现。

选择数据存储、方案、以及请求的语言等细节应该对客户端不可见，如果共享了数据库，则可能会暴露所有的实现细节。为什么要隐藏实现细节？这是因为如果暴露了实现细节，那么未来对实现细节进行调整时将有可能会导致客户端代码不可用，除非客户端也同步做了相应的修改(这种方式是不可行或不可持续的)。在图1的左侧，Customers 与 Orders共享了数据库，因此Orders可以访问Customers 的数据模型细节，当这些细节发生变化时，有可能会导致异常。

应该如何处理？

一种方式是像图1的右侧那样，让Customers 提供一个API，Orders客户以通过该API获取customer的数据。只要Customers的合同不变，则数据格式也不会发生变化。Orders 无需知道数据的来源，且Customers 可以自主决定将该数据替换为另一个流数据源，而无需担心对其他服务的影响。