目录
前言
作为后端开发攻城狮，学习并掌握一些架构的思想和技能是很有必要的。
《从零开始学架构》的作者李运华，资深技术专家。这本书是他从业十多年，对架构设计的心得和方法论的总结，比较系统化也比较通俗易懂；正如他在书中开篇提到的，照着做，你也能成为架构师。这很接地气，也正是吸引我的地方。我打算按照读书的进度，记录和总结书中的主要内容，再结合我的理解，整理成几篇读书笔记，定时更新。
软件架构设计产生的历史背景
软件架构概括成一句话：系统的组织形式、内部联系和逻辑。
最早在60年代，就已经出现“软件架构”这个概念了，但真正流行却是从90年代开始的，这要从2次软件危机说起：
第一次软件危机与结构化程序设计（60年代~70年代），这次危机的根源在于软件的“逻辑”变得非常复杂，这次危机催生了结构化程序设计方法，结构化程序方法成为了 70年代软件开发的潮流。
第二次软件危机与面向对象（80年代），这次危机主要体现在软件的“扩展”变得非常复杂，这次危机，促进了面向对象的发展，80年代开始面向对象成为主流的开发思想。
90年代，人们对软件架构的研究发现：随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。这样很好解释了在一些大规模的软件开发中，非常容易面临的问题，如系统规模庞大，内部耦合严重，续修改和扩展困难；系统逻辑复杂，出问题后很难排查和修复。
70年代的危机主要是逻辑复杂问题，结构化编程可以解决这问题，创造了“模块”概念；80年代的危机主要是软件扩展问题，面向对象思想可以解决这问题，创造了“对象”；90年代的“软件架构”开始流行，创造了“组件”概念。我们可以看到，“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高。
软件架构设计的目的
软件架构设计的目的是为了解决软件系统复杂度带来的问题。为什么这么说，从前面的两次软件危机可以看到，随着系统规模、业务需求的不断增长，系统的复杂度（功能、性能、扩展、安全等等统称为复杂度）会不断上升，但上升到一定程度后，会导致现有系统难以继续开发维护。引进架构的设计，就是在系统开发之初，设计可行的架构方案，并在迭代过程，及早的发现可能出现的危机，并针对危机，对软件的架构进行调整优化。
系统复杂度来源
既然架构设计的目的是解决系统复杂度带来的问题，那就要先了解导致系统复杂度增加的几个主要来源：
追求高性能
一、单机高性能
单机的局限性明显，主要是通过多进程、多线程的方式，提高单机的的吞吐量。
二、集群的高性能
单机的性能有限，必须采用机器集群的方式来达到高性能。例如，支付宝和微信这种规模的业务系统，后台系统的机器数量都是万台级别的。
1、任务分配
任务分配的意思是指每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行。分配器可能是硬件网络设备，也可能是负载均衡软件（例如，Nginx、HAProxy）等，任务分配器需要增加分配算法。一般来说机器数量越多，集群整体的性能越强。
2、任务分解
如果业务本身也越来越复杂，单纯只通过任务分配的方式来扩展性能，收益会越来越低。可以将其拆分为更多的组成部分，例如微信的后台架构。
通过这种任务分解的方式，能够把原来大一统但复杂的业务系统，拆分成小而简单但需要多个系统配合的业务系统。为何通过任务分解就能够提升性能呢？
- 简单的系统更加容易做到高性能
系统的功能越简单，影响性能的点就越少，就更加容易进行有针对性的优化。而系统很复杂的情况下，首先是比较难以找到关键性能点，因为需要考虑和验证的点太多；其次是即使花费很大力气找到了，修改起来也不容易，因为可能将 A 关键性能点提升了，但却无意中将 B 点的性能降低了，整个系统的性能不但没有提升，还有可能会下降。
- 可以针对单个任务进行扩展
当各个逻辑任务分解到独立的子系统后，整个系统的性能瓶颈更加容易发现，而且发现后只需要针对有瓶颈的子系统进行性能优化或者提升，不需要改动整个系统，风险会小很多。
3、任务分解的误区
既然将一个大一统的系统分解为多个子系统能够提升性能，那是不是划分得越细越好呢？其实不然，这样做性能不仅不会提升，反而还会下降，最主要的原因是如果系统拆分得太细，为了完成某个业务，系统间的调用次数会呈指数级别上升，而系统间的调用通道目前都是通过网络传输的方式，性能远比系统内的函数调用要低得多。因此，任务分解带来的性能收益是有一个度的，并不是任务分解越细越好。
追求高可用
和之前高性能是一样的，都是通过增加更多机器来达到目的，但其实本质上是有根本区别的：高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。
一、计算高可用
这里的“计算”指的是业务的逻辑处理。计算有一个特点就是无论在哪台机器上进行计算，同样的算法和输入数据，产出的结果都是一样的，所以将计算从一台机器迁移到另外一台机器，对业务并没有什么影响。
二、存储高可用
存储高可用的痛点，在于多个数据库或缓存服务器之间，数据不一定时时刻刻是一致的，可能存在某一个时刻数据不一致的问题，例如主从数据库的数据同步可能存在网络延迟。
按照“数据 + 逻辑 = 业务”这个公式来套的话，数据不一致，即使逻辑一致，最后的业务表现就不一样了。所以存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响。
著名的 CAP 定理，从理论上论证了存储高可用的复杂度。也就是说，存储高可用不可能同时满足“一致性、可用性、分区容错性”，最多满足其中两个。后续的读书笔记中详细展开说明吧。
追求可扩展性
设计具备良好可扩展性的系统，有两个基本条件：正确预测变化、完美封装变化。但要达成这两个条件，本身也是一件复杂的事情。
一、预测变化
软件系统在发布后还可以不断地修改和演进，这就意味着不断有新的需求需要实现。预测变化的复杂性在于：
- 不能每个设计点都考虑可扩展性。
- 不能完全不考虑可扩展性。
- 所有的预测都存在出错的可能性。
二、应对变化
第一种应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。
- 系统需要拆分出变化层和稳定层
- 需要设计变化层和稳定层之间的接口
第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。抽象层是稳定的，实现层可以根据具体业务需要定制开发，当加入新的功能时，只需要增加新的实现，无须修改抽象层，例如设计模式中的策略模式。后续的读书笔记中详细展开说明吧。
追求安全、低成本、规模
一、安全
从技术的角度来讲，安全可以分为两类：一类是功能上的安全，一类是架构上的安全。
功能安全其实就是“防小偷”，从实现的角度来看，功能安全更多地是和具体的编码相关。
架构安全就是“防强盗”，传统的架构安全主要依靠防火墙，防火墙最基本的功能就是隔离网络，通过将网络划分成不同的区域，制定出不同区域之间的访问控制策略来控制不同信任程度区域间传送的数据流。例如DDos攻击防护。
二、低成本
成本可以简单的分为：机器硬件的成本、第三方软件的成本、人员开发和维护成本等等；
三、规模
软件规模带来复杂度的主要原因就是“量变引起质变”：
- 功能越来越多，导致系统复杂度指数级上升
- 数据越来越多，系统复杂度发生质变
读书小结
这次读书笔记，我主要分享了软件架构的出现的历史背景，列举了两次软件危机，软件架构设计的目的是为了解决系统复杂度带来的问题，以及系统的复杂度的来源等，下一次《从零开始学架构》读书笔记，我将分享软件架构设计的三个原则、架构设计流程等的读书心得。
