软件架构探索
“Phoenix”的字面意思，就是凤凰、不死鸟。
在软件工程的世界里，任何产品的研发、只要时间尺度足够长，人就总会疏忽犯错，代码就总会带有缺陷，电脑就总会宕机崩溃，网络就总会堵塞中断。所以如果一项工程需要大量的人员共同去研发，并保证他们分布在网络中的大量服务器节点能够同时运行，那么随着项目规模的增大，运作时间边长，它比如会受到墨菲定律的打击
墨菲定律：凡事只要有可能出错，那就一定会出错
为了得到高质量的软件产品，这两点都重要。前者重术、后者重道；前者更多与编码能力相关，后者更多和软件架构相关；前者主要由开发者个体水平决定，后者主要由技术决策者水平决定。 1.提升每一个人员、过程、产出物的能力和质量上 2.放在整体流程和架构上
前者是具体的语言、框架、工具，是相对具体的事物，后者是某一种风格的架构方式，例如单体、微服务、服务网格等，是相对抽象的。为了学习它，就需要真正去使用不同风格的架构方式，去实现某些需求，解决某些问题，在实践中观察他们的异同优劣。
可靠的系统
构建一个大规模但依然可靠的软件系统，是否可行？
如果一项工作，要经过多个“不靠谱”的过程相互协作完成，其中的误差会不断地累计叠加，导致最终结果比如不能收敛稳定。
计算机之父 冯·诺依曼研究这个问题，并得出一门理论《自复制自动机》，这个理论以机器应该如何从基本的部件中，构造出与自身相同的另一台机器引出。他的目的并不是单纯的模拟或理解生物体的自我复制，也不是简单的想制造自我复制的计算机。而是想回答一个理论问题：如何用一些不可靠的部件来够找出一个可靠的系统
“不可靠部件”可以理解为构成生命的大量细胞、分子。在各种因素干扰下，这些分子本身并不可靠。但却能完成遗传迭代。关键点：承认细胞、分子等零部件可能会出错，但在存续生命的微生态系统中，一定会有其后代的出现，重新代替该零部件的作用，以维持系统的整体稳定
因而，在这个微生态里，每一个部件都可以看作是一只“不死鸟 Phoenix”，他会老迈，而后涅槃重生。
架构的演进
软件架构风格从大型机（Mainframe），发展到多层单体架构（Monolithic），到分布式（Distributed），到微服务（Microservices），到服务网格（Service Mesh），到无服务（Serverless）...在技术机构上呈现出“从大到小”的发展趋势
架构演变的最重要驱动力，或者说产生这种“从大到小”趋势的最根本驱动力，始终是为了方便某个服务能够顺利的“死去”和“重生”而设计的。
举个例子 某个单体架构的Java系统，更新和升级都要在特定的时间窗口内开始，结束。如果出现计划之外的宕机，就是生产事故。
但软件的缺陷不会遵循这个规则来“固定时间出错”。所以为了应对缺陷和变化，要做到不停机检修。Java有OSGi和JVMTI Instrumentation等复杂的HotSwap方案，以实现给奔跑中的汽车更换轮胎这样匪夷所思却无可奈何得需求。
而在微服务架构的视角下，系统检修只不过是一次在线服务更新而已。先停掉1/3的机器，升级新的软件版本，再有条不紊的导流、测试、做金丝雀发布。而在无服务架构的视角下，我们甚至都不可能去关心服务所允许的基础设施，甚至连机器是哪台都不用知道。
流水不腐，有老朽、有消亡、有重生、有更迭，才是正常生态的运行合理规律
设想一下。如果系统中，每个部件都符合“Phoenix”特性，哪怕其中某些部件极不靠谱，出现严重的内存泄漏。只要在整体架构设计中，有恰当的、自动化的错误熔断、服务淘汰和重建的机制，那在系统外部观察，它在整体上仍然表现出稳定和健壮的服务能力。
为什么叫“The Fenix Project”
二十多年前，作者就开始用“LcyFenix”这个网名，它源自《星际争霸》里的一个Protoss英雄叫Fenix。他曾经是Zealot，牺牲后以Dragoon的形式重生，带领Protoss与刀锋女王Kerrigan继续抗争。
在课程里，作者会带着做不同架构风格的演示，演示不同架构技术。 那么既然要开始一段关于“Phoenix”的代码和故事，那便叫 “The Fenix Project”
