作者的凤凰指的是 Phfoenix 菲尼克斯（不死鸟）
架构本身就是在不断演进的
本书介绍了架构演进的历史：
架构并不是被发明出来的，而是持续演进的结果。
软件架构风格从大型机（Mainframe），到原始分布式（Distributed），到大型单体（Monolithic），到面向服务（Service-Oriented），到微服务（Microservices），到服务网格（Service Mesh），到无服务（Serverless）……技术架构上确实呈现出“从大到小”的发展趋势。
原始分布式：
UNIX 的分布式设计哲学：
Simplicity of both the interface and the implementation are more important than any other attributes of the system — including correctness, consistency, and completeness
保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。—— Richard P. Gabriel，The Rise of 'Worse is Better'，1991
可能与绝大多数人心中的认知会有差异，“使用多个独立的分布式服务共同构建一个更大型系统”的设想与实际尝试，反而要比今天大家所了解的大型单体系统出现的时间更早。
注：受限于早期计算机性能，人们开始尝试分布式系统。
单体架构（Monolithic）：
“单体架构”在整个软件架构演进的历史进程里，是出现时间最早、应用范围最广、使用人数最多、统治历史最长的一种架构风格，但“单体”这个名称，却是在微服务开始流行之后才“事后追认”所形成的概念。
此前，并没有多少人将“单体”视作一种架构来看待，如果你去查找软件架构的开发资料，可以轻而易举地找出大量以微服务为主题的书籍和文章，却很难找出专门教你如何开发单体系统的任何形式的材料，这一方面体现了单体架构本身的简单性，另一方面，也体现出在相当长的时间尺度里，大家都已经习惯了软件架构就应该是单体这种样子。
剖析单体架构之前，我们有必要先厘清一个概念误区，许多微服务的资料里，单体系统往往是以“反派角色”的身份登场的，譬如著名的微服务入门书《微服务架构设计模式》，第一章的名字就是“逃离单体的地狱”。这些材料所讲的单体系统，其实都是有一个没有明说的隐含定语：“大型的单体系统”。对于小型系统——即由单台机器就足以支撑其良好运行的系统，单体不仅易于开发、易于测试、易于部署，且由于系统中各个功能、模块、方法的调用过程都是进程内调用，不会发生进程间通信（Inter-Process Communication，IPC）。
注：单体架构是一种显然的自然而然的架构，但随着系统的增大，对机器性能要求的不断提高，系统的复杂度不断提高，最终导致“单体地狱”。
SOA 架构（Service-Oriented Architecture）：
面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。
微服务架构（Microservices）：
微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
后微服务时代（Cloud Native）：
从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代，此即为“后微服务时代”。
无服务架构（Serverless）：
如果说微服务架构是分布式系统这条路的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。
注：如本书所说
“虽然在顺序上笔者将“无服务”安排到了“微服务”和“云原生”时代之后，但它们两者并没有继承替代关系，强调这点是为了避免有读者从两者的名称与安排的顺序中产生“无服务就会比微服务更加先进”的错误想法。笔者相信软件开发的未来不会只存在某一种“最先进的”架构风格，多种具针对性的架构风格同时并存，是软件产业更有生命力的形态。笔者同样相信软件开发的未来，多种架构风格将会融合互补，“分布式”与“不分布式”的边界将逐渐模糊，两条路线在云端的数据中心中交汇。”
注：没有银弹，没有一种最好的架构，架构设计是为了解决需求，随着硬件软件的不断发展，演进出不同的架构风格，并且还在持续演进。
注：微服务主要是为了解决过大的单体系统，承认了系统组件是不可靠的，但可以通过不可靠组件构造一个可靠的系统。通过拆分服务，可以保证系统基本服务（登录认证，网关路由等）由资深开发控制，其他业务功能可以交给不同业务小组实现，单一业务服务出错不会影响到整体服务。
注：分布式系统的八大谬误
注：后微服务/无服务，随着云计算的发展，绝对意义的无限性能虽然不存在，但相对意义的无限性能已经成为了现实，实际上由云计算的软硬件实现了微服务，而不用应用来管理。
注：架构 一词来源于建筑行业，被引入到软件工程，但实际上软件工程中更类似于城市规划而不是房屋设计，架构 语义常常导致大家默认架构设计好了之后就基本不会再变动了，正如房屋建好了就基本不会变动框架了，可能存在修修补补。如果用城市规划来比喻可能更好，城市本身就是在不断发展，旧的道路房屋可能被重新规划设计，城市一步步扩大。
注：下图来自 《Clean Code》（代码整洁之道）
不可靠部件构造的可靠的系统
《自复制自动机》（Theory of Self-Reproducing Automata）
计算机之父冯·诺依曼（John von Neumann）
自复制机恰好就是一个最好的用不可靠部件构造的可靠的系统例子。这里，“不可靠部件”可以理解为构成生命的大量细胞、甚至是分子。由于热力学扰动、生物复制差错等因素干扰，这些分子本身并不可靠。但是生命系统之所以可靠的本质，恰是因为它可以使用不可靠的部件来完成遗传迭代。这其中的关键点便是承认细胞等这些零部件可能会出错，某个具体的零部件可能会崩溃消亡，但在存续生命的微生态系统中一定会有其后代的出现，重新代替该零部件的作用，以维持系统的整体稳定。在这个微生态里，每一个部件都可以看作一只不死鸟（Phoenix），它会老迈，而之后又能涅槃重生。
注：由于翻译问题，凤凰同 Phfoenix 菲尼克斯（不死鸟）的语义逐步混淆，同样的还包括 朱雀 。