第1篇概述
1 大型网站架构演化
2 大型网站架构模式
3 大型网站核心架构要素
4 瞬时响应：网站的高性能架构
- 4.1 网站性能测试
  - 4.1.1 不同视角下的网站性能
  - 4.1.2 性能测试指标

第1篇概述

1 大型网站架构演化

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

高并发，大流量
高可用：系统7*24小时不间断服务
海量数据
用户分布广泛，网络情况复杂
安全环境恶劣
需求快速变更，发布频繁
渐进式发展

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

1.2.1 初始阶段的网站架构

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

缺点：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足。

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

应用和数据分离后整个网站使用三台服务器：应用服务器、文件服务器和数据库服务器：

应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU；
数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存；
文件服务器需要存储大量用户上传的文件，因此需要更大的磁盘。

缺点：数据库压力太大导致访问延迟，今儿影响整个网站的性能，用户体验受到影响。

1.2.3 使用缓存改善网站性能

二八定律：80%的业务访问集中在20%的数据上

网站使用的缓存可以分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。

优点：数据访问压力得到有效缓解

缺点：在网站访问高峰期，应用服务器成为整个网站的瓶颈。

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

通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。

1.2.5 数据库读写分离

问题：网站在使用缓存后，使绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。

解决方案：数据库读写分离，改善数据库负载压力。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明。

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

CDN和反向代理的基本原理都是缓存，区别在于：

CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；
反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。

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

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。

分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。

1.2.8 使用NoSQL和搜索引擎

NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

1.2.9 业务拆分

技术上，会根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间可以通过一个超链接建立关系，也可以通过消息队列进行数据分发，最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

1.2.10 分布式服务

每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。

目前许多大型网站都开始建设云计算平台，将计算作为一种基础资源出售，中小网站不需要再关心技术架构问题，只需要按需付费，就可以使网站随着业务的增长逐渐获得更大的存储空间和更多的计算资源。

1.3 大型网站架构演化的价值观

中小网站：LAMP技术（Linux+Apache+MySQL+PHP），既便宜又简单，而且对付一个中小型网站绰绰有余。

1.3.1 大型网站架构技术的核心价值是随网站所需灵活应对

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

是业务成就了技术，是事业成就了人，而不是相反。

1.4 网站架构设计误区

1.4.1 一味追随大公司的解决方案

1.4.2 为了技术而技术

1.4.3 企图用技术解决所有问题

12306真正的问题其实不在于它的技术架构，而在于它的业务架构。

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

1.5 小结

网站架构技术演化过程难以重现，所以网站架构师更应该对这个过程深刻了解，理解已成熟的网站架构技术方案的来龙去脉和历史渊源，在技术选型和架构决策时才能有的放矢，直击要害。

2 大型网站架构模式

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

模式的关键在于模式的可重复性，问题与场景的可重复性带来解决方案的可重复使用。

2.1 网站架构模式

为了解决大型网站面临的高并发访问、海量数据处理、高可靠运行等一系列问题与挑战，大型互联网公司在实践中提出了许多解决方案，以实现网站高性能、高可用、易伸缩、可扩展、安全等各种技术架构目标。这些解决方案又被更多网站重复使用，从而逐渐形成大型网站架构模式。

2.1.1 分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。

网站分层架构：

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

虽然分层架构模式最初的目的是规划软件清晰的逻辑结构便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向发展至关重要。因此在网站规模还很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对。

2.1.2 分割

分割是纵向方向对软件进行切分。

网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

2.1.3 分布式

对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署。

分布式的问题：

分布式意味着服务调用必须通过网络，这可能对性能造成比较严重的影响
服务宕机的概率变大，降低网站的可用性
数据在分布式的环境中保持数据一致性也非常困难，分布式事务也难以保证
分布式还导致网站依赖错综复杂，开发管理维护困难。

因此分布式设计要根据具体情况量力而行，切莫为了分布式而分布式。

分布式方案：

分布式应用和服务
分布式静态资源：动静分离
分布式数据和存储
分布式计算
分布式配置、分布式锁、分布式文件系统等

2.1.4 集群

使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块（比如网站的首页），还需要将独立部署的服务器集群化，即多态服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

2.1.5 缓存

CDN
反向代理（缓存网站的静态资源）
本地缓存
分布式缓存

使用缓存有两个前提条件：

数据访问热点不均衡，某些数据会被更频繁的访问
数据在某个时间段内有效，不会很快过期

2.1.6 异步

计算机软件发展的一个重要目标和驱动力是降低软件耦合性。

将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

异步架构是典型的生产者消费者模式，两者不存在直接调用，只要保持数据结构不变，彼此功能实现可以随意变化而不互相影响，这对网站扩展新功能非常便利。

异步消息队列特性：

提高系统可用性：抗消费者服务器故障
加快网站响应速度
消除并发访问高峰

需要注意的是，使用异步方式处理业务可能会对用户体验、业务流程造成影响，需要网站产品设计方面的支持。

2.1.7 冗余

想要保证服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份。

数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份。

全球范围内部署灾备数据中心。

2.1.8 自动化

发布过程自动化：

自动化代码管理
自动化测试
自动化安全检测
自动化部署

网站运行过程中：

自动化监控
自动化报警
自动化失效转移：将失效的服务器从集群中隔离出去
自动化失效恢复
自动化降级：通过拒绝部分请求及关闭部分不重要的服务将系统负载降至一个安全的水平。
自动化分配资源：将空闲资源分配给重要的服务，扩大其部署规模。

2.1.9 安全

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

2.2 架构模式在新浪微博的应用

2.3 小结

好的设计绝对不是模仿，不是生搬硬套某个模式，而是对问题深刻理解之上的创造与创新。山寨与创新的最大区别不在于是否抄袭，是否模仿，而在于对问题和需求是否真正理解与把握。

3 大型网站核心架构要素

架构：最高层次的规划，难以改变的决定

软件架构：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计

除了当前的系统功能需求外，软件架构还需要关注：

性能
可用性
伸缩性
扩展性
安全性

3.1 性能

性能优化：

浏览器端：通过浏览器缓存、使用页面压缩、合理布局页面，减少Cookie传输等手段改善性能，还可以使用CDN
应用服务器端：使用服务器本地缓存和分布式缓存；也可以通过异步操作；可以将多台应用服务器组成一个集群共同对外服务，提高整体处理能力，改善性能；在代码层面，可以通过使用多线程、改善内存管理手段优化性能。
数据库服务器端：索引、缓存、SQL优化；NoSQL数据库通过优化数据模型、存储结构、伸缩特性

衡量网站性能的指标：

响应时间
TPS
系统性能计数器

3.2 可用性

网站高可用的主要手段是冗余。

对于应用服务器而言，多台应用服务器通过负载均衡设备组成一个集群共同对外提供服务，任何一台服务器宕机，只需把请求切换到其他服务器就可实现应用的高可用，但是一个前提条件是应用服务器上不能保存请求的会话信息。

对于存储服务器，由于其上存储着数据，需要对数据进行实时备份，当服务器宕机时需要对数据访问转移到可用的服务器上，并进行数据恢复以保证继续有服务器宕机的时候数据依然可用。

通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能，避免故障范围扩大。

衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。

3.3 伸缩性

伸缩性：通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。

衡量架构伸缩性的主要标准：

是否可以用多台服务器构建集群
是否容易向集群中添加新的服务器
加入新的服务器后是否可以提供和原来的服务器无差别的服务
集群中可容纳的总的服务器数量是否有限制

对于应用服务器集群，只要服务器上不保存数据，所有服务器都是对等的，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。

对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，进而导致集群中大部分缓存数据都无法访问。需要改进缓存路由算法保证缓存数据的可访问性

关系数据库虽然支持数据复制，主从热备等机制，但是很难做到大规模集群的伸缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。

至于大部分NoSQL数据产品，由于其先天就是为海量数据而生，因此其对伸缩性的支持通常都非常好，可以做到在较少运维参与的情况下实现集群规模的线性伸缩。

3.4 扩展性

网站可扩展架构的主要目的：如何设计网站的架构使其能够快速响应需求变化

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

网站可扩展架构的主要手段：事件驱动架构和分布式服务。

事件驱动架构在网站通常利用消息队列实现，将用户请求和其他业务事件构造成消息发不到消息队列，消息的处理者作为消息的消费者从消息队列中获取消息进行处理。

分布式服务则是将业务和可复用服务分离出来，通过分布式服务框架调用。

3.5 安全性

网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。

衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。

3.6 小结

性能、可用性、伸缩性、扩展性和安全性是网站架构最核心的几个要素。

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

网站性能是客观的指标，可以具体体现到响应时间、吞吐量等技术指标，同时也是主观的感受。

4.1 网站性能测试

性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。

4.1.1 不同视角下的网站性能

1. 用户视角下的网站性能

不同计算机的性能差异，不同浏览器解析HTML速度的差异，不同网络运营商提供的互联网宽带服务的差异，这些差异最终导致用户感受到的响应延迟可能会远远大于网站服务器处理请求需要的时间。

前端架构优化：

优化页面HTML式样
利用浏览器端的并发和异步特性
调整浏览器缓存策略
使用CDN服务
反向代理

目标：使浏览器尽快地显示用户感兴趣的内容、尽可能近地获取页面内容，即使不优化应用程序和架构，也可以很大程度地改善用户视角下的网站性能。

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

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

主要优化手段：

使用缓存加速数据读取
使用集群提高吞吐能力
使用异步消息加快请求响应及实现削峰
使用代码优化手段改善程序性能

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

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