什么是 The fenix Project

Phoenix 不死鸟

在软件设计、架构工作中，都需要考虑哪些因素、需要解决哪些问题、有哪些行业标准的解决方案。我一直认为，技术人员的成长是有“捷径”的，做技术不仅要去看、去读、去想、去用，更要去写、去说。

也许是东西方文化差异的原因，尽管我们东方人会说“失败是成功之母”，但骨子里还是更注重一次就能把事做对、做好，尽量别出乱子；而西方人则要“更看得开”一些，把出错看作是正常、甚至是必须的发展过程，只要出了问题能够兜底，能重回正轨就好。

其实在软件工程的世界里，任何产品的研发，只要时间尺度足够长，人就总会疏忽犯错，代码就总会带有缺陷，电脑就总会宕机崩溃，网络就总会堵塞中断……

如何学习一项具体的语言、框架、工具，比如 Java、Spring、Vue.js，等等，都是相对具象的，不论其蕴含的内容多少、复杂程度的高低，它们至少是能看得见、摸得着的。

而如何学习某一种风格的架构方法，比如单体、微服务、服务网格、无服务、云原生，等等，则是相对抽象的，谈论它们可能要面临着“一百个人眼中有一百个哈姆雷特”的困境。

生命系统之所以可靠的本质，恰恰是因为它可以使用不可靠的部件来完成遗传迭代。这其中的关键点，便是承认细胞、分子等这些零部件可能会出错，某个具体的零部件可能会崩溃消亡，但在存续生命的微生态系统中，一定会有其后代的出现，重新代替该零部件的作用，以维持系统的整体稳定。因而，在这个微生态里，每一个部件都可以看作是一只不死鸟（Phoenix），它会老迈，而之后又能涅槃重生。

软件架构风格从大型机（Mainframe），发展到了多层单体架构（Monolithic），到分布式（Distributed），到微服务（Microservices），到服务网格（Service Mesh），到无服务（Serverless）……你能发现，在技术架构上确实呈现出“从大到小”的发展趋势。架构演变最重要的驱动力，或者说产生这种“从大到小”趋势的最根本的驱动力，始终都是为了方便某个服务能够顺利地“死去”与“重生”而设计的。个体服务的生死更迭，是关系到整个系统能否可靠续存的关键因素。

流水不腐，有老朽、有消亡、有重生、有更迭，才是正常生态的运作合理规律。

那么你来设想一下，如果你的系统中，每个部件都符合“Phoenix”的特性，哪怕其中的某些部件采用了极不靠谱的程序代码，哪怕存在严重的内存泄漏问题，最多只能服务三分钟就一定会崩溃。而即便这样，只要在整体架构设计中，有恰当的、自动化的错误熔断、服务淘汰和重建的机制，那在系统外部来观察，它在整体上仍然有可能表现出稳定和健壮的服务能力。

（nestjs曾经出现几分钟就重启一次，但是因为有pm2 和 pod机制的保证，只是接口调用失败率增加，而并非完全停机不可用）

从细胞构建生命的角度去理解架构设计，以及架构设计的演变。流水不腐，户枢不蠹。那句架构演变的重要驱动力是让服务顺利死亡和重生的观点，还是挺耐人寻味的，期待后边课程。