不靠谱的组件与可靠的系统

一、我们应该把精力放到单个组件的精益求精上还是整体流程和架构上？

这个问题说实话很不好回答，要么得罪程序员要么得罪架构师，按照中国传统的中庸哲学，肯定是走中间路线，谁也不得罪。所以我们会说，都要重要。重视组件主要是编码能力和编码质量，很多时候由技术人员个体水平决定，重视架构则是软件工程和软件架构的规划和设计，更多是技术管理和管控层的水平决定。重视单个组件的精益演进是“术”层面的事情，重视架构是“道”层面的事情。

另外，从工程实践层面讲，单个组件的迭代和优化属于具象化的，是可见可控的。流程和架构的持续迭代是抽象的，根据情况的不同和干系人的不同会有不同的办法和演进思路。

二、构建一个大规模却依然可靠的软件系统是否可行？

这个问题乍一听，觉得有点不可理喻，要是不靠谱，我们这一大帮人整天瞎忙活什么啊，散了算了。

其实，这个问题要从墨菲定律谈起。

“墨菲定律”很复杂，简而言之，其根本内容是“凡是可能出错的事有很大几率会出错”，指的是任何一个事件，只要具有大于零的机率，就不能够假设它不会发生。通俗来讲，事情往往会朝化的一面演进和发展。

回到我们的问题上。有了“墨菲定律”这样一个神论断，加上“大规模”这样一个吓人的前提，我们会发现在软件开发和运行过程中，代码质量、硬件稳定性、网络可靠性等因素，其负面影响会形成叠加效应，会被不断放到，直到成为制约软件成败的关键因素。所以我们可以得出这样的结论，如果一项工作要经过多个“不靠谱”环节和过程的协同作用，其误差和负面影响会叠加，最终导致结果不能收敛不可控。

这样来看，我们好像得出了一个相反的结论，其实不然。我们可以用一个生命体来类比。

不可靠的部件可以理解成构成生命体的基本细胞和分子，在热力学扰动、生物学复制差错的影响下，这些细胞和分子是不可靠的，是不靠谱的。但是我们的生命体却是鲜活的，恰恰是因为使用了不可靠的部件完成遗传进化，这里面的关键是我们的生命体承认细胞和分子的不可靠，会靠生命体本身的代偿机制和进化机制，实现细胞和分子的新旧交替，不可靠的细胞和分子一定会消亡，也终究会在靠谱的系统组织下重生。

回到我们的话题上，那就是架构在起作用，有人把这种架构称之为“凤凰架构”，俗称“不死鸟”。

三、演进的架构是系统永葆青春的秘籍

从单体应用、SOA、微服务、服务网格、无服务等架构的兴起，我们的系统架构其实一种呈现一种有规律的演技，从集中到分散、从大到小、从宏观到微观。但是，我们也应该看到，“分久必合合久必分”的天下大势，回归到我们的系统架构上，集中与分散都是因势而为。每一种架构的优点都是让系统活得更好，但是系统架构的关键问题是如何让系统持续稳定的运行，至于用什么架构去实现，那是术层面的问题，切不可本末倒置。

流水不腐户枢不蠹，有老朽，有消亡，有重生，有更替，这才是一个生态应该有的正常秩序。哪怕系统采用了十分不靠谱的组件，只要整体架构设计了恰当熔断和服务淘汰和重建机制，从系统外部观察，架构依然会表现出整体的稳定性和持续的服务能力。