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

Posted 2020-09-30 netoxi

目录

· 大型网站软件系统的特点

· 大型网站架构演化发展历程

    · 初始阶段的网站架构

        · 需求/解决问题

        · 架构

    · 应用服务和数据服务分离

        · 需求/解决问题

        · 架构

    · 使用缓存改善网站性能

        · 需求/解决问题

        · 架构

    · 使用应用服务器集群改善网站的并发处理能力

        · 需求/解决问题

        · 架构

    · 数据库读写分离

        · 需求/解决问题

        · 架构

    · 使用反向代理和CDN加速网站响应

        · 需求/解决问题

        · 架构

    · 使用分布式文件系统和分布式数据库系统

        · 需求/解决问题

        · 架构

    · 使用NoSQL和搜索引擎

        · 需求/解决问题

        · 架构

    · 业务拆分

        · 需求/解决问题

        · 架构

    · 分布式服务

        · 需求/解决问题

        · 架构

· 大型网站架构演化心得

· 大型网站架构模式

    · 综述

    · 分层

        · 概念

        · 目的

        · 举例

    · 分割

        · 概念

        · 目的

        · 举例

    · 分布式

        · 概念

        · 目的

        · 缺点

        · 举例

    · 集群

        · 概念

        · 目的

    · 缓存

        · 概念

        · 目的

        · 举例

    · 异步

        · 概念

        · 目的

    · 冗余

        · 概念

        · 目的

        · 举例

    · 自动化

        · 目的

        · 举例

    · 安全

        · 举例

· 大型网站核心架构要素

    · 性能

        · 网站性能测试

            · 不同视角下的网站性能

            · 性能测试指标

            · 性能测试方法

            · 性能测试报告

        · Web前端性能优化

            · 浏览器访问优化

            · CDN加速

            · 反向代理

        · 应用服务器性能优化

            · 分布式缓存

            · 异步操作

            · 使用集群

            · 代码优化

        · 存储性能优化

    · 可用性

        · 网站可用性的度量与考核

            · 度量

            · 考核

        · 网站架构高可用（总述）

        · 应用层高可用

            · 通过负载均衡进行无状态服务失效转移

            · 应用服务器集群的Session管理

        · 服务层高可用

        · 数据层高可用

            · CAP原理

            · 数据备份

            · 失效转移

        · 高可用网站软件质量保证

            · 网站发布

            · 自动化测试

            · 预发布验证

            · 代码控制

            · 自动化发布

            · 灰度发布

        · 网站运行监控

            · 监控数据采集

            · 监控管理

    · 伸缩性

        · 网站架构的伸缩性设计

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

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

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

            · HTTP重定向负载均衡

            · DNS域名解析负载均衡

            · 反向代理负载均衡

            · IP负载均衡

            · 数据链路层负载均衡

            · 负载均衡算法

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

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

            · 关系数据库集群的伸缩性设计

            · NoSQL数据库集群的伸缩性设计

    · 扩展性

        · 扩展性与伸缩性

        · 构建可扩展的网站架构

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

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

    · 安全性

        · 网站应用攻击与防御

            · XSS攻击

            · 注入攻击

            · CSRF攻击

        · Web应用防火墙

        · 网站安全漏洞扫描

        · 信息加密技术及密钥安全管理

            · 单向散列加密

            · 对称加密

            · 非对称加密

        · 密钥安全管理

· 网购秒杀系统架构设计案例分析

    · 秒杀活动的技术挑战

    · 秒杀系统架构设计

---

 

大型网站软件系统的特点

与传统企业应用相比，大型互联网应用系统有以下特点：

1. 高并发，大流量；

2. 高可用：系统7×24小时不间断服务；

3. 海量数据：需要存储、管理海量数据，需要使用大量服务器；

4. 用户分布广泛，网络情况复杂：许多大型互联网都是为全球用户提供服务的，用户分布范围广，各地网络情况千差万别；

5. 安全环境恶劣：由于互联网的开放性，使得互联网更容易受到攻击，大型网站几乎每天都会被黑客攻击；

6. 需求快速变更，发布频繁：和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，其产品发布频率是极高的；

7. 渐进式发展：与传统软件产品或企业应用系统一开始就规划好全部的功能和非功能需求不同，几乎所有的大型互联网网站都是从一个小网站开始，渐进地发展起来的。

大型网站架构演化发展历程

初始阶段的网站架构

需求/解决问题

小网站最开始没有太多人访问。

架构

应用程序、数据库、文件等所有的资源都在一台服务器上。

应用服务和数据服务分离

需求/解决问题

随着网站业务的发展，越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足。

架构

应用和数据分离后整个网站使用三台服务器，其对硬件资源的要求各不相同：应用服务器处理大量业务逻辑，需要更快更强大的CPU；数据库服务器快速磁盘检索和数据

缓存，需要更快的磁盘和更大的内存；文件服务器存储大量用户上传的文件，需要更大的磁盘。

使用缓存改善网站性能

需求/解决问题

用户逐渐增多，数据库压力太大导致访问延迟。

架构

根据二八定律：80%的业务访问集中在20%的数据上，把小部分数据缓存在内存中，可减少数据库访问压力。

类型	原理	优点	缺点
本地缓存	缓存在应用服务器	访问速度更快	受应用服务器内存限制
分布式缓存	部署大内存缓存服务器集群	理论上不受内存容量限制	--

 

使用应用服务器集群改善网站的并发处理能力

需求/解决问题

单一应用服务器能够处理的请求连接有限。

架构

Scale up有限，Scale out无限，所以应用服务器要Scale out。

 

数据库读写分离

需求/解决问题

一部分读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库。

架构

应用服务器写数据时，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库；当应用服务器读数据时，可通过从数据库获得数据。通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明。

使用反向代理和CDN加速网站响应

需求/解决问题

中国网络环境复杂，不同地区的用户访问网站时，速度差别极大，网站访问延迟导致用户流失率提高。

架构

CDN和反向代理目的都是尽早返回数据、加快访问速度、减轻后端服务器负载压力。

1. CDN：部署在网络提供商机房。用户请求网站服务时，可从距离自己最近的网络提供商机房获取数据。

2. 反向代理：部署在网站中心机房。用户请求到达中心机房后，首先访问反向代理服务器，如果反向代理服务器缓存着用户请求的资源，就将其直接返回给用户。

使用分布式文件系统和分布式数据库系统

需求/解决问题

读写分离伸缩性有限。

架构

只有在单表数据规模非常庞大的时候（不到万不得已）才数据库拆分，按业务分库，不同的业务数据部署在不同的物理服务器上。

使用NoSQL和搜索引擎

需求/解决问题

随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂。

架构

1. NoSQL和搜索引擎都是源自互联网的技术手段，可伸缩的分布式特性更好；

2. 应用服务器通过一个统一数据访问模块访问各种数据。

业务拆分

需求/解决问题

业务场景日益复杂。

架构

1. 将整个网站业务分成不同产品线（如大型购物交易网站拆分为首页、商铺、订单、买家、卖家），分归不同业务团队负责。

2. 根据产品线划分，将网站拆分成不同应用，每个应用独立部署维护。应用间关联方式：

    a) 超链接（首页上导航链接每个应用地址）；

    b) 通过消息队列进行数据分发；

    c) 通过同一数据存储系统构成一个关联的完整系统（最多）。

分布式服务

需求/解决问题

所有应用要和所有数据库系统链接，在数万台服务器规模的网站中，连接数目是服务器规模的平方，导致数据库连接资源不足，拒绝服务。

架构

将共用的业务提取出服务，独立部署。

大型网站架构演化心得

1. 大型网站架构技术的核心价值不是从无到有搭建一个大型网站，而是能够伴随小型网站业务的逐步发展，慢慢地演化成一个大型网站。

2. 驱动大型网站技术发展的主要力量是网站的业务发展。

3. 技术是用来解决业务问题的，而业务问题，也可以通过业务手段去解决。

    a) 12306的问题不在于技术架构，而在于业务架构：几亿中国一票难求的情况下，零点开始出售若干天后的车票；

    b) 解决：售票方式上引入排队机制、整点售票调整为分时段售票。

大型网站架构模式

综述

1. 模式：每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复工作。

2. 网站架构模式：大型互联网公司在实践中提出了许多解决方案，以实现网站高性能、高可用、易伸缩、可扩展、安全等各种技术框架目标。这些解决方案又被更多网站重复使用，从而逐渐形成大型网站架构模式。

分层

概念

1. 将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。

2. 实践中，大的分层结构内部还可以继续分层。

目的

1. 便于分工合作开发和维护；

2. 各层独立，只要维持调用接口不变，各层可根据具体问题独立演化发展而无需其他层必须相应调整；

3. 物理部署上，三层结构可部署在同一物理机器上，随着网站业务发展，必然要分离部署，其三层结构分别部署在不同服务器，使网站拥有更多计算资源应对更多用户访

问。

举例

应用层	负责具体业务和视图展示，如网站首页及搜索输入和结果展示
服务层	为应用层提供服务支持，如用户管理服务，购物车服务等
数据层	提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等

分割

概念

1. 从纵向方面对软件进行切分，将不同功能和服务分割开来，包装成高内聚低耦合的模块单元。

2. 大型网站分割粒度可能会很小。

目的

1. 有助于软件开发和维护；

2. 便于不同模块的分布式部署，提供网站的并发处理能力和功能扩展能力。

举例

1. 在应用层，按业务分割为购物、论坛、搜索、广告不同的应用，独立团队负责，部署在不同服务器；

2. 同一应用内部，如果规模庞大业务复杂，会继续分割，比如购物业务分割为机票酒店业务、3C业务、小商品业务等更细小的粒度。

分布式

概念

分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即不同模块部署在不同服务器上，通过远程调用协同工作。

目的

可使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源也越多，处理并发访问和数据量就越大。

缺点

1. 分布式服务调用必须通过网络，可能会影响性能；

2. 服务器越多，服务器宕机概率就越大；

3. 分布式环境数据一致性非常困难，分布式事务也难以保证；

4. 分布式导致网站依赖错综复杂，开发管理维护困难。

举例

1. 分布式应用和服务：将分层和分割后的应用和服务模块分布式部署。

2. 分布式静态资源：网站的静态资源如JS、CSS、Logo图片等资源独立分布式部署，并采用独立域名，即动静分离。

3. 分布式数据和存储：大型网站需处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，此时需分布式存储。

4. 分布式计算：严格来说，应用、服务、实时数据处理都是计算，网站除了要处理这些在线业务，还有很大一部分后台业务，包括搜索引擎的索引构建、数据仓库的数据分析统计等。

集群

概念

通过负载均衡技术为一个应用构建一个多台服务器组成的集群，共同对外提供服务。

目的

提高系统可用性。

缓存

概念

将数据存放在距离计算最近的位置。

目的

加快处理速度。

举例

1. CDN。

2. 反向代理。

3. 本地缓存。

4. 分布式缓存。

5. 以上4个都在前面章节已说明，不再赘述。

异步

概念

1. 单一服务器内部可通过多线程共享内部队列方式实现异步，业务操作前面的线程将输出写入队列，后面的线程从队列读取数据处理。

2. 分布式系统中，多个服务器集群通过分布式消息队列实现异步。

目的

1. 提高系统可用性：消费者服务器发生故障，数据会在消息队列服务器存储堆积，生产服务器可以继续处理业务请求，系统整体表现无故障。消费者服务器恢复正常后，继续处理消息队列中的数据。

2. 加快网站响应速度：业务处理前端的生产着服务器将数据写入消息队列，无需等待消费者服务器处理就可以返回，响应延迟减少。

3. 消除并发访问高峰：用户访问网站是随机的，虽然存在高峰和低谷，但突发事件（促销活动、微博热点事件）会造成网站并发访问突然增大。使用消息队列将突然增加的访问请求数据放入消息队列，等待消费者服务器依次处理，减小网站负载压力。

4. 解耦，提升扩展性。

5. 缺点：消费者服务器处理（如业务校验、写数据库）失败，以订单提交为例，可在成功提交后Email或短信通知用户订单成功，避免交易纠纷。

冗余

概念

任何服务都必须部署至少两台服务器构成的一个集群。

目的

实现服务高可用。

举例

1. 冷备份：定期备份，存档保存。

2. 热备份：主从分离，实时同步。

自动化

目的

减少人为干预，减少故障。

举例

1. 自动化发布。

    a) 自动化代码管理：代码版本控制、代码分支创建合并等过程自动化，开发工程师只要提交自己参与开发的产品代号，系统自动为其创建开发分支，后期自动合并代码。

    b) 自动化测试：代码开发完成，提交测试后，系统自动将代码部署到测试环境，启动自动化测试用例测试，向相关人员发送测试报告，向系统反馈测试结果。

    c) 自动化安全检测：安全检测工具对代码静态安全扫描及部署到安全测试环境进行安全攻击测试，评估安全性。

    d) 自动化部署：将工程代码自动部署到线上生产环境。

2. 自动化监控。

    a) 自动化报警：对线上生产环境自动化监控，对服务器心跳检测，及各项性能指标和应用程序的关键数据指标。如果发现异常、超出预设阀值，自动化向相关人员发送报警，警告故障可能发生。

    b) 自动化失效转移：检测到故障发生后，系统自动化将失效服务器从集群隔离，不再处理请求。

    c) 自动化失效恢复：待故障消除后，系统自动化重新启动服务，同步数据保证数据一致性。

    d) 自动化降级：网站遇到访问高峰，超出网站最大处理能力时，为保证整个网站安全可用，会自动化拒绝部分请求及关闭部分不重要服务将系统负载降至安全水平。

    e) 自动化分配资源：将空闲资源分配给重要服务，扩大部署规模。

安全

举例

1. 通过密码和手机验证码身份认证。

2. 登录、交易等操作需网络通信加密，网站服务器上存储的敏感数据也加密处理。

3. 使用验证码识别，防止机器人程序滥用网络资源攻击网站。

4. 对常见的用于攻击网站的XSS攻击、SQL注入进行编码转换等处理。

5. 对垃圾信息、敏感信息过滤。

6. 对交易转账等重要操作根据交易模式和交易信息进行风险控制。

大型网站核心架构要素

性能

网站性能测试

不同视角下的网站性能

1. 用户视角：用户在浏览器上直观感受到的网站相应速度，包括用户计算机和网站服务器通信的速度、网站服务器处理的速度、用户计算机浏览器构造请求解析响应数据的速度。

2. 开发人员视角：应用程序本身及其相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标。

3. 运维人员视角：基础设施性能和资源利用率，如网络运营商的带宽、服务器硬件的配置、数据中心网络架构、服务器和网络带宽的资源利用率等。

性能测试指标

1. 响应时间

    a) 解释：从发出请求开始到收到最后响应数据所需要的时间。

    b) 意义：系统最重要的性能指标。

    c) 测试方法：测试程序通过模拟应用程序，记录收到响应和发出请求之间的时间差；通常重复请求，取平均值。

    d) 常用系统操作响应时间表。

操作	响应时间
打开一个网站	几秒
在数据库中查询一条记录（有索引）	十几毫秒
机械磁盘一次寻址定位	4毫秒
从机械磁盘顺序读取1MB数据	2毫秒
从SSD磁盘顺序读取1MB数据	0.3毫秒
从远程分布式缓存Redis读取一个数据	0.5毫秒
从内存中读取1MB数据	十几微妙
Java程序本地方法调用	几微妙
网络传输2KB数据	1微妙

2. 并发数

    a) 解释：同时处理请求的数目，反映了系统的负载特性。网站并发数指“并发用户数”。

    b) 并发用户数：同时提交请求的用户数目。

    c) 在线用户数：当前登录网站的用户数目。

    d) 系统用户数：可能访问系统的总用户数，对多数网站而言就是注册用户数。

    e) 三者数量比较关系：系统用户数>>在线用户数>>并发用户数。

    f) 意义：网站产品设计初期，产品经理和运营人员要规划不同发展阶段网站系统用户数，以此为基础，推算在线用户数和并发用户数，这些指标是非功能设计的重要依据。

    g) 测试方法：测试程序多线程模拟并发用户测试并发处理能力；测试程序并不多线程不停发送请求，而是两次请求间加随机等待时间，模拟用户思考时间。

3. 吞吐量

    a) 解释：单位时间内系统处理的请求数量。

    b) 常用量化指标：“请求数/秒”或“页面数/秒”、“访问人数/天”或“处理的业务数/小时”、TPS（每秒事务数）、HPS（每秒HTTP请求数）、QPS（每秒查询数）。

    c) 三者关系：并发数由小逐增过程中，服务器资源消耗逐增，吞吐量逐增，响应时间小幅上升；达到吞吐量极限后，并发数增加反而下降，响应时间快速上升；达到系统崩溃点后，系统资源耗尽，吞吐量为零，失去响应。

4. 性能计数器

    a) 解释：描述服务器或操作系统性能一些数据指标，包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络IO等。

    b) 意义：系统监控的重要参数，监控系统发现性能计数器超过阀值时，向运维人员报警，及时发现处理异常。

    c) System Load（系统负载）：当前正在被CPU执行和等待被CPU执行的进程数目总和，反映系统闲忙程度的重要指标。多核CPU情况下，Load值等于CPU数目时，说明所有CPU都在使用，没有CPU不足和空闲；Load值大于CPU数目时，说明进程排队等待CPU调度，资源不足；Load值小于CPU数目时，说明CPU空闲。Linux的“top”命令可查询最近1分钟、10分钟、15分钟的运行队列平均进程数。

性能测试方法

1. 性能测试是总称，细分为：

    a) 性能测试：以系统设计初期规划的性能指标为预期目标，不断施加压力（增加并发请求），验证系统在资源可接受范围，可否达到预期。

    b) 负载测试：不断施加压力（增加并发请求），直到某项或多项性能指标达到安全临界值（比如资源已饱和）。此时继续加压，系统处理能力会下降。

    c) 压力测试：超过安全负载情况下，不断施加压力（增加并发请求），直到系统崩溃或无法处理任何请求，依此获得系统最大压力承受能力。

    d) 稳定性测试：被测试系统在特定硬件、软件、网络环境下，加载一定业务压力（模拟生产环境不同时间点、不均匀请求，呈波浪特性）运行一段较长时间，以此检测系统是否稳定。

2. 性能测试曲线：横坐标为消耗的系统资源，纵坐标为吞吐量。a~b为网站日常运行区间，c为系统最大负载点，d为系统崩溃点。

性能测试报告

并发数	响应时间（ms）	TPS	错误率（%）	Load	内存（GB）	备注
10	500	20	0	5	8	性能测试
20	800	30	0	10	10	性能测试
30	1000	40	2	15	14	性能测试
40	1200	45	20	30	16	负载测试
60	2000	30	40	50	16	压力测试
80	超时	0	100	不详	不详	压力测试

Web前端性能优化

浏览器访问优化

1. 减少HTTP请求：合并CSS、合并javascript、合并图片。

2. 使用浏览器缓存：CSS、JavaScript、Logo、图标等静态资源文件更新频率较低，通过HTTP头Cache-Control和Expires设置缓存数天，甚至几个月。更新此类文件时，不更新内容，而是修改文件名，生成新文件并更新html引用。当有一批此类文件要更新时，不宜一次全部更新，而是逐个更新，并有时间间隔，以免浏览器大量缓存失效，集中更新缓存，服务器负载剧增。

3. 启用压缩：文本文件（如HTML、CSS、JavaScript）GZip压缩率可达80%以上，有效减少通信传输数据量。但服务器、浏览器压力上升，所以要权衡。

4. CSS放在页面最上面，JavaScript放在页面最下面：浏览器下载全部CSS后才渲染页面，而在加载JavaScript后立即执行，可能会阻塞页面，渲染缓慢。

5. 减少Cookie传输：每次请求和响应都会包含Cookie，影响数据传输；静态资源访问（如CSS、JavaScript）发送Cookie无意义。可静态资源使用独立域名，避免请求静态资源时发送Cookie。

CDN加速

前面章节已说明，不再赘述。

反向代理

前面章节已说明，不再赘述。

应用服务器性能优化

分布式缓存

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

2. 缓存优点：缓存访问速度快，减少数据访问时间；如果缓存的数据是经过计算得到的，则此类数据无需重复计算可直接使用。

3. 缓存本质：以一对Key、Value形式存储在内存的Hash表，读写时间复杂度O(1)。

4. 使用缓存注意事项。

    a) 频繁修改的数据：如果缓存频繁修改的数据，会造成写入缓存后来不及读取已失效。一般数据读写比应在2:1以上，甚至更高。

    b) 没有热点的访问：缓存使用内存，资源宝贵，应遵循二八定律，即缓存20%热点数据。

    c) 数据不一致与脏读：一般设置缓存失效时间，失效后从数据库加载，因此要容忍一定时间的数据不一致。也可数据更新时立即更新缓存，但会带来更多系统开销和事务一致性问题。

    d) 缓存可用性：为避免缓存雪崩（缓存不可用造成数据库无法承受压力而宕机），可将缓存数据分布到集群多台服务器，宕机时只有部分缓存数据丢失。

    e) 缓存预热（warn up）：热点数据是通过LRU（最近最久未用算法）淘汰生成的，需较长时间。

    f) 缓存穿透：缓存不存在的数据（其值为null），避免不恰当业务或恶意攻击高并发请求某个不存在数据，造成数据库压力而崩溃。

异步操作

前面章节已说明，不再赘述。

使用集群

前面章节已说明，不再赘述。

代码优化

1. 多线程

    a) 目的：利用多线程IO阻塞与执行交替进行，最大限度利用CPU资源；多线程最大限度利用多核CPU。

    b) Web容器线程数设置：如果都是CPU计算型任务，则线程数最多不超过CPU内核数（更多线程CPU来不及调度）；如果都是等待磁盘IO、网络IO的任务，则多启动线程有助于提高任务并发度，提高吞吐能力。

2. 资源复用：单例（Singleton）、对象池（Object Pool）。

3. 数据结构。

4. 垃圾回收：即优化JVM。

存储性能优化

可能暂时不重要，以后需要时在看书。

可用性

网站可用性的度量与考核

度量

1. 业界通常用多少个9来衡量网站可用性。

2. 网站不可用也称网站故障。

3. 网站不可用时间公式：

网站不可用时间（故障时间）= 故障修复时间点-故障发现（报告）时间点

4. 网站年度可用性指标公式：

网站年度可用性指标 =（1-网站不可用时间/年度总时间）×100%

5. 常见可用性：

可用性（9）	可用性（百分比）	网站年度不可用时间	说明
2个9	99%	小于88小时
3个9	99.9%	小于9小时
4个9	99.99%	小于53分钟	具有自动恢复能力
5个9	99.999%	小于5分钟	可用性极高

考核

1. 故障分：对网站故障进行分类加权计算故障责任的方法。

2. 网站故障分类权重表（示例）

分类	描述	权重
事故级故障	严重故障，网站整体不可用	100
A类故障	网站访问不顺畅或核心功能不可用	20
B类故障	非核心功能不可用，或核心功能少数用户不可用	5
C类故障	以上故障以外的其他故障	1

3. 故障分公式：

故障分=故障时间（分钟）×故障权重

4. 考核过程：年初或考核季度开始时，根据网站产品可用性指标计算总的故障分，然后根据团队和个人职责角色分摊故障分，这个可用性指标和故障分是管理预期；故障发生后，根据故障分类和责任划分给故障产生的故障分分配给责任者承担；年末或考核季度末时，个人及团队实际承担的故障分如果超过年度分摊的故障分，绩效考核受到影响。

网站架构高可用（总述）

1. 以百度为例。

    a) 应用层：文库、贴吧、百科等属不同产品，各自独立部署集群。

    b) 服务层：应用层产品依赖共同的复用业务，这些业务服务各自部署集群。

    c) 数据层：各自部署集群。

2. 实现高可用架构主要手段：数据和服务的冗余备份及失效转移。

3. 应用层高可用：通过负载均衡设备将一组服务器组成一个集群对外处理高并发请求，负载均衡设备通过心跳检测等手段监控到应用服务器不可用时，将其从集群列表剔除，请求分发到集群其他可用服务器上。

4. 服务层高可用：也是通过集群实现高可用。服务层被应用层通过分布式服务调用框架访问，分布式服务调用框架在应用层客户端中实现负载均衡，服务注册中心获取服务层服务器心跳检测，发现不可用服务器，立即通知客户端修改服务层访问列表，剔除不可用服务器（说的就是Dubbo）。

5. 数据层高可用：比较特殊，数据服务器存储了数据。数据写入时同步复制数据到多台服务器上，实现数据冗余备份；数据服务器宕机时，数据访问切换到备份数据服务器上。

6. 网站升级发布可能引起故障。

应用层高可用

通过负载均衡进行无状态服务失效转移

无状态应用：应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据处理业务逻辑，多台服务器之间完全对等，请求提交到任意服务器结果一样。是应用层高可用的基础。

应用服务器集群的Session管理

事实上业务总是有状态的（Session），负载均衡集群环境下，负载均衡服务器可能会将请求分发到集群任何依他应用服务器上，所以每次请求获取正确的Session要比单机复杂。几种手段：

1. Session复制：集群各台服务器间同步Session对象，每台服务器都保存所有用户的Session信息。服务器内存无法保存大量Session，不适合大型网站。

2. Session绑定：利用负载均衡的源地址Hash算法，负载均衡服务器总是将源于同一IP的请求分发到同一服务器。服务器宕机Session丢失，无法高可用，不适合大型网站。

3. 利用Cookie记录Session：Cookie大小限制；每次请求响应都传输Cookie，影响性能；用户关闭Cookie将不正常。Cookie简单易用，可用性高，支持应用服务器线性伸缩，许多网站或多或少都使用Cookie记录Session。

4. Session服务器：利用分布式缓存、数据库等存取Session，实现应用服务器的状态分离。可用性高、伸缩性好、性能不错，适合大型网站。

服务层高可用

1. 分级管理。

    a) 核心应用和服务优先使用更好的硬件和更快的运维响应速度。

    b) 部署隔离，避免故障连锁反应：低优先级服务启动不同线程或部署在不同虚拟机上隔离；高优先级服务部署在不同物理机上；核心服务和数据甚至部署在不同地域的数据中心。

2. 超时设置：在应用程序设置服务调用超时时间，超时后通信框架抛出异常，避免因服务器宕机、线程死锁导致应用程序对服务端调用失去响应，进而用户请求长时间得不到响应，同时占用应用程序资源。

3. 异步调用：前面章节已说明，不再赘述。

4. 服务降级：有两种手段。

    a) 拒绝服务：拒绝低优先级应用的调用，减少并发数，确保核心应用正常调用；随机拒绝部分请求调用，让另一部分请求成功，避免大家一起死的餐具。

    b) 关闭服务：关闭部分不重要服务或服务内部关闭部分不重要功能，节约开销。

5. 幂等性设计：应用层只要未收到调用成功的响应，都认为调用服务失败，并重试服务调用，因此服务层必须保证服务重复调用和调用一次的结果相同，即服务具有幂等性。

数据层高可用

CAP原理

1. 数据高可用含义。

    a) 数据持久性：在各种情况下都不会出现数据丢失问题。

    b) 数据可访问性：多数据副本分别存放在不同存储设备情况下，失效转移能很快完成（终端用户几乎没有感知）。

    c) 数据一致性：多数据副本情况下，各副本之间数据一致。

2. CAP原理：一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availability）、分区耐受性（Partition Tolerance）这三个条件。

3. 大型网站实践：通常选择强化分布式存储系统的可用性（A）和伸缩性（P），而在某种程度上放弃一致性（C）。一般数据不一致出现在系统高并发写操作或集群状态不稳定（故