如何开始

《凤凰架构：构建可靠的大型分布式系统》这个开源文档项目的是笔者对自己在软件架构方面知识的总结，它是完全免费开放的，但免费的、开源的文档并不意味着你使用它时就没有成本，也不见得这个文档中所有的内容对每一个开发人员来说都是必要的。鲁迅说浪费别人的时间等于谋财害命，为了避免浪费阅读者的时间和精力，笔者除了自身力求在知识点准确性和叙述流畅性方面保证质量之外，同时也在本文中简要介绍每一章的主题和所面向的读者类型，本文档各章节之间并没有明显的前后依赖关系，阅读时有针对性的查阅是完全可行的，无需一篇不漏地顺序阅读，在此目录中列出了各文章的明细及字数，希望有助于你制定阅读计划。

引导篇 探索起步 字数: 20,606 字

这部分面向于准备对文档介绍的内容亲身实践的探索者。

这部分没有知识性的内容，是整部文档的引导，也可以视为这个文档附带示例工程的说明书，以及相应运行环境的部署手册。之所以将它安排在目录的第一位，是因为笔者相信如果你是一名驾驶初学者，最合理的学习路径应该是先把汽车发动，然后慢慢行驶起来，而不是马上从“引擎动力原理”、“变速箱构造”入手去设法深刻地了解一台汽车。相信计算机技术也是同理，先从运行程序，看看效果，搭建好开发、调试环境，对即将进行的工作有一个整体的认知开始是很有好处的。

工程提示

本文档所涉及到的工程均在 GitHub 上存有独立的项目，以方便构建、阅读、运行和 fork。

这部分中的部分内容，是由这些工程的 README.md 文件人工同步而来，并没有通过持续集成工具自动处理，所以可能有偶尔更新不一致的情况，如可能，建议到这些项目的 GitHub 页面上查看最新情况，在右上角[0].click())有相应的超链接。如这些工程对你有用，望请不吝给个 。

这部分所提供的工程是作为后面所述知识的演示样例，由于数量确实不少，并无必要一次性地把上面所有的工程都运行起来。因为它们是采用不同的技术来解决同一个问题，所以每个工程执行后，最终看到的界面效果均是一样的，只是实现的架构不同。而通过不同的架构、技术去解决同一个问题，这也正是这批工程的最大价值所在。

如果你本身对某些架构风格已经熟练掌握，那笔者的建议是不妨选择一种你目前关注的架构风格去运行起来，然后与你熟悉的技术方案进行比对（引导篇 探索起步）、了解它解决的问题与背景（第一部分 演进中的架构）、思考这种架构涉及到哪些标准方案（第二部分 架构师的视角）、理清分布式系统中新的挑战与应对（第三部分 分布式的基石），以及如何将这些纯粹的技术问题隐藏起来，使其不会干扰业务代码（第四部分 不可变基础设施）。

第一部分 演进中的架构 字数: 20,313 字

这部分适合所有开发者，但尤其推荐刚刚从单体架构向微服务架构转型的开发者去阅读。

架构并不是“发明”出来的，是持续进化的结果。“服务架构演进史”这部分，笔者假借讨论历史之名，来梳理微服务发展里程中出现的大量名词、概念，借着微服务的演变过程，我们将从这些概念起源的最初，去分析它们是什么、它们取代了什么、以及它们为什么能够在斗争中取得成功，为什么变得不可或缺的支撑，又或者它们为什么会失败，在竞争中被淘汰，或逐渐湮灭于历史的烟尘当中。

第二部分 架构师的视角 字数: 123,486 字

这部分讨论与风格无关的架构知识，适合所有技术架构师、系统设计、开发人员。

“架构师”这个词的外延非常宽泛，不同语境中有不同所指，这部文档中的技术架构师特指的是企业架构中面向技术模型的系统设计者，这意味着讨论范围不会涉及到贴近于企业战略、业务流程的系统分析、信息战略设计等内容，而是聚焦于贴近一线研发人员的技术方案设计者。这部分将介绍作为一个架构师，你应该在做架构设计时思考哪些问题，有哪些主流的解决方案和行业标准做法，各种方案有什么优点、缺点，不同的解决方法会带来什么不同的影响，等等。以达到将“架构设计”这种听起来抽象的工作具体化、具象化的目的。

这部分介绍的内容与具体哪一种架构风格无关，作为后续实践的基础，讨论的是普适的架构技术与技巧，无论你是否关注微服务、云原生这些概念，无论你是从事架构设计还是从事编码开发，了解这里所列的基础知识，对每一个技术人员都是有价值的。

第三部分 分布式的基石 字数: 72,594 字

这部分面向于使用分布式架构的开发人员。

只要选择了分布式架构，无论是 SOA、微服务、服务网格或者其他架构风格，涉及与远程服务交互时，服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通讯、事务处理，等等，这一系列问题都是无可避免的。不同的架构风格，其区别是到底要在技术规范上提供统一的解决方案，还是由应用系统自行去解决，又或者在基础设施层面将一类问题隔离掉，这部分将会讨论这类问题的解决思路、方法和常见工具。

第四部分 不可变基础设施 字数: 89,111 字

这部分面向于基础设施运维人员、技术平台的开发者。

“不可变基础设施”这个概念由来已久。2012 年 Martin Fowler 设想的“凤凰服务器”与 2013 年 Chad Fowler 正式提出的“不可变基础设施”，都阐明了基础设施不变性所能带来的益处。在云原生基金会（Cloud Native Computing Foundation，CNCF）所定义的“云原生”概念中，“不可变基础设施”提升到了与微服务平级的重要程度，此时它的内涵已不再局限于方便运维、程序升级和部署的手段，而是升华为向应用代码隐藏分布式架构复杂度、让分布式架构得以成为一种可普遍推广的普适架构风格的必要前提。在云原生时代、后微服务时代中，软件与硬件之间的界线已经彻底模糊，无论是基础设施的运维人员，抑或技术平台的开发人员，都有必要深入理解基础设施不变性的目的、原理与实现途径。

第五部分 技术方法论 字数: 14,790 字

这部分面向于在企业中能对重要技术决策进行拍板的决策者。

这部文档的主体内容是务实的，多谈具体技术，少谈方向理论。只在这部分中会集中讨论几点与分布式、微服务、架构等相关的相对务虚的话题。

笔者认为对于一个技术人员，成长主要的驱动力是实践，在开发程序、解决问题中增长自身的知识，再将知识归纳、总结、升华成为理论的，所以笔者将这部分安排到了整部文档的末尾，也是希望大家能先去实践，再谈理论。同时，笔者也认为对于一名研究人员，或者企业中真正能决定技术方向的决策者，理论与实践都不可缺少，涉及决策的场景中，成体系的理论知识甚至比实践经验还要关键，因为执行力再强也必须用在正确的方向上才有价值。如果你对自己的规划是有朝一日要从一名技术人员发展成研究或者管理角色，补充这部分知识是必不可少的。

篇外 随笔文章 字数: 36,007 字

这部分无特定读者对象，内容是笔者日常文章的整理。

这部分是一些笔者所了解的开发、设计中心得感悟的集合，由于它们还不具备足够的系统性，没有安排入前面的知识框架之中。但有一些或精彩，或有价值，或实用的技巧，笔者不想错过，所以安排了这一章相对独立的内容。

另外，这部分内容类似于笔者的随笔博客，将不会出现在文档的音频版与传统纸质书版本中。

篇外 附录 字数: 12,034 字

这部分面向刚开始接触云原生环境的设计者、开发者。

这一章内容主要是云原生环境搭建和程序发布过程，原本它们并不属于笔者准备讨论的重点话题，至少没有到单独开一章的必要程度。但由于容器化的服务编排环境本身构建、管理和运维都有一定的复杂性，尤其是在国内特殊的网络环境下，无法直接访问到 Google 等国外的代码仓库，以至于不得不通过手工预载镜像或者代理的方式来完成环境搭建。为了避免刚刚接触这一领域的读者在入门第一步就受到不必要的心理打击，笔者专门设置了这个目录章节。这章与其他几章讨论设计思想、实现原理的风格差异很大，它是整部文档唯一的讨论具体如何操作的内容。

市面上介绍如何安装环境的书籍、资料已经不计其数，肯定有相当一部分读者这章的内容本身就是了解的，已掌握的读者建议无需仔细阅读，在有需要的时候，可当作工具查阅。