架构设计的目的

主要目的是为了解决软件系统复杂度带来的问题。

架构设计的三大原则

合适、简单、演化
1、合适优于业界领先
2、简单优于复杂
3、演化优于一步到位

高性能、高可用、可扩展性

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

高可用

”状态决策“,即系统需要能够判断当前的状态是正常还是异常,如果出现了异常就要采取行动来保证高可用。

高可用状态决策:
1、独裁式(决策者决定)
2、协商式(主从决策)
3、民主式(投票)

可扩展性

两个基本条件:正确预测变化、完美封装变化

应对变化:将“变化”封装在一个“变化层”,将不变的部分封装在一个独立的“稳定层”。

一、高性能

• 数据库集群:读写分离、分库分表

• NoSQL、缓存架构

• 单服务器:PPC与TPC、Reactor与Proactor

• 负载均衡:分类及架构、算法

(1)读写分离

读写分离的基本原理是将数据库读写操作分散到不同的节点上。

两个设计复杂度:主从复制延迟和分配机制

复制延迟

解决方法

1. 写操作后的读操作指定发给数据库主服务器

2. 读从机失败后再读一次主机

3. 关键业务读写操作全部指向主机,非关键业务采用读写分离

分配机制

将读写操作区分开来,然后访问不同的数据库服务器,一般有两种方式:程序代码封装和中间件封装。

(2)分库分表

业务分库

按照业务模块将数据分散到不同的数据库服务器。比如把用户数据、商品数据、订单数据放在三台不同的数据库服务器上。

带来问题
1、join操作问题
2、事务问题
3、成本问题

分表

单表数据拆分有两种方式:垂直分表和水平分表

垂直分表:将表中某些不常用且占了大量空间的列拆分出去。
水平分表:适合表行数特别大的表。

水平分表的路由算法

1、范围路由
2、Hash路由
3、配置路由

(3)NoSQL

关系数据库存在如下缺点:

1. 存储的是行记录,无法存储数据结构

2. schema 扩展很不方便

3. 在大数据场景下 I/O 较高

4. 全文搜索功能比较弱

常见的 NoSQL 方案分为 4 类

1. K-V 存储:解决关系数据库无法存储数据结构的问题,以 Redis 为代表。

2. 文档数据库:解决关系数据库强 schema 约束的问题,以 MongoDB 为代表。

3. 列式数据库:解决关系数据库大数据场景下的 I/O 问题,以 HBase 为代表。

4. 全文搜索引擎:解决关系数据库的全文搜索性能问题,以 Elasticsearch 为代表。

(4)缓存架构

1. 缓存穿透

指缓存没有发挥作用,业务系统虽然去缓存查询数据,但缓存中没有数据,业务系统需要再次去存储系统查询数据。通常情况下有两种情况:

1. 存储数据确实不存在

2. 存储系统中存在数据,但缓存数据生成耗费大量时间或者资源,或刚好在业务访问的时候缓存失效了

2. 缓存雪崩

指当缓存失效(过期)后引起系统性能急剧下降的情况

缓存雪崩的常见解决方法有两种:更新锁机制和后台更新机制。

1. 更新锁
对缓存更新操作进行加锁保护,保证只有一个线程能够进行缓存更新,未能获取更新锁的线程要么等待锁释放后重新读取缓存,要么就返回空值或者默认值。

2. 后台更新
由后台线程来更新缓存,而不是由业务线程来更新缓存,缓存本身的有效期设置为永久,后台线程定时更新缓存。

3. 缓存热点

缓存热点的解决方案就是复制多份缓存副本,将请求分散到多个缓存服务器上,减轻缓存热点导致的单台缓存服务器压力。

不同的缓存副本不要设置统一的过期时间,否则就会出现所有缓存副本同时生成同时失效的情况,从而引发缓存雪崩效应。正确的做法是设定一个过期时间范围,不同的缓存副本的过期时间是指定范围内的随机值。

(5)单服务器高性能模式:Reactor和Proactor

PPC 模式最主要的问题就是每个连接都要创建进程,解决这个问题是将 read 操作改为非阻塞,然后进程不断地轮询多个连接。但轮询是要消耗 CPU 的;

为了解决上述问题,只有当连接上有数据的时候进程才去处理,这就是** I/O 多路复用技术的来源**。

I/O 多路复用结合线程池,取了一个很牛的名字:Reactor。

Reactor 模式的核心组成部分包括 Reactor 和处理资源池(进程池或线程池),其中Reactor 负责监听和分配事件,处理资源池负责处理事件。

Reactor 模式有这三种实现方案:

1. 单 Reactor 单进程 / 线程。

2. 单 Reactor 多线程。

3. 多 Reactor 多进程 / 线程。

1. 单 Reactor 单进程 / 线程

优点:没有进程间通信,没有进程竞争,全部都在同一个进程内完成。
缺点:无法发挥多核 CPU 的性能;只能采取部署多个系统来利用多核 CPU。

只适用于业务处理非常快速的场景,目前比较著名的开源软件中使用单 Reactor 单进程的是 Redis。

2. 单 Reactor 多线程

优点:充分利用多核多 CPU 的处理能力
缺点:多线程数据共享和访问比较复杂。例如,子线程完成业务处理后,要把结果传递给主线程的 Reactor 进行发送,这里涉及共享数据的互斥和保护机制。

3. 多 Reactor 多进程 / 线程

多 Reactor 多进程 / 线程的方案看起来比单 Reactor 多线程要复杂,但实际实现时反而更加简单,主要原因是:

1. 父进程和子进程的职责非常明确,父进程只负责接收新连接,子进程负责完成后续的业务处理。

2. 父进程和子进程的交互很简单,父进程只需要把新连接传给子进程,子进程无须返回数据。

3. 子进程之间是互相独立的,无须同步共享之类的处理(这里仅限于网络模型相关的select、read、send 等无须同步共享,“业务处理”还是有可能需要同步共享的)。

目前著名的开源系统 Nginx 采用的是多 Reactor 多进程,采用多 Reactor 多线程的实现有Memcache 和 Netty。

(6)负载均衡

高性能集群的复杂性主要体现在需要增加一个任务分配器,现在更流行的叫法是“负载均衡器”。

常见的负载均衡系统包括 3 种:DNS 负载均衡、硬件负载均衡和软件负载均衡。

DNS 负载均衡

一般用来实现地理级别的均衡。

DNS 负载均衡的本质是 DNS 解析同一个域名可以返回不同的 IP 地址。例如,同样是 www.baidu.com,北方用户解析后获取的地址是 61.135.165.224(这是北京机房的 IP),南方用户解析后获取的地址是14.215.177.38(这是深圳机房的 IP)。

优点:就近访问,提升访问速度
缺点:更新不及时、扩展性差、分配策略比较简单

硬件负载均衡

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能,这类设备和路由器、交换机类似,可以理解为一个用于负载均衡的基础网络设备。目前业界典型的硬件负载均衡设备有两款:F5 和 A10。

软件负载均衡

软件负载均衡通过负载均衡软件来实现负载均衡功能,常见的有 Nginx 和 LVS,其中Nginx 是软件的 7 层负载均衡,LVS 是 Linux 内核的 4 层负载均衡。4 层和 7 层的区别就在于协议和灵活性,Nginx 支持HTTP、E-mail 协议;而 LVS 是 4 层负载均衡,和协议无关,几乎所有应用都可以做,例如,聊天、数据库等。

负载均衡典型架构(三种组合使用)

二、高可用

(1)FMEA 方法

在架构设计领域,FMEA 的具体分析方法是:

1. 给出初始的架构设计图。

2. 假设架构中某个部件发生故障。

3. 分析此故障对系统功能造成的影响。

4. 根据分析结果,判断架构是否需要进行优化。

(2)高可用储存:双机架构

析常见的双机高可用架构:主备、主从、主备 / 主从切换和主主。

(3)高可用储存:数据集群和数据分区

数据分区

设计一个良好的数据分区架构,需要从多方面去考虑
1. 数据量:数据量的大小直接决定了分区的规则复杂度。
2. 分区规则:
3. 复制规则:

(4)异地多活架构

异地多活架构可以分为同城异区、跨城异地、跨国异地。

跨国异地:

1. 为不同地区用户提供服务

2. 只读类业务做多活

异地多活 - 四大技巧

1. 优先实现核心业务的异地多活

2. 保证核心数据最终一致性

3. 采用多种手段同步数据(MySQL 的主备复制、Redis 的 Cluster 功能、Elasticsearch 的集群功能)

4. 只保证绝大部分用户的异地多活

异地多活 - 四步走

第 1 步:业务分级
访问量大的业务、核心业务、产生大量收入的业务

第 2 步:数据分类
数据量、唯一性、实时性、可丢失性、可恢复性

第 3 步:数据同步
存储系统同步、消息队列同步、重复生成

第 4 步:异常处理
多通道同步、同步和访问结合、日志记录、用户补偿

(5)应对接口级的故障

导致接口级故障的原因一般有下面几种:

• 内部原因:程序 bug 导致死循环,某个接口导致数据库慢查询,程序逻辑不完善导致耗尽内存等。

• 外部原因:黑客攻击、促销或者抢购引入了超出平时几倍甚至几十倍的用户,第三方系统大量请求,第三方系统响应缓慢等。

解决接口级故障的核心思想和异地多活基本类似:优先保证核心业务和优先保证绝大部分用户。

应对接口级的故障方法:
1. 降级:系统将某些业务或者接口的功能降低,可以是只提供部分功能,也可以是完全停掉所有功能。
2. 熔断:降级的目的是应对系统自身的故障,而熔断的目的是应对依赖的外部系统故障的情况。
3. 限流:只允许系统能够承受的访问量进来,超出系统访问能力的请求将被丢弃。
4. 排队:限流的一个变种,限流是直接拒绝用户,排队是让用户等待一段时间

三、可扩展性

可扩展的基本思想:拆

常见的拆分思路有如下三种:

• 面向流程拆分:分层架构,将整个业务流程拆分为几个阶段,每个阶段作为一部分。

• 面向服务拆分:SOA、微服务,将系统提供的服务拆分,每个服务作为一部分。

• 面向功能拆分:微内核架构,将系统提供的功能拆分,每个功能作为一部分。

微服务

1. 服务发现、服务路由、服务容错:这是最基本的微服务基础设施。

2. 接口框架、API 网关:主要是为了提升开发效率,接口框架是提升内部服务的开发效率,API 网关是为了提升与外部服务对接的效率。

3. 自动化部署、自动化测试、配置中心:主要是为了提升测试和运维效率。

4. 服务监控、服务跟踪、服务安全:主要是为了进一步提升运维效率。

微内核架构

微内核架构,也被称为插件化架构,是一种面向功能进行拆分的可扩展性架构

微内核架构包含两类组件:核心系统和插件模块。

核心系统负责和具体业务功能无关的通用功能,例如模块加载、模块间通信等;插件模块负责实现具体的业务逻辑,例如专栏前面经常提到的“学生信息管理”系统中的“手机号注册”功能。