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

时间 2019-11-11

标签大型网站技术架构核心原理案例分析笔记栏目网站开发繁體版

原文原文链接

大型网站软件系统的特色

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

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）。通常数据不一致出如今系统高并发写操做或集群状态不稳定（故障恢复、集群扩容等）时，应用系统要对分布式数据处理系统的数据不一致性有了解并进行某种意义上的补偿和纠错，以保证最终一致性。

4. 举例：2012年淘宝“双十一”，活动开始第一分钟就涌入1000万独立用户访问，极端的高并发对数据处理系统形成巨大压力，存储系统较弱的数据一致性致使部分商品超卖。

数据备份

1. 冷备。

a) 优势：简单、廉价，成本和技术难度都较低。

b) 缺点：没法保证数据一致性（备份设备中的数据比系统中的数据陈旧）。

c) 现状：做为传统的数据保护手段依然在运维中使用。

2. 热备。

a) 异步热备：多份数据副本的写入操做异步完成，即应用程序收到数据服务系统的写操做成功响应时，只写成功了一份，存储系统将异步地写其余副本（该过程可能失败）。

b) 同步热备：多份数据副本的写入操做同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操做成功。

3. 同步热备优化：应用程序客户端并发向多个存储服务器同时写入数据，全部写操做成功响应后，再通知应用程序成功。优势：存储服务器无主从之分，彻底对等，便于管理维护；并发写操做意味着多份数据的总写操做延时是响应最慢的那台存储服务响应。

4. 实际：一般使用读写分离，写操做只访问Master数据库，读操做只访问Slave数据库。

失效转移

1. 失效确认：有心跳检测和应用程序访问失败报告两种手段。对于后者，控制中心还要再一次发送心跳检测确认，以避免错误判断服务器宕机。

2. 访问转移：将数据读写访问从新路由到其余服务器上。

3. 数据恢复：数据副本数目已减小，必须将副本数目恢复到系统设定的值，不然再有宕机可能没法访问转移（全部副本服务器宕机）。

高可用网站软件质量保证

网站发布

1. 网站发布是一次提早预知的服务器宕机，过程能够更柔和，对用户影响更小。

2. 一般使用发布脚本完成发布。

自动化测试

1. 目的：回归测试，以保证没有引入未预料的Bug；测试浏览器兼容性。

2. 实际：大部分网站采用Web自动化测试，使用自动化测试工具或脚本完成测试。如Selenium。

预发布验证

1. 缘由：测试环境和线上环境不一样，特别是应用依赖的服务（如数据库、缓存、功用业务服务、电信短信网关、银行网银接口等）。

2. 方法：先发布到预发布上，工程师在预发布服务器上验证（如执行典型业务流程）后，确认无误才正式发布。预发布服务器与线上正式服务器惟一的区别是没有配置在负载均衡服务器上，外部用户没法访问。

代码控制

1. 主干开发、分支发布：在主干上修改代码，发布时，从主干拉一个分支发布；若是发现Bug，继续在该分支上修改发布，并将修改合并回主干。

a) 优势：主干代码反映整个应用的状态，一目了然，便于管理，也利于持续集成。

b) 缺点：A功能发布的时候，B功能时半成品，致使A没法发布。

2. 分支发布、主干发布：不得在主干上直接修改，开发新功能或修复Bug时，从主干拉一个分支开发，完成且测试经过后，合并回主干，而后从主干发布，主干上代码永远是最新发布的版本。

a) 优势：各分支独立，互不干扰，使不一样发布周期的开发在同一应用进行。

b) 网站开发主要使用该方式。

自动化发布

1. 固定发布日期：不少网站选择周四做为发布日，这样一周前面有三天时间准备发布，后面还有一天时间能够挽回错误。若是选择周五发布，发现问题就必需要周末加班了。

2. 火车发布模型：每一个应用发布过程看做一次火车旅行，火车定点运行，期间有若干站点，每一站都例行检查，不经过的项目下车，剩下的下项目继续坐火车旅行，直到火车到到终点（发布成功）。有可能全部项目都下车，那么空车前进是没意义的，火车要回到起点，等待问题解决再重来。还有可能车上有重点项目，他出了错，你们都跟着重来。

3. 火车发布模型基于规则驱动流程，因此能够自动化。

灰度发布

1. 目的：大型网站集群规模很是庞大，故障发生后回滚须要很长时间完成。

2. 方法：将集群服务器分为若干部分，天天只发布其中一部分，观察稳定无端障后，持续几天才把整个集群所有发布完毕，期间发现问题，只要回滚已发布的一部分服务器。

网站运行监控

监控数据采集

广义上网站监控涵盖全部非直接业务行为的数据采集和管理，包括数据分析师和产品设计师的网站用户行为日志、业务运行数据，运维工程师和开发工程师使用的系统性能数据等。

1. 用户行为日志收集：用户在浏览器上的全部操做及其操做环境，包括操做系统、浏览器版本、IP地址、页面访问路径、网页停留时间等，对统计网站PV/UV、分析用户行为、优化网站设计、个性营销与推荐很是重要。

a) 服务器端日志收集：优势是简单，Web服务器都支持；缺点是失真（如代理服务器IP非真实IP），没法识别访问路径。

b) 浏览器日志收集：优势是精准；缺点是比较麻烦，在页面嵌入JavaScript收集。

c) 日志处理：数据量惊人，存储和计算压力大，许多网站基于实时计算框架Storm日志统计与分析。

2. 服务器性能监控：收集服务器性能指标，如系统Load、内存占用、磁盘IO、网络IO等。

a) 目的：尽早故障预警，防患于未然；合理安排集群规模、改善性能和调整伸缩性的依据。

b) 工具：Zabbix、Ganglia、Nagios。

监控管理

1. 系统预警：超过预设阀值意味着可能出现故障，此时经过邮件、短信等方式报警。

2. 失效转移：除应用程序访问时失效转移，监控系统在发现故障时主动通知应用失效转移。

3. 自动优雅降级：前面章节已说明，再也不赘述。

伸缩性

网站架构的伸缩性设计

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

1. 方法：不一样服务器部署不一样服务，提供不一样功能。

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

3. 横向分离（业务分割后分离）：将不一样的业务模块分离部署，实现伸缩性。

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

方法：集群内的多台服务器部署相同服务，提供相同功能。

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

1. 负载均衡器：HTTP请求分发装置。

2. 负载均衡：同时实现伸缩性和可用性，可谓网站的杀手锏。

HTTP重定向负载均衡

1. 原理：HTTP重定向服务器根据用户的HTTP请求计算一台真实Web服务器地址，将该地址写入HTTP重定向响应（状态码302）返回用户浏览器。

2. 优势：简单。

3. 缺点：浏览器两次请求服务器才能完成一次访问；302状态码重定向可能使搜索引擎判断为SEO做弊，下降搜索排名。

4. 实际：很少见。

DNS域名解析负载均衡

1. 原理：DNS服务器中配置多个A记录（如www.mysite.com IN A 114.100.80.一、www.mysite.com IN A 114.100.80.二、www.mysite.com IN A 114.100.80.3），每次域名解析请求都会根据负载均衡算法计算一个IP地址返回。

2. 优势：负载均衡交给DNS，省去维护负载均衡服务器的麻烦；DNS支持基于地理位置的解析，即解析距离用户最近的服务器地址。

3. 缺点：服务器下线时，更新DNS解析生效时间较长；DNS负载均衡控制权在域名服务商，没法对其更多改善和管理。

4. 实际：大型网站使用DNS解析做为第一级负载均衡，即解析获得的一组服务器是内部负载均衡服务器，再由内部负载均衡服务器分发到真是Web服务器。

反向代理负载均衡

1. 原理：反向代理同时实现了缓存和负载均衡功能；Web服务器不使用外部IP地址，由反向代理服务器配置双网卡和内外两套IP地址。

2. 优势：反向代理服务器功能集中，部署简单。

3. 缺点：反向代理服务器是全部请求的响应的中转站，性能可能成为瓶颈。

IP负载均衡

1. 原理：负载均衡服务器114.10.80.10在操做系统内核进程获取网络数据包，根据负载均衡算法计算获得一台Web服务器10.0.0.1，再将数据目的IP地址修改成10.0.0.1，无需用户进程处理；Web服务器10.0.0.1响应后，负载均衡服务器再将数据包源地址修改成自身IP地址114.10.80.10，发送给浏览器。

2. 优势：在内核进程完成数据分发，较反向代理负载均衡（应用程序分发）性能更好。

3. 缺点：与反向代理负载均衡相同。

数据链路层负载均衡

1. 原理：三角传输模式；直接路由方式（DR）；负载均衡服务器只在数据链路层修改目的MAC地址，配置真实物理服务器全部机器虚拟IP与负载均衡服务器IP地址一致，便可不修改数据包源地址和目的地址进行分发；真实物理服务器IP与数据请求目的IP一致，无需经过负载均衡服务器就可响应数据返回浏览器。

2. 优势：避免负载均衡服务器成为瓶颈。

3. 实际：大型网站使用最广的负载均衡。Linux上最好的开源产品是LVS（Linux Virtual Server）。

负载均衡算法

1. 轮询（Round Robin，RR）：全部请求依次分发到每台服务器，适合全部服务器硬件都相同的场景。

2. 加权轮询（Weight Round Robin，WRR）：轮询基础上，按照配置的权重将请求分发到每台服务器，高性能的服务器分配更多请求。

3. 随机（Random）：请求随机分发到每台服务器，也可加权随机。

4. 最少链接（Least Connections）：记录每台服务器正在处理请求（链接）数，将新请求分发到最少链接服务器，最符合负载均衡定义，也可加权最少链接。

5. 源地址散列（Source Hashing）：根据请求来源IP地址的Hash值，获得服务器，同一IP地址请求总在一台服务器上处理。

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

1. 分布式缓存集群特色：集群中各服务器数据不一样，缓存访问请求不能够在任意一台处理，必须先找到有缓存数据的服务器才能访问。

2. 分布式缓存集群访问原理：以写缓存Memcached为例，应用程序输入数据<'BEIJING',DATA>，API将KEY('BEIJING')输入路由算法模块，路由算法根据KEY和集群服务器列表计算获得一台服务器编号NODE1和IP地址、端口；API调用通讯模块将数据写入服务器NODE1。

3. 分布式缓存的一致性Hash算法：可解决伸缩性问题，但算法介绍Memcached且复杂，可能会使用Redis代替，之后再看。

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

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

1. 主从复制：利用关系数据库数据复制功能，进行简单伸缩。

2. 分库：不一样业务数据表部署在不一样数据库集群上。制约条件是跨库不能join操做。

3. 分片：对某些单表数据量大的表（如Facebook用户表、淘宝商品表），将一张表拆分存储在多个数据库。

a) 比较成熟的支持数据分片的开源分布式关系数据库产品：Amoeba、Cobar。

b) 分布式关系数据库特色：限制了关系数据库某些功能；海量数据压力不得不利用分布式关系数据库伸缩。

c) 分布式关系数据库注意：避免事务或利用事务补偿机制代替数据库事务；分解数据访问逻辑避免join操做。

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

NoSQL特色：放弃了关系数据库的以关系代数为基础的结构化查询语言（SQL）和事务一致性保证（ACID），而强化大型网站关注的高可用性和可伸缩性。

扩展性

扩展性与伸缩性

1. 扩展性（Extensibility）：对现有系统影响最小的状况下，系统功能可持续扩展或提高的能力。

2. 伸缩性（Scalability）：系统可以经过增长（减小）自身资源规模的方式加强（减小）本身计算处理事务的能力。

构建可扩展的网站架构

1. 设计网站可扩展架构的核心思想是模块化，并在此基础上下降模块间的耦合性，提升模块复用性。

2. 模块化的重要手段：分层和分割，分层、分割为若干个低耦合的独立组件模块（模块可分布式部署，从物理上分离模块间耦合），各模块以消息传递及依赖调用方式聚合成完整系统。

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

1. 事件驱动架构（Event Driven Architecture）：经过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通讯完成模块间合做。典型的EDA架构就是生产者消费者模式。大型网站最多见是分布式消息队列，利用发布/订阅模式工做。

2. 分布式消息队列。

a) 原理：前面章节已说明，再也不赘述。

b) 伸缩性：新服务器加入消息队列集群事，修改生产者服务器的消息队列服务器列表便可。

c) 可用性：为避免消费者进程处理缓慢、消息队列服务器内存不足等问题，若是内存队列已满，消息会被写入磁盘；为避免消息队列服务器宕机，生产者服务器会保存消息直至消息真正被消费者服务器处理后才删除，若是消息队列服务器宕机，生产者服务器会选择分布式消息队列集群中其余服务器发送。

d) 开源Apache ActiveMQ实现了可用性、伸缩性、数据一致性、性能和可管理性等。

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

1. 纵向拆分：将一个大应用拆分为多个小应用，若是新增业务较为独立，那么直接部署为一个独立的Web应用。

2. 横向拆分：将复用的业务拆分，独立部署为分布式服务，新增业务只须要调用这些分布式服务，无需依赖具体模块代码。

3. 不使用WebServices的理由：

a) 臃肿的注册与发现机制；

b) 低效的XML序列化手段；

c) 开销较高的HTTP远程通讯；

d) 复杂的部署和维护手段；

e) 没法解决大型网站高性能、高可用、易部署、易维护的要求。

4. 大型网站分布式服务的需求与特色：

a) 注册与发现；

b) 负载均衡

c) 失效转移；

d) 高效的远程通讯：核心服务天天调用次数数以亿计；

e) 整合异构系统：服务可能使用不一样语言开发并部署不一样平台；

f) 对应用最小侵入；

g) 版本管理：支持服务接口的多版本发布，方便服务调用者使用未升级的旧接口；

h) 实时监控。

5. 开源分布式服务框架：阿里巴巴Dubbo、Facebook Thrift。

安全性

网站应用攻击与防护

XSS攻击

1. 攻击：即跨站脚本攻击（Cross Site Script），攻击者经过篡改网页，注入恶意HTML脚本，在用户浏览器网页时，控制用户浏览器进行恶意操做。

a) 反射型：攻击者诱使用户点击一个嵌入恶意脚本的链接，达到攻击目的。

b) 持久型：攻击者提交含有恶意脚本的请求，保存在被攻击的Web站点的数据库，用户浏览网页时，恶意脚本被包含在正常网页中，达到攻击目的。

2. 防护。

a) 消毒：对某些HTML危险字符转义，如“>”转义为“>”、“<”转义为“<”。

b) HttpOnly：浏览器禁止JavaScript访问带有HttpOnly属性的Cookie。没法防护XSS，但可防止XSS攻击者窃取Cookie。

注入攻击

1. SQL攻击：攻击者在HTTP请求中注入恶意SQL（如drop table users），服务器用请求参数构造数据库SQL时，恶意SQL被一块儿执行。

2. 获取数据库表结构的手段。

a) 开源：网站采用开源软件（如Discuz!）搭建，已公开。

b) 错误回显：若是网站开启错误（服务器内部500）回显，攻击者构造非法参数，使异常信息输出到浏览器。

c) 盲注：若是网站关闭错误回显，攻击者根据页面变化判断SQL执行状况，猜想表结构。

3. 防护：使用预编译，绑定参数。

4. 其余注入攻击：OS命令、编程语言代码。

CSRF攻击

1. 攻击：跨站请求伪造（Cross Site Request Forgery），攻击者经过跨站请求，以合法用户身份进行非法操做。核心是利用浏览器Cookie或服务器Session盗取用户身份。

2. 防护。

a) 表单Token：页面表单增长一个随机数做为Token，每次响应页面Token都不一样，伪造的请求没法得到Token，服务器检查该Token合法性。

b) 验证码：请求提交时，需用户输入验证码，但验证码用户体验变差。

c) Referer check：HTTP请求头Referer记录请求来源，验证其合法性。不少网站利用该功能实现图片防盗链。

Web应用防火墙

ModSecurity是一个开源Web应用防火墙，既可嵌入Web应用服务器，也可独立部署。最先是Apache一个模块，支持Nginx。

网站安全漏洞扫描

安全漏洞扫描工具根据内置规则，构造具备攻击性的URL请求，模拟攻击者攻击行为，以发现漏洞。

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

单向散列加密

1. 解释：经过对不一样输入长度的信息进行散列计算，获得固定长度的输出，散列计算过程是单向的，即不能对固定长度输出进行计算得到输入信息。

2. 场景：密码加密保存。

3. 常见算法：MD五、SHA。

对称加密

1. 解释：加密和解密使用的密钥是同一个密钥（或者能够相互推算）。

2. 场景：信息需安全交换或存储的场合，如Cookie加密、通讯加密。

3. 优势：加解密效率高，系统开销小，适合大量数据加密。

4. 常见算法：DES、RC。

非对称加密

1. 解释：加密和解密使用的密钥不是同一密钥，一个公钥，一个私钥。

2. 场景：信息安全传输，数字签名场合。

3. 常见算法：RSA。

密钥安全管理

1. 应用程序调用加解密服务接口对信息加解密。

2. 加解密服务接口经过密钥服务器获取加解密密钥，并缓存在本地（定时更新）。

3. 密钥服务器中的密钥来自多个密钥存储服务器，一个密钥分片后存储在多个存储服务器。

4. 密钥申请者、密钥管理者、安全审核人员经过密钥管理控制台管理更新密钥，没有人能查看完整的密钥。

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

秒杀活动的技术挑战

1. 对现有网站业务形成冲击：活动时间短、并发访问量大，若是和网站原有应用部署在一块儿，必然对现有业务冲击。

2. 高并发下的应用、数据库负载：秒杀开始前，用户不断刷新浏览器页面保证不错过，请求若是按通常网站应用架构，会对应用服务器、数据库服务器形成极大负载。

3. 忽然增长的网络及服务器带宽：假设秒杀页面大小200KB（主要是商品图片），那么所需带宽是200KB×10000=2GB。

4. 直接下单：秒杀开始前，只能浏览，不容许下单。

秒杀系统架构设计

1. 秒杀系统独立部署：独立部署，甚至独立域名，使其与网站彻底隔离，即便秒杀系统奔溃，也不影响网站。

2. 秒杀页面静态化：将商品描述、商品参数、成交记录和用户评价所有写入静态页面，请求无需访问应用服务器和数据库服务器。

3. 秒杀页面尽可能简单：节约带宽；用户关心可否进入下单页面，而不是商品详情等用户体验细节。

4. 租借秒杀网络带宽：向运营商从新购买或租借带宽；秒杀页面缓存在CDN，需向CDN服务商临时租借新增出口带宽。

5. 动态生成随机下单页面URL：为避免用户直接访问下单页面URL，该URL必须动态化，在下单页面URL加入服务器生成的随机数做为参数，秒杀开始时才能得到。

6. 控制秒杀页面购买按钮点亮：该页面引用包含是否开始和下单页面URL随机数的JavaScript文件，秒杀开始时才生成该文件被浏览器加载。为避开缓存，该文件在CDN、反向代理服务器缓存，并使用随机版本号。

7. 只容许第一个提交的订单被发送到订单子系统：秒杀最终只有一个订单提交成功，为减轻服务器负载，可控制只有少数用户（根据集群处理能力肯定个数）能进入下单页面，其余用户直接进入秒杀结束页面。

做者：netoxi
出处：http://www.cnblogs.com/netoxi本文版权归做者和博客园共有，欢迎转载，未经赞成须保留此段声明，且在文章页面明显位置给出原文链接。欢迎指正与交流。

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

目录

大型网站软件系统的特色

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

初始阶段的网站架构

需求/解决问题

架构

应用服务和数据服务分离

需求/解决问题

架构

使用缓存改善网站性能

需求/解决问题

架构

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

需求/解决问题

架构

数据库读写分离

需求/解决问题

架构

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

需求/解决问题

架构

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

需求/解决问题

架构

使用NoSQL和搜索引擎

需求/解决问题

架构

业务拆分

需求/解决问题

架构

分布式服务

需求/解决问题

架构

大型网站架构演化心得

大型网站架构模式

综述

分层

概念

目的

举例

分割

概念

目的

举例

分布式

概念

目的

缺点

举例

集群

概念

目的

缓存

概念

目的

举例

异步

概念

目的

冗余

概念

目的

举例

自动化

目的

举例

安全

举例

大型网站核心架构要素

性能

网站性能测试

不一样视角下的网站性能

性能测试指标

性能测试方法

性能测试报告

Web前端性能优化

浏览器访问优化

CDN加速

反向代理