负载均衡

负载均衡简介

大型系统面临的挑战

大型系统通常要面对高并发、高可用、海量数据等挑战。

为了提升系统整体的性能，可以采用垂直扩展和水平扩展两种方式。

• 垂直扩展：在网站发展早期，可以从单机的角度通过提升硬件处理能力，比如 CPU 处理能力，内存容量，磁盘等方面，实现机器处理能力的提升。但是，单机是有性能瓶颈的，一旦触及瓶颈，再想提升，付出的成本和代价会极高。通俗来说，就三个字：得加钱！这显然不能满足大型分布式系统（网站）所有应对的大流量，高并发，海量数据等挑战。
• 水平扩展：通过集群来分担大型网站的流量。集群中的应用机器（节点）通常被设计成无状态，用户可以请求任何一个节点，这些节点共同分担访问压力。水平扩展有两个要点：
  • 集群化、分区化：将一个完整的应用化整为零，如果是无状态应用，可以直接集群化部署；如果是有状态应用，可以将状态数据分区（分片），然后部署到多台机器上。
  • 负载均衡：集群化、分区化后，要解决的问题是，请求应该被分发（寻址）到哪台机器上。这就需要通过某种策略来控制分发，这种技术就是负载均衡。

什么是负载均衡

“负载均衡（Load Balance，简称 LB）”是一种技术，用来在多个计算机、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到优化资源利用率、最大化吞吐率、最小化响应时间、同时避免过载的目的。

负载均衡的主要作用如下：

• 高并发：负载均衡可以优化资源使用率，通过算法调整负载，尽力均匀的分配资源，以此提高资源利用率、从而提升整体吞吐量。
• 伸缩性：发生增减资源时，负载均衡可以自动调整分发，使得应用集群具备伸缩性。
• 高可用：负载均衡器可以监控候选机器，当某机器不可用时，自动跳过，将请求分发给可用的机器。这使得应用集群具备高可用的特性。
• 安全防护：有些负载均衡软件或硬件提供了安全性功能，如：黑白名单、防火墙，防 DDos 攻击等。

负载均衡的分类

支持负载均衡的技术很多，我们可以通过不同维度去进行分类。

载体维度分类

从支持负载均衡的载体来看，可以将负载均衡分为两类：

• 硬件负载均衡
• 软件负载均衡

硬件负载均衡

硬件负载均衡，一般是在定制处理器上运行的独立负载均衡服务器，价格昂贵，土豪专属。

硬件负载均衡的主流产品有：F5 和 A10。

硬件负载均衡的优点：

• 功能强大：支持全局负载均衡并提供较全面的、复杂的负载均衡算法。
• 性能强悍：硬件负载均衡由于是在专用处理器上运行，因此吞吐量大，可支持单机百万以上的并发。
• 安全性高：往往具备防火墙，防 DDos 攻击等安全功能。

硬件负载均衡的缺点：

• 成本昂贵：购买和维护硬件负载均衡的成本都很高。
• 扩展性差：当访问量突增时，超过限度不能动态扩容。

软件负载均衡

软件负载均衡，应用最广泛，无论大公司还是小公司都会使用。

软件负载均衡从软件层面实现负载均衡，一般可以在任何标准物理设备上运行。

软件负载均衡的 主流产品 有：Nginx、HAProxy、LVS。

• LVS 可以作为四层负载均衡器。其负载均衡的性能要优于 Nginx。
• HAProxy 可以作为 HTTP 和 TCP 负载均衡器。
• Nginx、HAProxy 可以作为四层或七层负载均衡器。

软件负载均衡的 优点：

• 扩展性好：适应动态变化，可以通过添加软件负载均衡实例，动态扩展到超出初始容量的能力。
• 成本低廉：软件负载均衡可以在任何标准物理设备上运行，降低了购买和运维的成本。

软件负载均衡的 缺点：

• 性能略差：相比于硬件负载均衡，软件负载均衡的性能要略低一些。

网络通信分类

软件负载均衡从通信层面来看，又可以分为四层和七层负载均衡。

• 七层负载均衡：就是可以根据访问用户的 HTTP 请求头、URL 信息将请求转发到特定的主机。
  • DNS 重定向
  • HTTP 重定向
  • 反向代理
• 四层负载均衡：基于 IP 地址和端口进行请求的转发。
  • 修改 IP 地址
  • 修改 MAC 地址

DNS 负载均衡

DNS 负载均衡一般用于互联网公司，复杂的业务系统不适合使用。大型网站一般使用 DNS 负载均衡作为 第一级负载均衡手段，然后在内部使用其它方式做第二级负载均衡。DNS 负载均衡属于七层负载均衡。

DNS 即 域名解析服务，是 OSI 第七层网络协议。DNS 被设计为一个树形结构的分布式应用，自上而下依次为：根域名服务器，一级域名服务器，二级域名服务器，… ，本地域名服务器。显然，如果所有数据都存储在根域名服务器，那么 DNS 查询的负载和开销会非常庞大。

因此，DNS 查询相对于 DNS 层级结构，是一个逆向的递归流程，DNS 客户端依次请求本地 DNS 服务器，上一级 DNS 服务器，上上一级 DNS 服务器，… ，根 DNS 服务器（又叫权威 DNS 服务器），一旦命中，立即返回。为了减少查询次数，每一级 DNS 服务器都会设置 DNS 查询缓存。

DNS 负载均衡的工作原理就是：基于 DNS 查询缓存，按照负载情况返回不同服务器的 IP 地址。

DNS 重定向的 优点：

• 使用简单：负载均衡工作，交给 DNS 服务器处理，省掉了负载均衡服务器维护的麻烦
• 提高性能：可以支持基于地址的域名解析，解析成距离用户最近的服务器地址（类似 CDN 的原理），可以加快访问速度，改善性能；

DNS 重定向的 缺点：

• 可用性差：DNS 解析是多级解析，新增/修改 DNS 后，解析时间较长；解析过程中，用户访问网站将失败；
• 扩展性差：DNS 负载均衡的控制权在域名商那里，无法对其做更多的改善和扩展；
• 维护性差：也不能反映服务器的当前运行状态；支持的算法少；不能区分服务器的差异（不能根据系统与服务的状态来判断负载）

HTTP 负载均衡

HTTP 负载均衡是基于 HTTP 重定向实现的。HTTP 负载均衡属于七层负载均衡。

HTTP 重定向原理是：根据用户的 HTTP 请求计算出一个真实的服务器地址，将该服务器地址写入 HTTP 重定向响应中，返回给浏览器，由浏览器重新进行访问。

HTTP 重定向的 优点：方案简单。

HTTP 重定向的 缺点：

• 额外的转发开销：每次访问需要两次请求服务器，增加了访问的延迟。
• 降低搜索排名：使用重定向后，搜索引擎会视为 SEO 作弊。
• 如果负载均衡器宕机，就无法访问该站点。

由于其缺点比较明显，所以这种负载均衡策略实际应用较少。

反向代理负载均衡

反向代理（Reverse Proxy）方式是指以 代理服务器 来接受网络请求，然后 将请求转发给内网中的服务器，并将从内网中的服务器上得到的结果返回给网络请求的客户端。反向代理负载均衡属于七层负载均衡。

反向代理服务的主流产品：Nginx、Apache。

正向代理与反向代理有什么区别？

• 正向代理：发生在 客户端，是由用户主动发起的。翻墙软件就是典型的正向代理，客户端通过主动访问代理服务器，让代理服务器获得需要的外网数据，然后转发回客户端。
• 反向代理：发生在 服务端，用户不知道代理的存在。

反向代理是如何实现负载均衡的呢？以 Nginx 为例，如下所示：

首先，在代理服务器上设定好负载均衡规则。然后，当收到客户端请求，反向代理服务器拦截指定的域名或 IP 请求，根据负载均衡算法，将请求分发到候选服务器上。其次，如果某台候选服务器宕机，反向代理服务器会有容错处理，比如分发请求失败 3 次以上，将请求分发到其他候选服务器上。

反向代理的 优点：

• 多种负载均衡算法：支持多种负载均衡算法，以应对不同的场景需求。
• 可以监控服务器：基于 HTTP 协议，可以监控转发服务器的状态，如：系统负载、响应时间、是否可用、连接数、流量等，从而根据这些数据调整负载均衡的策略。

反向代理的 缺点：

• 额外的转发开销：反向代理的转发操作本身是有性能开销的，可能会包括创建连接，等待连接响应，分析响应结果等操作。

• 增加系统复杂度：反向代理常用于做分布式应用的水平扩展，但反向代理服务存在以下问题，为了解决以下问题会给系统整体增加额外的复杂度和运维成本：

• 反向代理服务如果自身宕机，就无法访问站点，所以需要有 高可用 方案，常见的方案有：主备模式（一主一备）、双主模式（互为主备）。

  • 反向代理服务自身也存在性能瓶颈，随着需要转发的请求量不断攀升，需要有 可扩展 方案。

IP 负载均衡

IP 负载均衡是在网络层通过修改请求目的地址进行负载均衡。

如上图所示，IP 均衡处理流程大致为：

1. 客户端请求 192.168.137.10，由负载均衡服务器接收到报文。
2. 负载均衡服务器根据算法选出一个服务节点 192.168.0.1，然后将报文请求地址改为该节点的 IP。
3. 真实服务节点收到请求报文，处理后，返回响应数据到负载均衡服务器。
4. 负载均衡服务器将响应数据的源地址改负载均衡服务器地址，返回给客户端。

IP 负载均衡在内核进程完成数据分发，较反向代理负载均衡有更好的处理性能。但是，由于所有请求响应都要经过负载均衡服务器，集群的吞吐量受制于负载均衡服务器的带宽。

数据链路层负载均衡

数据链路层负载均衡是指在通信协议的数据链路层修改 mac 地址进行负载均衡。

在 Linux 平台上最好的链路层负载均衡开源产品是 LVS (Linux Virtual Server)。

LVS 是基于 Linux 内核中 netfilter 框架实现的负载均衡系统。netfilter 是内核态的 Linux 防火墙机制，可以在数据包流经过程中，根据规则设置若干个关卡（hook 函数）来执行相关的操作。

LVS 的工作流程大致如下：

• 当用户访问 www.sina.com.cn 时，用户数据通过层层网络，最后通过交换机进入 LVS 服务器网卡，并进入内核网络层。
• 进入 PREROUTING 后经过路由查找，确定访问的目的 VIP 是本机 IP 地址，所以数据包进入到 INPUT 链上
• IPVS 是工作在 INPUT 链上，会根据访问的 vip+port 判断请求是否 IPVS 服务，如果是则调用注册的 IPVS HOOK 函数，进行 IPVS 相关主流程，强行修改数据包的相关数据，并将数据包发往 POSTROUTING 链上。
• POSTROUTING 上收到数据包后，根据目标 IP 地址（后端服务器），通过路由选路，将数据包最终发往后端的服务器上。

开源 LVS 版本有 3 种工作模式，每种模式工作原理截然不同，说各种模式都有自己的优缺点，分别适合不同的应用场景，不过最终本质的功能都是能实现均衡的流量调度和良好的扩展性。主要包括三种模式：DR 模式、NAT 模式、Tunnel 模式。

负载均衡算法

负载均衡器的实现可以分为两个部分：

• 根据负载均衡算法在候选机器列表选出一个机器；
• 将请求数据发送到该机器上。

负载均衡算法是负载均衡服务核心中的核心。负载均衡产品多种多样，但是各种负载均衡算法原理是共性的。

负载均衡算法有很多种，分别适用于不同的应用场景。本章节将由浅入深的，逐一讲解各种负载均衡算法的策略和特性，并根据算法之间的互补关系将它们串联起来。

注：负载均衡算法的实现，推荐阅读 Dubbo 官方负载均衡算法说明 ，源码讲解非常详细，非常值得借鉴。

下文中的各种算法的可执行示例已归档在 Github 仓库：java-load-balance，可以通过执行 io.github.dunwu.javatech.LoadBalanceDemo 查看各算法执行效果。

轮询算法

“轮询算法（Round Robin）”的策略是：将请求“依次”分发到候选机器。

如下图所示，轮询负载均衡器收到来自客户端的 6 个请求，编号为 1、4 的请求会被发送到服务端 0；编号为 2、5 的请求会被发送到服务端 1；编号为 3、6 的请求会被发送到服务端 2。

轮询算法适合的场景需要满足：各机器处理能力相近，且每个请求工作量差异不大。

【示例】轮询负载均衡算法实现示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class RoundRobinLoadBalance<N extends Node> extends BaseLoadBalance<N> implements LoadBalance<N> {

    private final AtomicInteger position = new AtomicInteger(0);

    @Override
    protected N doSelect(List<N> nodes, String ip) {
        int length = nodes.size();
        // 如果位置值已经等于节点数，重置为 0
        position.compareAndSet(length, 0);
        N node = nodes.get(position.get());
        position.getAndIncrement();
        return node;
    }

}

随机算法

“随机算法（Random）” 将请求“随机”分发到候选机器。

如下图所示，随机负载均衡器收到来自客户端的 6 个请求，会随机分发请求，可能会出现：编号为 1、5 的请求会被发送到服务端 0；编号为 2、4 的请求会被发送到服务端 1；编号为 3、6 的请求会被发送到服务端 2。

随机算法适合的场景需要满足：各机器处理能力相近，且每个请求工作量差异不大。

学习过概率论的都知道，调用量较小的时候，可能负载并不均匀，调用量越大，负载越均衡。

【示例】随机负载均衡算法实现示例

负载均衡接口

1
2
3
4
5

public interface LoadBalance<N extends Node> {

    N select(List<N> nodes, String ip);

}

负载均衡抽象类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public abstract class BaseLoadBalance<N extends Node> implements LoadBalance<N> {

    @Override
    public N select(List<N> nodes, String ip) {
        if (CollectionUtil.isEmpty(nodes)) {
            return null;
        }

        // 如果 nodes 列表中仅有一个 node，直接返回即可，无需进行负载均衡
        if (nodes.size() == 1) {
            return nodes.get(0);
        }

        return doSelect(nodes, ip);
    }

    protected abstract N doSelect(List<N> nodes, String ip);

}

机器节点类

1
2
3
4
5
6
7
8
9
10

public class Node implements Comparable<Node> {

    protected String url;

    protected Integer weight;

    protected Integer active;

    // ...
}

随机算法实现

1
2
3
4
5
6
7
8
9
10
11
12

public class RandomLoadBalance<N extends Node> extends BaseLoadBalance<N> implements LoadBalance<N> {

    private final Random random = new Random();

    @Override
    protected N doSelect(List<N> nodes, String ip) {
        // 在列表中随机选取一个节点
        int index = random.nextInt(nodes.size());
        return nodes.get(index);
    }

}

加权轮询/随机算法

轮询/随机算法适合的场景都需要满足：各机器处理能力相近，且每个请求工作量差异不大。

在理想状况下，假设每个机器的硬件条件相同，如：CPU、内存、网络 IO 等配置都相同；并且每个请求的耗时一样（请求传输时间、请求访问数据时间、计算时间等），这时轮询算法才能真正做到负载均衡。显然，要满足以上条件都相同是几乎不可能的，更不要说实际的网络通信中还有更多复杂的情况。

以上，如果有一点不能满足，都无法做到真正的负载均衡。个体存在较大差异，当请求量较大时，处理较慢的机器可能会逐渐积压请求，从而导致过载甚至宕机。

如下图所示，假设存在这样的场景：

• 服务端 1 的处理能力远低于服务端 0 和服务端 2；
• 轮询/随机算法可以保证将请求尽量均匀的分发给两个机器；
• 编号为 1、4 的请求被发送到服务端 0；编号为 3、6 的请求被发送到服务端 2；二者处理能力强，应对游刃有余；
• 编号为 2、5 的请求被发送到服务端 1，服务端 1 处理能力弱，应对捉襟见肘，导致过载。

《蜘蛛侠》电影中有一句经典台词：能力越大，责任越大。显然，以上情况不符合这句话，处理能力强的机器并没有被分发到更多的请求，它的处理能力被闲置了。那么，如何解决这个问题呢？

一种比较容易想到的思路是：引入权重属性，可以根据机器的硬件条件为其设置合理的权重值，负载均衡时，优先将请求分发到权重较高的机器。

“加权轮询算法（Weighted Round Robbin）” 和“加权随机算法（Weighted Random）” 都采用了加权的思路，在轮询/随机算法的基础上，引入了权重属性，优先将请求分发到权重较高的机器。这样，就可以针对性能高、处理速度快的机器设置较高的权重，让其处理更多的请求；而针对性能低、处理速度慢的机器则与之相反。一言以蔽之，加权策略强调了——能力越大，责任越大。

如下图所示，服务端 0 设置权重为 3，服务端 1 设置权重为 1，服务端 2 设置权重为 2。负载均衡器收到来自客户端的 6 个请求，那么编号为 1、2、5 的请求会被发送到服务端 0，编号为 4 的请求会被发送到服务端 1，编号为 3、6 的请求会被发送到机器 2。

【示例】加权随机负载均衡算法实现示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class WeightRandomLoadBalance<N extends Node> extends BaseLoadBalance<N> implements LoadBalance<N> {

    private final Random random = ThreadLocalRandom.current();

    @Override
    protected N doSelect(List<N> nodes, String ip) {

        int length = nodes.size();
        AtomicInteger totalWeight = new AtomicInteger(0);
        for (N node : nodes) {
            Integer weight = node.getWeight();
            totalWeight.getAndAdd(weight);
        }

        if (totalWeight.get() > 0) {
            int offset = random.nextInt(totalWeight.get());
            for (N node : nodes) {
                // 让随机值 offset 减去权重值
                offset -= node.getWeight();
                if (offset < 0) {
                    // 返回相应的 Node
                    return node;
                }
            }
        }

        // 直接随机返回一个
        return nodes.get(random.nextInt(length));
    }

}

【示例】加权轮询负载均衡算法实现示例

以下实现基于 Dubbo 加权轮询算法做了一些简化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148

public class WeightRoundRobinLoadBalance<N extends Node> extends BaseLoadBalance<N> implements LoadBalance<N> {

    /**
     * 60 秒
     */
    private static final int RECYCLE_PERIOD = 60000;

    /**
     * Node hashcode 到 WeightedRoundRobin 的映射关系
     */
    private ConcurrentMap<Integer, WeightedRoundRobin> weightMap = new ConcurrentHashMap<>();

    /**
     * 原子更新锁
     */
    private AtomicBoolean updateLock = new AtomicBoolean();

    @Override
    protected N doSelect(List<N> nodes, String ip) {

        int totalWeight = 0;
        long maxCurrent = Long.MIN_VALUE;

        // 获取当前时间
        long now = System.currentTimeMillis();
        N selectedNode = null;
        WeightedRoundRobin selectedWRR = null;

        // 下面这个循环主要做了这样几件事情：
        //   1. 遍历 Node 列表，检测当前 Node 是否有相应的 WeightedRoundRobin，没有则创建
        //   2. 检测 Node 权重是否发生了变化，若变化了，则更新 WeightedRoundRobin 的 weight 字段
        //   3. 让 current 字段加上自身权重，等价于 current += weight
        //   4. 设置 lastUpdate 字段，即 lastUpdate = now
        //   5. 寻找具有最大 current 的 Node，以及 Node 对应的 WeightedRoundRobin，
        //      暂存起来，留作后用
        //   6. 计算权重总和
        for (N node : nodes) {
            int hashCode = node.hashCode();
            WeightedRoundRobin weightedRoundRobin = weightMap.get(hashCode);
            int weight = node.getWeight();
            if (weight < 0) {
                weight = 0;
            }

            // 检测当前 Node 是否有对应的 WeightedRoundRobin，没有则创建
            if (weightedRoundRobin == null) {
                weightedRoundRobin = new WeightedRoundRobin();
                // 设置 Node 权重
                weightedRoundRobin.setWeight(weight);
                // 存储 url 唯一标识 identifyString 到 weightedRoundRobin 的映射关系
                weightMap.putIfAbsent(hashCode, weightedRoundRobin);
                weightedRoundRobin = weightMap.get(hashCode);
            }
            // Node 权重不等于 WeightedRoundRobin 中保存的权重，说明权重变化了，此时进行更新
            if (weight != weightedRoundRobin.getWeight()) {
                weightedRoundRobin.setWeight(weight);
            }

            // 让 current 加上自身权重，等价于 current += weight
            long current = weightedRoundRobin.increaseCurrent();
            // 设置 lastUpdate，表示近期更新过
            weightedRoundRobin.setLastUpdate(now);
            // 找出最大的 current
            if (current > maxCurrent) {
                maxCurrent = current;
                // 将具有最大 current 权重的 Node 赋值给 selectedNode
                selectedNode = node;
                // 将 Node 对应的 weightedRoundRobin 赋值给 selectedWRR，留作后用
                selectedWRR = weightedRoundRobin;
            }

            // 计算权重总和
            totalWeight += weight;
        }

        // 对 weightMap 进行检查，过滤掉长时间未被更新的节点。
        // 该节点可能挂了，nodes 中不包含该节点，所以该节点的 lastUpdate 长时间无法被更新。
        // 若未更新时长超过阈值后，就会被移除掉，默认阈值为 60 秒。
        if (!updateLock.get() && nodes.size() != weightMap.size()) {
            if (updateLock.compareAndSet(false, true)) {
                try {
                    // 遍历修改，即移除过期记录
                    weightMap.entrySet().removeIf(item -> now - item.getValue().getLastUpdate() > RECYCLE_PERIOD);
                } finally {
                    updateLock.set(false);
                }
            }
        }

        if (selectedNode != null) {
            // 让 current 减去权重总和，等价于 current -= totalWeight
            selectedWRR.decreaseCurrent(totalWeight);
            // 返回具有最大 current 的 Node
            return selectedNode;
        }

        // should not happen here
        return nodes.get(0);
    }

    protected static class WeightedRoundRobin {

        // 服务提供者权重
        private int weight;
        // 当前权重
        private AtomicLong current = new AtomicLong(0);
        // 最后一次更新时间
        private long lastUpdate;

        public long increaseCurrent() {
            // current = current + weight；
            return current.addAndGet(weight);
        }

        public long decreaseCurrent(int total) {
            // current = current - total;
            return current.addAndGet(-1 * total);
        }

        public int getWeight() {
            return weight;
        }

        public void setWeight(int weight) {
            this.weight = weight;
            // 初始情况下，current = 0
            current.set(0);
        }

        public AtomicLong getCurrent() {
            return current;
        }

        public void setCurrent(AtomicLong current) {
            this.current = current;
        }

        public long getLastUpdate() {
            return lastUpdate;
        }

        public void setLastUpdate(long lastUpdate) {
            this.lastUpdate = lastUpdate;
        }

    }

}

最少连接数算法

加权轮询/随机算法虽然一定程度上解决了机器处理能力不同时的负载均衡场景，但它最大的问题在于不能动态应对网络中负载不均的场景。加权的思路是在负载均衡处理的事前，预设好不同机器的权重，然后分发。然而，每个请求的连接时长不同，负载均衡器也不可能准确预估出请求的连接时长。因此，采用加权轮询/随机算法算法，都无法动态应对连接时长不均的网络场景，可能会出现某些机器当前连接数过多，而另一些机器的连接过少的情况，即并非真正的流量负载均衡。

如下图所示，假设存在这样的场景：

• 3 个服务端的处理能力相同；
• 编号为 1、4 的请求被发送到服务端 0，但是 1 很快就断开连接，此时只有 4 请求连接服务端 0；
• 编号为 2、5 的请求被发送到服务端 1，但是 2 始终保持长连接；该系统继续运行时，服务端 1 发生过载；
• 编号为 3、6 的请求被发送到服务端 2，但是 3 很快就断开连接，此时只有 6 请求连接服务端 2；

既然，请求的连接时长不同，会导致有的服务端处理慢，积压大量连接数；而有的服务端处理快，保持的连接数少。那么，我们不妨想一下，如果负载均衡器监控一下服务端当前所持有的连接数，优先将请求分发给连接数少的服务端，不就能有效提高分发效率了吗？最少连接数算法正是采用这个思路去设计的。

“最少连接数算法（Least Connections）” 将请求分发到连接数/请求数最少的候选机器。

要根据机器连接数分发，显然要先维护机器的连接数。因此，最少连接数算法需要实时追踪每个候选机器的活跃连接数；然后，动态选出连接数最少的机器，优先分发请求。最少连接数算法会记录当前时刻，每个候选节点正在处理的连接数，然后选择连接数最小的节点。该策略能够动态、实时地反应机器的当前状况，较为合理地将负责分配均匀，适用于对当前系统负载较为敏感的场景。

由此可见，最少连接数算法适用于对系统负载较为敏感且请求连接时长相差较大的场景。

如下图所示，假设存在这样的场景：

• 服务端 0 和服务端 1 的处理能力相同；
• 编号为 1、3 的请求被发送到服务端 0，但是 1、3 很快就断开连接；
• 编号为 2、4 的请求被发送到服务端 1，但是 2、4 保持长连接；
• 由于服务端 0 当前连接数最少，编号为 5、6 的请求被分发到服务端 0。

“加权最少连接数算法（Weighted Least Connection）”在最少连接数算法的基础上，根据机器的性能为每台机器分配权重，再根据权重计算出每台机器能处理的连接数。

【示例】最少连接数算法实现

最少连接数算法实现要点：活跃调用数越小，表明该服务节点处理能力越高，单位时间内可处理更多的请求，应优先将请求分发给该服务。在具体实现中，每个服务节点对应一个活跃数 active。初始情况下，所有服务提供者活跃数均为 0。每收到一个请求，活跃数加 1，完成请求后则将活跃数减 1。在服务运行一段时间后，性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快，此时这样的服务提供者能够优先获取到新的服务请求、这就是最少连接数负载均衡算法的基本思想。

以下实现基于 Dubbo 最少连接数负载均衡算法做了些许改动。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

public class LeastActiveLoadBalance<N extends Node> extends BaseLoadBalance<N> implements LoadBalance<N> {

    private final Random random = new Random();

    @Override
    protected N doSelect(List<N> nodes, String ip) {
        int length = nodes.size();
        // 最小的活跃数
        int leastActive = -1;
        // 具有相同“最少连接数”的服务者提供者（以下用 Node 代称）数量
        int leastCount = 0;
        // leastIndexs 用于记录具有相同“最少连接数”的 Node 在 nodes 列表中的下标信息
        int[] leastIndexs = new int[length];
        int totalWeight = 0;
        // 第一个最少连接数的 Node 权重值，用于与其他具有相同最少连接数的 Node 的权重进行对比，
        // 以检测是否“所有具有相同最少连接数的 Node 的权重”均相等
        int firstWeight = 0;
        boolean sameWeight = true;

        // 遍历 nodes 列表
        for (int i = 0; i < length; i++) {
            N node = nodes.get(i);
            // 发现更小的活跃数，重新开始
            if (leastActive == -1 || node.getActive() < leastActive) {
                // 使用当前活跃数更新最少连接数 leastActive
                leastActive = node.getActive();
                // 更新 leastCount 为 1
                leastCount = 1;
                // 记录当前下标值到 leastIndexs 中
                leastIndexs[0] = i;
                totalWeight = node.getWeight();
                firstWeight = node.getWeight();
                sameWeight = true;

                // 当前 Node 的活跃数 node.getActive() 与最少连接数 leastActive 相同
            } else if (node.getActive() == leastActive) {
                // 在 leastIndexs 中记录下当前 Node 在 nodes 集合中的下标
                leastIndexs[leastCount++] = i;
                // 累加权重
                totalWeight += node.getWeight();
                // 检测当前 Node 的权重与 firstWeight 是否相等，
                // 不相等则将 sameWeight 置为 false
                if (sameWeight && i > 0
                    && node.getWeight() != firstWeight) {
                    sameWeight = false;
                }
            }
        }

        // 当只有一个 Node 具有最少连接数，此时直接返回该 Node 即可
        if (leastCount == 1) {
            return nodes.get(leastIndexs[0]);
        }

        // 有多个 Node 具有相同的最少连接数，但它们之间的权重不同
        if (!sameWeight && totalWeight > 0) {
            // 随机生成一个 [0, totalWeight) 之间的数字
            int offsetWeight = random.nextInt(totalWeight);
            // 循环让随机数减去具有最少连接数的 Node 的权重值，
            // 当 offset 小于等于 0 时，返回相应的 Node
            for (int i = 0; i < leastCount; i++) {
                int leastIndex = leastIndexs[i];
                // 获取权重值，并让随机数减去权重值
                offsetWeight -= nodes.get(leastIndex).getWeight();
                if (offsetWeight <= 0) {
                    return nodes.get(leastIndex);
                }
            }
        }
        // 如果权重相同或权重为 0 时，随机返回一个 Node
        return nodes.get(leastIndexs[random.nextInt(leastCount)]);
    }

}

最少响应时间算法

“最少响应时间算法（Least Time）” 将请求分发到响应时间最短的候选机器。最少响应时间算法和最少连接数算法二者的目标其实是殊途同归，都是动态调整，将请求尽量分发到处理能力强的机器上。不同点在于，最少连接数关注的维度是机器持有的连接数，而最少响应时间关注的维度是机器上一次响应时间哪个最短。理论上来说，持有的连接数少，响应时间短，都可以表明机器潜在的处理能力比较强。

最少响应时间算法具有高度的敏感性、自适应性。但是，由于它需要持续监控候选机器的响应时延，相比于监控候选机器的连接数，会显著增加监控的开销。此外，请求的响应时延并不一定能完全反应机器的处理能力，有可能某机器上一次处理的请求恰好是一个开销非常小的请求。

哈希算法

前面提到的负载均衡算法，都只适用于无状态应用。所谓无状态应用，意味着：请求无论分发到集群中的任意机器上，得到的响应都是相同的：然而，有状态服务则不然：请求分发到不同的机器上，得到的结果是不一样的。典型的无状态应用是普通的 Web 服务器；典型的有状态应用是各种分布式数据库（如：Redis、ElasticSearch 等），这些数据库存储了大量，乃至海量的数据，无法全部存储在一台机器上，为了提高整体容量以及吞吐量，采用了分区（分片）的设计，将数据化整为零的存储在不同机器上。

对于有状态应用，不仅仅需要保证负载的均衡，更为重要的是，需要保证针对相同数据的请求始终访问的是相同的机器，否则，就无法获取到正确的数据。

那么，如何解决有状态应用的负载均衡呢？有一种方案是哈希算法。

“哈希算法（Hash）” 根据一个 key （可以是唯一 ID、IP、URL 等），通过哈希函数计算得到一个数值，用该数值在候选机器列表的进行取模运算，得到的结果便是选中的机器。

这种算法可以保证，同一关键字（IP 或 URL 等）的请求，始终会被转发到同一台机器上。哈希负载均衡算法常被用于实现会话粘滞（Sticky Session）。

但是 ，哈希算法的问题是：当增减节点时，由于哈希取模函数的基数发生变化，会影响大部分的映射关系，从而导致之前的数据不可访问。要解决这个问题，就必须根据新的计算公式迁移数据。显然，如果数据量很大的情况下，迁移成本很高；并且，在迁移过程中，要保证业务平滑过渡，需要使用数据双写等较为复杂的技术手段。

【示例】源地址哈希算法实现示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class IpHashLoadBalance<N extends Node> extends BaseLoadBalance<N> implements LoadBalance<N> {

    @Override
    protected N doSelect(List<N> nodes, String ip) {
        if (StrUtil.isBlank(ip)) {
            ip = "127.0.0.1";
        }

        int length = nodes.size();
        int index = hash(ip) % length;
        return nodes.get(index);
    }

    public int hash(String text) {
        return HashUtil.fnvHash(text);
    }

}

一致性哈希算法

哈希算法的缺点是：当集群中出现增减节点时，由于哈希取模函数的基数发生变化，会导致大量集群中的机器不可用；需要通过代价高昂的数据迁移，来解决问题。那么，我们自然会希望有一种更优化的方案，来尽量减少影响的机器数。一致性哈希算法就是为了这个目标而应运而生。

一致性哈希算法对哈希算法进行了改良。“一致性哈希算法（Consistent Hash）”，根据哈希算法将对应的 key 哈希到一个具有 2^32 个桶的空间，并且头尾相连（0 到 2^32-1），即一个闭合的环形，这个圆环被称为“哈希环”。哈希算法是对节点的数量进行取模运算；而一致性哈希算法则是对 2^32 进行取模运算。

哈希环的空间是按顺时针方向组织的，需要对指定 key 的数据进行读写时，会执行两步：

1. 先对节点进行哈希计算，计算的关键字通常是 IP 或其他唯一标识（例：hash(ip)），然后对 2^32 取模，以确定节点在哈希环上的位置。
2. 先对 key 进行哈希计算（hash(key)），然后对 2^32 取模，以确定 key 在哈希环上的位置。
3. 然后根据 key 的位置，顺时针找到的第一个节点，就是 key 对应的节点。

所以，一致性哈希是将“存储节点”和“数据”都映射到一个顺时针排序的哈希环上。

一致性哈希算法会尽可能保证，相同的请求被分发到相同的机器上。当出现增减节点时，只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响，不会引起剧烈变动。

• 相同的请求是指：一般在使用一致性哈希时，需要指定一个 key 用于 hash 计算，可能是：用户 ID、请求方 IP、请求服务名称，参数列表构成的串
• 尽可能是指：哈希环上出现增减节点时，少数机器的变化不应该影响大多数的请求。

（1）增加节点

如下图所示，假设，哈希环中新增了一个节点 S4，新增节点经过哈希计算映射到图中位置：

此时，只有 K1 收到影响；而 K0、K2 均不受影响。

（2）减少节点

如下图所示，假设，哈希环中减少了一个节点 S0：

此时，只有 K0 收到影响；而 K1、K2 均不受影响。

一致性哈希算法并不保证节点能够在哈希环上分布均匀，由此而产生一个问题，哈希环上可能有大量的请求集中在一个节点上。从概率角度来看，哈希环上的节点越多，分布就越均匀。正因为如此，一致性哈希算法不适用于节点数过少的场景。

如下图所示：极端情况下，可能由于节点在哈希环上分布不均，有大量请求计算得到的 key 会被集中映射到少数节点，甚至某一个节点上。此外，节点分布不均匀的情况下，进行容灾与扩容时，哈希环上的相邻节点容易受到过大影响，从而引发雪崩式的连锁反应。

【示例】一致性哈希算法示例

以下示例基于 Dubbo 的一致性哈希负载均衡算法做了一些简化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

public class ConsistentHashLoadBalance<N extends Node> extends BaseLoadBalance<N> implements LoadBalance<N> {

    private final ConcurrentMap<String, ConsistentHashSelector<?>> selectors = new ConcurrentHashMap<>();

    @SuppressWarnings("unchecked")
    @Override
    protected N doSelect(List<N> nodes, String ip) {
        // 分片数，这里设为节点数的 4 倍
        Integer replicaNum = nodes.size() * 4;
        // 获取 nodes 原始的 hashcode[11. 分布式协同](..%2F11.%B7%D6%B2%BC%CA%BD%D0%AD%CD%AC)
        int identityHashCode = System.identityHashCode(nodes);

        // 如果 nodes 是一个新的 List 对象，意味着节点数量发生了变化
        // 此时 selector.identityHashCode != identityHashCode 条件成立
        ConsistentHashSelector<N> selector = (ConsistentHashSelector<N>) selectors.get(ip);
        if (selector == null || selector.identityHashCode != identityHashCode) {
            // 创建新的 ConsistentHashSelector
            selectors.put(ip, new ConsistentHashSelector<>(nodes, identityHashCode, replicaNum));
            selector = (ConsistentHashSelector<N>) selectors.get(ip);
        }
        // 调用 ConsistentHashSelector 的 select 方法选择 Node
        return selector.select(ip);
    }

    /**
     * 一致性哈希选择器
     */
    private static final class ConsistentHashSelector<N extends Node> {

        /**
         * 存储虚拟节点
         */
        private final TreeMap<Long, N> virtualNodes;

        private final int identityHashCode;

        /**
         * 构造器
         *
         * @param nodes            节点列表
         * @param identityHashCode hashcode
         * @param replicaNum       分片数
         */
        ConsistentHashSelector(List<N> nodes, int identityHashCode, Integer replicaNum) {
            this.virtualNodes = new TreeMap<>();
            this.identityHashCode = identityHashCode;
            // 获取虚拟节点数，默认为 100
            if (replicaNum == null) {
                replicaNum = 100;
            }
            for (N node : nodes) {
                for (int i = 0; i < replicaNum / 4; i++) {
                    // 对 url 进行 md5 运算，得到一个长度为 16 的字节数组
                    byte[] digest = md5(node.getUrl());
                    // 对 digest 部分字节进行 4 次 hash 运算，得到四个不同的 long 型正整数
                    for (int j = 0; j < 4; j++) {
                        // h = 0 时，取 digest 中下标为 0 ~ 3 的 4 个字节进行位运算
                        // h = 1 时，取 digest 中下标为 4 ~ 7 的 4 个字节进行位运算
                        // h = 2, h = 3 时过程同上
                        long m = hash(digest, j);
                        // 将 hash 到 node 的映射关系存储到 virtualNodes 中，
                        // virtualNodes 需要提供高效的查询操作，因此选用 TreeMap 作为存储结构
                        virtualNodes.put(m, node);
                    }
                }
            }
        }

        public N select(String key) {
            // 对参数 key 进行 md5 运算
            byte[] digest = md5(key);
            // 取 digest 数组的前四个字节进行 hash 运算，再将 hash 值传给 selectForKey 方法，
            // 寻找合适的 Node
            return selectForKey(hash(digest, 0));
        }

        private N selectForKey(long hash) {
            // 查找第一个大于或等于当前 hash 的节点
            Map.Entry<Long, N> entry = virtualNodes.ceilingEntry(hash);
            // 如果 hash 大于 Node 在哈希环上最大的位置，此时 entry = null，
            // 需要将 TreeMap 的头节点赋值给 entry
            if (entry == null) {
                entry = virtualNodes.firstEntry();
            }
            // 返回 Node
            return entry.getValue();
        }

    }

    /**
     * 计算 hash 值
     */
    public static long hash(byte[] digest, int number) {
        return (((long) (digest[3 + number * 4] & 0xFF) << 24)
            | ((long) (digest[2 + number * 4] & 0xFF) << 16)
            | ((long) (digest[1 + number * 4] & 0xFF) << 8)
            | (digest[number * 4] & 0xFF))
            & 0xFFFFFFFFL;
    }

    /**
     * 计算 MD5 值
     */
    public static byte[] md5(String value) {
        MessageDigest md5;
        try {
            md5 = MessageDigest.getInstance("MD5");
        } catch (NoSuchAlgorithmException e) {
            throw new IllegalStateException(e.getMessage(), e);
        }
        md5.reset();
        byte[] bytes = value.getBytes(StandardCharsets.UTF_8);
        md5.update(bytes);
        return md5.digest();
    }

}

虚拟一致性哈希算法

在一致性哈希算法中，如果节点数过少，可能会分布不均，从而导致负载不均衡。在实际生产环境中，一个分布式系统应该具备良好的伸缩性，既能从容的扩展到大规模的集群，也要能支持小规模的集群。为此，又产生了虚拟哈希算法，进一步对一致性哈希算法进行了改良。

虚拟哈希算法的解决思路是：虽然实际的集群可能节点数较少，但是在哈希环上引入大量的虚拟哈希节点。具体来说，“虚拟哈希算法”有二次映射：先将虚拟节点映射到哈希环上，再将虚拟节点映射到实际节点上。

如下图所示，假设存在这样的场景：

• 分布式集群中有 4 个真实节点，分别是：S0、S1、S2、S3；
• 我们不妨先假定分配给哈希环 12 个虚拟节点，并将虚拟节点映射到真实节点上，映射关系如下：
  • S0 - S0_0、S0_1、S0_2、S0_3
  • S1 - S1_0、S1_1、S1_2、S1_3
  • S2 - S2_0、S2_1、S2_2、S2_3
  • S3 - S3_0、S3_1、S3_2、S3_3

通过引入虚拟哈希节点，是的哈希环上的节点分布相对均匀了。举例来说，假如此时，某请求的 key 哈希取模后，先映射到哈希环的 [S3_2, S0_0]、[S3_0, S0_1]、[S3_1, S0_2] 这三个区间的任意一点；接下来的二次映射都会匹配到真实节点 S0。

在实际应用中，虚拟哈希节点数一般都比较大（例如：Redis 的虚拟哈希槽有 16384 个），较大的数量保证了虚拟哈希环上的节点分布足够均匀。

虚拟节点除了会提高节点的均衡度，还会提高系统的稳定性。当节点变化时，会有不同的节点共同分担系统的变化，因此稳定性更高。例如，当某个节点被移除时，分配给该节点的多个虚拟节点会被一并移除，而这些虚拟节点按顺时针方向的下一个虚拟节点，可能会对应不同的真实节点，即这些不同的真实节点共同分担了节点变化导致的压力。

此外，有了虚拟节点后，可以通过调整分配给真实节点的虚拟节点数，来达到设置权重一样的效果，使得负载均衡更加灵活。

综上所述，虚拟一致性哈希算法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。

小结

下面通过一张思维导图对介绍的负载均衡算法做一个小结：

参考资料

• Comparing Load Balancing Algorithms - YouTube 上介绍常见负载均衡算法的视频
• Top 6 Load Balancing Algorithms Every Developer Should Know - YouTube 上介绍 6 种常见负载均衡算法的视频
• Consistent Hashing | Algorithms You Should Know - YouTube 上的一致性哈希算法视频
• 《大型网站技术架构：核心原理与案例分析》
• 什么是负载均衡
• Dubbo 官方文档之负载均衡
• 负载均衡算法及手段
• 利用 dns 解析来实现网站的负载均衡

系统架构概述

大型系统架构演化

一个大型系统的架构是一个渐进的演化过程。罗马不是一天建成的，同理，微信、淘宝等大型系统绝不是一蹴而就的。随着业务的不断发展，用户体量的增加，系统的复杂度势必不断攀升，最终迫使系统架构进化，以应对挑战。

了解大型系统架构的演化过程，有利于我们了解架构进化的发展规律和业界一些成熟的应对方案。帮助我们在实际工作中，如何去思考架构，如何去凝练解决方案。

大型系统架构演化比较具有代表性的就是大型网站的演化过程。这里介绍一下大型网站演化的一般规律。

单机架构

• 问题：网站运营初期，访问用户少，一台服务器绰绰有余。
• 特征：应用程序、数据库、文件等所有的资源都在一台服务器上。
• 描述：通常服务器操作系统使用 linux，应用程序使用 PHP 开发，然后部署在 Apache 上，数据库使用 Mysql，通俗称为 LAMP。汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。

应用服务和数据服务分离

• 问题：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，一台服务器已不足以支撑。
• 特征：应用服务器、数据库服务器、文件服务器分别独立部署。
• 描述：三台服务器对性能要求各不相同：
  • 应用服务器要处理大量业务逻辑，因此需要更快更强大的 CPU；
  • 数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存；
  • 文件服务器需要存储大量文件，因此需要更大容量的硬盘。

使用缓存改善性能

• 问题：随着用户逐渐增多，数据库压力太大导致访问延迟。
• 特征：由于网站访问和财富分配一样遵循二八定律：_80% 的业务访问集中在 20% 的数据上_。将数据库中访问较集中的少部分数据缓存在内存中，可以减少数据库的访问次数，降低数据库的访问压力。
• 描述：缓存分为两种：应用服务器上的本地缓存和分布式缓存服务器上的远程缓存。
  • 本地缓存访问速度更快，但缓存数据量有限，同时存在与应用程序争用内存的情况。
  • 分布式缓存可以采用集群方式，理论上可以做到不受内存容量限制的缓存服务。

负载均衡

• 问题：使用缓存后，数据库访问压力得到有效缓解。但是单一应用服务器能够处理的请求连接有限，在访问高峰期，成为瓶颈。
• 特征：多台服务器通过负载均衡同时向外部提供服务，解决单一服务器处理能力和存储空间不足的问题。
• 描述：使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。

数据库读写分离

• 问题：网站使用缓存后，使绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
• 特征：目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到一台服务器上。网站利用数据库的主从热备功能，实现数据库读写分离，从而改善数据库负载压力。
• 描述：应用服务器在写操作的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。这样当应用服务器在读操作的时候，访问从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离的对应用透明。

多级缓存

• 问题：中国网络环境复杂，不同地区的用户访问网站时，速度差别也极大。
• 特征：采用 CDN 和反向代理加快系统的静态资源访问速度。
• 描述：CDN 和反向代理的基本原理都是缓存，区别在于：
  • CDN 部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；
  • 而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器时反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

业务拆分

• 问题：大型网站的业务场景日益复杂，分为多个产品线。
• 特征：采用分而治之的手段将整个网站业务分成不同的产品线。系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。
• 描述：应用之间可以通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
  • 纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。
  • 横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

分库分表

• 问题：随着大型网站业务持续增长，数据库经过读写分离，从一台服务器拆分为两台服务器，依然不能满足需求。
• 特征：数据库采用分布式数据库。
• 描述：分布式数据库是数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用。不到不得已时，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。

分布式组件

• 问题：随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂。
• 特征：系统引入 NoSQL 数据库及搜索引擎。
• 描述：NoSQL 数据库及搜索引擎对可伸缩的分布式特性具有更好的支持。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

微服务

• 问题：随着业务越拆越小，存储系统越来越庞大，应用系统整体复杂程度呈指数级上升，部署维护越来越困难。由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。
• 特征：公共业务提取出来，独立部署。由这些可复用的业务连接数据库，通过分布式服务提供共用业务服务。
• 描述：大型网站的架构演化到这里，基本上大多数的技术问题都得以解决，诸如跨数据中心的实时数据同步和具体网站业务相关的问题也都可以组合改进现有技术架构来解决。

架构设计的考量

每一个模式描述了一个不但重复发生的问题及该问题解决方案的核心。这样，就可以不断复用该方案而减少重复工作。

什么是架构

架构是一个非常抽象的概念，每个人由于技术的深度、思维的视角等差异，对于架构的理解，各不相同。

这里摘抄网上某段比较精髓的定义：

• 架构是软件系统的顶层设计。
• 框架是面向编程或配置的半成品。
• 组件是从技术维度上的复用。
• 模块是从业务维度上职责的划分。
• 系统是相互协同可运行的实体。

架构设计的目标

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

架构设计应该按需设计。任何网站都是随着业务逐步发展，不断演化而成，不要指望一劳永逸。

关于架构设计的目的，常见的误区有：

• 因为架构很重要，所以要做架构设计
• 为了高性能、高可用、可扩展，所以要做架构设计
• 大厂都是这么做的，所以我们也这么做
• 这种新技术很牛逼，我们也一定要引入

架构的原则：

• 架构设计应该按需设计。任何网站都是随着业务逐步发展，不断演化而成，不要指望一劳永逸。
• 驱动技术发展的主要力量是业务发展。
• 不要盲目跟风大公司的解决方案。
• 不要盲目追求流行技术，而脱离了业务发展的实际情况。
• 不要把所有问题都丢给技术。现实中，有很多案例告诉我们，很多问题不一定需要通过技术来解决。归根结底，技术始终都是业务的辅助，业务问题究竟是通过技术来解决还是直接通过业务来解决，需要根据实际情况去分析判断。这就需要对业务领域有比较深入的理解和思考。

架构设计的原则

合适优于先进>演化优于一步到位>简单优于复杂

合适原则

没那么多人，却想干那么多活，是失败的第一个主要原因。

没有那么多积累，却想一步登天，是失败的第二个主要原因。

没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。

简单原则

再高大上的解决方案如果不能落地，也是白扯。

所以，应对需求

演化原则

演化优于一步到位。

不要妄图设计一个一步到位，永久不变的架构。

墨菲定律

• 任何事都没有表面看起来那么简单；
• 所有的事都会比你预计的时间长；
• 会出错的事总会出错；
• 如果你担心某种情况发生，那么它就更有可能发生。

康威定律

系统设计(产品结构)等同组织形式，每个设计系统的组织，其产生的设计等同于组织之间的沟通结构（简单点说就是，系统的设计受限于设计系统的组织的人员架构形式。

二八定律

高性能

性能是软件系统的重要衡量标准。很多扩展性、伸缩性、可用性的问题，是为了解决性能问题而引入的。

性能指标

响应延时、并发处理能力、内存、CPU、IO 开销等都可以视为系统的性能指标。

分析用户体量、日访问量的峰值，估算出为了平稳应对峰值访问流量所需的并发量、吞吐量。如果是应用型系统，性能够用就好，没必要一味追求高性能。比如：用户体量可能还不过万，一天总访问量可能也就一两千 PV，峰值也就几百 QPS，这样的系统如果要考虑每秒几万的 QPS，显然有些多虑了。

性能提升手段

常见的性能提升手段有：

• 前端
  • 浏览器缓存
  • 静态资源压缩
  • 合理布局页面
  • 减少 cookie 传输
  • CDN
• 应用服务
  • 负载均衡和反向代理
  • 本地缓存
  • 分布式缓存
  • 异步消息队列
  • 集群
  • 代码层面：使用多线程、改善内存管理
• 数据库
  • 索引
  • 数据库缓存
  • SQL 优化

注意：缓存是改善软件性能的第一手段。缓存除了可以加快数据访问速度以外，还可以减轻后端应用和数据存储的负载压力。所以，如果要提升系统性能，应该第一时间想到缓存。

使用缓存有两个前提：

• 数据访问热点不均匀，频繁访问的数据应该放在缓存中。
• 数据在某个时间段有效，不会很快过期，否则缓存数据会因已经失效而产生脏读。

高可用

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

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

单点系统，是无法保证高可用的。系统自身故障、断电、硬件故障、网络等等，都可能导致服务不可用。高可用方案五花八门，本质上都是通过“冗余”来实现高可用。

无状态应用的高可用

无状态应用一般具有幂等性，即无论在哪台机器上进行计算，同样的算法和输入数据，产出的结果都是一样的。所以，计算在任意节点服务器上执行，结果都一样。

无状态应用的高可用：

• 需要增加一个任务分配器，选择合适的任务分配器也是一件复杂的事情，需要综合考虑性能、成本、可维护性、可用性等各方面因素。
• 任务分配器和真正的业务服务器之间有连接和交互，需要选择合适的连接方式，并且对连接进行管理。例如，连接建立、连接检测、连接中断后如何处理等。
• 任务分配器需要增加分配算法。例如，常见的双机算法有主备、主主，主备方案又可以细分为冷备、温备、热备。

有状态应用的高可用

有状态应用，是指需要存储数据的系统，比如各种分布式存储。和无状态应用相比，有一个本质上的区别：各节点需要通过同步保持数据一致。分布式领域里面有一个著名的 CAP 定理，从理论上论证了存储高可用的复杂度。也就是说，存储高可用不可能同时满足“一致性、可用性、分区容错性”，最多满足其中两个，这就要求我们在做架构设计时结合业务进行取舍。

高可用手段

高可用的常用手段：

• 负载均衡 - 通过负载均衡设备建立集群共同对外提供服务。
• 备份 - 数据存储在多台服务器，互相备份。即使访问和负载很小的服务也必须部署至少两台服务器，构成一个集群，目的就是通过冗余实现服务的高可用。
  • 冷备份 - 数据应该定期备份；
  • 热备份 - 为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步 。
  • 灾备 - 为了抵御地震、海啸等不可抗因素导致的网站完全瘫痪，某些大型网站会对整个数据中心进行备份，全球范围内部署 灾备数据中心。网站程序和数据定期同步到多个灾备数据中心。
• 自动化 - 自动化是指，大型系统有必要通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能。常见自动化手段有：
  • 发布过程自动化
    • 自动化代码管理
    • 自动化测试
    • 自动化安全监测
    • 自动化部署
  • 运维自动化
    • 自动化监控
    • 自动化报警
    • 自动化失效转移
    • 自动化失效恢复
    • 自动化降级
    • 自动化分配资源

扩展性

可扩展性指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。

衡量扩展性的标准就是增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或很少改动，既有功能就可以上线新产品。

软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，彼此影响就越小，也就更容易独立发展，即扩展性好。

主要手段有：

• 分层 - 分层是扩展性设计的最基本手段。通过分层，可以将一个的软件系统切分为不同的部分，便于分工合作开发和维护；各层间具有一定的独立性。

  • 分层架构的约束：禁止跨层次的调用及逆向调用。
  • 即使系统规模很小，也应该考虑采用分层的架构，这样便于以后扩展。

• 分割 - 将不同的功能和服务分割开来，包装成高内聚、低耦合的模块单元。这有助于软件的开发和维护，便于不同模块的分布式部署，提高系统的并发处理能力和功能扩展能力。

• 异步 - 业务间的消息传递不是同步调用，而是将一个业务操作拆分成多阶段，每个阶段间通过共享数据的方式异步执行进行协作。

  • 在单一服务器内部可通过多线程共享内存队列的方式实现异步，处在业务操作前面的线程将操作输出到队列，后面的线程从队列中读取数据进行处理；
  • 在分布式系统中，多个服务器集群通过分布式消息队列实现异步。

• 分布式 - 将业务和可复用服务分离，通过分布式服务框架调用。分布式是指多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。着意味着服务可以用更多的机器工作，即扩展 CPU、内存、IO 等资源，从而提高系统整体的吞吐量和并发处理能力。

  • 常用的分布式方案：
    • 分布式应用和服务
    • 分布式静态资源
    • 分布式数据和存储
    • 分布式计算
  • 分布式也引入了一些问题：
    • 服务调用必须通过网络，网络延迟会影响性能。
    • 服务器越多，宕机概率也越大，导致可用性降低。
    • 数据一致性非常困难，分布式事务也难以保证。
    • 网站依赖错综复杂，开发管理维护困难。

伸缩性

衡量伸缩的标准就是是否可以用多台服务器构建集群，是否容易向集群中增删服务器节点。增删服务器节点后是否可以提供和之前无差别的服务。集群中可容纳的总服务器数是否有限制。

伸缩性是指通过增/减服务器节点数，来灵活的提高/降低系统处理能力。

主要手段有:

• 应用服务器集群 - 只要服务器上保存数据，则所有服务器都是对等的，通过负载均衡设备向集群中不断加入服务器即可
• 缓存服务器集群 - 加入新的服务器可能会导致缓存路由失效，进而导致集群中的大部分缓存数据都无法访问。虽然缓存数据可以通过数据库重新加载，但是如果应用严重依赖缓存，可能会导致网站崩溃。需要改进缓存路由算法保证缓存数据的可访问性。
• 关系型数据库集群 - 关系型数据库虽然支持数据复制，主从热备等机制，但是很难做到大规模集群的可伸缩性，因此关系型数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。
• Nosql 数据库集群 - 由于先天就是为了应对海量数据而产生，因此对伸缩性的支持通常都非常好。

安全性

安全是指系统应该对恶意攻击有一定的抵抗能力，保护重要数据不被窃取。

• 密码 和 手机校验码 进行身份认证
• 登录、交易等重要操作需要对网络通信进行 加密，存储的敏感数据如用户信息等也进行加密处理
• 防止机器人程序攻击网站，使用 验证码 进行识别
• 对常见用于 攻击 网站的 XSS 攻击、SQL 注入、进行编码转换等相应处理
• 对垃圾信息、敏感信息进行 过滤
• 对交易转账等重要操作根据交易模式和交易信息进行 风险控制

常见架构模型

分层架构

分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。

这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。

四层的结构最常见。

• 表现层（presentation）：用户界面，负责视觉和用户互动
• 业务层（business）：实现业务逻辑
• 持久层（persistence）：提供数据，SQL 语句就放在这一层
• 数据库（database） ：保存数据

优点

• 结构简单，容易理解和开发
• 不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构
• 每一层都可以独立测试，其他层的接口通过模拟解决

缺点

• 一旦环境变化，需要代码调整或增加功能时，通常比较麻烦和费时
• 部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布
• 软件升级时，可能需要整个服务暂停
• 扩展性差。用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难

事件驱动架构

事件（event）是状态发生变化时，软件发出的通知。

事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。

• 事件队列（event queue）：接收事件的入口
• 分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
• 事件通道（event channel）：分发器与处理器之间的联系渠道
• 事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作

对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

优点

• 分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好
• 适用性广，各种类型的项目都可以用
• 性能较好，因为事件的异步本质，软件不易产生堵塞
• 事件处理器可以独立地加载和卸载，容易部署

缺点

• 涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂
• 难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚
• 分布式和异步特性导致这个架构较难测试

微核架构

微核架构（microkernel architecture）又称为”插件架构”（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。

内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

优点

• 良好的功能延伸性（extensibility），需要什么功能，开发一个插件即可
• 功能之间是隔离的，插件可以独立的加载和卸载，使得它比较容易部署，
• 可定制性高，适应不同的开发需要
• 可以渐进式地开发，逐步增加功能

缺点

• 扩展性（scalability）差，内核通常是一个独立单元，不容易做成分布式
• 开发难度相对较高，因为涉及到插件与内核的通信，以及内部的插件登记机制

微服务架构

微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。

每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如 REST、SOAP）联系。

微服务架构分成三种实现模式。

• RESTful API 模式：服务通过 API 提供，云服务就属于这一类
• RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部
• 集中消息模式：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群

优点

• 扩展性好，各个服务之间低耦合
• 容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元
• 容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级
• 易于测试，可以单独测试每一个服务

缺点

• 由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳。
• 一旦服务之间需要通信（即一个服务要用到另一个服务），整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性。
• 分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。

云架构

云结构（cloud architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。

它的高扩展性，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元；访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，最好要进行数据持久化。

这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。

• 处理单元：实现业务逻辑
• 虚拟中间件：负责通信、保持 sessions、数据复制、分布式处理、处理单元的部署。

虚拟中间件又包含四个组件。

• 消息中间件（Messaging Grid）：管理用户请求和 session，当一个请求进来以后，决定分配给哪一个处理单元。
• 数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
• 处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元
• 部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。

优点

• 高负载，高扩展性
• 动态部署

缺点

• 实现复杂，成本较高
• 主要适合网站类应用，不合适大量数据吞吐的大型数据库应用
• 较难测试

参考资料

• 《大型网站技术架构：核心原理与案例分析》
• 《从 0 开始学架构》
• 软件架构入门- 阮一峰的网络日志

系统高性能架构

性能简介

要设计高性能的系统架构，应该有以下的思维步骤：

首先，要明确影响性能的因素有哪些？性能的指标有哪些？——做到有的放矢。

其次，要了解如何测试性能指标？性能优化，必须要有前后的效果对比，才能证明性能确实有改善。

接下来，学习针对不同场景下，不同性指标的优化策略以及具体实施方案。——见招拆招。

计算机资源

了解性能指标前，需要先知道哪些计算机资源会影响性能。一般来说，影响性能的计算机资源包括：

• CPU
• 内存
• 磁盘 I/O
• 网络 I/O
• 数据库
• 锁竞争

性能指标

性能测试的主要指标有：

• 响应时间
• 并发数
• 吞吐量
  • QPS
  • TPS
• 资源分配使用率

响应时间

响应时间(RT)是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。

响应时间越短，性能越好，一般一个接口的响应时间是在毫秒级。

响应时间可以进一步细分：

• 客户端响应时间
• 网络响应时间
• 服务端响应时间
• 数据库响应时间

并发数

并发数是指系统能同时处理的请求、事务数。

系统自身的 CPU 处理能力、内存、以及系统自身的线程复用、锁竞争等都会影响并发数。

吞吐量

吞吐量计算公式：

1

吞吐量 = 并发数 / 平均响应时间

吞吐量越大，性能越好。

一般，系统呈现给外部的最常见的吞吐量指标，就是：

• QPS(每秒查询数) - 即系统每秒可以处理的读请求。
• TPS(每秒事务数) - 即系统每秒可以处理的写请求。

而在系统内部，存在以下吞吐量：

• 磁盘吞吐量 - 体现了磁盘随机读写的性能。
• 网络吞吐量 - 除了受限于网络带宽，CPU 的处理能力、网卡、防火墙、外部接口以及 I/O、系统 IO 算法都会影响到网络吞吐量。

资源分配使用率

通常由 CPU 占用率、内存使用率、磁盘 I/O、网络 I/O 、对象与线程数来表示资源使用率。这些指标也是系统监控的重要参数。

性能测试

性能测试手段：

• 性能测试
• 负载测试
• 压力测试
• 稳定性测试

对于 Java 应用而言，最简单的，可以使用 Jmeter 进行性能测试。

性能测试报告示例：

性能测试时，需要注意一些问题：

• 热身问题 - 系统刚开始运行时，自身可能加载缓存，JVM 可能会优化热点代码等，这些行为都可能使得前后有较大的性能差异。所以，性能测试时，应该先跳过一段热身时间，等趋于稳定后，再开始性能测试。
• 测试结果不稳定 - 性能测试中，有很多不稳定的因素，如环境、网络等，几乎不可能每次都是一样的结果。所以应该多次测试，求平均值。
• 多 JVM 情况下的影响 - 应尽量避免一台机器部署多个 JVM 的情况。因为任意一个 JVM 都拥有整个系统的资源使用权，所以在性能测试时，可能会彼此干扰。

性能优化策略

1. 性能分析 - 如果请求响应慢，存在性能问题。需要对请求经历的各个环节逐一分析，排查可能出现性能瓶颈的地方，定位问题。检查监控数据，分析影响性能的主要因素：内存、磁盘、网络、CPU，可能是代码或架构设计不合理，又或者是系统资源确实不足。
2. 性能优化 - 性能优化根据网站分层架构，大致可分为前端性能优化、应用服务性能优化、存储服务性能优化。

应用服务性能优化

缓存

网站性能优化第一定律：第一优先考虑使用缓存提升性能。

缓存是用于存储数据的硬件或软件的组成部分，以使得后续更快访问相应的数据。缓存中的数据可能是提前计算好的结果、数据的副本等。

• 单点应用可以使用进程内缓存（如：ConcurrentHashMap、Caffeine）；
• 分布式应用可以使用分布式缓存（如：Redis、Memcached），或进程缓存+分布式缓存的多级缓存方案。

缓存解决方案请参考：缓存基本原理

并发模型

高并发需要根据两个条件划分：连接数量，请求数量。

• 海量连接（成千上万）海量请求：例如抢购，双十一等
• 常量连接（几十上百）海量请求：例如中间件
• 海量连接常量请求：例如门户网站
• 常量连接常量请求：例如内部运营系统，管理系统

单服务器高性能的关键之一就是服务器采取的并发模型

• 服务器如何管理连接。
• 服务器如何处理请求。

以上两个设计点最终都和操作系统的 I/O 模型及进程模型相关。

• I/O 模型：阻塞、非阻塞、同步、异步。
• 进程模型：单进程、多进程、多线程。

PPC

PPC 是 Process Per Connection 的缩写，其含义是指每次有新的连接就新建一个进程去专门处理这个连接的请求，这是传统的 UNIX 网络服务器所采用的模型。基本的流程图是：

• 父进程接受连接（图中 accept）。
• 父进程“fork”子进程（图中 fork）。
• 子进程处理连接的读写请求（图中子进程 read、业务处理、write）。
• 子进程关闭连接（图中子进程中的 close）。

这种模式的缺点：

• fork 代价高
• 父子进程通信复杂
• 支持的并发连接数量有限

prefork

PPC 模式中，当连接进来时才 fork 新进程来处理连接请求，由于 fork 进程代价高，用户访问时可能感觉比较慢，prefork 模式的出现就是为了解决这个问题。

顾名思义，prefork 就是提前创建进程（pre-fork）。系统在启动的时候就预先创建好进程，然后才开始接受用户的请求，当有新的连接进来的时候，就可以省去 fork 进程的操作，让用户访问更快、体验更好。prefork 的基本示意图是：

prefork 的实现关键就是多个子进程都 accept 同一个 socket，当有新的连接进入时，操作系统保证只有一个进程能最后 accept 成功。但这里也存在一个小小的问题：“惊群”现象，就是指虽然只有一个子进程能 accept 成功，但所有阻塞在 accept 上的子进程都会被唤醒，这样就导致了不必要的进程调度和上下文切换了。幸运的是，操作系统可以解决这个问题，例如 Linux 2.6 版本后内核已经解决了 accept 惊群问题。

prefork 模式和 PPC 一样，还是存在父子进程通信复杂、支持的并发连接数量有限的问题，因此目前实际应用也不多。Apache 服务器提供了 MPM prefork 模式，推荐在需要可靠性或者与旧软件兼容的站点时采用这种模式，默认情况下最大支持 256 个并发连接。

TPC

TPC 是 Thread Per Connection 的缩写，其含义是指每次有新的连接就新建一个线程去专门处理这个连接的请求。与进程相比，线程更轻量级，创建线程的消耗比进程要少得多；同时多线程是共享进程内存空间的，线程通信相比进程通信更简单。因此，TPC 实际上是解决或者弱化了 PPC fork 代价高的问题和父子进程通信复杂的问题。

TPC 的基本流程是：

• 父进程接受连接（图中 accept）。
• 父进程创建子线程（图中 pthread）。
• 子线程处理连接的读写请求（图中子线程 read、业务处理、write）。
• 子线程关闭连接（图中子线程中的 close）。

注意，和 PPC 相比，主进程不用“close”连接了。原因是在于子线程是共享主进程的进程空间的，连接的文件描述符并没有被复制，因此只需要一次 close 即可。

TPC 虽然解决了 fork 代价高和进程通信复杂的问题，但是也引入了新的问题，具体表现在：

• 创建线程虽然比创建进程代价低，但并不是没有代价，高并发时（例如每秒上万连接）还是有性能问题。
• 无须进程间通信，但是线程间的互斥和共享又引入了复杂度，可能一不小心就导致了死锁问题。
• 多线程会出现互相影响的情况，某个线程出现异常时，可能导致整个进程退出（例如内存越界）。

除了引入了新的问题，TPC 还是存在 CPU 线程调度和切换代价的问题。因此，TPC 方案本质上和 PPC 方案基本类似，在并发几百连接的场景下，反而更多地是采用 PPC 的方案，因为 PPC 方案不会有死锁的风险，也不会多进程互相影响，稳定性更高。

prethread

TPC 模式中，当连接进来时才创建新的线程来处理连接请求，虽然创建线程比创建进程要更加轻量级，但还是有一定的代价，而 prethread 模式就是为了解决这个问题。

和 prefork 类似，prethread 模式会预先创建线程，然后才开始接受用户的请求，当有新的连接进来的时候，就可以省去创建线程的操作，让用户感觉更快、体验更好。

由于多线程之间数据共享和通信比较方便，因此实际上 prethread 的实现方式相比 prefork 要灵活一些，常见的实现方式有下面几种：

• 主进程 accept，然后将连接交给某个线程处理。
• 子线程都尝试去 accept，最终只有一个线程 accept 成功，方案的基本示意图如下：

Apache 服务器的 MPM worker 模式本质上就是一种 prethread 方案，但稍微做了改进。Apache 服务器会首先创建多个进程，每个进程里面再创建多个线程，这样做主要是为了考虑稳定性，即：即使某个子进程里面的某个线程异常导致整个子进程退出，还会有其他子进程继续提供服务，不会导致整个服务器全部挂掉。

prethread 理论上可以比 prefork 支持更多的并发连接，Apache 服务器 MPM worker 模式默认支持 16 × 25 = 400 个并发处理线程。

Reactor

I/O 多路复用技术归纳起来有两个关键实现点：

• 当多条连接共用一个阻塞对象后，进程只需要在一个阻塞对象上等待，而无须再轮询所有连接，常见的实现方式有 select、epoll、kqueue 等。
• 当某条连接有新的数据可以处理时，操作系统会通知进程，进程从阻塞状态返回，开始进行业务处理。

I/O 多路复用结合线程池，完美地解决了 PPC 和 TPC 的问题

Reactor 模式的核心组成部分包括 Reactor 和处理资源池（进程池或线程池），其中 Reactor 负责监听和分配事件，处理资源池负责处理事件。初看 Reactor 的实现是比较简单的，但实际上结合不同的业务场景，Reactor 模式的具体实现方案灵活多变，主要体现在：

• Reactor 的数量可以变化：可以是一个 Reactor，也可以是多个 Reactor。
• 资源池的数量可以变化：以进程为例，可以是单个进程，也可以是多个进程（线程类似）。

最终 Reactor 模式有这三种典型的实现方案：

• 单 Reactor 单进程 / 线程。
• 单 Reactor 多线程。
• 多 Reactor 多进程 / 线程。

异步操作

异步处理不仅可以减少系统服务间的耦合度，提高扩展性，事实上，它还可以提高系统的性能。异步处理可以有效减少响应等待时间，从而提高响应速度。

异步处理一般是通过分布式消息队列的方式。

异步处理可以解决以下问题：

• 异步响应
• 应用解耦
• 流量削锋
• 日志处理
• 消息通讯

负载均衡

在高并发场景下，使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群，将并发访问请求分发到多台服务器上处理，避免单一服务器因负载压力过大而响应缓慢，使用户请求具有更好的响应延迟特性。

高性能集群的复杂性主要体现在需要增加一个任务分配器，以及为任务选择一个合适的任务分配算法。

缓存解决方案请参考：负载均衡

代码优化

多线程

从资源利用的角度看，使用多线程的原因主要有两个：IO 阻塞和多 CPU。

线程数并非越多越好，那么启动多少线程合适呢？

有个参考公式：

1

启动线程数 = (任务执行时间 / (任务执行时间 - IO 等待时间)) * CPU 内核数

最佳启动线程数和 CPU 内核数成正比，和 IO 阻塞时间成反比。

• 如果任务都是 CPU 计算型任务，那么线程数最多不要超过 CPU 内核数，因为启动再多线程，CPU 也来不及调度；
• 相反，如果是任务需要等待磁盘操作，网络响应，那么多启动线程有助于任务并发，提高系统吞吐量。

线程安全问题

线程安全问题时指多个线程并发访问某个资源，导致数据混乱。

解决手段有：

• 将对象设计为无状态对象 - 典型应用：Servlet 就是无状态对象，可以被服务器多线程并发调用处理用户请求。
• 使用局部对象
• 并发访问资源时使用锁 - 但是引入锁会产生性能开销，应尽量使用轻量级的锁。

资源复用

应该尽量减少那些开销很大的系统资源的创建和销毁，如数据库连接、网络通信连接、线程、复杂对象等。从编程角度，资源复用主要有两种模式：单例模式和对象池。

数据结构

根据具体场景，选择合适的数据结构。

垃圾回收

如果 Web 应用运行在 JVM 等具有垃圾回收功能的环境中，那么垃圾回收可能会对系统的性能特性产生巨大影响。立即垃圾回收机制有助于程序优化和参数调优，以及编写内存安全的代码。

存储性能优化

数据库

数据库读写分离

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

详细解决方案参考：读写分离

数据库分库分表

数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。

详细解决方案参考：分库分表

Nosql

关系型数据库的优势在于：存储结构化数据，有利于进行各种复杂查询。

但是，它也存在一些缺点：

• 关系数据库存储的是行记录，无法存储数据结构
• 关系数据库的 schema 扩展很不方便
• 关系数据库在大数据场景下 I/O 较高
• 关系数据库的全文搜索功能比较弱

为了解决上述问题，分别诞生了解决不同问题的 Nosql 数据库。

常见的 NoSQL 数据库可以分为四类：

• K-V 数据库：KV 存储非常适合存储不涉及过多数据关系业务关系的数据，同时能有效减少读写磁盘的次数，比 SQL 数据库存储拥有更好的读写性能，能够解决关系型数据库无法存储数据结构的问题。以 Redis 为代表。
• 列式数据库：适合于批量数据处理和即时查询，解决关系数据库大数据场景下的 I/O 问题。以 HBase 为代表。
• 文档数据库：文档数据库（也称为文档型数据库）是旨在将半结构化数据存储为文档的一种数据库，它可以解决关系型数据库表结构 schema 扩展不方便的问题。文档数据库通常以 JSON 或 XML 格式存储数据。以 MongoDB 为代表。
• 全文搜索引擎：解决关系型数据库全文搜索功能较弱的问题。以 Elasticsearch 为代表。

详情参考：Nosql 技术选型

文件存储

机械键盘和固态硬盘

考虑使用固态硬盘替代机械键盘，因为它的读写速度更快。

B+数和 LSM 树

传统关系数据库的数据库索引一般都使用两级索引的 B+ 树 结构，树的层次最多三层。因此可能需要 5 次磁盘访问才能更新一条记录（三次磁盘访问获得数据索引及行 ID，然后再进行一次数据文件读操作及一次数据文件写操作）。

由于磁盘访问是随机的，传统机械键盘在数据随机访问时性能较差，每次数据访问都需要多次访问磁盘影响数据访问性能。

许多 Nosql 数据库中的索引采用 LSM 树 作为主要数据结构。LSM 树可视为一个 N 阶合并树。数据写操作都在内存中进行。在 LSM 树上进行一次数据更新不需要磁盘访问，速度远快于 B+ 树。

RAID 和 HDFS

RAID 是 Redundant Array of Independent Disks 的缩写，中文简称为独立冗余磁盘阵列。

RAID 是一种把多块独立的硬盘（物理硬盘）按不同的方式组合起来形成一个硬盘组（逻辑硬盘），从而提供比单个硬盘更高的存储性能和提供数据备份技术。

HDFS(分布式文件系统) 更被大型网站所青睐。它可以配合 MapReduce 并发计算任务框架进行大数据处理，可以在整个集群上并发访问所有磁盘，无需 RAID 支持。

HDFS 对数据存储空间的管理以数据块（Block）为单位，默认为 64 MB。所以，HDFS 更适合存储较大的文件。

前端性能优化

浏览器访问优化

1. 减少 HTTP 请求 - HTTP 请求需要建立通信链路，进行数据传输，开销高昂，所以减少 HTTP 请求数可以有效提高访问性能。减少 HTTP 的主要手段是合并 Css、JavaScript、图片。
2. 使用浏览器缓存 - 因为静态资源文件更新频率低，可以缓存浏览器中以提高性能。设置 HTTP 头中的 Cache-Control 和 Expires 属性，可设定浏览器缓存。
3. 启用压缩 - 在服务器端压缩静态资源文件，在浏览器端解压缩，可以有效减少传输的数据量。由于文本文件压缩率可达 80% 以上，所以可以对静态资源，如 Html、Css、JavaScrip 进行压缩。
4. CSS 放在页面最上面，JavaScript 放在页面最下面 - 浏览器会在下载完全部的 Css 后才对整个页面进行渲染，所以最好的做法是将 Css 放在页面最上面，让浏览器尽快下载 Css；JavaScript 则相反，浏览器加载 JavaScript 后立即执行，可能会阻塞整个页面，造成页面显示缓慢，因此 JavaScript 最好放在页面最下面。
5. 减少 Cookie 传输 - Cookie 包含在 HTTP 每次的请求和响应中，太大的 Cookie 会严重影响数据传输。

CDN

CDN 一般缓存的是静态资源。

CDN 的本质仍然是一个缓存，而且将数据缓存在离用户最近的地方，使用户已最快速度获取数据，即所谓网络访问第一跳。

反向代理

传统代理服务器位于浏览器一侧，代理浏览器将 HTTP 请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站服务器接收 HTTP 请求。

反向代理服务器可以配置缓存功能加速 Web 请求，当用户第一次访问静态内容时，静态内容就会被缓存在反向代理服务器上。

反向代理还可以实现负载均衡，通过负载均衡构建的集群可以提高系统总体处理能力。

因为所有请求都必须先经过反向代理服务器，所以可以屏蔽一些攻击 IP，达到保护网站安全的作用。

参考资料

• 《大型网站技术架构：核心原理与案例分析》
• 极客时间教程 - Java 性能调优实战

系统伸缩性架构

伸缩性架构是指不需要改变系统的软硬件设计，仅通过改变部署服务器数量就可以扩大或缩小系统的服务处理能力。

系统架构的伸缩性设计

不同功能进行物理分离实现伸缩

• 纵向分离（分层后分离） - 将业务处理流程上的不同部分分离部署，实现系统伸缩性。
• 横向分离（业务分割后分离） - 将不同的业务模块分离部署，实现系统伸缩性。

单一功能通过集群规模实现伸缩

将不同功能分离部署可以实现一定程度的伸缩性，但是随着访问量逐步增加，即使分离到最小粒度的独立部署，单一的服务器也不能满足业务规模的要求。因此必须使用服务器集群，即将相同服务部署在多态服务器上构成一个集群整体对外提供服务。

应用服务器集群的伸缩性设计

如果 HTTP 请求分发装置可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求，那么就实现了应用服务器集群的伸缩性。

HTTP 重定向负载均衡

利用 HTTP 重定向协议实现负载均衡。

这种负载均衡方案的优点是比较简单。

缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差：重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用 HTTP 302 响应码重定向，可能使搜索引擎判断为 SEO 作弊，降低搜索排名。

DNS 域名解析负载均衡

利用 DNS 处理域名解析请求的同时进行负载均衡处理的一种方案。

在 DNS 服务器中配置多个 A 记录，如：

1
2
3

114.100.40.1 www.mysite.com
114.100.40.2 www.mysite.com
114.100.40.3 www.mysite.com

每次域名解析请求都会根据负载均衡算法计算一个不同的 IP 地址返回，这样 A 记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。

DNS 域名解析负载均衡的优点：

• 将负载均衡的工作转交给了 DNS，省掉了网站管理维护的麻烦。
• 同时，许多 DNS 服务器还支持基于地理位置的域名解析，即将域名解析成距离用户地理最近的一个服务器地址，这样可以加快用户访问速度，改善性能。

DNS 域名解析负载均衡的缺点：

• DNS 是多级解析，每一级 DNS 都可能缓存 A 记录，当某台服务器下线后，即使修改了 DNS 的 A 记录，要使其生效也需要较长时间。这段时间，依然会域名解析到已经下线的服务器，导致用户访问失败。
• DNS 的负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。

反向代理负载均衡

大多数反向代理服务器同时提供反向代理和负载均衡的功能。

反向代理服务器的优点是部署简单。缺点是反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。

IP 负载均衡

在网络层通过修改请求目标地址进行负载均衡。

负载均衡服务器（网关服务器）在操作系统内核获取网络数据包，根据负载均衡算法计算得到一台真实 Web 服务器 10.0.0.1，然后将目的 IP 地址修改为 10.0.0.1，不需要通过用户进程。真实 Web 服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器再将数据包原地址修改为自身的 IP 地址（114.100.80.10）发送给浏览器。

IP 负载均衡在内核完成数据分发，所以处理性能优于反向代理负载均衡。但是因为所有请求响应都要经过负载均衡服务器，集群的最大响应数据吞吐量受制于负载均衡服务器网卡带宽。

数据链路层负载均衡

数据链路层负载均衡是指在通信协议的数据链路层修改 mac 地址进行负载均衡。

这种方式又称作三角传输方式，负载均衡数据分发过程中不修改 IP 地址，只修改目的 mac 地址，通过配置真实物理服务器集群所有机器虚拟 IP 和负载均衡服务器 IP 地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实物理服务器 IP 和数据请求目的 IP 一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。这种负载方式又称作直接路由方式。

在 Linux 平台上最好的链路层负载均衡开源产品是 **LVS(Linux Virtual Server)**。

负载均衡算法

负载均衡服务器的实现可以分为两个部分：

1. 根据负载均衡算法和 Web 服务器列表计算得到集群中一台 Web 服务器的地址。
2. 将请求数据发送到该地址对应的 Web 服务器上。

负载均衡算法通常有以下几种：

• 轮询（Round Robin） - 所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数据都相同，适合于所有服务器硬件都相同的场景。
• 加权轮询（Weighted Round Robin） - 根据服务器硬件性能情况，在轮询的基础上，按照配置权重将请求分发到每个服务器，高性能服务器能分配更多请求。
• 随机（Random） - 请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很平均，即使应用服务器硬件配置不同，也可以使用加权随机算法。
• 最少连接（Least Connection） - 记录每个应用服务器正在处理的连接数，将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。
• 源地址 Hash（Source Hash） - 根据请求来源的 IP 地址进行 Hash 计算，得到应用服务器，这样来自同一个 IP 地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，从而实现会话粘滞。

分布式缓存集群的伸缩性设计

目前比较流行的分布式集群伸缩性方案就是：一致性 HASH 算法

数据存储服务集群的伸缩性设计

关系型数据库的伸缩性设计

• 主从复制 - 主流关系型数据库一般都支持主从复制。
• 分库 - 根据业务对数据库进行分割。制约条件是跨库的表不能进行 Join 操作。
• 分表 - 使用数据库分片中间件，如 Cobar 等。

NoSql 数据库的伸缩性设计

一般而言，Nosql 不支持 SQL 和 ACID，但是强化了对于高可用和伸缩性的支持。

参考资料

• 《大型网站技术架构：核心原理与案例分析》

系统高可用架构

高可用架构简介

系统可用性的度量

系统不可用也被称作系统故障，业界通常用多个 9 来衡量系统的可用性。如 QQ 的可用性为 4 个 9，即 99.99% 可用。

1
2

网站不可用时间 = 故障修复时间点 - 故障发现时间点
网站年度可用性指标 = (1 - 网站不可用时间/年度总时间) * 100%

可用性计量表：

故障原因

系统宕机原因主要有以下：

无计划的

• 系统级故障，包括主机、操作系统、中间件、数据库、网络、电源以及外围设备。
• 数据和中介的故障，包括人员误操作、硬盘故障、数据乱了。
• 还有自然灾害、人为破坏，以及供电问题等。

有计划的

• 日常任务：备份，容量规划，用户和安全管理，后台批处理应用。
• 运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护。
• 升级相关：数据库、应用、中间件、操作系统、网络，包括硬件升级。

我们再给它们归个类。

1. 网络问题。网络链接出现问题，网络带宽出现拥塞……
2. 性能问题。数据库慢 SQL、Java Full GC、硬盘 IO 过大、CPU 飙高、内存不足……
3. 安全问题。被网络攻击，如 DDoS 等。
4. 运维问题。系统总是在被更新和修改，架构也在不断地被调整，监控问题……
5. 管理问题。没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步……
6. 硬件问题。硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题……

什么是高可用的系统架构

通常，企业级应用系统为提高系统可用性，会采用较昂贵的软硬件设备，当然这样的设备也比较稳定。

互联网公司或一些初创型公司基于成本考虑，更多采用 PC 级软硬件设备，节约成本所付出的代价就是设备较为不稳定。服务器一年中出现几次宕机，高强度读写磁盘导致磁盘损坏等事件实属正常。

综上，硬件出现故障应视为必然的，而高可用的系统架构设计目标就是要保证当出现硬件故障时，服务依然可用，数据依然能够保存并被访问。实现高可用的系统架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上；如果磁盘损坏，则从备份的磁盘读取数据。

大型系统的分层架构及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点。关闭服务或服务器宕机时产生的影响也不相同，高可用的解决方案也差异甚大。大致可以分为：

• 高可用的应用 - 主要手段是：负载均衡
• 高可用的服务 - 主要手段是：分级管理、超时重试、异步调用、限流、降解、断路、幂等性设计
• 高可用的数据 - 主要手段是：数据备份和失效转移

高可用架构理论

学习高可用架构，首先需要了解分布式基础理论：CAP 和 BASE。

然后，很多著名的分布式系统，都利用选举机制，来保证主节点宕机时的故障恢复。如果要深入理解选举机制，有必要了解：Paxos 算法 和 Raft 算法。Paxos 和 Raft 是为了实现分布式系统中高可用架构而提出的共识性算法，已经成为业界标准。

CAP 定理又称为 CAP 原则，指的是：在一个分布式系统中， 一致性（C：Consistency）、可用性（A：Availability） 和 分区容忍性（P：Partition Tolerance），最多只能同时满足其中两项。

BASE 是 基本可用（Basically Available）、软状态（Soft State） 和 最终一致性（Eventually Consistent） 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

CAP 和 BASE 理论的详细说明请参考：分布式一致性

Paxos 和 Raft 的详细说明请参考：Paxos 算法 和 Raft 算法

架构模式

主备复制

主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能，例如 MySQL、Redis、MongoDB 等。

主备复制要点：

• 存在一主多备。
• 主机负责读&写，并定期复制数据给备机。
• 一旦主机宕机，可以通过人工手段，将其中一个备节点作为主节点。

优点

• 主备复制架构中，客户端可以不感知备机的存在。即使灾难恢复后，原来的备机被人工修改为主机后，对于客户端来说，只是认为主机的地址换了而已，无须知道是原来的备机升级为主机。
• 主备复制架构中，主机和备机之间，只需要进行数据复制即可，无须进行状态判断和主备切换这类复杂的操作。

缺点

• 主备复制架构中，故障后需要人工干预，无法自动恢复。

适用场景

综合主备复制架构的优缺点，内部的后台管理系统使用主备复制架构的情况会比较多，例如学生管理系统、员工管理系统、假期管理系统等，因为这类系统的数据变更频率低，即使在某些场景下丢失数据，也可以通过人工的方式补全。

主从复制

主从复制和主备复制只有一字之差，区别在于：主从复制模式中，从机要承担读操作。

主从复制要点：

• 存在一主多从。
• 主机负责读&写，并定期复制数据给从机。
• 从机只负责读。
• 一旦主机宕机，可以通过人工手段，将其中一个从节点作为主节点。

优点

• 主从复制架构中，主机故障时，读操作相关的业务可以继续运行。
• 主从复制架构中，从机提供读操作，发挥了硬件的性能。

缺点

• 主从复制架构中，客户端需要感知主从关系，并将不同的操作发给不同的机器进行处理，复杂度比主备复制要高。
• 主从复制架构中，从机提供读业务，如果主从复制延迟比较大，业务会因为数据不一致出现问题。
• 主从复制架构中，故障时需要人工干预。

适用场景

综合主从复制的优缺点，一般情况下，写少读多的业务使用主从复制的存储架构比较多。例如，论坛、BBS、新闻网站这类业务，此类业务的读操作数量是写操作数量的 10 倍甚至 100 倍以上。

集群+分区

在主备复制和主从复制模式中，都由一个共性问题：

每个机器上存储的都是全量数据。但是，单机的数据存储量总是有上限的，当数据量上升为 TB 级甚至 PB 级数据，单机终究有无法支撑的时候。这时，就需要对数据进行分片（sharding）。

分片后的节点可以视为一个独立的子集，针对子集，任然需要保证高可用。

高可用的应用

应用层主要处理网站应用的业务逻辑，一个显著的特点是应用的 无状态 性。

所谓的 无状态 的应用是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。

由于无状态应用，各实例之间不用考虑数据一致性问题，所以其高可用方案相对简单。主要手段是：

• 负载均衡
• 分布式 Session

负载均衡

负载均衡，顾名思义，主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上，以提高整体的负载处理能力。

无状态应用的失效转移可以利用负载均衡来实现。

无状态的应用实现高可用架构十分简单，由于服务器不保存请求状态，那么所有服务器完全对等，在任意节点执行同样的请求，结果总是一致的。这种情况下，最简单的高可用方案就是使用负载均衡。

负载均衡原理可以参考：负载均衡基本原理

分布式 Session

应用服务器的高可用架构设计主要基于服务无状态这一特性。事实上，业务总是有状态的，如购物车记录用户的购买信息；用户的登录状态；最新发布的消息等等。

在分布式场景下，一个用户的 Session 如果只存储在一个服务器上，那么当负载均衡器把用户的下一个请求转发到另一个服务器上，该服务器没有用户的 Session，就可能导致用户需要重新进行登录等操作。

为了解决分布式 Session 问题，常见的解决方案有：

• 粘性 session
• 应用服务器间的 session 复制共享
• 基于缓存的 session 共享 ✅

分布式会话原理可以参考：分布式会话基本原理

高可用的服务

可复用的服务为业务产品提供基础公共服务，大型系统中这些服务通常都独立分布式部署，被具体应用远程调用。可复用的服务和应用一样，一般也是无状态的服务，因此，同样可以使用负载均衡的失效转移策略来实现高可用。

除此以外，还有以下手段来保证服务的高可用：

• 分级管理
• 超时重试
• 异步调用
• 过载保护
  • 限流
  • 降级
  • 断路
• 幂等性设计

分级管理

将服务根据业务重要性进行分级管理，核心应用和服务优先使用更好的硬件，在运维响应速度上也格外迅速。

在服务部署上进行必要的隔离，避免故障的连锁反应。低优先级的服务通过启动不同的线程或部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至要部署在不同地域的数据中心。

超时重试

由于服务器宕机、线程死锁等原因，可能导致应用程序对服务端的调用失去响应。所以有必要引入超时机制，一旦调用超时，服务化框架抛出异常，应用程序根据服务调度策略，选择重试或请求转移到其他机器上。

异步调用

对于需要即时响应的业务，应用在调用服务时可以通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。当然不是所有服务调用都可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失；此外，对于那些必须确认服务调用才能继续下一步操作的应用也不适宜食用异步调用。

过载保护

过载保护的手段，一般有：限流、降级、熔断。

限流

降级是从系统功能优先级的角度考虑如何应对故障，而限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。

常见的限流方式可以分为两类：基于请求限流和基于资源限流。

基于请求限流

基于请求限流指从外部访问的请求角度考虑限流，常见的方式有：限制总量、限制时间量。

限制总量的方式是限制某个指标的累积上限，常见的是限制当前系统服务的用户总量，例如某个直播间限制总用户数上限为 100 万，超过 100 万后新的用户无法进入；某个抢购活动商品数量只有 100 个，限制参与抢购的用户上限为 1 万个，1 万以后的用户直接拒绝。限制时间量指限制一段时间内某个指标的上限，例如，1 分钟内只允许 10000 个用户访问，每秒请求峰值最高为 10 万。

无论是限制总量还是限制时间量，共同的特点都是实现简单，但在实践中面临的主要问题是比较难以找到合适的阈值。

基于资源限流

基于请求限流是从系统外部考虑的，而基于资源限流是从系统内部考虑的，即：找到系统内部影响性能的关键资源，对其使用上限进行限制。常见的内部资源有：连接数、文件句柄、线程数、请求队列等。

基于资源限流相比基于请求限流能够更加有效地反映当前系统的压力，但实践中设计也面临两个主要的难点：如何确定关键资源，如何确定关键资源的阈值。

降级

降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。

在服务访问的高峰期，服务可能因为大量并发调用而性能下降，严重时可能会导致宕机。为了保证核心功能的正常运行，需要对服务进行降级。降级有两种手段：

拒绝服务 - 拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用。或者随机拒绝部分调用，节约资源，避免要死大家一起死的惨剧。

关闭服务 - 关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约资源。

熔断

熔断和降级是两个比较容易混淆的概念，因为单纯从名字上看好像都有禁止某个功能的意思，但其实内在含义是不同的，原因在于降级的目的是应对系统自身的故障，而熔断的目的是应对依赖的外部系统故障的情况。

熔断机制实现的关键是需要有一个统一的 API 调用层，由 API 调用层来进行采样或者统计，如果接口调用散落在代码各处就没法进行统一处理了。

幂等性设计

服务调用失败后，调用方会将请求转发到其他服务器上，但是这个失败可能是虚假的失败。比如服务已经处理成功，但因为网络故障导致调用方没有收到应答，或等待超时。这种情况下，重新发起请求，可能会导致重复操作，如：向数据库写入两条记录。如果这个操作是比较敏感的交易操作，就会产生严重后果。

服务重复调用时无法避免的，但是只要能从业务实现上保证，重复调用和一次调用的处理结果一致，则业务就没有问题，这就是幂等性设计。

有些服务的业务天然具有幂等性，比如将用户性别设为男性，不管执行多少次，结果是一致的。但有些复杂的业务，要想保证幂等性，就需要根据全局性的 ID 去进行有效性验证，验证通过才能继续执行。

高可用的存储

对于绝大部分软件系统而言，数据都是最宝贵的虚拟资产，一旦丢失，可以说是毁灭性的打击。

保证存储高可用的主要手段是：数据备份和失效转移。

存储高可用架构的复杂性主要体现在：如何应对副本同步延迟和中断导致的数据一致性问题。

提示：再开始学习这部分内容前，建议先学习 二、高可用架构理论

数据备份

数据备份是保证数据有多个副本，任意副本的丢失都不会导致数据的永久丢失。

• 冷备份 - 定期将数据复制到某种存储介质。
• 热备份
  • 异步热备方式 - 异步热备方式是指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本。
  • 同步热备方式 - 同步热备方式是指多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操作成功。但是当应用程序收到数据写操作失败的响应式，可能有部分副本或者全部副本都已经写入成功了（因为网络或者系统故障，无法返回操作成功的响应）。

失效转移

失效转移是保证任意一个副本不可访问时，可以快速切换访问其他副本，保证系统整体可用。

失效确认

判断服务器宕机的手段有两种：心跳检测和访问失败报告。

对于应用程序的访问失败报告，控制中心还需要再一次发送心跳检测进行确认，以免错误判断服务器宕机。因为一旦进行数据访问的失效转移，意味着数据存储多份副本不一致，需要进行后续一系列的复杂动作。

访问转移

确认某台数据服务器宕机后，就需要将数据读写访问重新路由到其他服务器上。对于完全对等存储的服务器，当其中一台宕机后，应用程序根据配置直接切换到对等服务器上。如果存储不对等，就需要重新计算路由，选择存储服务器。

数据恢复

因为某台服务器宕机，所以数据存储的副本数目会减少，必须将副本的数目恢复到系统设定的值，否则，再有服务器宕机时，就可能出现无法访问转移，数据永久丢失的情况。因此系统需要从健康的服务器复制数据，将数据副本数目恢复到设定值。

辅助手段

异地多活

异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动、活跃的意思。

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

异地多活架构的代价：

• 系统复杂度会发生质的变化，需要设计复杂的异地多活架构。
• 成本会上升，毕竟要多在一个或者多个机房搭建独立的一套业务系统。

异地多活的设计原则：

• 保证核心业务的异地多活
• 保证核心数据最终一致性
• 采用多种手段同步数据
• 只保证绝大部分用户的异地多活

异地多活设计步骤：

• 业务分级 - 常见的分级标准有：
  • 流量大的业务
  • 核心业务
  • 盈利业务
• 数据分类 - 常见的数据分析维度有：
  • 数据量
  • 唯一性
  • 实时性
  • 可丢实性
  • 可恢复性
• 数据同步 - 常见的数据同步方案
  • 存储系统同步
  • 消息队列同步
  • 重复生成
• 异常处理 - 常见异常处理措施：
  • 多通道同步
  • 同步和访问结合
  • 日志记录
  • 用户补偿

发布流程

高可用的软件质量保证的手段：

• 自动化测试
• 预发布验证
• 代码控制
• 自动化发布
• 灰度发布

系统监控

不允许没有监控的系统上线。

• 监控数据采集
  • 用户行为日志收集
    • 服务端日志收集 - Apache、Nginx 等几乎所有 Web 服务器都具备日志记录功能，只要开启日志记录即可。如果是服务器比较多，需要集中采集日志，通常会使用 Elastic 来进行收集。
    • 客户端日志收集 - 利用页面嵌入专门的 JavaScript 脚本可以收集用户真实的操作行为。
    • 日志分析 - 可以利用 ElasticSearch 做语义分析及搜索；利用实时计算框架 Storm、Flink 等开发日志统计与分析工具。
  • 服务器性能监控 - 收集服务器性能指标，如系统负载、内存占用、CPU 占用、磁盘 IO、网络 IO 等。常用的监控工具有：Apache SkyWalking 、Pinpoint 等。
  • 运行数据报告 - 应该监控一些与具体业务场景相关的技术和业务指标，如：缓存命中率、平均响应时延、TPS、QPS 等。
• 监控管理
  • 系统报警 - 设置阈值。当达到阈值，及时触发告警（短信、邮件、通信工具均可），通过及时判断状况，防患于未然。
  • 失效转移 - 监控系统可以在发现故障的情况下主动通知应用进行失效转移。
  • 自动优雅降级
    • 优雅降级是为了应付突然爆发的访问高峰，主动关闭部分功能，释放部分资源，以保证核心功能的优先访问。
    • 系统在监控管理基础之上实现自动优雅降级，是柔性架构的理想状态。

参考资料

• 《大型网站技术架构：核心原理与案例分析》
• 《亿级流量网站架构核心技术：跟开涛学搭建高可用高并发系统》
• 左耳听风

系统扩展性架构

扩展性和伸缩性是不同的概念：

• 扩展性（Extensibility） - 指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。它是系统架构设计层面的开闭原则（对扩展开放、对修改关闭），架构设计考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。
• 伸缩性（Scalability） - 指系统能够通过增加减少自身资源规模的方式增减自己计算处理事务的能力。如果这种增减是成比例的，就被称作线性伸缩性。在网站架构中 ，通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力。

可扩展的基本思想

• 面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。
• 面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。
• 面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。

可扩展方式

典型的可扩展系统架构有：

• 面向流程拆分：分层架构。
• 面向服务拆分：SOA、微服务。
• 面向功能拆分：微内核架构。

分层架构

分层架构的核心点时：需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构

分层架构是很常见的架构模式，它也叫 N 层架构，通常情况下，N 至少是 2 层。例如，C/S 架构、B/S 架构。常见的是 3 层架构（例如，MVC、MVP 架构）、4 层架构，5 层架构的比较少见，一般是比较复杂的系统才会达到或者超过 5 层，比如操作系统内核架构。

典型分层架构：

• C/S 架构、B/S 架构
• MVC 架构、MVP 架构
• 逻辑分层架构

SOA

SOA 的全称是 Service Oriented Architecture，即“面向服务的架构”。

SOA 提出了 3 个关键概念。

• 服务 - 所有业务功能都是一项服务，服务就意味着要对外提供开放的能力，当其他系统需要使用这项功能时，无须定制化开发。
• ESB - ESB 的全称是 Enterprise Service Bus，即 “企业服务总线”。ESB 将企业中各个不同的服务连接在一起。因为各个独立的服务是异构的，如果没有统一的标准，则各个异构系统对外提供的接口是各式各样的。SOA 使用 ESB 来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。
• 松耦合 - 松耦合的目的是减少各个服务间的依赖和互相影响。因为采用 SOA 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖。如果做不到松耦合，某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。

微服务

微服务是去掉 ESB 后的 SOA。

微服务的问题：

• 服务划分过细，服务间关系复杂 - 服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了。
• 服务数量太多，团队效率急剧下降
• 调用链太长，性能下降
• 调用链太长，问题定位困难
• 没有自动化支撑，无法快速交付
• 没有服务治理，微服务数量多了后管理混乱

微服务拆分：

• 基于业务逻辑拆分
• 基于可扩展拆分 - 将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。
• 基于可靠性拆分 - 将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。

基础设施：

• 服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
• 接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
• 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
• 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。

微内核

微内核的核心系统设计的关键技术有：插件管理、插件连接和插件通信。

插件管理

核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。常见的实现方法是插件注册表机制。核心系统提供插件注册表（可以是配置文件，也可以是代码，还可以是数据库），插件注册表含有每个插件模块的信息，包括它的名字、位置、加载时机（启动就加载，还是按需加载）等。

插件连接

插件连接指插件如何连接到核心系统。通常来说，核心系统必须制定插件和核心系统的连接规范，然后插件按照规范实现，核心系统按照规范加载即可。

常见的连接机制有 OSGi（Eclipse 使用）、消息模式、依赖注入（Spring 使用），甚至使用分布式的协议都是可以的，比如 RPC 或者 HTTP Web 的方式。

插件通信

插件通信指插件间的通信。虽然设计的时候插件间是完全解耦的，但实际业务运行过程中，必然会出现某个业务流程需要多个插件协作，这就要求两个插件间进行通信。由于插件之间没有直接联系，通信必须通过核心系统，因此核心系统需要提供插件通信机制。这种情况和计算机类似，计算机的 CPU、硬盘、内存、网卡是独立设计的配件，但计算机运行过程中，CPU 和内存、内存和硬盘肯定是有通信的，计算机通过主板上的总线提供了这些组件之间的通信功能。微内核的核心系统也必须提供类似的通信机制，各个插件之间才能进行正常的通信。

易扩展的系统架构

低耦合的系统更容易扩展、复用。

可扩展架构的核心思想是模块化，并在此基础上，降低模块间的耦合性，提高模块的复用性。

分层和分割不仅可以进行架构伸缩，也是模块化设计的重要手段，利用分层和分割的方式将软件分割为若干个低耦合的独立的组件模块，这些组件模块以消息传递及依赖调用的方式聚合成一个完整的系统。

在大型网站中，这些模块通过分布式部署的方式，独立的模块部署在独立的服务器上，从物理上分离模块间的耦合关系，进一步降低耦合性提高复用性。

利用分布式消息队列降低系统耦合性

事件驱动架构

事件驱动架构通过在低耦合的模块间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作。典型的事件驱动架构就是操作系统中常见的生产者消费者模式。在大型网站中，最常见的实现手段就是分布式消息队列。

分布式消息队列

消息生产者应用程序通过远程访问接口将消息推送给消息队列服务器，消息队列服务器将消息写入本地内存队列后立即返回成功响应给消息生产者。消息队列服务器根据消息订阅列表查找订阅该消息的消息消费者应用程序，将消息队列中的消息按照先进先出（FIFO）的原则将消息通过远程通信接口发送给消息消费者程序。

在伸缩性方面，由于消息队列服务器上的数据可以看作是即时处理的，因此类似于无状态的服务器，伸缩性设计比较简单。将新服务器加入分布式消息队列集群中，通知生产者服务器更改消息队列服务器列表即可。

在可用性方面，为了避免消费者进程处理缓慢，分布式消息队列服务器内存空间不足造成的问题，如果内存队列已满，会将消息写入磁盘，消息推送模块在将内存队列消息处理完成以后，将磁盘内容加载到内存队列继续处理。

利用分布式服务打造可复用的业务平台

巨无霸系统的问题：

• 构建、部署困难
• 代码分支管理困难
• 数据库连接耗尽
• 扩展业务困难

而解决巨无霸系统问题的方案就是拆分：

• 通过纵向拆分将业务拆分多个应用或模块；
• 通过横向拆分将可复用业务作为独立应用。

然后，需要通过一个分布式服务管理框架将这些应用或服务组织管理起来：通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。常见的分布式服务管理框架如：Spring Cloud、Dubbo 等。

大型网站分布式服务的需求与特点：

• 负载均衡
• 失效转移
• 高效的远程通信
• 整合异构系统
• 对应用最少侵入
• 版本管理
• 实时监控

可扩展的数据结构

传统的关系型数据库为了保证关系运算的正确性，在设计数据库表结构的时候，就需要指定表的 schema ——字段名称，数据类型等，并要遵循特定的设计范式。这些规范带来一个问题：难以面对需求变更带来的挑战，所以有人通过预先设计一些冗余字段来应对。

许多 NoSql 数据库使用 ColumnFamily 设计来设计可扩展的数据结构。

开放平台

很多大公司会利用开放平台提供大量开放性 API 使得企业和个人可以方便的接入业务。通过开放平台，可以构建生态圈，提升品牌价值以及竞争力。

开放平台不是一朝一夕完成的，这需要大量 OPEN API 的沉淀。系统架构在设计之初，应该有意识的将未来可能被复用的接口好好设计，以便于需要开放 OPEN API 时，可以便捷的暴露服务接口。

参考资料

• 《大型网站技术架构：核心原理与案例分析》

系统安全性架构

关键词：XSS、CSRF、SQL 注入、DoS、消息摘要、加密算法、证书

认证

SSO

SSO(Single Sign On)，即单点登录。所谓单点登录，就是同平台的诸多应用登陆一次，下一次就免登陆的功能。

SSO 需要解决多个异构系统之间的问题：

• Session 共享问题
• 跨域问题

Session 共享问题

分布式 Session 的几种实现策略：

• 粘性 Session - 缺点：当服务器节点宕机时，将丢失该服务器节点上的所有 Session。
• 应用服务器间的 Session 复制共享 - 缺点：占用过多内存；同步过程占用网络带宽以及服务器处理器时间。
• 基于缓存的 Session 共享 ✅ （推荐方案） - 不过需要程序自身控制 Session 读写，可以考虑基于 spring-session + redis 这种成熟的方案来处理。

Cookie 跨域

Cookie 不能跨域！比如：浏览器不会把 www.google.com 的 cookie 传给 www.baidu.com。

这就存在一个问题：由于域名不同，用户在系统 A 登录后，浏览器记录系统 A 的 Cookie，但是访问系统 B 的时候不会携带这个 Cookie。

针对 Cookie 不能跨域 的问题，有几种解决方案：

• 服务端生成 Cookie 后，返回给客户端，客户端解析 Cookie ，提取 Token （比如 JWT），此后每次请求都携带这个 Token。
• 多个域名共享 Cookie，在返回 Cookie 给客户端的时候，在 Cookie 中设置 domain 白名单。
• 将 Token 保存在 SessionStroage 中（不依赖 Cookie 就没有跨域的问题了）。

CAS

CAS 是实现 SSO 的主流方式。

CAS 分为两部分，CAS Server 和 CAS Client

• CAS Server - 负责用户的认证工作，就像是把第一次登录用户的一个标识存在这里，以便此用户在其他系统登录时验证其需不需要再次登录。
• CAS Client - 业务应用，需要接入 CAS Server。当用户访问我们的应用时，首先需要重定向到 CAS Server 端进行验证，要是原来登陆过，就免去登录，重定向到下游系统，否则进行用户名密码登陆操作。

术语：

• Ticket Granting Ticket (TGT) - 可以认为是 CAS Server 根据用户名、密码生成的一张票，存在 Server 端。
• Ticket Granting Cookie (TGC) - 其实就是一个 Cookie，存放用户身份信息，由 Server 发给 Client 端。
• Service Ticket (ST) - 由 TGT 生成的一次性票据，用于验证，只能用一次。

CAS 工作流程：

1. 用户访问 CAS Client A（业务系统），第一次访问，重定向到认证服务中心（CAS Server）。CAS Server 发现当前请求中没有 Cookie，再重定向到 CAS Server 的登录页面。重定向请求的 URL 中包含访问地址，以便认证成功后直接跳转到访问页面。
2. 用户在登录页面输入用户名、密码等认证信息，认证成功后，CAS Server 生成 TGT，再用 TGT 生成一个 ST。然后返回 ST 和 TGC（Cookie）给浏览器。
3. 浏览器携带 ST 再度访问之前想访问的 CAS Client A 页面。
4. CAS Client A 收到 ST 后，向 CAS Server 验证 ST 的有效性。验证通过则允许用户访问页面。
5. 此时，如果登录另一个 CAS Client B，会先重定向到 CAS Server，CAS Server 可以判断这个 CAS Client B 是第一次访问，但是本地有 TGC，所以无需再次登录。用 TGC 创建一个 ST，返回给浏览器。
6. 重复类似 3、4 步骤。

以上了归纳总结如下：

1. 访问服务 - 用户访问 SSO Client 资源。
2. 定向认证 - SSO Client 重定向用户请求到 SSO Server。
3. 用户认证 - 用户身份认证。
4. 发放票据 - SSO Server 会产生一个 Service Ticket (ST) 并返回给浏览器。
5. 验证票据 - 浏览器每次访问 SSO Client 时，携带 ST，SSO Client 向 SSO Server 验证票据。只有验证通过，才允许访问。
6. 传输用户信息 - SSO Server 验证票据通过后，传输用户认证结果信息给 SSO Client。

Oauth 2.0

基本原理

OAuth 在”客户端”与”服务提供商”之间，设置了一个授权层（authorization layer）。”客户端”不能直接登录”服务提供商”，只能登录授权层，以此将用户与客户端区分开来。”客户端”登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

“客户端”登录授权层以后，”服务提供商”根据令牌的权限范围和有效期，向”客户端”开放用户储存的资料。

OAuth 2.0 的运行流程如下图，摘自 RFC 6749。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放资源。

不难看出来，上面六个步骤之中，B 是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。

授权模式

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0 定义了四种授权方式。

• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

授权码模式

授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与”服务提供商”的认证服务器进行互动。

（A）用户访问客户端，后者将前者导向认证服务器。

（B）用户选择是否给予客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的”重定向 URI”（redirection URI），同时附上一个授权码。

（D）客户端收到授权码，附上早先的”重定向 URI”，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了授权码和重定向 URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

下面是上面这些步骤所需要的参数。

A 步骤中，客户端申请认证的 URI，包含以下参数：

• response_type：表示授权类型，必选项，此处的值固定为”code”
• client_id：表示客户端的 ID，必选项
• redirect_uri：表示重定向 URI，可选项
• scope：表示申请的权限范围，可选项
• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

下面是一个例子。

1
2
3

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
  &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

C 步骤中，服务器回应客户端的 URI，包含以下参数：

• code：表示授权码，必选项。该码的有效期应该很短，通常设为 10 分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端 ID 和重定向 URI，是一一对应关系。
• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

下面是一个例子。

1
2
3

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
    &state=xyz

D 步骤中，客户端向认证服务器申请令牌的 HTTP 请求，包含以下参数：

• grant_type：表示使用的授权模式，必选项，此处的值固定为”authorization_code”。
• code：表示上一步获得的授权码，必选项。
• redirect_uri：表示重定向 URI，必选项，且必须与 A 步骤中的该参数值保持一致。
• client_id：表示客户端 ID，必选项。

下面是一个例子。

1
2
3
4
5
6
7

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

E 步骤中，认证服务器发送的 HTTP 回复，包含以下参数：

• access_token：表示访问令牌，必选项。
• token_type：表示令牌类型，该值大小写不敏感，必选项，可以是 bearer 类型或 mac 类型。
• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
• refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

下面是一个例子。

1
2
3
4
5
6
7
8
9
10
11
12

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
 "access_token":"2YotnFZFEjr1zCsicMWpAA",
 "token_type":"example",
 "expires_in":3600,
 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
 "example_parameter":"example_value"
}

从上面代码可以看到，相关参数使用 JSON 格式发送（Content-Type: application/json）。此外，HTTP 头信息中明确指定不得缓存。

简化模式

简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了”授权码”这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

（A）客户端将用户导向认证服务器。

（B）用户决定是否给于客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端指定的”重定向 URI”，并在 URI 的 Hash 部分包含了访问令牌。

（D）浏览器向资源服务器发出请求，其中不包括上一步收到的 Hash 值。

（E）资源服务器返回一个网页，其中包含的代码可以获取 Hash 值中的令牌。

（F）浏览器执行上一步获得的脚本，提取出令牌。

（G）浏览器将令牌发给客户端。

下面是上面这些步骤所需要的参数。

A 步骤中，客户端发出的 HTTP 请求，包含以下参数：

• response_type：表示授权类型，此处的值固定为”token”，必选项。
• client_id：表示客户端的 ID，必选项。
• redirect_uri：表示重定向的 URI，可选项。
• scope：表示权限范围，可选项。
• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

下面是一个例子。

1
2
3

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
  &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

C 步骤中，认证服务器回应客户端的 URI，包含以下参数：

• access_token：表示访问令牌，必选项。
• token_type：表示令牌类型，该值大小写不敏感，必选项。
• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

下面是一个例子。

1
2
3

HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
         &state=xyz&token_type=example&expires_in=3600

在上面的例子中，认证服务器用 HTTP 头信息的 Location 栏，指定浏览器重定向的网址。注意，在这个网址的 Hash 部分包含了令牌。

根据上面的 D 步骤，下一步浏览器会访问 Location 指定的网址，但是 Hash 部分不会发送。接下来的 E 步骤，服务提供商的资源服务器发送过来的代码，会提取出 Hash 中的令牌。

密码模式

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向”服务商提供商”索要授权。

在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

它的步骤如下：

（A）用户向客户端提供用户名和密码。

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

（C）认证服务器确认无误后，向客户端提供访问令牌。

B 步骤中，客户端发出的 HTTP 请求，包含以下参数：

• grant_type：表示授权类型，此处的值固定为”password”，必选项。
• username：表示用户名，必选项。
• password：表示用户的密码，必选项。
• scope：表示权限范围，可选项。

下面是一个例子。

1
2
3
4
5
6

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w

C 步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。

1
2
3
4
5
6
7
8
9
10
11
12

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
 "access_token":"2YotnFZFEjr1zCsicMWpAA",
 "token_type":"example",
 "expires_in":3600,
 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
 "example_parameter":"example_value"
}

上面代码中，各个参数的含义参见《授权码模式》一节。

整个过程中，客户端不得保存用户的密码。

客户端模式

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向”服务提供商”进行认证。严格地说，客户端模式并不属于 OAuth 框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求”服务提供商”提供服务，其实不存在授权问题。

它的步骤如下：

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。

（B）认证服务器确认无误后，向客户端提供访问令牌。

A 步骤中，客户端发出的 HTTP 请求，包含以下参数：

• granttype：表示授权类型，此处的值固定为”clientcredentials”，必选项。
• scope：表示权限范围，可选项。

1
2
3
4
5
6

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

认证服务器必须以某种方式，验证客户端身份。

B 步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。

1
2
3
4
5
6
7
8
9
10
11

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
 "access_token":"2YotnFZFEjr1zCsicMWpAA",
 "token_type":"example",
 "expires_in":3600,
 "example_parameter":"example_value"
}

上面代码中，各个参数的含义参见《授权码模式》一节。

更新令牌

如果用户访问的时候，客户端的”访问令牌”已经过期，则需要使用”更新令牌”申请一个新的访问令牌。

客户端发出更新令牌的 HTTP 请求，包含以下参数：

• granttype：表示使用的授权模式，此处的值固定为”refreshtoken”，必选项。
• refresh_token：表示早前收到的更新令牌，必选项。
• scope：表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。

下面是一个例子。

1
2
3
4
5
6

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

鉴权

RBAC

**RBAC（Role-Based Access Control）即：基于角色的权限控制**。通过角色关联用户，角色关联权限的方式间接赋予用户权限。

每个用户关联一个或多个角色，每个角色关联一个或多个权限，从而可以实现了非常灵活的权限管理。角色可以根据实际业务需求灵活创建，这样就省去了每新增一个用户就要关联一遍所有权限的麻烦。简单来说 RBAC 就是：用户关联角色，角色关联权限。

角色继承

角色继承(Hierarchical Role) 就是指角色可以继承于其他角色，在拥有其他角色权限的同时，自己还可以关联额外的权限。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

职责分离(Separation of Duty)

为了避免用户拥有过多权限而产生利益冲突，例如一个篮球运动员同时拥有裁判的权限（看一眼就给你判犯规狠不狠？），另一种职责分离扩展版的 RBAC 被提出。

职责分离有两种模式：

静态职责分离(Static Separation of Duty)：用户无法同时被赋予有冲突的角色。

动态职责分离(Dynamic Separation of Duty)：用户在一次会话（Session）中不能同时激活自身所拥有的、互相有冲突的角色，只能选择其一。

讲了这么多 RBAC，都还只是在用户和权限之间进行设计，并没有涉及到用户和对象之间的权限判断，而在实际业务系统中限制用户能够使用的对象是很常见的需求。

RBAC0 模型

最简单的用户、角色、权限模型。这里面又包含了 2 种：

1. 用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户担当。
2. 用户和角色是多对多关系，即：一个用户可同时充当多种角色，一种角色可以有多个用户担当。

那么，什么时候该使用多对一的权限体系，什么时候又该使用多对多的权限体系呢？

如果系统功能比较单一，使用人员较少，岗位权限相对清晰且确保不会出现兼岗的情况，此时可以考虑用多对一的权限体系。其余情况尽量使用多对多的权限体系，保证系统的可扩展性。如：张三既是行政，也负责财务工作，那张三就同时拥有行政和财务两个角色的权限。

RBAC1 模型

相对于 RBAC0 模型，增加了子角色，引入了继承概念，即子角色可以继承父角色的所有权限。

使用场景：如某个业务部门，有经理、主管、专员。主管的权限不能大于经理，专员的权限不能大于主管，如果采用 RBAC0 模型做权限系统，极可能出现分配权限失误，最终出现主管拥有经理都没有的权限的情况。

而 RBAC1 模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持在经理权限上删减主管权限。

RBAC2 模型

基于 RBAC0 模型，增加了对角色的一些限制：角色互斥、基数约束、先决条件角色等。

• 角色互斥：同一用户不能分配到一组互斥角色集合中的多个角色，互斥角色是指权限互相制约的两个角色。案例：财务系统中一个用户不能同时被指派给会计角色和审计员角色。
• 基数约束：一个角色被分配的用户数量受限，它指的是有多少用户能拥有这个角色。例如：一个角色专门为公司 CEO 创建的，那这个角色的数量是有限的。
• 先决条件角色：指要想获得较高的权限，要首先拥有低一级的权限。例如：先有副总经理权限，才能有总经理权限。
• 运行时互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。

RBAC3 模型

称为统一模型，它包含了 RBAC1 和 RBAC2，利用传递性，也把 RBAC0 包括在内，综合了 RBAC0、RBAC1 和 RBAC2 的所有特点，这里就不在多描述了。

什么是权限

说了这么久用户-角色-权限，可能小伙伴们都了解了什么是用户、什么是角色。但是有的小伙伴会好奇，那权限又是个什么玩意呢？

权限是资源的集合，这里的资源指的是软件中所有的内容，包括模块、菜单、页面、字段、操作功能（增删改查）等等。具体的权限配置上，目前形式多种多样，按照我个人的理解，可以将权限分为：页面权限、操作权限和数据权限（这种分类法，主要是结合自己在工作中的实际情况理解总结而来，若有不足之处，也请大家指出）。

页面权限：所有系统都是由一个个的页面组成，页面再组成模块，用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面权限。

如下图：

客户列表、客户黑名单、客户审批页面组成了客户管理这个模块。对于普通用户，不能进行审批操作，即无客户审批页面权限，在他的账号登录后侧边导航栏只显示客户列表、客户黑名单两个菜单。

操作权限：用户凡是在操作系统中的任何动作、交互都是操作权限，如增删改查等。

数据权限：一般业务管理系统，都有数据私密性的要求：哪些人可以看到哪些数据，不可以看到哪些数据。

简单举个例子：某系统中有销售部门，销售专员负责推销商品，销售主管负责管理销售专员日常工作，经理负责组织管理销售主管作业。

如下图：

按照实际理解，‘销售专员张三’登录时，只能看到自己负责的数据；销售主管 2 登录时，能看到他所领导的所有业务员负责的数据，但看不到其他团队业务员负责的数据。

换另外一句话就是：我的客户只有我和我的直属上级以及直属上级的领导能看到，这就是我理解的数据权限。

要实现数据权限有多种方式：

1. 可以利用 RBAC1 模型，通过角色分级来实现。
2. 在‘用户-角色-权限’的基础上，增加用户与组织的关联关系，用组织决定用户的数据权限。

具体如何做呢？

① 组织层级划分：

② 数据可视权限规则制定：上级组织只能看到下级组织员工负责的数据，而不能看到其他平级组织及其下级组织的员工数据等。

通过以上两点，系统就可以在用户登录时，自动判断要给用户展示哪些数据了。

用户组的使用

当平台用户基数增大，角色类型增多时，如果直接给用户配角色，管理员的工作量就会很大。这时候我们可以引入一个概念“用户组”，就是将相同属性的用户归类到一起。

例如：加入用户组的概念后，可以将部门看做一个用户组，再给这个部门直接赋予角色（1 万员工部门可能就几十个），使部门拥有部门权限，这样这个部门的所有用户都有了部门权限，而不需要为每一个用户再单独指定角色，极大的减少了分配权限的工作量。

同时，也可以为特定的用户指定角色，这样用户除了拥有所属用户组的所有权限外，还拥有自身特定的权限。

用户组的优点，除了减少工作量，还有更便于理解、增加多级管理关系等。如：我们在进行组织机构配置的时候，除了加入部门，还可以加入科室、岗位等层级，来为用户组内部成员的权限进行等级上的区分。

关于用户组的详细疑难解答，请查看https://wen.woshipm.com/question/detail/88fues.html。在这里也十分感谢为我解答疑惑的朋友们！

实例分析

如何设计 RBAC 权限系统

首先，我们思考一下一个简单的权限系统应该具备哪些内容？

答案显而易见，RBAC 模型：用户-角色-权限。所以最基本的我们应该具备用户、角色、权限这三个内容。

接下来，我们思考，究竟如何将三者关联起来。回顾前文，角色作为枢纽，关联用户、权限。所以在 RBAC 模型下，我们应该：创建一个角色，并为这个角色赋予相应权限，最后将角色赋予用户。

将这个问题抽象为流程，如下图：

现在，基本的流程逻辑已经抽象出来了，接下来，分析该如何设计呢？

• 第一步，需要角色管理列表，在角色管理列表能快速创建一个角色，且创建角色的同时能为角色配置权限，并且支持创建成功的角色列表能随时进行权限配置的的修改；
• 第二步，需要用户管理列表，在用户管理列表能快速添加一个用户，且添加用户时有让用户关联角色的功能。

简单来说权限系统设计就包含以上两步，接下来为大家进行实例分析。

实例分析

① 创建角色列表

在角色列表快速创建一个角色：点击创建角色，支持创建角色时配置权限。

② 创建用户列表

在用户列表快速创建一个用户：支持用户关联角色的功能。

上述案例是基于最简单的 RBAC0 模型创建，适用于大部分常规的权限管理系统。

下面再分析一下 RBAC1 中角色分级具体如何设计。

1. 在 RBAC0 的基础上，加上角色等级这个字段。
2. 权限分配规则制定：低等级角色只能在高等级角色权限基础上进行删减权限。

具体界面呈现如下图：

以上就是简单的 RBAC 系统设计，若需更复杂的，还请读者根据上面的分析自行揣摩思考，尽管样式不同，但万变不离其宗，理解清楚 RBAC 模型后，结合自己的业务就可以设计出一套符合自己平台需求的角色权限系统，具体的就不再多阐述了。

审计

TODO

网站攻击

互联网环境鱼龙混杂，网站被攻击是常见现象，所以了解一些常见的网站攻击手段十分必要。下面列举比较常见的 4 种攻击手段：

XSS

概念

跨站脚本（Cross-site scripting，通常简称为XSS） 是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了 HTML 以及用户端脚本语言。

XSS 攻击示例：

假如有下面一个 textbox

1

<input type="text" name="address1" value="value1from" />

value1from 是来自用户的输入，如果用户不是输入 value1from,而是输入 "/><script>alert(document.cookie)</script><!- 那么就会变成：

1
2
3
4
5

<input type="text" name="address1" value="" />
<script>
  alert(document.cookie)
</script>
<!- ">

嵌入的 JavaScript 代码将会被执行。攻击的威力，取决于用户输入了什么样的脚本。

攻击手段和目的

常用的 XSS 攻击手段和目的有：

• 盗用 cookie，获取敏感信息。
• 利用植入 Flash，通过 crossdomain 权限设置进一步获取更高权限；或者利用 Java 等得到类似的操作。
• 利用 iframe、frame、XMLHttpRequest 或上述 Flash 等方式，以（被攻击）用户的身份执行一些管理动作，或执行一些一般的如发微博、加好友、发私信等操作。
• 利用可被攻击的域受到其他域信任的特点，以受信任来源的身份请求一些平时不允许的操作，如进行不当的投票活动。
• 在访问量极大的一些页面上的 XSS 可以攻击一些小型网站，实现 DDoS 攻击的效果。

应对手段

• 过滤特殊字符 - 将用户所提供的内容进行过滤，从而避免 HTML 和 Jascript 代码的运行。如 > 转义为 &gt、< 转义为 &lt 等，就可以防止大部分攻击。为了避免对不必要的内容错误转移，如 3<5 中的 < 需要进行文本匹配后再转移，如：<img src= 这样的上下文中的 < 才转义。
• 设置 Cookie 为 HttpOnly - 设置了 HttpOnly 的 Cookie 可以防止 JavaScript 脚本调用，就无法通过 document.cookie 获取用户 Cookie 信息。

:point_right: 参考阅读：

• Wiki 词条 - 跨站脚本
• Web 安全测试之 XSS

CSRF

概念

**跨站请求伪造（Cross-site request forgery，CSRF）**，也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF。它是一种挟持用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。和跨站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

攻击手段和目的

可以如此理解 CSRF：攻击者盗用了你的身份，以你的名义发送恶意请求。

CSRF 能做的事太多：

• 以你名义发送邮件，发消息
• 用你的账号购买商品
• 用你的名义完成虚拟货币转账
• 泄露个人隐私
• …

应对手段

• 表单 Token - CSRF 是一个伪造用户请求的操作，所以需要构造用户请求的所有参数才可以。表单 Token 通过在请求参数中添加随机数的办法来阻止攻击者获得所有请求参数。
• 验证码 - 请求提交时，需要用户输入验证码，以避免用户在不知情的情况下被攻击者伪造请求。
• Referer check - HTTP 请求头的 Referer 域中记录着请求资源，可通过检查请求来源，验证其是否合法。

:point_right: 参考阅读：

• Wiki 词条 - 跨站请求伪造
• 浅谈 CSRF 攻击方式
• “每日一题”CSRF 是什么？“每日一题”CSRF 是什么？
• WEB 安全之-CSRF（跨站请求伪造）

SQL 注入

概念

**SQL 注入攻击（SQL injection）**，是发生于应用程序之数据层的安全漏洞。简而言之，是在输入的字符串之中注入 SQL 指令，在设计不良的程序当中忽略了检查，那么这些注入进去的指令就会被数据库服务器误认为是正常的 SQL 指令而运行，因此遭到破坏或是入侵。

攻击示例：

考虑以下简单的登录表单：

1
2
3
4
5

<form action="/login" method="POST">
  <p>Username: <input type="text" name="username" /></p>
  <p>Password: <input type="password" name="password" /></p>
  <p><input type="submit" value="登陆" /></p>
</form>

我们的处理里面的 SQL 可能是这样的：

1
2
3

username:=r.Form.Get("username")
password:=r.Form.Get("password")
sql:="SELECT * FROM user WHERE username='"+username+"' AND password='"+password+"'"

如果用户的输入的用户名如下，密码任意

1

myuser' or 'foo' = 'foo' --

那么我们的 SQL 变成了如下所示：

1

SELECT * FROM user WHERE username='myuser' or 'foo' = 'foo' --'' AND password='xxx'

在 SQL 里面 -- 是注释标记，所以查询语句会在此中断。这就让攻击者在不知道任何合法用户名和密码的情况下成功登录了。

对于 MSSQL 还有更加危险的一种 SQL 注入，就是控制系统，下面这个可怕的例子将演示如何在某些版本的 MSSQL 数据库上执行系统命令。

1
2

sql:="SELECT * FROM products WHERE name LIKE '%"+prod+"%'"
Db.Exec(sql)

如果攻击提交 a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- 作为变量 prod 的值，那么 sql 将会变成

1

sql:="SELECT * FROM products WHERE name LIKE '%a%' exec master..xp_cmdshell 'net user test testpass /ADD'--%'"

MSSQL 服务器会执行这条 SQL 语句，包括它后面那个用于向系统添加新用户的命令。如果这个程序是以 sa 运行而 MSSQLSERVER 服务又有足够的权限的话，攻击者就可以获得一个系统帐号来访问主机了。

虽然以上的例子是针对某一特定的数据库系统的，但是这并不代表不能对其它数据库系统实施类似的攻击。针对这种安全漏洞，只要使用不同方法，各种数据库都有可能遭殃。

攻击手段和目的

• 数据表中的数据外泄，例如个人机密数据，账户数据，密码等。
• 数据结构被黑客探知，得以做进一步攻击（例如 SELECT * FROM sys.tables）。
• 数据库服务器被攻击，系统管理员账户被窜改（例如 ALTER LOGIN sa WITH PASSWORD='xxxxxx'）。
• 获取系统较高权限后，有可能得以在网页加入恶意链接、恶意代码以及 XSS 等。
• 经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统（例如 xp_cmdshell “net stop iisadmin”可停止服务器的 IIS 服务）。
• 破坏硬盘数据，瘫痪全系统（例如 xp_cmdshell “FORMAT C:”）。

应对手段

• 使用参数化查询 - 建议使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中，即不要直接拼接 SQL 语句。例如使用 database/sql 里面的查询函数 Prepare 和 Query ，或者 Exec(query string, args ...interface{})。
• 单引号转换 - 在组合 SQL 字符串时，先针对所传入的参数进行字符替换（将单引号字符替换为连续 2 个单引号字符）。

:point_right: 参考阅读：

• Wiki 词条 - SQL 注入攻击
• 避免 SQL 注入
• 实例讲解 SQL 注入攻击

DoS

**拒绝服务攻击（denial-of-service attack, DoS）亦称洪水攻击**，是一种网络攻击手法，其目的在于使目标电脑的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问。

当黑客使用网络上两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动“拒绝服务”式攻击时，称为分布式拒绝服务攻击（distributed denial-of-service attack，缩写：DDoS attack、DDoS）。

攻击方式

• 带宽消耗型攻击
• 资源消耗型攻击

应对手段

• 防火墙 - 允许或拒绝特定通讯协议，端口或 IP 地址。当攻击从少数不正常的 IP 地址发出时，可以简单的使用拒绝规则阻止一切从攻击源 IP 发出的通信。
• 路由器、交换机 - 具有速度限制和访问控制能力。
• 流量清洗 - 通过采用抗 DoS 软件处理，将正常流量和恶意流量区分开。

:point_right: 参考阅读：

• 拒绝服务攻击

加密技术

对于网站来说，用户信息、账户等等敏感数据一旦泄漏，后果严重，所以为了保护数据，应对这些信息进行加密处理。

信息加密技术一般分为：

• 消息摘要
• 加密算法
  • 对称加密
  • 非对称加密
• 证书

消息摘要

常用数字签名算法：MD5、SHA 等。

应用场景：将用户密码以消息摘要形式保存到数据库中。

:point_right: 参考阅读： Java 编码和加密

加密算法

对称加密

对称加密指加密和解密所使用的密钥是同一个密钥。

常用对称加密算法：DES、AES 等。

应用场景：Cookie 加密、通信机密等。

非对称加密

非对称加密指加密和解密所使用的不是同一个密钥，而是一个公私钥对。用公钥加密的信息必须用私钥才能解开；反之，用私钥加密的信息只有用公钥才能解开。

常用非对称加密算法：RSA 等。

应用场景：HTTPS 传输中浏览器使用的数字证书实质上是经过权威机构认证的非对称加密公钥。

:point_right: 参考阅读： Java 编码和加密

密钥安全管理

保证密钥安全的方法：

1. 把密钥和算法放在一个独立的服务器上，对外提供加密和解密服务，应用系统通过调用这个服务，实现数据的加解密。
2. 把加解密算法放在应用系统中，密钥则放在独立服务器中，为了提高密钥的安全性，实际存储时，密钥被切分成数片，加密后分别保存在不同存储介质中。

证书

证书可以称为信息安全加密的终极手段。公开密钥认证（英语：Public key certificate），又称公开密钥证书、公钥证书、数字证书（digital certificate）、数字认证、身份证书（identity certificate）、电子证书或安全证书，是用于公开密钥基础建设的电子文件，用来证明公开密钥拥有者的身份。此文件包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对这份文件的数字签名，以保证这个文件的整体内容正确无误。

透过信任权威数字证书认证机构的根证书、及其使用公开密钥加密作数字签名核发的公开密钥认证，形成信任链架构，已在 TLS 实现并在万维网的 HTTP 以 HTTPS、在电子邮件的 SMTP 以 STARTTLS 引入并广泛应用。

众所周知，常见的应用层协议 HTTP、FTP、Telnet 本身不保证信息安全。但是加入了 SSL/TLS 加密数据包机制的 HTTPS、FTPS、Telnets 是信息安全的。传输层安全性协议（Transport Layer Security, TLS），及其前身安全套接层（Secure Sockets Layer, SSL）是一种安全协议，目的是为互联网通信，提供安全及数据完整性保障。

证书原理

SSL/TLS 协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

这里有两个问题：

（1）如何保证公钥不被篡改？

解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

（2）公钥加密计算量太大，如何减少耗用的时间？

解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。

SSL/TLS 协议的基本过程是这样的：

1. 客户端向服务器端索要并验证公钥。
2. 双方协商生成”对话密钥”。
3. 双方采用”对话密钥”进行加密通信。

:point_right: 参考阅读：

• 传输层安全性协议
• 公开密钥认证
• SSL/TLS 协议运行机制的概述

信息过滤

在网络中，广告和垃圾信息屡见不鲜，泛滥成灾。

常见的信息过滤与反垃圾手段有：

文本匹配

解决敏感词过滤。系统维护一份敏感词清单，如果信息中含有敏感词，则自动进行过滤或拒绝信息。

黑名单

黑名单就是将一些已经被识别出有违规行为的 IP、域名、邮箱等加入黑名单，拒绝其请求。

黑名单可以通过 Hash 表来实现，方法简单，复杂度小，适于一般应用场景。

但如果黑名单列表非常大时，Hash 表要占用很大的内存空间，这时就不再使用了。这种情况下，可以使用布隆过滤器来实现，即通过一个二进制列表和一组随机数映射函数来实现。

分类算法

对于海量信息，难以通过人工去审核。对广告贴。

垃圾邮件等内容的识别比较好的自动化方法就是采用分类算法。

简单来说，即将批量已分类的样本输入分类算法进行训练，得到一个分类模型，然后利用分类算法结合分类模型去对信息进行识别。想了解具体做法，需要去理解机器学习相关知识。

风险控制

网络给商务、金融领域带来极大便利的同时，也将风险带给了对网络安全一无所知的人们。由于交易双方信息的不对等，使得交易存在着风险，而当交易发生在网络上时，风险就更加难以控制了。

风险种类

• 账户风险 - 盗用账户、恶意注册账户等
• 买家风险 - 虚假询盘、恶意拒收、恶意下单、黄牛党抢购热门商品等
• 卖家风险 - 虚假发货、出售违禁品、侵权等
• 交易风险 - 信用卡盗刷、交易欺诈、洗钱、套现、电信诈骗等

风险控制手段

大型电商网站系统或金融系统都配备专业的风控团队进行风险控制。风险控制手段既包括人工审核也包括自动审核。

自动风控的技术手段主要有规则引擎和统计模型。

规则引擎

在交易中，买家、卖家的某些指标满足一定条件时，就会被认为存在风险。如：交易金额超过某个数值；用户来自黑名单；用户和上次登录的地址距离差距很大；用户在一定时间内频繁交易等等。

如果以上这些条件都通过 if … else … 式样的代码去实现，代码维护、扩展会非常不便。因此，就有了规则引擎来处理这类问题。规则引擎是一种将业务规则和规则处理逻辑相分离的技术，业务规则由运营人员通过管理界面去编辑，实现无需修改代码，即可实时的使用新规则。

统计模型

规则引擎虽然技术简单，但是随着规则不断增加，规模越来越大。可能会出现规则冲突，难以维护的情况，并且规则越多，性能也越差。

为了解决这种问题，就有了统计模型。统计模型会使用分类算法或更复杂的机器学习算法进行智能统计。根据历史交易中的信息训练分类，然后将经过采集加工后的交易信息输入分类算法，得到交易风险值，然后基于此，做出预测。

经过充分训练后的统计模型，准确率不低于规则引擎。但是，需要有领域专家、行业专家介入，建立合理的训练模型，并不断优化。

参考资料

• 《大型网站技术架构：核心原理与案例分析》
• Wiki 词条 - 跨站脚本
• Web 安全测试之 XSS
• Wiki 词条 - 跨站请求伪造
• 浅谈 CSRF 攻击方式
• “每日一题”CSRF 是什么？“每日一题”CSRF 是什么？
• WEB 安全之-CSRF（跨站请求伪造）
• Wiki 词条 - SQL 注入攻击
• 避免 SQL 注入
• 实例讲解 SQL 注入攻击
• 拒绝服务攻击
• 传输层安全性协议
• 公开密钥认证
• SSL/TLS 协议运行机制的概述
• http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
• CAS 实现 SSO 单点登录原理
• 权限系统设计模型分析（DAC，MAC，RBAC，ABAC）
• RBAC 模型：基于用户-角色-权限控制的一些思考

秒杀系统设计

秒杀系统所要应对的场景就是：瞬时海量请求。

秒杀系统的难点

• 高并发：秒杀系统是极致的高并场景发自不用说。其高并发可以细分为二：
  • 并发读：主要是读取剩余库存量以及商品信息
  • 并发写：主要是下单后，系统写入订单记录
• 超卖：秒杀系统中售卖的商品一般都是性价比很高，不怎么赚钱，甚至赔钱赚哟喝的商品。一旦出现超卖现象，会给商家带来巨大的经济损失。从系统层面来看，比如某秒杀商品本来库存 100 件，但是在高并发场景下，瞬时下单量超过 100 件，处理不当，让这些下单都成功了，就会出现超卖。
• 恶意请求：有些人为了低价购入秒杀商品，通过在多台机器上跑脚本，模拟大量用户抢商品的请求（走自己的路，让别人无路可走）。
• 数据库崩溃：海量请求下，如果没有 MQ 削峰，没有过载保护，让所有请求都打到数据库，那么数据库基本就挂了。数据库如果挂了，也会波及其他业务，从而可能让整个系统、网站陷入瘫痪。
• 对现有业务造成冲击

秒杀系统的思考

稳准快

秒杀系统架构的思考角度可以概括为：稳、准、快

• 稳（高可用）：系统架构要满足高可用，系统要能撑住活动。
• 准（一致性）：商品减库存方式非常关键，不能出现超卖。
• 快（高性能）：整个请求链路，从前端到后端，依赖组件都要做到协同优化。

前端优化

静态页面

把秒杀商品页面静态化，减少查数据库的 IO 开销。然后，可以将这些静态页面做 CDN 缓存，如果项目是前后端分离的，还可以在反向代理服务器侧设置静态缓存。

如每个商品都由 ID 来标识，那么 http://item.xxx.com/item.htm?id=xxxx 就可以作为唯一的 URL 标识。相应的页面可以提前做前端缓存，这样就不需要向后台查询商品信息。

按钮控制

在秒杀活动开启时间前，下单按钮禁用。

此外，按钮一旦点击之后，禁用一段时间，防止有人疯狂输出。

后端优化

隔离

秒杀活动，本质上还是一个营销活动，性质和打折、促销一样。

秒杀系统设计底线原则，是不应该影响现有业务。所以，为了避免防不胜防，百密一疏的情况下，秒杀系统崩了。

限流、熔断、降级、隔离

• 隔离：将秒杀系统、数据与其他正常业务隔离。彼此隔离，自然互不影响。

• 限流：设置阈值，超过阈值，拒绝请求。防止数据库被打死。

• 降级：保证核心业务继续工作，非核心业务各安天命。

• 熔断：不要影响别的系统。

缓存

缓存要预热，避免瞬间流量冲击。

此外，防止雪崩、穿透、击穿问题的常规处理要做好。

缓存也要保证高可用。

流量削峰

削峰的思路：排队、答题、分层过滤。

• 排队：用消息队列来缓冲瞬时流量的方案。但是，消息队列自身也有上限，如果积压过多，也会处理不了。
• 答题（摇一摇）：可以限制秒杀器并延缓请求。
• 分层过滤：采用漏斗式的设计尽可能拦截无效请求。

减库存

恶意下单

恶意下单的解决方案还是要结合安全和反作弊措施来制止：

• 识别频繁下单不付款或重复下单不付款的卖家，阻断其下单。
• 限制个人购买数

避免超卖

减库存在数据一致性上，主要就是保证大并发请求时库存数据不能为负数，也就是要保证数据库中的库存字段值不能为负数，一般我们有多种解决方案：一种是在应用程序中通过事务来判断，即保证减后库存不能为负数，否则就回滚；另一种办法是直接设置数据库的字段数据为无符号整数，这样减后库存字段值小于零时会直接执行 SQL 语句来报错；再有一种就是使用 CASE WHEN 判断语句，例如这样的 SQL 语句：

1

UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END

在交易环节中，“库存”是个关键数据，也是个热点数据，因为交易的各个环节中都可能涉及对库存的查询。但是，我在前面介绍分层过滤时提到过，秒杀中并不需要对库存有精确的一致性读，把库存数据放到缓存（Cache）中，可以大大提升读性能。

URL 动态化

通过 MD5 之类的加密算法加密随机的字符串去做 url，然后通过前端代码获取 url 后台校验才能通过。

参考资料

• 如何设计一个秒杀系统
• 一个秒杀系统的设计思考

Eclipse 快速入门

代码智能提示

Java 智能提示

Window -> Preferences -> Java -> Editor -> Content Assist -> Auto Activation

delay 是自动弹出提示框的延时时间，我们可以修改成 100 毫秒；triggers 这里默认是”.”，只要加上”abcdefghijklmnopqrstuvwxyz”或者”abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”，嘿嘿！这下就能做到和 VS 一样的输入每个字母都能提示啦：

其它类型的文件比如 HTML、JavaScript、JSP 如果也能提供提示那不是更爽了？有了第二点设置的基础，其实这些设置都是一样的。

JavaScript 智能提示

Window -> Preferences -> JavaScript-> Editor -> Content Assist -> Auto-Activation

HTML 智能提示

Window -> Preferences -> Web -> HTML Files -> Editor -> Content Assist -> Auto-Activation

保存后，我们再来输入看看，感觉真是不错呀：

插件安装

很多教科书上说到 Eclipse 的插件安装都是通过 Help -> Install New SoftWare 这种自动检索的方式，操作起来固然是方便，不过当我们不需要某种插件时不太容易找到要删除哪些内容，而且以后 Eclipse 版本升级的时候，通过这种方式安装过的插件都得再重新装一次。另外一种通过 Link 链接方式，就可以解决这些问题。

我们以 Eclipse 的中文汉化包插件为例，先到官方提供的汉化包地址下载一个：http://www.eclipse.org/babel/downloads.php，注意选好自己的 Eclipse 版本：

我的版本是 Kepler，然后进入下载页面，单击红框框中的链接，即可下载汉化包了：

下载完解压缩后，会有个包含 features 和 plugin 目录的 eclipse 文件夹，把这个 eclipse 放在我们的 Eclipse 安装根目录，也就是和 eclipse.exe 同一级目录下。然后仍然在这一级目录下，新建一个 links 文件夹，并在该文件夹内，建一个 language.link 的文本文件。该文本文件的名字是可以任取的，后缀名是.link，而不是.txt 哟。好了，最后一步，编辑该文件，在里面写入刚才放入的语言包的地址，并用“\”表示路径，一定要有 path= 这个前缀。

保存文件后，重新打开 Eclipse，熟悉的中文界面终于看到了。虽然汉化不完全，不过也够用了不是么。如果仍然出现的是英文，说明汉化失败，重新检查下 language.link 文件中配置的信息是否和汉化包的目录一致。　　其它的插件安装方法也是如此，当不需要某个插件时，只需删除存放插件的目录和 links 目录下相应的 link 文件，或者改变下 link 文件里面的路径变成无效路径即可；对 Eclipse 做高版本升级时，也只需把老版存放插件的目录和 links 目录复制过去就行了。

基本设置

在 Preference 的搜索项中搜索 Text Editors。
可以参考我的设置：
Show line numbers
Show print margin
Insert spaces for tabs

设置代码的字体类型和大小：

Window -> Preferences -> General -> Appearance -> Content Assist -> Colors and Fornts，只需修改 Basic 里面的 Text Font 就可以了。

推荐 Courier New。

设置文本文件及 JSP 文件编码

Window -> Preferences -> General -> Workspace -> Text file encoding -> Other：

设置 JDK 本地 JavaDOC API 路径及源码路径

还都生成的是无意义的变量名，这样可能会对含有相同类型的变量参数的调用顺序造成干扰；

这种问题，我们把 JDK 或者相应 Jar 包的源码导入进去就能避免了：

Window -> Preferences -> Java -> Installed JREs -> Edit：

选中设置好的 JRE 目录，编辑，然后全选 JRE system libraries 下的所有 Jar 包，点击右边的 Source Attachment；

External location 下，选中 JDK 安装目录下的 src.zip 文件，一路 OK 下来。

设置完，我们再来看看，幸福来的好突然有木有！

设置 Servlet 源码或其它 Jar 包源码

上一步已经设置过了 JDK 的源码或 JavaDoc 路径，为啥现在又出来了呢？其实这个不难理解，因为我们使用到的类的源码并不在 JDK 的源码包中。

仔细看，我们会发现这些 Jar 包其实都在 Tomcat 根目录下的 lib 文件夹中，但是翻遍了 Tomcat 目录也没有相应的 jar 或 zip 文件呀。既然本地没有，那就去官网上找找：

http://tomcat.apache.org/download-70.cgi这里有Tomcat的安装包和源码包；

可以自定义一个专门用于存放 JavaSource 和 JavaDoc 的文件夹，把下载文件放到该目录下，

然后再切换到 Eclipse 下，选中没有代码提示的类或者函数， 按下 F3，点击 Change Attached Source：

选择我们刚才下载好的 tomcat 源码文件，一路 OK。

然后再回过头看看我们的代码提示，友好多了：

其它 Jar 包源码的设置方式也一样。

反编译插件 JD-Eclipse

无论是开发还是调试，反编译必不可少，每次都用 jd-gui 打开去看，多麻烦，干脆配置下 JD 插件，自动关联.class：

先从 http://jd.benow.ca/ 上下载离线安装包 jdeclipse_update_site.zip，解压缩后把 features、plugins 这 2 个文件夹复制到 新建文件夹 jdeclipse，然后把 jdeclipse 文件夹整个复制到 Eclipse 根目录的 dropins 文件夹下，重启 Eclipse 即可。这种方式是不是比建 link 文件更方便了？

打开 Eclipse，Window -> Preferences -> General - > Editors ，把 .class 文件设置关联成 jd 插件的 editor

Validate 优化

我们在 eclipse 里经常看到这个进程，validating… 逐个的检查每一个文件。那么如何关闭一些 validate 操作呢？

打开 eclipse，点击【window】菜单，选择【preferences】选项。

在左侧点击【validation】选项，在右侧可以看到 eclipse 进行的自动检查都有哪些内容。

将 Manual（手动）保持不动，将 build 里面只留下 classpath dependency Validator，其他的全部去掉。

最后点击【OK】按钮，保存设置。

以后如果需要对文件进行校验检查的时候，在文件上点击右键，点击【Validate】进行检查。

常用快捷键

一篇文章让你掌握 Python

解释器

Linux/Unix 的系统上，Python 解释器通常被安装在 /usr/local/bin/python3.4 这样的有效路径（目录）里。

我们可以将路径 /usr/local/bin 添加到您的 Linux/Unix 操作系统的环境变量中，这样您就可以通过 shell 终端输入下面的命令来启动 Python 。

在 Linux/Unix 系统中，你可以在脚本顶部添加以下命令让 Python 脚本可以像 SHELL 脚本一样可直接执行：

1

#! /usr/bin/env python3.4

注释

Python 中的注释有三种形式：

• 以 # 开头
• 以 ''' 开始，以 ''' 结尾
• 以 """ 开始，以 """ 结尾

1
2
3
4
5
6
7
8
9
10
11
12
13

# 单行注释

'''
这是多行注释，用三个单引号
这是多行注释，用三个单引号
这是多行注释，用三个单引号
'''

"""
这是多行注释，用三个双引号
这是多行注释，用三个双引号
这是多行注释，用三个双引号
"""

数据类型

Python3 中有六个标准的数据类型：

• Numbers（数字）
• String（字符串）
• List（列表）
• Tuple（元组）
• Sets（集合）
• Dictionaries（字典）

操作符

Python 语言支持以下类型的运算符:

• 算术运算符

• 比较（关系）运算符

• 赋值运算符

• 逻辑运算符

• 位运算符

• 成员运算符

• 身份运算符

• 运算符优先级

算术运算符

比较运算符

赋值运算符

位运算符

逻辑运算符

成员运算符

身份运算符

运算符优先级

控制语句

条件语句

1
2
3
4
5
6

if condition_1:
    statement_block_1
elif condition_2:
    statement_block_2
else:
    statement_block_3

循环语句

while

1
2

while 判断条件：
    statements

for

1
2

for <variable> in <sequence>:
  <statements>

range()

1
2

for i in range(0, 10, 3) :
    print(i)

break 和 continue

• break 语句可以跳出 for 和 while 的循环体。
• continue 语句被用来告诉 Python 跳过当前循环块中的剩余语句，然后继续进行下一轮循环。

pass

pass 语句什么都不做。它只在语法上需要一条语句但程序不需要任何操作时使用.例如:

1
2

while True:
    pass  # 等待键盘中断 (Ctrl+C)

函数

Python 定义函数使用 def 关键字，一般格式如下：

1
2

def  函数名（参数列表）：
    函数体

函数变量作用域

1
2
3
4
5
6
7
8
9
10
11

#!/usr/bin/env python3
a = 4  # 全局变量

def print_func1():
    a = 17 # 局部变量
    print("in print_func a = ", a)
def print_func2():
    print("in print_func a = ", a)
print_func1()
print_func2()
print("a = ", a)

以上实例运行结果如下：

1
2
3

in print_func a =  17
in print_func a =  4
a =  4

关键字参数

函数也可以使用 kwarg=value 的关键字参数形式被调用.例如,以下函数:

1
2
3
4
5

def parrot(voltage, state='a stiff', action='voom', type='Norwegian Blue'):
    print("-- This parrot wouldn't", action, end=' ')
    print("if you put", voltage, "volts through it.")
    print("-- Lovely plumage, the", type)
    print("-- It's", state, "!")

可以以下几种方式被调用:

1
2
3
4
5
6

parrot(1000)                                          # 1 positional argument
parrot(voltage=1000)                                  # 1 keyword argument
parrot(voltage=1000000, action='VOOOOOM')             # 2 keyword arguments
parrot(action='VOOOOOM', voltage=1000000)             # 2 keyword arguments
parrot('a million', 'bereft of life', 'jump')         # 3 positional arguments
parrot('a thousand', state='pushing up the daisies')  # 1 positional, 1 keyword

以下为错误调用方法：

1
2
3
4

parrot()                     # required argument missing
parrot(voltage=5.0, 'dead')  # non-keyword argument after a keyword argument
parrot(110, voltage=220)     # duplicate value for the same argument
parrot(actor='John Cleese')  # unknown keyword argument

可变参数列表

最后,一个最不常用的选择是可以让函数调用可变个数的参数.这些参数被包装进一个元组(查看元组和序列).在这些可变个数的参数之前,可以有零到多个普通的参数:

1
2
3
4
5

def arithmetic_mean(*args):
    sum = 0
    for x in args:
        sum += x
    return sum

返回值

Python 的函数的返回值使用 return 语句，可以将函数作为一个值赋值给指定变量：

1
2
3

def return_sum(x,y):
    c = x + y
    return c

异常

异常处理

try 语句按照如下方式工作；

• 首先，执行 try 子句（在关键字 try 和关键字 except 之间的语句）
• 如果没有异常发生，忽略 except 子句，try 子句执行后结束。
• 如果在执行 try 子句的过程中发生了异常，那么 try 子句余下的部分将被忽略。如果异常的类型和 except 之后的名称相符，那么对应的 except 子句将被执行。最后执行 try 语句之后的代码。
• 如果一个异常没有与任何的 except 匹配，那么这个异常将会传递给上层的 try 中。
• 不管 try 子句里面有没有发生异常，finally 子句都会执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import sys

try:
    f = open('myfile.txt')
    s = f.readline()
    i = int(s.strip())
except OSError as err:
    print("OS error: {0}".format(err))
except ValueError:
    print("Could not convert data to an integer.")
except:
    print("Unexpected error:", sys.exc_info()[0])
    raise
finally:
    # 清理行为

抛出异常

Python 使用 raise 语句抛出一个指定的异常。例如:

1
2
3
4

>>> raise NameError('HiThere')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: HiThere

自定义异常

可以通过创建一个新的 exception 类来拥有自己的异常。异常应该继承自 Exception 类，或者直接继承，或者间接继承。

当创建一个模块有可能抛出多种不同的异常时，一种通常的做法是为这个包建立一个基础异常类，然后基于这个基础类为不同的错误情况创建不同的子类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30