元光研究院副院长

是什么”

“ ”这个词在东方人中并不常用，但在西方的软件工程读物中却经常出现，尤其是关于和等主题的著作。软件工程小说《精益》讲述了一个濒临死亡的项目在精益方法下重生的故事；马丁·福勒（ ）在对“ ”的解读中也多次提到“ ”（意为“涅槃重生”）和“ ”（意为“没有两片相同的雪花”）的对比。或许这就是东西方文化的差异吧，虽然有“失败是成功之母”这样的谚语，但我们东方人更在意的是把事情一次做对、做好，尽量不犯任何错误；而西方人则应该“更开明”，把错误看作一个正常甚至是必要的开发过程，只要有一个底线就可以让事情回到正轨。

在软件工程中，任何一个产品的研发中，只要时间尺度足够长，人总会犯错误，代码总会有缺陷，计算机总会当机，网络总会堵塞中断……如果一个项目需要大量人共同开发一款大型软件产品，并分布到网络中大量的服务器节点上同时运行，那么随着项目规模越来越大，运作时间越来越长，必然会受到墨菲定律的无情打击。

定律：能走的就走

为了获得高质量的软件产品，我们应该更加注重提高每个人、每个流程、每个输出的能力和质量，还是应该更加注重整体的流程和架构？

首先我来“糊弄”一下这个问题：两者都重要，前者重在技术，后者重在职业道德；前者更多是跟编程能力有关，后者更多是跟软件架构有关；前者主要由开发者个人水平决定，后者主要由技术决策者的水平决定；

但是，我也必须强调这个问题的另一面：两者的理解路径和抽象层次是不一样的。如何学习一门具体的语言、框架、工具，比如 Java、Vue.js 等，是相对具体的，不管它包含的内容有多少，有多复杂，至少是看得见摸得着的。而如何学习某种风格的架构方法，比如 、、 mesh、、 等，是相对抽象的，讲起来可能会面临“一百个人眼里一百个哈姆雷特”的困境。要讲这个话题，不能是简单的实证陈述。我觉得，回到这些架构的根本出发点和问题，真正用这些不同风格的架构方法去实现某些需求、解决某些问题，然后在实践中观察它们的相同点、不同点、优缺点，会是一个好的，也许是最好的方法。我想讲这些架构，我想讲透彻。 这需要代码和文字的配合，不太适合以传统书籍的形式直接书写，所以这个项目就应运而生了。

可靠的系统

我们再思考另一个问题：构建一个规模庞大，但仍然可靠的软件系统是否可行？

这个问题第一眼看上去可能有点荒唐：无稽之谈。如果这件事情理论上不可能，那我们软件开发者还在忙什么呢？但仔细想想，上文提到的“墨菲定律”以及“大规模”前提下必然会遇到的各种不可靠的人员、代码、硬件、网络等因素，可以得出一个听起来相当合乎逻辑和直观的结论：如果某项工作要通过一系列“不可靠”的流程来完成，错误就会不断积累，导致最终的结果无法收敛和稳定。

这个问题并非是空穴来风。20 世纪 40 年代末，计算机之父约翰·冯·诺依曼花了大约两年时间研究这个问题，并提出了一个名为“自复制自动机”的理论。这个理论的基础是一台机器应该如何从基本部件构造出另一台与自己完全相同的机器。它的目的并不是简单地模拟或理解生物的自我复制，也不是简单地制造一台自复制的计算机。他的最终目标是回答一个理论问题：如何用一些不可靠的部件构造一个可靠的系统。

而自我复制的生物体恰好是用不可靠部件构建的可靠系统的最佳例子。在这里，“不可靠部件”可以理解为构成生命的大量细胞乃至分子，由于受到热力学扰动、生物复制误差等因素的干扰，这些分子本身是不可靠的。但生命系统可靠性的本质恰恰在于它能够利用不可靠部件完成遗传迭代。这里的关键点是承认细胞等这些部件可能会犯错，某个特定部件可能会崩溃死亡，但在生命这个微生态系统中，它的后代一定会出现，并取代该部件的作用，维持系统的整体稳定性。在这个微生态系统中，每一个部件都可以看作是一只凤凰（凤凰），它会变老，然后它就能重生。

建筑的演变

软件架构风格从大型机（），到多层单体架构（），到分布式架构（），到微服务（），到服务网格（Mesh），到无服务器架构（）……技术架构确实呈现出由大到小的发展趋势。近些年微服务兴起之后，各种文章纷纷总结、推崇微服务的好处，比如简化部署、逻辑拆分更清晰、方便技术异构、易于扩展扩容以应对更高性能等等，这些当然都是重要的优点和动机。但是，如果我们不拘泥于具体系统的具体问题，站在更宏观的角度看，上面列举的各种好处就像是锦上添花，是让系统“活得更好”的动机，绝对不如系统“保证生存”的需要那么基本、必不可少。 我认为，架构演进最重要的驱动力，或者说这种“由大到小”的最根本的驱动力，始终是为了便于某个服务的平滑“死亡”与“重生”。单个服务的生死存亡，是关系到整个系统可靠生存的关键本质。

比如企业中使用的单体架构的Java系统，更新升级必须有固定的停机计划，只能在特定的时间窗口内准时开始和结束。如果发生计划外停机，就是生产事故。但软件Bug并不会按照领导制定的停机计划“计划时间错误”来运行。为了应对缺陷和变更，Java曾经想出了OSGi等复杂的解决方案，来实现给正在运行的汽车换轮胎这种不可思议却又无奈的需求；从微服务架构的角度来看，这只是一个线上服务更新，先关掉1/3的机器，升级新软件版本，然后做流量测试，有条不紊地做金丝雀发布，实在是再正常不过了；从无服务器架构的角度来看，我们甚至都可以不用关心服务运行在什么基础设施上，甚至​​不需要知道是哪台机器，停机升级就无从谈起。

流水不腐，有衰败，有灭绝，有重生，有变迁，这是生态正常运转的合理规律。请试想一下，如果你的系统中的每一个组件都符合“”的特性，即使其中有些组件使用了极不靠谱的人员开发的极不靠谱的程序代码，比如有严重的内存泄漏，最多只能服务3分钟就会崩溃。即便如此，得益于整体架构中恰当、自动化的阻塞错误和重建服务的机制，从系统外部来看，整体系统依然能够稳定、健壮。

这

在企业软件开发历史上，每当一项新技术发布时，往往都会有一个传统，即设立“宠物店”（如 J2EE、.NET 等），用于展示该技术的发展。在展示不同的架构风格时，我也想遵循这个传统，但我从来没有养过宠物，所以我开了一家书店（），里面卖我写的几本书。这算是私下出售，也避免了使用资料时可能出现的版权问题。

虽然相信没人会误解，但我还是要强调，Sun 等公司设计宠物商店的目的并不是为了将来可以在网上卖小猫小狗，而纯粹是为了展示技术。所以请不要以“为了满足本次学生毕业设计的复杂度而引入如此大型的架构或框架，纯粹是一门大炮打苍蝇，绝对是过度设计”的观点来看待接下来的“”项目。相反，如果可能的话，作者会在新的技术和框架发布时继续更新，并以适当的形式将其添加到项目的不同版本中，这可能会使其技术栈越来越复杂。作者希望将这些新的、不断发展的知识融入到现有的知识框架中，让自己可以学习、理解和思考，然后将这些技术连同自己的观点和看法一起传播给有兴趣的人。

那是缘分。二十多年前，我在读中学的时候，就开始使用“ ”这个网名。它原本取自暴雪即时战略游戏《星际争霸》的英雄——顾名思义，他曾经是一位英雄，在牺牲自己之后，又重生为英雄，继续与刀锋女王战斗。虽然中学时，我就确定自己将来会从事信息技术工作，但显然无法预料到，二十年后我会写下这些文字。

那么，既然我们要开始一个关于“”的代码和故事，把它叫做“The ”怎么样？

《软件架构探索》一书阅读链接：

结尾