鬆耦合的关键

系统架构就和公司架构、或政府架构、或生物体一样，当规模很小、複杂度很低的时候，可以用单一控制中心的组织形式，强力地、完整地、完美地、精準地控制所有的流程。但是当系统的规模大、複杂度高的时候，如果还想用这种我所谓的控制狂（Control Freak）架构，系统反而容易失控，一个小的意外就会导致连锁反应，延烧形成不可挽回的局面，导致系统错乱甚至崩溃，这是必然的、早晚会发生的事情。

现代社会因为商业竞争和使用者太多等因素，导致系统需求多、需求複杂、需求经常需要改变、且牵涉因素太多，想要完美地控制流程难度越来越高。况且，控制狂的设计还会导致牵一髮动全身，风险非常高。从这个时代开始，设计分散式、鬆耦合的系统才是正确的道路。

鬆耦合的（loosely-Coupled）系统是由许多小巧的、自给自足的程式模组（连同其资料）组合起来的，好的微服务（microservices）设计也应该以此为设计原则。这些自给自足的程式模组可以随时加入系统或者从系统中移除，不会造成系统太大的涟漪。模组动态加入、移除、更新，根据系统繁忙程度动态地複製模组实体来分担任务，或消减模组实体来减少资源耗费，这些都是这类系统的日常，只要一开始设计的好，后面一点都不费劲。

当我们不设计一大块的控制狂系统，改设计许许多多的鬆耦合模组联合的系统时，我们马上面临一个问题：这些模组要如何彼此协作，还能够保持彼此之间鬆耦合？答案是透过「讯息」的传递，这就是为什么「讯息」在现代的系统中扮演很重要的角色。

当一个模组接收到讯息时，就会做出一些反应，反应的结果可能会产生数量不一定的讯息，这些讯息又进入到其他模组。就是在这些讯息的收发之间，许多模块一同完成了一件更大的任务。所以说：鬆耦合的（loosely-Coupled）系统是由许多小巧的、自给自足的程式模组（连同其资料）组合起来的。

大量透过讯息来联繫许多的模组，会面临一个潜在的问题：讯息量太大的时候怎么办？使用讯息时，我们一般透过所谓的「传讯中间系统」（messaging middleware）来传递讯息，以保持模组之间的鬆耦合。我们当然可以利用一个中央的传讯中间系统来连上系统内的全部模组，但我不建议这么做，因为如果讯息量很大，就算是丛集化（clustered）的中央传讯系统，依然可能很快就抵挡不住大量讯息的狂风暴雨。

「微服务设计的十个步骤」一文提到第七步是「设计讯息瀑布」，就是用来解决这个问题的。我发明了一个「讯息瀑布」机制，来尽可能在设计之初就保留最大的弹性，抵抗讯息风暴。讯息瀑布机制的两个重要的意义是：1. 让讯息之间的上下游关係明确，避免讯息发生循环。2. 「传讯中间系统」一开始就分割得很细，有助于后续的扩展。

讯息瀑布的设计重点是：1. 先把所有的讯息类型排列出来。2. 设计出数个「传讯中间系统」，每个只经手某些类型的讯息，「传讯中间系统」之间要有严格的上下游关係。3. 每个模组再根据各自关联的讯息，连接到适当的「传讯中间系统」，一个模组可以连接到不只一个传讯中间系统。

儘管你的鬆耦合系统一开始可能没有抵抗讯息风暴的需要，但我还是建议你一开始就设计讯息瀑布，总有一天老闆会称讚你有先见之明的。

鬆耦合的系统，对我们在程式设计、架构设计、和维运方式等方面都提出挑战，所幸的是，一旦我们通过了挑战，我们就能进入一个美好的桃花源。这挑战，值！