分布式中耦合有哪些类型？

前言里说过，耦合是系统结构中各模块间相互联系紧密程度的一种度量。我们希望这种联系越松散越好，但是显然一点儿联系也没有是不可能的。耦合有多种类型，不同类型的耦合代表的模块间的紧密程度也是不一样的。

这里所说的模块是指系统的组成部分，系统组成包括多个模块以及模块间的关系。在技术层面模块可能存在于一个单体应用中，也可能以分布式的系统存在，这不影响我们耦合类型的讨论。

从上图中可以看到，各种耦合类型导致的系统紧密程度不一样，越松散就越好。下面我们解释几种常见的类型。 - Content Coupling：内容耦合是最糟糕的耦合。假如有A和B两个模块，B模块直接访问了A模块内部的数据，那么A对B的依赖就太重了，耦合就太紧了。这是对封装或者叫数据隐藏最直接的破坏，这就像你不是去银行柜台取钱，而是直接进入银行的金库去拿钱。且不说法律和安全上是否允许，你能不能拿到钱，很大程度上依赖于银行金库内钱的存储的结构以及你对它的熟悉程度。微服务倡导的，一个服务应用应该独享自己的数据存储，服务间要通过远程通信来协作，正很大程度上能避免了这个问题。

• Common Coupling：这种耦合比上一种好一些，也好不到哪里去。A和B两个模块都依赖一份数据，只是这个数据即不属于A也不属于B。当然，严格遵守微服务的原则也能避免这种耦合。

• Stamp Coupling：比共享数据更好的方式是通过参数传递数据。银行柜台的营业员就是一个接口，你要取钱的时候，去找他，把你的需要告诉他，而不是直接闯入金库去拿钱，这就是一种参数传递。但怎么描述你的需求也很关键，我们举个栗子，你来到柜台前，告诉营业员，下周你要带女盆友去国外旅游，你把你的行程表给他看，然后，聪明的营业员从你的定期账户里解冻了2万元到活期账户里，然后又把它转换成美元交给了你。这个是一个参数传递的例子，你的行程表就是入参，但这样并不好，原因是营业员直接需要的不是这个行程表，他需要从你的输入中提炼信息才能完成任务，这就是Stamp Couping。

• Data Coupling：更好的是Data Coupling，它也是通过参数传递数据，与Stamp Coupling不同的是，交流的参数结构是由接口提供者定义的。作为客户，你直接告诉营业员，从你的定期账户里解冻2万元到活期账户，然后再把活期账户里的2万元转换成美元给你，这就可以了，你在用银行规定的概念和银行的营业员交流，至于你去干什么，银行并不关心，你也无需赘述。

当我们使用微服务架构构建的是分布式系统的时候，显式的数据共享造成的耦合基本避免了，但Stamp Coupling还是很常见。

注意，我这里说的是显式的数据共享造成的耦合基本避免了，还有一些隐性的，后面会举个例子。