基础架构

1.架构到底是指什么

架构”这个词常见，但如果深究一下“架构”到底指什么，大部分人也许并不一定能够准确地回答。
例如：架构和框架是什么关系？有什么区别？
Linux 有架构，MySQL 有架构，JVM 也有架构，使用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪个架构呢？
微信有架构，微信的登录系统也有架构，微信的支付系统也有架构，当我们谈微信架构时，到底是在谈什么架构？
要想准确地回答这几个问题，关键在于梳理几个有关系而又相似的概念：系统与子系统、模块与组件、框架与架构。

1.1 系统与子系统

    系统：由一群有关联的个体组成，按照某种规则运作，能完成个别元件所不能单独完成的工作的群体。

    子系统：子系统也是由一群有关联的个体组成的系统。是更大的系统中的一部分。

1.2 模块与组件

    模块：软件模块（Module）是一套一致而互相有紧密关联的软件组织。包含了程序和数据结构两部分。模块有接口，模块间可以互相调用。

    组件：自包含的、可编程的、可重用的的软件单元。软件组件可以很容易被用于组装应用程序中。

    模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。

1.3 框架与架构

    框架(framework)：为了实现某个业界标准或完成特定基本任务的软件组件规范。也指为了实现某个软件组件规范时，提供规范要求只基础功能的软件产品。

    架构(Architecture)：软件架构的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。

    框架关注的是“规范”，架构关注的是“结构”。

1.4 重新定义架构

    参考*的定义，我将架构重新定义为：软件 架构指软件系统的顶层结构。

    这个定义看似很简单，但包含的信息很丰富，基本上把系统、子系统、模块、组件、架构等概念都串起来了，我来详细解释一下。

    • 首先，“系统是一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等；架构需要明确系统包含哪些“个体”。

    • 其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。

    • 第三，*定义的架构用到了“基础结构”这个说法，我改为“顶层结构”，可以更好地区分系统和子系统，避免将系统架构和子系统架构混淆在一起导致架构层次混乱。

1.4 架构的分类（系统架构，技术架构，应用架构）

    • 系统架构：指的完整系统的组成架构，例如系统分成几个部分？服务平台、管理门户、终端门户、ATM门户、外部系统以及接口、支撑系统等，将这些系统进行合理的划分。然后再进行功能分类细分，例如服务平台内部划分为系统管理、用户管理、帐号管理、支付管理、接口层、统计分析等逻辑功能。总之，将整个系统业务分解为逻辑功能模块，并且科学合理，就是系统架构了。

    • 技术架构：从技术层面描述，主要是分层模型，例如持久层、数据层、逻辑层、应用层、表现层等，然后每层使用什么技术框架，例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等，分别说明，要求这些技术能够将整个系统的主要实现概括。

    • 应用架构：主要考虑部署，例如你不同的应用如何分别部署，如何支持灵活扩展、大并发量、安全性等，需要画出物理网络部署图。按照应用进行划分的话，还需要考虑是否支持分布式SOA。

 

2.架构设计的历史背景

    理解了架构的有关概念和定义之后，今天，我会给你讲讲架构设计的历史背景。我认为，如果想要深入理解一个事物的本质，最好的方式就是去追寻这个事物出现的历史背景和推动因素。我们先来简单梳理一下软件开发进化的历史，探索一下软件架构出现的历史背景。

2.1 机器语言（1940 年之前）

    最早的软件开发使用的是“机器语言”，直接使用二进制码 0 和 1 来表示机器可以识别的指令和数据。例如，在 8086 机器上完成“s=768+12288-1280”的数学运算，机器码如下：

101100000000000000000011
000001010000000000110000
001011010000000000000101

    不用多说，不管是当时的程序员，还是现在的程序员，第一眼看到这样一串东西时，肯定是一头雾水，因为这实在是太难看懂了，这还只是一行运算，如果要输出一个“hello world”，面对几十上百行这样的 0/1 串，眼睛都要花了！

    看都没法看，更何况去写这样的程序，如果不小心哪个地方敲错了，将 1 敲成了 0，例如：

101100000000000000000011
000001010000000000110000
001011000000000000000101

    如果要找出这个程序中的错误，程序员的心里阴影面积有多大？

    归纳一下，机器语言的主要问题是三难：太难写、太难读、太难改！

2.2 汇编语言（20 世纪 40 年代）

    为了解决机器语言编写、阅读、修改复杂的问题，汇编语言应运而生。汇编语言又叫“符号语言”，用助记符代替机器指令的操作码，用地址符号（Symbol）或标号（Label）代替指令或操作数的地址。例如，为了完成“将寄存器 BX 的内容送到 AX 中”的简单操作，汇编语言和机器语言分别如下。

机器语言：1000100111011000
汇编语言：mov ax,bx

    相比机器语言来说，汇编语言就清晰得多了。mov 是操作，ax 和 bx 是寄存器代号，mov ax,bx 语句基本上就是“将寄存器 BX 的内容送到 AX”的简化版的翻译，即使不懂汇编，单纯看到这样一串语言，至少也能明白大概意思。

    汇编语言虽然解决了机器语言读写复杂的问题，但本质上还是面向机器的，因为写汇编语言需要我们精确了解计算机底层的知识。例如，CPU 指令、寄存器、段地址等底层的细节。这对于程序员来说同样很复杂，因为程序员需要将现实世界中的问题和需求按照机器的逻辑进行翻译。

2.3 高级语言（20 世纪 50 年代）

    为了解决汇编语言的问题，计算机前辈们从 20 世纪 50 年代开始又设计了多个高级语言，最初的高级语言有下面几个，并且这些语言至今还在特定的领域继续使用。

    为什么称这些语言为“高级语言”呢？

    原因在于这些语言让程序员不需要关注机器底层的低级结构和逻辑，而只要关注具体的问题和业务即可。除此以外，通过编译程序的处理，高级语言可以被编译为适合不同 CPU 指令的机器语言。程序员只要写一次程序，就可以在多个不同的机器上编译运行，无须根据不同的机器指令重写整个程序。

2.4 第一次软件危机与结构化程序设计（20 世纪 60 年代~20 世纪 70 年代）

    高级语言的出现，解放了程序员，但好景不长，随着软件的规模和复杂度的大大增加，20 世纪 60 年代中期开始爆发了第一次软件危机，典型表现有软件质量低下、项目无法如期完成、项目严重超支等，因为软件而导致的重大事故时有发生。例如，1963 年美国（http://en.wikipedia.org/wiki/Mariner_1）的水手一号火箭发射失败事故，就是因为一行 FORTRAN 代码错误导致的。

    软件危机最典型的例子莫过于 IBM 的 System/360 的操作系统开发。佛瑞德·布鲁克斯（Frederick P. *s, Jr.）作为项目主管，率领 2000 多个程序员夜以继日地工作，共计花费了 5000 人一年的工作量，写出将近 100 万行的源码，总共投入 5 亿美元，是美国的“曼哈顿”原子弹计划投入的 1/4。尽管投入如此巨大，但项目进度却一再延迟，软件质量也得不到保障。布鲁克斯后来基于这个项目经验而总结的《人月神话》一书，成了畅销的软件工程书籍。

    为了解决问题，在 1968、1969 年连续召开两次著名的 NATO 会议，会议正式创造了“软件危机”一词，并提出了针对性的解决方法“软件工程”。虽然“软件工程”提出之后也曾被视为软件领域的银弹，但后来事实证明，软件工程同样无法根除软件危机，只能在一定程度上缓解软件危机。

    差不多同一时间，“结构化程序设计”作为另外一种解决软件危机的方案被提了出来。艾兹赫尔·戴克斯特拉（Edsger Dijkstra）于 1968 年发表了著名的《GOTO 有害论》论文，引起了长达数年的论战，并由此产生了结构化程序设计方法。同时，第一个结构化的程序语言 Pascal 也在此时诞生，并迅速流行起来。

    结构化程序设计的主要特点是抛弃 goto 语句，采取“自顶向下、逐步细化、模块化”的指导思想。结构化程序设计本质上还是一种面向过程的设计思想，但通过“自顶向下、逐步细化、模块化”的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。结构化程序方法成为了 20 世纪 70 年代软件开发的潮流。

2.5 第二次软件危机与面向对象（20 世纪 80 年代）

    结构化编程的风靡在一定程度上缓解了软件危机，然而随着硬件的快速发展，业务需求越来越复杂，以及编程应用领域越来越广泛，第二次软件危机很快就到来了。

    第二次软件危机的根本原因还是在于软件生产力远远跟不上硬件和业务的发展。第一次软件危机的根源在于软件的“逻辑”变得非常复杂，而第二次软件危机主要体现在软件的“扩展”变得非常复杂。结构化程序设计虽然能够解决（也许用“缓解”更合适）软件逻辑的复杂性，但是对于业务变化带来的软件扩展却无能为力，软件领域迫切希望找到新的银弹来解决软件危机，在这种背景下，面向对象的思想开始流行起来。

    面向对象的思想并不是在第二次软件危机后才出现的，早在 1967 年的 Simula 语言中就开始提出来了，但第二次软件危机促进了面向对象的发展。面向对象真正开始流行是在 20 世纪 80 年代，主要得益于 C++ 的功劳，后来的 Java、C# 把面向对象推向了新的高峰。到现在为止，面向对象已经成为了主流的开发思想。

    虽然面向对象开始也被当作解决软件危机的银弹，但事实证明，和软件工程一样，面向对象也不是银弹，而只是一种新的软件方法而已。

2.6 软件架构的历史背景

    虽然早在 20 世纪 60 年代，戴克斯特拉这位上古大神就已经涉及软件架构这个概念了，但软件架构真正流行却是从 20 世纪 90 年代开始的，由于在 Rational 和 Microsoft 内部的相关活动，软件架构的概念开始越来越流行了。

    与之前的各种新方法或者新理念不同的是，“软件架构”出现的背景并不是整个行业都面临类似相同的问题，“软件架构”也不是为了解决新的软件危机而产生的，这是怎么回事呢？

    卡内基·梅隆大学的玛丽·肖（Mary Shaw）和戴维·加兰（David Garlan）对软件架构做了很多研究，他们在 1994 年的一篇文章《软件架构介绍》（An Introduction to Software Architecture）中写到：

    “When systems are constructed from many components, the organization of the overall system-the software architecture-presents a new set of design problems.”

    简单翻译一下：随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。

    这段话很好地解释了“软件架构”为何先在 Rational 或者 Microsoft 这样的大公司开始逐步流行起来。因为只有大公司开发的软件系统才具备较大规模，而只有规模较大的软件系统才会面临软件架构相关的问题，例如：

    • 系统规模庞大，内部耦合严重，开发效率低；

    • 系统耦合严重，牵一发动全身，后续修改和扩展困难；

    • 系统逻辑复杂，容易出问题，出问题后很难排查和修复。

    软件架构的出现有其历史必然性。20 世纪 60 年代第一次软件危机引出了“结构化编程”，创造了“模块”概念；20 世纪 80 年代第二次软件危机引出了“面向对象编程”，创造了“对象”概念；到了 20 世纪 90 年代“软件架构”开始流行，创造了“组件”概念。我们可以看到，“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高。

    《人月神话》中提到的 IBM 360 大型系统，开发时间是 1964 年，那个时候结构化编程都还没有提出来，更不用说软件架构了。如果 IBM 360 系统放在 20 世纪 90 年代开发，不管是质量还是效率、成本，都会比 1964 年开始做要好得多，当然，这样的话我们可能就看不到《人月神话》了。

2.7 理解与思考：为何结构化编程、面向对象编程、软件工程、架构设计最后都没有成为软件领域的银弹

    在古代的狼人传说中，只有用银质子弹（银弹）才能制服这些异常凶残的怪兽。在软件开发活动中，“银弹”特指人们渴望找到用于制服软件项目这头难缠的“怪兽”的“万能钥匙”。

    软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。从IT技术的发展历程来看，先辈们在上述不同的环节中提出过很多在当时看来很先进的方法与理念。但是，这些方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点：我们可以通过诸多方式去接近“银弹”，但很遗憾，软件活动中没有“银弹”。

    布鲁克斯发表《人月神话》三十年后，又写了《设计原本》。他认为一个成功的软件项目的最重要因素就是设计，架构师、设计师需要在业务需求和IT技术中寻找到一个平衡点。个人觉得，对这个平衡点的把握，就是架构设计中的取舍问题。而这种决策大部分是靠技术，但是一定程度上也依赖于架构师的“艺术”，技术可以依靠新工具、方法论、管理模式去提升，但是“艺术”无法量化 ，是一种权衡。

    软件设计过程中，模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论，软件架构是一种对软件的“组织”方法论。一分一合，其目的是为了软件研发过程中的成本、进度、质量得到有效控制。但是，一个成功的软件设计是要适应并满足业务需求，同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”，这就决定了这是一个动态活动，出现新问题，解决新问题，没有所谓的“一招鲜”。

    以上只是针对设计领域的银弹讨论，放眼到软件全生命周期，银弹问题会更加突出。

    小到一个软件开发团队，大到一个行业，没有银弹，但是“行业最佳实践”可以作为指路明灯，这个可以有。

 

3.架构设计的目的

3.1 架构设计的误区

    • 因为架构很重要，所以要做架构设计

    • 不是每个系统都要做架构设计吗

    • 公司流程要求系统开发过程中必须有架构设计

    • 为了高性能、高可用、可扩展，所以要做架构设计

3.2 架构设计的真正目的

    通过分享的架构设计的历史背景，可以看到，整个软件技术发展的历史，其实就是一部与“复杂度”斗争的历史，架构的出现也不例外。简而言之，架构也是为了应对软件系统复杂度而提出的一个解决方案，通过回顾架构产生的历史背景和原因，我们可以基本推导出答案：架构设计的主要目的是为了解决软件系统复杂度带来的问题。

 

4.复杂度来源

4.1 复杂度来源:高性能

    软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度。

4.1.1 单机复杂度

    计算机内部复杂度最关键的地方：操作系统

    操作系统和性能最相关的是：进程和线程

    分时调度，本质上仍然是串行任务

    多cpu才能做到真正的同时执行计算任务

    常见解决方案：SMP（对称多处理器结构）、NUMA（非一致存储访问结构）、MPP（海量并行处理结构）

4.1.2 集群复杂度

任务分配【横向扩展】

    指的是每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行

任务分解【隔离局部瓶颈 把握拆分粒度】

    通过任务分配的方式，我们能够突破单台机器处理性能的瓶颈，通过增加更多的机器来满足业务的性能需求，但如果业务本身也越来越复杂，单纯只通过任务分配的方式来扩展性能，收益会越来越低。例如，业务简单的时候 1 台机器扩展到 10 台机器，性能能够提升 8 倍（需要扣除机器群带来的部分性能损耗，因此无法达到理论上的 10 倍那么高），但如果业务越来越复杂，1 台机器扩扩展到 10 台，性能可能只能提升 5 倍。造成这种现象的主要原因是业务越来越复杂，单台机器处理的性能会越来越低。为了能够继续提升性能，我们需要采取第二种方式：任务分解。

4.2 复杂度来源：高可用

    高可用定义：系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。

    系统的高可用方案五花八门，但万变不离其宗，本质上都是通过“冗余”来实现高可用。

    高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。

    分布式领域里面有一个著名的 CAP 定理，从理论上论证了存储高可用的复杂度。也就是说，存储高可用不可能同时满足“一致性、可用性、分区容错性”，最多满足其中两个，这就要求我们在做架构设计时结合业务进行取舍。

    无论是计算高可用还是存储高可用，其基础都是“状态决策”，即系统需要能够判断当前的状态是正常还是异常，如果出现了异常就要采取行动来保证高可用。

几种常见的决策方式：

    • *式。存在一个独立的决策主体，我们姑且称它为“决策者”，负责收集信息然后进行决策；所有冗余的个体，我们姑且称它为“上报者”，都将状态信息发送给决策者。

    • 协商式。两个独立的个体通过交流信息，然后根据规则进行决策，最常用的协商式决策就是主备决策。

    • *式。个独立的个体通过投票的方式来进行状态决策。

4.3 复杂度来源：可拓展性

4.3.1 What：什么是架构的可扩展性？

    业务需求、运行环境方面的变化都会导致软件系统发生变化，而这种软件系统对上述变化的适应能力就是可扩展性。

    可扩展性可以理解为是一种从功能需求方面考虑的软件属性，属性就会存在好坏之分。

    按照可扩展性的定义，一个具备良好可扩展性的架构设计应当符合开闭原则：对扩展开放，对修改关闭。衡量一个软件系统具备良好可扩展性主要表现但不限于：（1）软件自身内部方面。在软件系统实现新增的业务功能时，对现有系统功能影响较少，即不需要对现有功能作任何改动或者很少改动。（2）软件外部方面。软件系统本身与其他存在协同关系的外部系统之间存在松耦合关系，软件系统的变化对其他软件系统无影响，其他软件系统和功能不需要进行改动。反之，则是一个可扩展性不好的软件系统。

4.3.2 How：如何设计可扩展性好的架构？

    面向对象思想、设计模式都是为了解决可扩展性的而出现的方法与技术。

    设计具备良好可扩展性的系统，有两个思考角度：

（1）从业务维度。对业务深入理解，对可预计的业务变化进行预测。

    在业务维度。对业务深入理解，对业务的发展方向进行预判，也就是不能完全不考虑可扩展性；但是，变化无处不在，在业务看得远一点的同时，需要注意:警惕过度设计；不能每个设计点都考虑可扩展性；所有的预测都存在不正确的可能性。

（2）从技术维度。利用扩展性好的技术，实现对变化的封装。

    在技术维度。预测变化是一回事，采取什么方案来应对变化，又是另外一个复杂的事情。即使预测很准确，如果方案不合适，则系统扩展一样很麻烦。第一种应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。

4.3.3 在实际工作场景中的解决方案

    在实际软件系统架构设计中，常通过以下技术手段实现良好的可扩展性:

（1）使用分布式服务(框架)构建可复用的业务平台。

    利用分布式服务框架(如Dubbo)可以将业务逻辑实现和可复用组件服务分离开，通过接口降低子系统或模块间的耦合性。新增功能时，可以通过调用可复用的组件实现自身的业务逻辑，而对现有系统没有任何影响。可复用组件升级变更的时候，可以提供多版本服务对应用实现透明升级，对现有应用不会造成影响。

（2）使用分布式消息队列降低业务模块间的耦合性。

    基于生产者-消费者编程模式，利用分布式消息队列(如RabbitMQ)将用户请求、业务请求作为消息发布者将事件构造成消息发布到消息队列，消息的订阅者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息生产和消息处理分离开来，可以透明地增加新的消息生产者任务或者新的消息消费者任务。

4.4 复杂度来源：低成本

    当我们的架构方案只涉及几台或者十几台服务器时，一般情况下成本并不是我们重点关注的目标，但如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点。

    低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束。我们首先设定一个成本目标，当我们根据高性能、高可用的要求设计出方案时，评估一下方案是否能满足成本目标，如果不行，就需要重新设计架构；如果无论如何都无法设计出满足成本要求的方案，那就只能找老板调整成本目标了。

    低成本给架构设计带来的主要复杂度体现在，往往只有“创新”才能达到低成本目标。

    实现低成本的几个经典例子：

    • NoSQL(如MS、redis)是为了解决关系型数据库无法应用高并发下的访问压力。

    • 全文搜索引擎(ES)是为了解决关系型数据库like搜索低效的问题。

    • Hadoop是为了解决传统文件系统无法应对海量数据的计算和存储问题。

    无论是引进新技术还是创造新技术，都需是一件复杂的事情。引进新技术，需要花费时间去学习新技术，并与现有的技术相结合。创造新技术则需要去创建新的理念和技术，并且与现有的技术有很大的飞跃。

4.5  复杂度来源：安全

    安全是一个庞大而复杂的领域，一旦出现安全问题，对于企业影响非常重大。我们时常可以听到一些关系安全方面的事故，比如用户信息泄露等。正因为安全对于企业影响重大，所以在做架构时要多考虑安全方面的问题。

    从技术的角度来讲，安全可以分为两类：一类是功能上的安全，一类是架构上的安全。

    传统的架构安全主要依靠防火墙，防火墙最基本的功能就是隔离网络

    互联网系统的架构安全目前并没有太好的设计手段来实现，更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力，较少自己来设计和实现。

4.6  复杂度来源：规模

    规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。

    常见的规模带来的复杂度：

    • 功能越来越多，导致系统复杂度呈指数级上升。

    • 数据越来越多，其复杂度越来越高。

 

5.架构设计三原则

    架构即决策。架构需要面向业务需求，并在各种资源（人、财、物、时、事）约束条件下去做权衡、取舍。而决策就会存在不确定性。采用一些高屋建瓴的设计原则有助于去消除不确定，去逼近解决问题的最优解。

5.1 合适原则（合适优于业界领先）

    架构无优劣，但存合适性。“汝之蜜糖，吾之砒霜”；架构一定要匹配企业所在的业务阶段；不要面向简历去设计架构，高大上的架构不等于适用；削足适履与打肿充胖都不符合合适原则；所谓合适，一定要匹配业务所处阶段，能够合理地将资源整合在一起并发挥出最大功效，并能够快速落地。

5.2 简单原则（简单优于复杂）

    "我没有时间写一封短信，所以只好写一封长信"。其实，简单比复杂更加困难。面对系统结构、业务逻辑和复杂性，我们可以编写出复杂的系统，但在软件领域，复杂代表的是“问题”。架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案。但是，事实上，当软件系统变得太复杂后，就会有人换一个思路进行重构、升级，将它重新变得简单，这也是软件开发的大趋势。 简单原则是一个朴素且伟大的原则，Google的MapReduce系统就采用了分而治之的思想，而背后就是将复杂问题转化为简单问题的典型案例。

5.3 演化原则（演化优于一步到位）

    大到人类社会、自然生物，小到一个细胞，似乎都遵循这一普世原则，软件架构也不例外。业务在发展、技术在创新、外部环境在变化，这一切都是在告诫架构师不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。怀胎需要十月，早一月或晚一月都很危险。

 

6.架构设计流程

6.1 架构设计流程：识别复杂度

    • 架构的复杂度主要来源于“高性能”“高可用”“可扩展”等几个方面，但架构师在具体判断复杂性的时候，不能生搬硬套，认为任何时候架构都必须同时满足这三方面的要求。实际上大部分场景下，复杂度只是其中的某一个，少数情况下包含其中两个，如果真的出现同时需要解决三个或者三个以上的复杂度，要么说明这个系统之前设计的有问题，要么可能就是架构师的判断出现了失误，即使真的认为要同时满足这三方面的要求，也必须要进行优先级排序。

    • 一个个来解决问题，不要幻想一次架构重构解决所有问题。正确的做法是将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题。

    • 对于同一个复杂度问题，软件系统的方案可以有多个，总是可以挑出综合来看性价比最高的方案。

    • 有经验的架构师可能一看需求就知道复杂度大概在哪里；如果经验不足，那只能采取“排查法”，从不同的角度逐一进行分析。

    • 对于架构师来说，关注的不是一天的数据，而是 1 秒的数据，即 TPS 和 QPS。

    • 系统设计需要考虑一定的性能余量。由于现在的基数较低，为了预留一定的系统容量应对后续业务的发展。注意，这里的设计目标设定为峰值的 4 倍是根据业务发展速度来预估的，不是固定为 4 倍，不同的业务可以是 2 倍，也可以是 8 倍，但一般不要设定在 10 倍以上，更不要一上来就按照 100 倍预估。

6.2 架构设计流程：设计备选方案

    成熟的架构师需要对已经存在的技术非常熟悉，对已经经过验证的架构模式烂熟于心，然后根据自己对业务的理解，挑选合适的架构模式进行组合，再对组合后的方案进行修改和调整。

    高可用的主备方案、集群方案，高性能的负载均衡、多路复用，可扩展的分层、插件化等技术，绝大部分时候我们有了明确的目标后，按图索骥就能够找到可选的解决方案。

    事实上方案的创新绝大部分情况下也都是基于已有的成熟技术。

    新技术都是在现有技术的基础上发展起来的，现有技术又来源于先前的技术。将技术进行功能性分组，可以大大简化设计过程，这是技术“模块化”的首要原因。技术的“组合”和“递归”特征，将彻底改变我们对技术本质的认识。

6.2.1 第一种常见的错误：设计最优秀的方案。

6.2.2 第二种常见的错误：只做一个方案。心里会简单地对几个方案进行初步的设想，再简单地判断哪个最好。

    弊端：

    • 心里评估过于简单，可能没有想得全面，只是因为某一个缺点就把某个方案给否决了，而实际上没有哪个方案是完美的，某个地方有缺点的方案可能是综合来看最好的方案。

    • 架构师再怎么牛，经验知识和技能也有局限，有可能某个评估的标准或者经验是不正确的，或者是老的经验不适合新的情况，甚至有的评估标准是架构师自己原来就理解错了。

    • 单一方案设计会出现过度辩护的情况，即架构评审时，针对方案存在的问题和疑问，架构师会竭尽全力去为自己的设计进行辩护，经验不足的设计人员可能会强词夺理。

    比较好的做法：

    • 备选方案的数量以 3 ~ 5 个为最佳。少于 3 个方案可能是因为思维狭隘，考虑不周全；多于 5 个则需要耗费大量的精力和时间，并且方案之间的差别可能不明显。

    • 备选方案的差异要比较明显。例如，主备方案和集群方案差异就很明显，或者同样是主备方案，用 ZooKeeper 做主备决策和用 Keepalived 做主备决策的差异也很明显。但是都用 ZooKeeper 做主备决策，一个检测周期是 1 分钟，一个检测周期是 5 分钟，这就不是架构上的差异，而是细节上的差异了，不适合做成两个方案。

    • 备选方案的技术不要只局限于已经熟悉的技术。设计架构时，架构师需要将视野放宽，考虑更多可能性。很多架构师或者设计师积累了一些成功的经验，出于快速完成任务和降低风险的目的，可能自觉或者不自觉地倾向于使用自己已经熟悉的技术，对于新的技术有一种不放心的感觉。就像那句俗语说的：“如果你手里有一把锤子，所有的问题在你看来都是钉子”。例如，架构师对 MySQL 很熟悉，因此不管什么存储都基于 MySQL 去设计方案，系统性能不够了，首先考虑的就是 MySQL 分库分表，而事实上也许引入一个 Memcache 缓存就能够解决问题。

6.2.3 第三种常见的错误：备选方案过于详细。

    缺点

    • 耗费了大量的时间和精力。

    • 将注意力集中到细节中，忽略了整体的技术设计，导致备选方案数量不够或者差异不大。

    • 评审的时候其他人会被很多细节给绕进去，评审效果很差。

    正确的做法是备选阶段关注的是技术选型，而不是技术细节，技术选型的差异要比较明显。

    架构师的技术储备越丰富、经验越多，备选方案也会更多，从而才能更好地设计备选方案。

6.3 架构设计流程：评估和选择备选方案

    • “360 度环评”！具体的操作方式为：列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。

    • 常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。在评估这些质量属性时，需要遵循架构设计原则 1“合适原则”和原则 2“简单原则”，避免贪大求全，基本上某个质量属性能够满足一定时期内业务发展就可以了。

    • 如果每次做方案都考虑这种小概率事件，我们的方案会出现过度设计，导致投入浪费。

    • 如果某个质量属性评估和业务发展有关系（例如，性能、硬件成本等），需要评估未来业务发展的规模时，一种简单的方式是将当前的业务规模乘以 2 ~4 即可，如果现在的基数较低，可以乘以 4；如果现在基数较高，可以乘以 2。

    • 量变会引起质变，具体哪些地方质变，是很难提前很长时间能预判到的。

    • 正确的做法是按优先级选择，即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级。

6.4 架构设计流程：详细方案设计

    • 选方案进行细化，使得备选方案变成一个可以落地的设计方案。

    • 简单来说，详细方案设计就是将方案涉及的关键技术细节给确定下来。

    • 详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行，一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。

    • 这种情况可以通过下面方式有效地避免：

        架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深入的理解。

        通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度，方案本身的复杂度越高，某个细节推翻整个方案的可能性就越高，适当降低复杂性，可以减少这种风险。

        如果方案本身就很复杂，那就采取设计团队的方式来进行设计，博采众长，汇集大家的智慧和经验，防止只有 1~2 个架构师可能出现的思维盲点或者经验盲区。