《从0开始学架构》-第1部分-架构基础

Posted 2021-03-03 yeyang

目录

01架构到底是指什么？

02架构设计的历史背景

03架构设计的目的

04复杂度来源：高性能

    单台计算机内部为了高性能带来的复杂度

    多台计算机集群为了高性能带来的复杂度

05复杂度来源：高可用

    高可用方案的本质

    冗余”带来的复杂性

        一、计算高可用

        二、存储高可用

    高可用状态决策

        1）独裁式

        2）协商式

        3）民主式

    思考题：高性能和高可用哪个更难？

06复杂度来源：可扩展性

07复杂度来源：低成本、安全、规模

08架构设计三原则

    合适原则

    简单原则

    演化原则

09架构设计原则案例

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

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

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

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

01架构到底是指什么？

“架构”到底指什么？

 

涉及到的关键概念分析：

	区别与联系
系统与子系统	系统 系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。 关键点：关联、规则、能力   子系统
模块与组件	模块和组件都是系统的组成部分，只是从不同角度拆拆分系统而已 从逻辑角度拆分，得到的单元叫模块。划分模块的主要目的是职责分离。 从物理角度拆分，得到的单元叫组件。划分组件的主要目的是单元复用。 举例：学生信息管理系统。从逻辑角度拆分，分为“登录注册模块”、“个人信息模块”、“个人成绩模块”。从物理角度拆分，可分为nginx、WebServer、mysql
框架与架构	框架（FrameWork）关注的是规范。 架构（Architecture）关注的是结构。

 

重新定义架构：

架构：软件架构指软件系统的顶层架构。

 

02架构设计的历史背景

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

 

03架构设计的目的

架构设计的目的：架构设计的主要目的是为了解决软件系统复杂度带来的问题

 

04复杂度来源：高性能

单台计算机内部为了高性能带来的复杂度

• 单机如何高性能？多进程、多线程、进程间通信、多线程并发

• 如何选择？Nginx可以多进程也可多线程、Redis采用单进程、Memchache采用多线程，都实现了高性能

 

多台计算机集群为了高性能带来的复杂度

多台机器配合达到高性能的方式有

任务分配：（业务比较简单的情况）每台机器都可以处理完整的业务，不同任务分配到不同机器上执行

任务分解：（业务很复杂）将复杂的业务系统，拆分为多个简单但需要配合的业务系统

 

05复杂度来源：高可用

高可用方案的本质

高可用方案本质都是通过“冗余”实现高可用

• 一台不够两台

• 一个机房可能断点，那就两个机房

• 一台通道可能故障，那就两条，两条不够就三条（移动、联通、电信）

 

高性能与高可用的区别

高可用的“冗余”解决方案，单纯从形式上来看，和之前讲的高性能是一样的，都是通过增加更多机器来达到目的，但其实本质上是有根本区别的：高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。

 

冗余”带来的复杂性

一、计算高可用

特点：无论从哪台机器上进行计算，同样的算法和输入，产出都是一样的。

复杂度分析举例：双机架构

 

 

 

1）任务分配器的选择，性能、成本、可维护性、可用性等因素

2）任务分配器和计算服务器交互。什么连接方式、如何进行连接管理（连接建立、连接检测、连接中断处理）

3）任务分配器的分配算法。双机算法：主备（冷备、温备、热备）、主主。

二、存储高可用

存储与计算相比的本质区别：将数据从一台机器搬到另一台机器，需要经过线路进行传输。

传输带来的问题：数据的不一致

• 1）传输时延：同机房几毫秒、不同地方的机房几十甚至上百毫秒（广州到北京）

• 2）传输链路可用性：传输中断、阻塞、丢包、错包，光缆被挖断

存储高可用的难点：如何减少或规避数据不一致对业务的影响

 

高可用状态决策

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

矛盾点：通过冗余实现的高可用，状态决策本质上都不可能完美，都会有问题点。

常见决策方式

1）独裁式

一个“决策者”，其他为“上报者”。“决策者”收集信息进行决策，“上报者”将状态信息发送给决策者。

问题点：因为只有一个决策者，当决策者异常，整个系统无法进行决策

2）协商式

两个个体进行交流，进行决策。常用协商式决策是主备决策。两台机器，一个主机，一个备机。

问题点：两个机器信息交换出现问题（如主备之间连接中断），如何做决策？主备之间连接中断。备机认为主机故障了，升级为主机，导致出现了两个主机；备机认为主机没故障，但主机确实故障了，导致没有主机了。

3）民主式

多个个体投票进行决策。常见的Zookeeper集群选举Leader。

问题点：脑裂

• 一般通过“投票数必须超过总结点数一半”解决脑裂问题。据CAP理论，但会降低系统可用性。

 

思考题：高性能和高可用哪个更难？

课后思考题：高性能和高可用是很多系统的核心复杂度，你认为哪个更复杂一些？理由是什么？

精彩评论1：

高可用

• 为什么会出现不可用？

  • 硬件故障。如服务器宕机。

  • 软件故障。如软件bug。

  • 不可抗力。如地震、洪水、战争。

• 高可用的复杂度体现

  • 状态监控、服务切换、服务恢复

• 如何做到高可用？

  • 硬件故障引起的不可用解决方法：

    • （1）应用服务器：多台机器，负载均衡检测服务器不可用时，将其从集群中摘除。前提（无状态设计）：服务需要设计为无状态的，即不保存业务的上下文信息，而仅根据每次请求提交的数据进行业务逻辑的响应。

    • （2）数据服务器：数据冗余备份

  • 软件故障引起的不可用解决方法：通过软件开发过程进行质量保证。如测试、灰度发布

 

精彩评论2：

高性能非必须做。不管通过什么方式，或多或少，性能总能提高。高可用必须做。系统宕机或数据丢失，谈高性能没有意义。

精彩评论3：

高可用的解决方法不是解决，而是减少或者规避，而规避某个问题的时候，一般都会引发另一个问题，只是这个问题比之前的小，高可用的设计过程其实也是一个取舍的过程。这也就是为什么系统可用性永远只是说几个九，永远缺少那个一。而高性能，这个基本上就是定义计算能力，可以通过架构的优化，算法的改进，硬件的升级都可以得到很好的解决，从而达到我们心里对性能的预期…

精彩评论4：

高性能虽然复杂，但是只要通过合理的集群方案还是可以解决业务的性能需求，但是高可用也只能做到相对高可用，绝对高可用是不存在的，总会有诸多突发外界因素进行干扰，高性能的实现是受人为控制的，只要是在人的控制范围内，那问题都不是问题，但是要做到高可用，很多事情都不是人能控制的，比如天灾人祸

精彩评论5：

古人有言：先解决有无，再解决优化。所以可用更难，性能次之

 

06复杂度来源：可扩展性

设计具备良好可扩展性的系统，有两个基本条件：正确预测变化、完美封装变化

1）预测变化的复杂性

• 不是每个设计点都考虑可扩展性

• 不能完全不考虑可扩展性

• 所有的预测都存在出错的可能性

2）应对变化

常见方案1：将“变化”封装在“变化层”，将不变的部分封装在“稳定层”。

复杂性

• • 1）需要拆分出变化层和稳定层，但是对于哪些属于变化层、哪些属于稳定层，并不好分辨

  • 2）需要设计变化层和稳定层之间的接口

常见方案2：提炼出一个“抽象层”和一个“实现层”。

• 典型案例：设计模式、规则引擎。

 

07复杂度来源：低成本、安全、规模

规模：典型案例就是关系型数据库存储数据，需要进行分库分表。

软件架构图如何画？4+1视图。http://hongyitong.github.io/2017/02/17/4+1%E8%A7%86%E5%9B%BE%E5%88%86%E6%9E%90/

 

08架构设计三原则

合适原则

合适原则：“合适优于业界领先”

 

简单原则

简单原则：“简单优于复杂”（KISS原则：Keep it simple，stupid！)

• 简单的方案和复杂的方案都能满足要求，最好选择简单的方案。

   

演化原则

演化原则：“演化优于一步到位”

• 软件架构需要根据业务的发展不断变化。

 

09架构设计原则案例

分析了淘宝和手机QQ的发展历程

 

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

将主要的复杂度问题列出来，优先解决当前面临的最主要的复杂度问题

举例：是否需要高性能、是否需要高可用、是否需要高可扩展性。按优先级排序，前面的优先解决。

需注意的是：业务阶段不同，复杂度问题的优先级可能不同。

 

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

注意事项

• 备选方案的数据以3-5个为最佳。

• 备选方案之间的差异要比较明显。

  • 主备方案VS集群方案，zookeeper做主备决策VS用keepalived做主备决策。

• 备选方案的技术不要只局限于已经熟悉的技术。

• 备选方案不要过于详细。备选阶段关注的是技术选型，而不是技术细节。

   

几种常见的设计误区。

1）设计最优秀的方案（技术人的技术情结，方案中的技术越牛逼越好）。而是要根据“合适”、“简单”、“演进”的架构设计原则，决策出与需求、团队、技术能力相匹配的合适方案。

2）只做一个方案。一个方案容易陷入思考问题片面、自我坚持的认知陷阱。

 

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

几种流派

• 最简派。挑选最简单的方案。

• 最牛派。挑选最牛逼的方案。

• 最熟派。挑选最熟悉的方案。

   

对上面几种流派的看法：

并无绝对正确和错误，关键是不同场景采取不同方式。即有时最简，有时最牛，有时最熟。

 

如何选出最终方案？

• 1）列出需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案。常见的质量属性点：性能、可用性、扩展性、安全性、硬件成本、项目投入（时间、人力）、复杂度、可维护性、运维难度

• 2）根据当前业务发展情况、团队规模和技能、业务发展预测等因素，将质量属性按优先级排序，首先挑选满足高优先级的。

 

实战案例

 

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

就是将方案设计到的关键技术细节给确定下来

• 如确定使用MySQL分库分表，那就需要确定哪些表要分库分表、按什么维度分库分表、分库分表后联合查询怎么处理。

可能遇到的问题是在详细设计阶段发现备选方案不可行，一般原因是备选方案设计时遗漏了关键技术点或关键质量属性。

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