送书方式：送书4本，留言区点赞最高4位，机器刷赞无效，截止时间7月7日晚8点。

周志明老师的《深入理解Java虚拟机》想必大家都不陌生，这本书凭借着生动易懂的文风、系统实用的知识点、成为原创计算机图书经典中的经典。如今周志明老师的开源项目《凤凰架构》纸质书已正式出版，这是一本从架构视角讲解如何构建大型分布式系统的著作，是作者多年架构和研发经验的总结，相信本书必将成为原创计算机图书领域的又一座丰碑。

架构模式的每一次演进都是凤凰涅槃

系统架构的每一次迭代都是浴火重生

构成系统的每一个部件都是一只不死鸟

构成大规模系统的每一个部件都可以是不可靠的，会出错，会老朽，甚至是消亡，如何让不可靠部件构成的系统持续保持可靠性，本书将给你答案：

《凤凰架构：构建可靠的大型分布式系统》

超级畅销书《深入理解Java虚拟机》作者周志明最新力作，国内多位架构专家联袂推荐，从架构演进、架构设计思维、分布式技术、不可变基础设施、技术方法论5个维度全面探索如何构建可靠的大型分布式系统。

“Phoenix”（凤凰）这个词在东方的技术书中不常用，但在西方的软件工程读物中，尤其是在关于敏捷、DevOps话题的作品中时常出现。软件工程小说《凤凰项目》讲述了徘徊在死亡边缘的凤凰项目在精益方法下浴火重生的故事；MartinFowler在诠释“持续交付”时，曾多次提到“PhoenixServer”（凤凰服务器，取其能够“涅槃重生”之意）与“SnowflakeServer”（雪花服务器，取其“世界上没有相同的两片雪花”之意）的优劣比对。也许是东西方文化的差异，尽管有“失败是成功之母”这样的谚语，但我们东方人的骨子里更注重的还是一次把事做对、做好，尽量别出乱子；而西方人则要“更看得开”一些，把出错看作正常甚至是必需的发展过程，只要出了问题能够兜底使其重回正轨便好。

在软件工程里，任何产品的研发，如果持续时间很长，人总免不了疏忽、犯错，导致代码存在缺陷，电脑宕机崩溃，网络堵塞中断……如果一项工程需要大量的人员共同研发某个大规模的软件产品，并使其分布在网络中的大量的服务器节点中同时运行，随着项目规模增大、运作时间变长，其必然会受到墨菲定律的无情打击。

为了得到高质量的软件产品，我们是应该把精力更多地集中在提升其中每一个人员、过程、产出物的能力和质量上？还是应该把更多精力放在整体流程和架构上？

笔者对这个问题先给一个“和稀泥”式的回答：这两者都重要。前者重术，后者重道；前者更多与编码能力相关，后者更多与软件架构相关；前者主要由开发者个体的水平决定，后者主要由技术决策者的水平决定。

然而，笔者也必须强调此问题的另外一面：这两者的理解路径和抽象程度是不一样的。如何学习一项具体的语言、框架、工具，譬如Java、Spring、Vue.js等，是相对具象的，不论其蕴含的内容多少，复杂程度高低，它至少是能看得见、摸得着的。而如何学习某一种风格的架构方法，譬如单体、微服务、服务网格、无服务、云原生等，则是相对抽象的，谈论它们可能要面临“一千个人眼中有一千个哈姆雷特”的困境。谈这方面的话题，若要言之有物，就不能是单纯的经验陈述。回到这些架构根本的出发点和问题上，笔者认为，真正去使用这些不同风格的架构方法来实现某些需求，解决某些问题，然后在实践中观察它们的异同优劣，会是一种很好的也许是最好的讲述方式。笔者想说一下这些架构，而且想说得透彻明白，就需要代码与文字的配合，于是便有了这本书，以及与它配套的实践项目。

可靠的系统

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

这个问题听起来的第一感觉也许会有点荒谬。如果这个事情从理论上来说就是根本不可能的，那我们这些软件开发人员在瞎忙活些什么？但你再仔细想想，前面才提到的“墨菲定律”和在“大规模”这个前提下必然会遇到各种“不靠谱”的人员、代码、硬件、网络等因素，从中能得出一个听起来颇为合理的推论：如果一项工作要经过多个“不靠谱”的过程相互协作完成，其中的误差应会不断累积叠加，导致最终结果必然不能收敛稳定。

这个问题也并非杞人忧天、庸人自扰式的瞎操心，计算机之父冯·诺依曼在20世纪40年代末期，曾经花费大约两年时间，研究这个问题并且得出了一个理论—自复制自动机（Self-ReproducingAutomata）。这个理论以机器应该如何从基本的部件中构造出与自身相同的另一台机器引出，其目的并不是想单纯地模拟或者理解生物体的自我复制，也并不是想简单地制造自我复制的计算机，而是想回答一个理论问题：如何用一些“不可靠”部件构造出一个可靠的系统。

当时自复制自动机的艺术表示（图片来自维基百科）

自复制自动机恰好就是一个最好的用“不可靠”部件构造可靠系统的例子。这里，“不可靠”部件可以理解为构成生命的大量细胞，甚至是分子。由于热力学扰动、生物复制差错等因素干扰，这些分子本身并不可靠。但是生命系统之所以可靠，恰是因为它可以使用“不可靠”部件来完成遗传迭代。这其中的关键点便是承认细胞等零部件可能会出错，某个具体的零部件可能会崩溃消亡，但在存续生命的微生态系统中其后代一定会出现，重新代替该零部件，实现它的作用，以维持系统的整体稳定。在这个微生态里，每一个部件都可以看作一只“不死鸟”（Phoenix），它会老迈，又能涅槃重生。

架构的演进

从大型机（Mainframe）、原始分布式（Distributed）、大型单体（Monolithic）、面向服务（Service-Oriented）、微服务（Microservice）、服务网格（ServiceMesh）到无服务（Serverless）等，技术架构确实呈现出“从大到小”的发展趋势。近年来，自微服务兴起以后，涌现出各类文章去总结、赞美微服务带来的种种好处，诸如简化部署、逻辑拆分更清晰、便于技术异构、易于伸缩拓展以提供更高的性能等，这些当然都是重要优点和动力。可是，如果不拘泥于特定系统或特定某个问题，以更宏观的角度来看，前面所列的种种好处都只能算是“锦上添花”，是属于让系统“活得更好”的动因，肯定比不上系统如何“确保生存”的需求更关键、更贴近本质。在笔者看来，架构演变最重要的驱动力，或者说这种“从大到小”的变化趋势的最根本驱动力，始终都是为了方便某个服务能够顺利地“死去”与“重生”。个体服务的生死更迭，是关系到整个系统能否可靠存续的关键因素。

举个例子，某企业中应用的单体架构的Java系统，其更新、升级都必须要有固定的停机计划，必须在特定的时间窗口内才能按时开始，且必须按时结束。如果出现了非计划的宕机，那便是生产事故。但是软件的缺陷不会遵循定下的停机计划来“安排时间出错”。为了应对缺陷与变化，做到不停机地检修，Java曾经制定了OSGi和JVMTIInstrumentation等复杂的HotSwap方案，以实现“给奔跑中的汽车更换轮胎”这种匪夷所思却又无可奈何的需求。而在微服务架构的视角下，所谓系统检修，不过只是一次在线服务更新而已，先停掉1/3的机器，升级新的软件版本，再有条不紊地导流、测试、做金丝雀发布，一切都显得如此理所当然、平淡寻常。在无服务架构的视角下，我们甚至都不需要关心服务所运行的基础设施，连机器是哪台都不必知道，停机升级就更无须

转载请注明:http://www.aideyishus.com/lkgx/3876.html