◎目录
与传统企业应用相比，大型互联网应用系统有以下特点：
1. 高并发，大流量；
2. 高可用：系统7×24小时不间断服务；
3. 海量数据：需要存储、管理海量数据，需要使用大量服务器；
4. 用户分布广泛，网络情况复杂：许多大型互联网都是为全球用户提供服务的，用户分布范围广，各地网络情况千差万别；
5. 安全环境恶劣：由于互联网的开放性，使得互联网更容易受到攻击，大型网站几乎每天都会被黑客攻击；
6. 需求快速变更，发布频繁：和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，其产品发布频率是极高的；
7. 渐进式发展：与传统软件产品或企业应用系统一开始就规划好全部的功能和非功能需求不同，几乎所有的大型互联网网站都是从一个小网站开始，渐进地发展起来的。
大型网站都是从小型网站发展而来，网站架构也是一样，是从小型网站架构逐步演化而来。小型网站最开始时没有太多人访问，只需要一台服务器就绰绰有余，这时的应用程序、数据库、文件等所有的资源都在一台服务器上。通常服务器操作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySQL，汇集各种免费开源软件及一台廉价服务器就可以开始网站的发展之路了
小网站最开始没有太多人访问。
架构
应用程序、数据库、文件等所有的资源都在一台服务器上。
应用服务和数据服务分离
随着网站业务的发展，一台服务器逐渐不能满足需求：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足。这时就需要将应用和数据分离。应用和数据分离后整个网站使用三台服务器：应用服务器、文件服务器和数据库服务器。这三台服务器对硬件资源的要求各不相同，应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存；文件服务器需要存储大量用户上传的文件，因此需要更大的硬盘
需求/解决问题
随着网站业务的发展，越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足。
架构
应用和数据分离后整个网站使用三台服务器，其对硬件资源的要求各不相同：应用服务器处理大量业务逻辑，需要更快更强大的CPU；数据库服务器快速磁盘检索和数据
缓存，需要更快的磁盘和更大的内存；文件服务器存储大量用户上传的文件，需要更大的磁盘。
使用缓存改善网站性能
网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%的数据上。既然大部分的业务访问集中在一小部分数据上，那么如果把这一小部分数据缓存在内存中，就可以减少数据库的访问压力，提高整个网站的数据访问速度，改善数据库的写入性能
网站使用的缓存可以分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数据量有限，而且会出现和应用程序争用内存的情况。远程分布式缓存可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存内容限制的缓存服务
需求/解决问题
用户逐渐增多，数据库压力太大导致访问延迟。
架构
根据二八定律：80%的业务访问集中在20%的数据上，把小部分数据缓存在内存中，可减少数据库访问压力。
类型 | 原理 | 优点 | 缺点 |
本地缓存 | 缓存在应用服务器 | 访问速度更快 | 受应用服务器内存限制 |
分布式缓存 | 部署大内存缓存服务器集群 | 理论上不受内存容量限制 | -- |
使用应用服务器集群改善网站的并发处理能力
使用缓存后，数据访问压力得到有效缓解，但是单一应用服务器能够处理的请求连接有限，在网站访问高峰期，应用服务器成为整个网站的瓶颈
使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时，通过增加一台服务器分担原有服务器的访问及存储压力。对网站架构而言，只要能通过增加一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性。应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种
通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈
需求/解决问题
单一应用服务器能够处理的请求连接有限。
架构
Scale up有限，Scale out无限，所以应用服务器要Scale out。
数据库读写分离
网站在使用缓存后，使绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作(缓存访问不命中、缓存过期)和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈
目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力
应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明
需求/解决问题
一部分读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库。
架构
应用服务器写数据时，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库；当应用服务器读数据时，可通过从数据库获得数据。通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明。
使用反向代理和CDN加速网站响应
随着网站业务不断发展，用户规模越来越大，由于复杂的网络环境，不同地区的用户访问网站时，速度差别也极大。为了提供更好的用户体验，留住用户，网站需要加速网站访问速度。主要手段有使用CDN和反向代理
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户
使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力
需求/解决问题
中国网络环境复杂，不同地区的用户访问网站时，速度差别极大，网站访问延迟导致用户流失率提高。
架构
CDN和反向代理目的都是尽早返回数据、加快访问速度、减轻后端服务器负载压力。
1. CDN：部署在网络提供商机房。用户请求网站服务时，可从距离自己最近的网络提供商机房获取数据。
2. 反向代理：部署在网站中心机房。用户请求到达中心机房后，首先访问反向代理服务器，如果反向代理服务器缓存着用户请求的资源，就将其直接返回给用户。
使用分布式文件系统和分布式数据库系统
任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后，从一台服务器拆分成两台服务器，但是随着网站业务的发展依然不能满足需求，这时需要使用分布式数据库。文件系统也是一样，需要使用分布式文件系统
分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上
需求/解决问题
读写分离伸缩性有限。
架构
只有在单表数据规模非常庞大的时候（不到万不得已）才数据库拆分，按业务分库，不同的业务数据部署在不同的物理服务器上。
使用NoSQL和搜索引擎
随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎
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. 运维人员视角：基础设施性能和资源利用率，如网络运营商的带宽、服务器硬件的配置、数据中心网络架构、服务器和网络带宽的资源利用率等。