架构系统松耦合的关键！

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

 

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

 

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

 

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

 

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

 

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

 

「微服务设计的十个步骤」一文提到第七步是「设计信息瀑布」，就是用来解决这个问题的。我发明了一个「信息瀑布」机制，来尽可能在设计之初就保留最大的弹性，抵抗信息风暴。信息瀑布机制的两个重要的意义是：

1.让信息之间的上下游关系明确，避免信息发生循环。

2. 「传讯中间系统」一开始就分割得很细，有助于后续的扩展。

 

信息瀑布的设计重点是：

1. 先把所有的信息类型排列出来。

2. 设计出数个「传讯中间系统」，每个只经手某些类型的信息，「传讯中间系统」之间要有严格的上下游关系。

3. 每个模块再根据各自关联的信息，连接到适当的「传讯中间系统」，一个模块可以连接到不只一个传讯中间系统。

 

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

 

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