紧接上篇《大型网站技术架构：核心原理与案例分析-第1篇 概述》

4　瞬时响应：网站的高性能架构

1. 网站性能测试
2. Web前端性能优化
3. 应用服务器性能优化

5　万无一失：网站的高可用架构

1. 网站可用性的度量与考核
2. 高可用的网站架构
3. 高可用的应用
4. 高可用的服务
5. 高可用的数据
6. 高可用网站的软件质量保证
7. 网站运行监控

6　永无止境：网站的伸缩性架构

1. 网站架构的伸缩性设计
2. 应用服务器集群的伸缩性设计
3. 分布式缓存集群的伸缩性设计
4. 数据存储服务器集群的伸缩性设计

7　随需应变：网站的可扩展架构

1. 构建可扩展饿网站架构
2. 利用分布式消息队列降低系统耦合性
3. 利用分布式服务打造可复用的业务平台

8　固若金汤：网站的安全架构

1. 道高一尺魔高一丈的网站应用攻击与防御
2. 信息加密技术及密钥安全管理

第2篇　架构

• 4　瞬时响应：网站的高性能架构
• 4.1　网站性能测试
• 4.1.1　不同视角下的网站性能
• 4.1.2　性能测试指标
• 4.1.3　性能测试方法
• 4.1.4　性能测试报告
• 4.1.5　性能优化策略
• 4.2　Web前端性能优化
• 4.2.1　浏览器访问优化
• 4.2.2　CDN加速
• 4.2.3　反向代理
• 4.3　应用服务器性能优化
• 4.3.1　分布式缓存
• 4.3.2　异步操作
• 4.3.3　使用集群
• 4.3.4　代码优化
• 4.4　存储性能优化
• 4.4.1　机械硬盘vs.固态硬盘
• 4.4.2　B＋树vs.LSM树
• 4.4.3　RAIDvs.HDFS
• 5　万无一失：网站的高可用架构
• 5.1　网站可用性的度量与考核
• 5.1.1　网站可用性度量
• 5.1.2　网站可用性考核
• 5.2　高可用的网站架构
• 5.3　高可用的应用
• 5.3.1　通过负载均衡进行无状态服务的失效转移
• 5.3.2　应用服务器集群的Session管理
• 5.4　高可用的服务
• 5.5　高可用的数据
• 5.5.1　CAP原理
• 5.5.2　数据备份
• 5.5.3　失效转移
• 5.6　高可用网站的软件质量保证
• 5.6.1　网站发布
• 5.6.2　自动化测试
• 5.6.3　预发布验证
• 5.6.4　代码控制
• 5.6.5　自动化发布
• 5.6.6　灰度发布
• 5.7　网站运行监控
• 5.7.1　监控数据采集
• 5.7.2　监控管理
• 6　永无止境：网站的伸缩性架构
• 6.1　网站架构的伸缩性设计
• 6.1.1　不同功能进行物理分离实现伸缩
• 6.1.2　单一功能通过集群规模实现伸缩
• 6.2　应用服务器集群的伸缩性设计
• 6.2.1　HTTP重定向负载均衡
• 6.2.2　DNS域名解析负载均衡
• 6.2.3　反向代理负载均衡
• 6.2.4　IP负载均衡
• 6.2.5　数据链路层负载均衡
• 6.2.6　负载均衡算法
• 6.3　分布式缓存集群的伸缩性设计
• 6.3.1　Memcached分布式缓存集群的访问模型
• 6.3.2　Memcached分布式缓存集群的伸缩性挑战
• 6.3.3　分布式缓存的一致性Hash算法
• 6.4　数据存储服务器集群的伸缩性设计
• 6.4.1　关系数据库集群的伸缩性设计
• 6.4.2　NoSQL数据库的伸缩性设计
• 7　随需应变：网站的可扩展架构
• 7.1　构建可扩展的网站架构
• 7.2　利用分布式消息队列降低系统耦合性
• 7.2.1　事件驱动架构
• 7.2.2　分布式消息队列
• 7.3　利用分布式服务打造可复用的业务平台
• 7.3.1　WebService与企业级分布式服务
• 7.3.2　大型网站分布式服务的需求与特点
• 7.3.3　分布式服务框架设计
• 7.4　可扩展的数据结构
• 7.5　利用开放平台建设网站生态圈
• 8　固若金汤：网站的安全架构
• 8.1　道高一尺魔高一丈的网站应用攻击与防御
• 8.1.1　XSS攻击
• 8.1.2　注入攻击
• 8.1.3　CSRF攻击
• 8.1.4　其他攻击和漏洞
• 8.1.5　Web应用防火墙
• 8.1.6　网站安全漏洞扫描
• 8.2　信息加密技术及密钥安全管理
• 8.2.1　单向散列加密
• 8.2.2　对称加密
• 8.2.3　非对称加密
• 8.2.4　密钥安全管理
• 8.3　信息过滤与反垃圾
• 8.3.1　文本匹配
• 8.3.2　分类算法
• 8.3.3　黑名单
• 8.4　电子商务风险控制
• 8.4.1　风险
• 8.4.2　风控

第3篇　案例

• 9　淘宝网的架构演化案例分析
• 10　维基百科的高性能架构设计分析
• 11　海量分布式存储系统Doris的高可用架构设计分析
• 12　网购秒*系统架构设计案例分析
• 13　大型网站典型故障案例分析
• 13.1　写日志也会引发故障
• 13.2　高并发访问数据库引发的故障
• 13.3　高并发情况下锁引发的故障
• 13.4　缓存引发的故障
• 13.5　应用启动不同步引发的故障
• 13.6　大文件读写独占磁盘引发的故障
• 13.7　滥用生产环境引发的故障
• 13.8　不规范的流程引发的故障
• 13.9　不好的编程习惯引发的故障

第4篇　架构师

• 14　架构师领导艺术
• 15　网站架构师职场攻略
• 16　漫话网站架构师

同类型的两个网站，X网站服务器平均每个请求的处理时间是500毫秒，Y网站服务器平均每个请求的处理时间是1000毫秒，为什么用户却反映Y网站的速度快呢？

网站性能是客观的指标，可以具体体现到响应时间、吞吐量等技术指标，同时也是主观的感受，而感受则是一种与具体参与者相关的微妙的东西，用户的感受和工程师的感受不同，不同的用户感受也不同。

性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。不同视角下的网站性能有不同的标准，也有不同的优化手段。

4.1.1 不同的视角下的网站性能

1．用户视角的网站性能

从用户角度，网站性能就是用户在浏览器上直观感受到的网站响应速度快还是慢。用户感受到的时间，包括用户计算机和网站服务器通信的时间、网站服务器处理的时间、用户计算机浏览器构造请求解析响应数据的时间。

在实践中，使用一些前端架构优化手段，通过优化页面HTML式样、利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反向代理等手段，使浏览器尽快地显示用户感兴趣的内容、尽可能近地获取页面内容，即使不优化应用程序和架构，也可以很大程度地改善用户视角下的网站性能。

2．开发人员视角的网站性能

开发人员关注的主要是应用程序本身及其相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标。主要的优化手段有使用缓存加速数据读取，使用集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码优化手段改善程序性能。

3．运维人员视角的网站性能

运维人员更关注基础设施性能和资源利用率，如网络运营商的带宽能力、服务器硬件的配置、数据中心网络架构、服务器和网络带宽的资源利用率等。主要优化手段有建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用等。

4.1.2 性能测试指标

1．响应时间

2．并发数

指系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。

网站系统用户数>>网站在线用户数>>网站并发用户数

3．吞吐量

指单位时间内系统处理的请求数量，体现系统的整体处理能力。对于网站，可以用“请求数/秒”或是“页面数/秒”来衡量，也可以用“访问人数/天”或是“处理的业务数/小时”等来衡量。TPS（每秒事务数）是吞吐量的一个常用量化指标，此外还有HPS（每秒HTTP请求数）、QPS（每秒查询数）等。

系统吞吐量和系统并发数，以及响应时间的关系可以形象地理解为高速公路的通行状况：吞吐量是每天通过收费站的车辆数目（可以换算成收费站收取的高速费），并发数是高速公路上的正在行驶的车辆数目，响应时间是车速。

4．性能计数器

它是描述服务器或操作系统性能的一些数据指标。包括SystemLoad、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。这些指标也是系统监控的重要参数，对这些指标设置报警阈值，当监控系统发现性能计数器超过阈值时，就向运维和开发人员报警，及时发现处理系统异常。

4.1.3 性能测试方法

性能测试是一个总称，具体可细分为性能测试、负载测试、压力测试、稳定性测试。

性能测试

以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。

负载测试

对系统不断地增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值，如某种资源已经呈饱和状态，这时继续对系统施加压力，系统的处理能力不但不能提高，反而会下降。

压力测试

超过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。

稳定性测试

被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。在不同生产环境、不同时间点的请求压力是不均匀的，呈波浪特性，因此为了更好地模拟生产环境，稳定性测试也应不均匀地对系统施加压力。

一般说来Web前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、图片服务、CDN服务等，主要优化手段有优化浏览器访问、使用反向代理、CDN等。

4.2.1 浏览器访问优化

1. 减少http请求

HTTP协议是无状态的应用层协议，意味着每次HTTP请求都需要建立通信链路、进行数据传输，而在服务器端，每个HTTP都需要启动独立的线程去处理。这些通信和服务的开销都很昂贵，减少HTTP请求的数目可有效提高访问性能。

减少HTTP的主要手段是合并CSS、合并JavaScript、合并图片。将浏览器一次访问需要的JavaScript、CSS合并成一个文件，这样浏览器就只需要一次请求。图片也可以合并，多张图片合并成一张，如果每张图片都有不同的超链接，可通过CSS偏移响应鼠标点击操作，构造不同的URL。

2. 使用浏览器缓存

通过设置HTTP头中CacheControl和Expires的属性，可设定浏览器缓存，缓存时间可以是数天，甚至是几个月。

在某些时候，静态资源文件变化需要及时应用到客户端浏览器，这种情况，可通过改变文件名实现，即更新JavaScript文件并不是更新JavaScript文件内容，而是生成一个新的JS文件并更新HTML文件中的引用。

3. 启用压缩

4. CSS放在页面最上面、JavaScript放在页面下面

5. 减少Cookie传输

反向代理

和传统代理服务器可以保护浏览器安全一样，反向代理服务器也具有保护网站安全的作用，来自互联网的访问请求必须经过代理服务器，相当于在Web服务器和可能的网络攻击之间建立了一个屏障。

优化手段主要有缓存、集群、异步等。

1. 分布式缓存

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

合理使用缓存

• 频繁修改的数据：一般说来，数据的读写比在2:1以上，即写入一次缓存，在数据更新前至少读取两次，缓存才有意义。
• 没有热点的访问
• 数据不一致与脏读
• 缓存可用性
• 缓存预热：最好在缓存系统启动时就把热点数据加载好，这个缓存预加载手段叫作缓存预热（warmup）。
• 缓存穿透

2. 分布式缓存架构

3. 异步操作

任何可以晚点做的事情都应该晚点再做。

5.1.1　网站可用性度量

对于大多数网站而言，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟。

5.1.2　网站可用性考核

不同的业务产品会部署在不同的服务器集群上，如某网站的文库、贴吧、百科等属于不同的产品，部署在各自独立的服务器集群上，互不相干。这些产品又会依赖一些共同的复用业务，如注册登录服务、Session管理服务、账户管理服务等，这些可复用的业务服务也各自部署在独立的服务器集群上。至于数据层，数据库服务、文件服务、缓存服务、搜索服务等数据存储与访问服务都部署在各自独立的服务器集群上。

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

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

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

1、分级管理

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

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

2、超时设置

在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据服务调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。

3、异步调用

如果采用异步调用的方式，应用程序将用户注册信息发送给消息队列服务器后立即返回用户注册成功响应。

4、服务降级

为了保证核心应用和功能的正常运行，需要对服务进行降级。降级有两种手段：拒绝服务及关闭服务。

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

关闭功能：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为重要的服务和功能让出资源。淘宝在每年的“双十一”促销中就使用这种方法，在系统最繁忙的时段关闭“评价”、“确认收货”等非核心服务，以保证核心交易服务的顺利完成。

5、幂等性设计

应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。比如服务已经处理成功，但因为网络故障应用没有收到响应，这时应用重新提交请求就导致服务重复调用，如果这个服务是一个转账操作，就会产生严重后果。

服务重复调用是无法避免的，应用层也不需要关心服务是否真的失败，只要没有收到调用成功的响应，就可以认为调用失败，并重试服务调用。因此必须在服务层保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。

有些服务天然具有幂等性，比如将用户性别设置为男性，不管设置多少次，结果都一样。但是对于转账交易等操作，问题就会比较复杂，需要通过交易编号等信息进行服务调用有效性校验，只有有效的操作才能继续执行。

5.4.1 CAP原理

1、数据持久型

2、数据可访问性

3、数据一致性

CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（PatitionTolerance，系统具有跨网络分区的伸缩性）这三个条件。

5.6.1 网站发布

5.6.2 自动化测试

5.6.3 预发布验证

即使是经过严格的测试，软件部署到线上服务器之后还是经常会出现各种问题，甚至根本无法启动服务器。主要原因是测试环境和线上环境并不相同，特别是应用需要依赖的其他服务，如数据库，缓存、公用业务服务等，以及一些第三方服务，如电信短信网关、银行网银接口等。

也许是数据库表结构不一致；也许是接口变化导致的通信失败；也许是配置错误导致连接失败；也许是依赖的服务线上环境还没有准备好，这些问题都有可能导致应用故障。

因此在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一些典型的业务流程，确认系统没有问题后才正式发布。

预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的不同就是没有配置在负载均衡服务器上，外部用户无法访问。

在网站应用中强调的一个处理错误的理念是快速失败（fastfailed），即如果系统在启动时发现问题就立刻抛出异常，停止启动让工程师介入排查错误，而不是启动后执行错误的操作。

5.6.4 代码控制

5.6.5 自动化发布

对于有固定发布日期的网站（很多网站选择周四作为发布日，这样一周前面有三天时间可以准备发布，后面还有一天时间可以挽回错误。如果选择周五发布，发现问题就必须要周末加班了。），一到发布日，整个技术部门甚至运营部门就如临大敌，电话声此起彼伏，工程师步履匆匆，连空气中的温度都仿佛升高了几度。即便如此，发布过程还是常常出错，发布日工程师加班到凌晨是常有的事。而且容易忙中出错，因发布引发的故障也居高不下。

5.6.6 灰度发布

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

事物总是先求生存，然后求发展。

一般说来，网站的伸缩性设计可分成两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务，提供不同的功能；后者是集群内的多台服务器部署相同的服务，提供相同的功能。

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

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

横向分离（业务分割后分离）：将不同的业务模块分离部署，实现系统伸缩性。

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

当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车。

6.2.1 HTTP重定向负载均衡

HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应中（响应状态码302）返回给用户浏览器。

这种负载均衡方案的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差；重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用HTTP302响应码重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。因此实践中使用这种方案进行负载均衡的案例并不多见。

6.2.2 DNS域名解析负载均衡

DNS域名解析负载均衡的优点是将负载均衡的工作转交给DNS，省掉了网站管理维护负载均衡服务器的麻烦，同时许多DNS还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样可加快用户访问速度，改善性能。但是DNS域名解析负载均衡也有缺点，就是目前的DNS是多级解析，每一级DNS都可能缓存A记录，当下线某台服务器后，即使修改了DNS的A记录，要使其生效也需要较长时间，这段时间，DNS依然会将域名解析到已经下线的服务器，导致用户访问失败；而且DNS负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。