从零开始学架构读书笔记

第一章架构基础。

1.1，架构到底指什么？对技术人员来说，架构是一个再常见不过的词语了。我们经常需要给别人介绍项目的架构，参加架构设计评审，学习行业内的开源系统的架构等等。但是如果深入研究一下架构，到底指什么并不很容易回答？

比如说架构和框架是什么关系？有什么区别？离尼斯有加购满蛇口有架构结vm也有架构。莉莉斯上的业务系统也有架构，我们应该关注哪个架构呢？

想要准确的回答上面的问题关键在于树立几个有关系，而又相似的概念，包括系统子系统模块组件框架和架构。

1.1.1 系统与子系统。首先看一下维基百科的定义。系统泛指有一群有关联的个体组成根据某种规则运行能够完成个别元件不能单独完成的工作的群体。他的意思是总体整体或联盟。

危机百科的定义有三个关键内容，第一是关联，系统，是由一群有关联的个体组成的，没有关联的个体堆在一起，不能形成系统。比如说把一个汽车发动机和一台电脑放在一起，不能称之为一个系统。第二点是规则系统内的个体需要按照指定的规则运作，而不是单个个体各自为政。第三点是能力系统，能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力。比如汽车的例子，汽车能够载重前进，而发动机车轮本身不具有这样的功能。

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

1.1.2 模块与组件。

工作中常见的说法。第一买塞口模块，主要负责存储数据，而以来自各个模块主要负责数据搜索。

第二种说法，我们有安全加密组件，由审核组箭第三种说法APP的下载模块使用了第三方的组件。

组件和模块不容易，区分的原因是因为他们都是系统的组成部分，只是从不同的角度拆分系统而已，从逻辑角度来拆分，得到的单元就是模块，从物理角度来拆分，得到的单元就是组件。划分模块的主要目的是职责分离，华分组涧的主要目的是单元复用。

1.1.3框架与架构。

参考维基百科框架的定义如下软件框架，通常指的是为了实现某个业界标准或完成特定或完成特定的软件件规范，也只为了实现某个软件组件规范时提供规范所要求置基础功能的软件产品。

软件架构是指软件系统的基础结构，创造这些基础结构的准则，以及对这些结构的描述。

单纯从定义的角度看，框架和架构的区别还是比较明显的，框架关注的是规范架构，关注的是结构。

1.1.4，重新定义架构。

软件架构师值软件系统的顶层结构。

1.2架构设计的目的。

1.2.1 架构设计的误区。常见的误区有如下几种。第一种是因为架构很重要，所以要做加固设计，这是一句正确的废话。第二种是公司流程，要求系统开发过程中必须要有架构设计。第三种说法是为了高性能，高可用，可扩展，所以要做架构设计。

1.2.2 以史为鉴，来看看为什么需要做架构设计？

机器语言。太难写，太难读，太难改。汇编语言。为了解决机器语言编写，阅读修改复杂的问题，汇编语言应运而生，汇编语言又叫符号语言，用驻地福代体机器指令的操作码。

接下来是高级语言。比如说fortune LISP kobo。第一次软件危机与结构化程序设计，20世纪60年代到20世纪70年代。著名的软件危机1963年美国的水手一号火箭发射失败，事故就是因为一行fortune代码错误导致的。软件危机最典型的例子莫过于IBM的system 360的操作系统开发。当时的项目主管率领2000多个程序员，夜以继日的工作，共计花费了5000人一年的工作量，写出将近100万行代码，总投入超过五亿美元，已经达到了美国曼哈顿原子弹计划投入的1/4。尽管项目投入如此之大，但项目进度却一再延迟，软件质量也得不到保证。后来布鲁克斯基于这个项目经验，而总结的人月神话一说，成为了畅销的软件工程书籍。那么软件工程一次也是在这个年代提出来的。

结构化程序设计的主要特点是放弃goto语句，采用自顶向下逐步细化模块化的指导思想。

第二次软件危机和面向对象，20世纪80年代。

软件架构。卡内基梅隆大学的Mary shaw和David gary对软件架构做了很多研究，它们在1994年的一篇文章，按introduction to software architecture中写道。随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题，当系统有许多部分组成是整个系统的组织，也就是所说的软件架构导致了一系列新的设计问题。

回顾软件架构的出现，历史20世纪60年代第一次软件危机引出了结构化编程，创造了模块概念，20世纪80年代第二次软件危机引出了面向对象程序设计，创造了对象的概念，到了20世纪90年代，软件架构开始流行，创造了组件的概念，我们可以看到么？会对象组建本质上都是对到达一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的力度越来越粗，拆分的角度越来越高。

1.2.3架构设计的真正目的。

整个软件技术的发展历史，其实就是一部一复杂度斗争的历史架构的出现，也不例外，那么架构设计的主要目的是为了解决复杂度带来的问题。

1.3。复杂度的来源。

复杂度的来源有四个方面，第一是高性能。第20高可用。第三是可扩展。第四是提成本。第五是安全，第六是规模。

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

在阐述单击复杂度的时候，作者首先介绍了计算机操作系统的发展历史。作者首先讲到了最开始的打孔输入式的计算机，然后介绍了批处理操作系统，然后介绍了多进程，然后介绍了多线程。最后是总结。如果我没有完成一个高性能的软件系统，需要考虑，如下技术点多进程多线程进程间通信多线程，并发等。这些技术并不是最新的，就是最好的，也不是非此，即彼在做架构设计的时候需要花费很大的精力来结合业务进行判断分析选择组合，这个过程很复杂。

在介绍集群复杂度的时候，作者引入了两个例子，一是2016年双十一支付宝，每秒峰值达12万笔支付2017年春节微信红包每秒达76万个。

集训的复杂度，主要体现在两个方面，第一个方面是任务分配。任务分配的意思是指每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上，执行。任务分解指的是并不在单一的一台机器上完成，所有业务逻辑而是将整个业务逻辑拆分成不同的子业务部署在同的计算机上。那么这个概念有点类似于微服务的概念。

1.3点二高可用。

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

这里面的内容包括了计算高可用。存储高可用。高可用状态决策。在存储高可用方面存储高可用的难点，不在于如何备份数据而在于如何减少或规避数据不一致，对业务造成的影响。

第二章架构设计的原则。

架构设计有三个原则合适原则，简单原则，衍化原则。

2.1合适原则。原则宣言，合适优于业界领先。

第一将军难打，无兵之仗，没有那么多人，却想干那么多活，是失败的第一个主要原因。第二罗马不是一天建成的。没有那么多积累，却想一步登天是失败的第一个原因。第三冰山下面才是关键，没有那么多与卓越的有长剑，却幻想灵光一闪，成为天才，是失败的第三个主要原因。

2.2简单原则。原则宣言简单优于复杂。软件领域的复杂性体现在以下两个方面，第一是结构的复杂性。第二是逻辑的复杂性。结构的复杂性体现在。组成复杂系统的组件数量越多，同时这些组件之间的关系也会更加复杂。第二方面是逻辑的复杂性，看到结构的复杂性以后我们的第一反应可能是降低组件数量，毕竟组件数量越少，系统结构越简单，最简单的结构当是整个系统只有一个组件也就是系统本身所有的功能和逻辑都在这一个组件中实现。但是这样做是不行的，除了考虑结构复杂性以外，我们还要考虑逻辑复杂性，如果某个组件的逻辑太复杂，一样会带来问题。

2.3演化原则原则宣言演化由于一步到位。对于建筑来说，永恒是主题，对于软件来说变化才是主题。