大型网站技术架构

1 大型网站架构演化

1.1 大型网站系统的特点：

1. 高并发、大流量

2. 高可用：提供7 x 24小时不间断服务。

3. 海量数据

4. 用户分布广泛，网络情况复杂。

5. 安全环境恶劣：每天都面临着被攻击的风险。

6. 需求快速变更，发布频繁：为适应市场，满足用户需求，系统版本功能需要不断迭代更新。

7. 渐进式发展：几乎所有大型的互联网站都是从一个小网站开始逐渐发展起来的。

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

1、初级阶段的网站架构

单机架构，使用一台服务器搭建网站，应用程序、数据库、文件等所有资源都在一台服务器上。

2、应用服务和数据服务分离

随着业务的发展，一台服务器逐渐不能满足需求，越来越多的数据会导致单机的存储空间不足，这时采用应用服务和数据服务分离的架构。使用三台服务器，应用服务器（具备强大的CPU）用于处理业务逻辑，数据库服务器（具备更快的硬盘和更大的内存）用于快速检索和数据缓存，文件服务器（更大的硬盘）用于存储用户上传的文件。

3、使用缓存改善网站性能

随着用户增多，会导致数据库压力太大导致访问延迟，进而影响整个网站的性能。由于网站的访问特点遵循二八定律：80%的业务访问集中在20%的数据上。使用缓存将这20%的数据缓存在内存中，从而能够提高整个网站的访问速度。

缓存也分为两种方式：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地缓存速度更快，但是缓存大小受限于应用服务器的内存大小，而且会与应用程序争抢内存。分布式缓存可以使用集群的方式，部署在大内存的服务器作为专门的缓存服务器，理论上可以做到不受内存容量限制的缓存服务（横向扩展）

4、应用服务器集群提高网站的并发处理能力

使用缓存后数据访问压力得到有效缓解，但是单一应用程序服务器的请求连接有限，难以处理高并发量的请求。因此使用集群部署应用服务器，横向扩展应用服务器的个数，实现系统的可伸缩性。

通过负载均衡调度服务器，将用户请求均衡分发到各个应用服务器上去处理。

5、数据库读写分离

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

目前主流数据库都具备主从热备的功能，通过配置两台数据库服务器的主从关系，将一台数据库服务器上的数据更新同步到另一台数据库服务器上，主库负责数据的写操作，从读负责数据的读操作，实现读写分离。

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

由于中国复杂的网络环境，不同地区的用户访问网站的速度差别也很大。为了给用户提供更好的使用体验，需要加速网站的响应速度。主要手段有使用CDN加速和反向代理两种方式。

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

使用CDN和反向代理一方面能提高网站的响应速度，另一方面能够减轻后端服务器的压力。

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

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。虽然数据库服务器经过读写分离后从一台拆分为两台，但是仍然满足不了大型网站的性能需求，这时需要分布式数据库，文件系统也是一样，需要分布式文件系统。

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

8、使用NoSQL和搜索引擎

随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。

9、业务拆分

面对日益复杂的业务，可通过分而治之的思想将业务进行拆分，如大型购物网站会将首页、店铺、订单、买家、卖家等拆分成不同的产品，分归不同的业务团队负责。每个应用独立部署维护，通过超链接建立关系、通过消息队列进行数据分发或通过访问同一个数据存储系统来构成一个关联的完整系统。

10、分布式服务

随着业务拆分越来越细，存储系统越来越大，应用系统的整体复杂度呈指数级别增加。因为所有应用要和所有数据库系统连接，在数万台服务器规模的网站中，这些连接的数据是服务器规模的平方，会导致数据库连接资源不足，拒绝服务。

即然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务完成具体业务操作。

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

网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的。

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

2 大型网站架构模式

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

2.1 网站架构模式

1、分层

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

分层结构在计算机世界中无处不在，如网络的7层通信协议，计算机的硬件、操作系统、应用软件层次。大型网站的分层一般分为三层：应用层、服务层、数据层。

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

分层架构必须合理规划层次边界和接口，开发过层严格遵循分层架构的约束，禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）。

上述提到的分层架构是逻辑上的，在物理部署上，三层结构可以部署在同一个物理机器上，但随着网站业务的发展，必然需要对已经分层的模块分离部署，将三层架构分别部署在不同的服务器上，使网站拥有更多的计算资源以应对越来越多的用户访问。

2、分割

分层是将软件在横向方面进行切分，而分割是在纵向方面对软件进行切分。

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

比如将购物、论坛、搜索、广告分割成不同的应用，由独立的团队负责，部署在不同的服务器上。在同一个应用内部，如果规模庞大业务复杂，会继续分割，比如购物业务，可以进一步分割成机票酒店业务、3C业务，小商品业务等更细小的粒度。

3、分布式

对于大型网站，分层和分割的一个主要目的是切分后的模块便于分布式部署。不同模块部署在不同的服务器上，通过远程调用协同工作。通过分布式能够使用更多的计算机资源进行工作。

分布式存在的问题：1、服务调用必须通过网络，可能对性能造成比较严重的影响（网络延迟）；2、服务器越多，宕机的概率越大，一台服务器宕机可能会导致很多应用不可访问，使网站可用性降低；3、数据在分布式环境中保持数据一致性也很困难，分布式事务也难以保证，可能会影响网站业务正确性和业务流程；4、分布式会增加系统的复杂度，开发管理维护困难。

常用的分布式方案：

1. 分布式应用和服务：将分层和分割后的应用和服务模块分布式部署，除了可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗外；还可以使不同应用复用共同的服务，便于业务功能扩展。

2. 分布式静态资源：网站的静态资源如JS、CSS、LOGO图片等资源独立分布式部署，并采用独立的域名，即动静分离。静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载速度；由负责用户体验的团队进行开发维护有利于网站分工合作，使不同技术工种术业有专攻。

3. 分布式数据和存储：大型网站需要处理以 P 为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据需要分布式存储。除了对传统的关系数据库进行分布式部署外，为网站应运而生的各种NoSQL产品几乎都是分布式的。

4. 分布式计算：网站业务的计算规模非常庞大，目前普遍使用 Hadoop 及其 MapReduce 分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。

5. 还有支持网站线上服务器配置实时更新的分布式配置：分布式环境下实现并发和协同的分布式锁；支持云存储的分布式文件系统等。

4、集群

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

通过使用集群部署应用，能够提高网站的并发能力以及可用性。

5、缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存设计方案主要有以下几种：

1. CDN：内容分发网络，部署在距离终端用户最近的网络服务商

2. 反向代理

3. 本地缓存：在应用服务器本地缓存着热点数据，应用程序可以在本机内存中直接访问数据，而无需访问数据库。

4. 分布式缓存：将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据。

使用缓存必须具备两个前提条件：

• 数据访问热点不均衡，某些数据（热点数据）被更频繁访问，这些数据应该放在缓存中。

• 数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响结果的正确性。

6、异步

低耦合是计算机软件发展的一个重要目标。事物之间的直接关系越少，彼此的影响就越小，越能独立发展。在大型网站架构中，系统解耦合的手段除了分层、分割、分布等，还有一个重要的手段是异步。将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

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

分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署。

使用异步消息队列的好处：

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

• 加快网站响应速度：处在业务处理前端的生产者服务器在处理完业务请求后，将数据写入消息队列，不需要等待消费者服务器处理就可以返回，降低响应延迟。

• 消除并发访问高峰：当出现突发事件时，如促销秒杀、热点新闻，系统的并发访问会骤增，造成整个网站的负载过重，严重时会出现宕机的情况。使用消息队列可以将突然增加的访问请求数据放入到消息队列中，等待消费者服务器依次处理，就不会对整个网站负载造成太大压力。

使用消息队列的坏处：可能会对用户体验（延迟）、业务流程（错乱）造成影响。

7、冗余

网站需要 7 x 24 小时持续运行，给用户提供高可用的服务，但是服务器随时可能出现故障，特别是服务器规模比较大时，出现某台服务器宕机是必然的事情。要保证服务器宕机后网站依然可以继续服务，不丢失数据，就需要在一定程序的服务器冗余运行，数据冗余备份，这样当某台服务器宕机时，可以将其上的服务和数据访问转移到其他机器上。

8、自动化

发布过程自动化：

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

• 自动化测试：系统自动将代码部署到测试环境，启动自动化测试用例进行测试，向相关人员发送测试报告，向系统反馈测试结果；

• 自动化安全检测：对代码进行静态安全扫描以及部署到安全测试环境进行安全攻击测试，评估其安全性；

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

• 自动化监控：监控线上生产环境，对服务器进行心跳检测，发现异常能自动化报警；检测故障后能自动化失效转移；故障消除后能自动化失效恢复，重新启动服务；遇到访问高峰，超出网站最大处理能力时，能自动化降级，拒绝部分请求或关闭部分不重要的服务；必要时，可自动化分配资源，将空闲资源分配给重要的服务。

9、安全

网络在安全架构的模式：

• 通过密码和手机验证进行身份认证

• 登陆、交易等操作需要对网络通信进行加密，网站服务器上存储的敏感数据如用户信息等也进行加密处理

• 防止机器人程序滥用网络资源攻击网站，使用验证码进行识别

• 对于常见的XSS攻击、SQL注入具备相应的防范处理

• 对于垃圾信息、敏感信息进行过滤

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

小结

正确使用模式可以更好地利用业界和前人的思想与实践，用更少的时间开发出更好的环境。但是模式受其使用场景限制，对系统的要求和约束也很多，不恰当使用模式只会画虎不成反类犬，不但没有解决原来的老文，反而带来更加棘手的新问题。

3 大型网站核心架构要素

软件架构的定义：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。系统的各个重要组成部分及其关系构成了系统的架构，这些组成部分可以是具体的功能模块，也可以是非功能的设计与决策，他们相互关系组成一个整体，共同构成了软件系统的架构。

系统出了当前的系统功能需求外，还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构元素。

3.1 性能

性能是网站的一个重要指标，优化网站性能的途径有如下这些：

1. 在浏览器端，通过浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输等手段改善性能。

2. 使用CDN和反向代理缓存热点数据，加快响应速度，减轻应用服务器的压力。

3. 应用服务器端可以使用服务器本地缓存和分布式缓存，通过缓存热点数据，加快请求处理过程，减轻数据库负载压力。

4. 通过异步操作将用户请求发送至消息队列等待后续处理，而当前请求直接返回响应给用户。

5. 使用多台应用服务器组建集群。

6. 代码层面使用多线程、改善内存管理等手段优化性能。

7. 数据库服务器端，使用索引、缓存、SQL优化等性能优化手段。还有NoSQL数据库通过优化数据模型结构、存储结构、伸缩特性等手段提高性能。

衡量网站性能的指标：响应时间、TPS、系统性能计数器等。

3.2 可用性

网站宕掉、服务不可用是一个重大事故，必须保证网站的可用性。保证网站高可用的主要手段是冗余。

3.3 伸缩性

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

衡量架构伸缩性能的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。

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

• 对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，进而导致集群中大部分缓存数据都无法访问。虽然缓存的数据可以通过数据库重新加载，但是如果应用已经严重依赖缓存，可能会导致整个网站崩溃。

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

• 大部分NoSQL数据库产品先天就是为海量数据而生，其对伸缩性的支持非常友好。

3.4 扩展性

不同于其他架构要素主要关注非功能性需求，网站的扩展性架构直接关注网站的功能需求。网站的功能需要不断扩展，如何设计网站的架构使其快速响应需求变化， 是网站扩展架构的主要目的。

衡量网站架构扩展性好坏的主要标准是网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有功能就可以上线新产品。不同产品之间的耦合小，一个产品改动对其他产品无影响，其他产品和功能不需要受牵连进行改动。

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

• 事件驱动架构通常利用消息队列实现，将用户请求和其他业务事件构造成消息发布到消息队列，消息的处理者（消费者）从消息队列中获取消息数据进行处理。

• 分布式服务则是将业务和可复用业务分离开，通过分布式服务框架调用。新增产品可以调用可复用的服务实现自身的业务逻辑，而对现有产品没有任何影响。

3.5 安全性

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

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

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

4.1 网站性能测试

1、不同视角下的网站性能

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

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

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

2、性能测试指标

1. 响应时间。应用执行一个操作需要的时间，包括从发出请求到收到最后响应数据所需要的时间。

2. 并发数。指系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。对于网站而言，并发数即网站并发用户数，指同时提交请求的用户数目。

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

4. 性能计数器。描述服务器或操作系统性能的一些数据指标。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。

3、性能测试方法

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

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

负载测试：对系统不断地增加并发请求以增加系统压力，指导系统的某项或多项性能指标达到安全临界值，如某种资源已经达到饱和状态，如果继续对系统施加压力，系统的处理能力会下降。

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

稳定性测试：被测试系统在特定硬件、软件、网络环境条件下，给系统施加一定业务压力（需要模拟真实生产环境，进行不均匀地施加压力），使系统运行一段较长时间，以此监测系统是否稳定。

性能测试遵循下图的规律，a - b区间是网站的日常运行区间，c点是系统的最大负载点，d点是系统的崩溃点。

用户访问时间的随系统的状态变化而呈现如下图的规律：

4、性能优化策略

性能分析：检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是CPU，是代码问题还是架构设计不合理，或者系统资源确实不足。

性能优化：确定产生性能问题的具体原因后，需要进行性能优化，根据网站分层架构，可分为Web前端优化、应用服务器性能优化、存储服务器性能优化3大类。

4.2 Web前端性能优化

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

1、优化浏览器访问

1. 减少HTTP请求。由于每次HTTP请求都需要建立通信链路、进行数据传输，而在服务器端，每个HTTP请求都需要一个独立的线程去处理。通信和服务的开销太昂贵，因此减少HTTP请求数能有效提高访问性能。减少HTTP请求数的手段主要有合并CSS、合并JavaScript、合并图片。将浏览器一次访问需要的JavaScript、CSS合并成一个文件，多张图片合并成一张等。

2. 使用浏览器缓存。将CSS、JavaScript等静态资源文件缓存在浏览器中，可以更好地改善性能。

3. 启动压缩。服务端对文件进行压缩，传输到浏览器端再对文件解压缩，可有效减少通信传输的数据量。

4. 减少Cookie传输。由于Cookie包含在每次请求和响应中，应尽量控制Cookie传输的数据量。

2、CDN加速

CDN（Content Distribute Network，内容分发网络）本质就是一个缓存，将CDN服务器部署在离用户最近的网络运营商的机房中，用户请求路由的第一跳就到达CDN服务器，如果CDN服务器缓存着用户请求的资源，从CDN直接返回给浏览器，从而加速访问速度。

CDN一般缓存的是静态资源，如图片、文件、CSS、Script脚本、静态网页等。

3、反向代理

传统的代理服务器位于浏览器一侧，将HTTP请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站Web服务器接收HTTP请求。如下：

反向代理服务器通过配置缓存功能加速Web请求，除了可以缓存静态资源外，反向代理服务器还可以缓存动态内容，比如维基百科及某些博客论坛网站，把热门词条、帖子、博客缓存在反向代理服务器上加速访问速度，当这些动态内容有变化时，通过内部通知机制通知反向代理服务器缓存失效，反向代理服务器会重新加载最新的动态内容并再次缓存。

反向代理还可以实现负载均衡的功能，并且能作为Web网站的一个安全屏障。

4.3 应用服务器性能优化

1、分布式缓存

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

1）缓存的基本原理

缓存是指将数据存储在相对较高访问速度的存储介质中，以供系统处理。一方面缓存访问的速度快，可以减少数据访问的时间，另一方面如果缓存的数据是经过计算处理得到，那么被缓存的数据无需重复计算即可直接使用。

缓存的本质是一个内存Hash表，主要用来存放哪些读写比很高、变化很少的数据，如商品的类目信息，热门词的搜索列表信息，热门商品信息等。应用程序读取数据时先到缓存中读取，如果读取不到或数据已失效，再访问数据库，并将数据写入缓存。

2）合理使用缓存

1. 频繁修改的数据不适合作为缓存数据。

2. 没有热点访问的数据不适合作为缓存数据，不然会浪费宝贵的内存资源。

3. 可能会出现数据不一致与脏读的情况。当数据库的数据被更新，没有及时更新到缓存中，用户读取到的数据可能是旧的。虽然可以在数据更新时立即更新缓存，但是会带来更多系统开销和事务一致性的问题。

4. 缓存可用。随着业务发展，缓存会承担大部分数据访问的压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃时，数据库可能会承受不住这么大的压力而宕机，导致整个网站不可用。解决手段主要有缓存热备和分布式缓存服务器集群。

5. 缓存需要预热。新启动的缓存系统没有任何数据，此时最好把热点数据加载进来。

6. 缓存穿透。如果因为不恰当的业务、或者恶意攻击持续高并发地请求某个不存在的数据，由于缓存没有保存该数据，所有请求都会落到数据库上，给数据库造成很大的压力。处理策略是不存在的数据缓存为null值、或使用布隆过滤器。

3）分布式缓存架构

分布式缓存是指部署在多个服务器组成的集群中，以集群的方式提供服务。架构方式主要有两种，一种是以JBoss Cache为代表的需要更新同步的分布式缓存，一种是以Memcached为代表的不互相通信的分布式缓存。

JBoss Cache的集群中所有服务器都缓存着相同的数据，当某台服务器有缓存数据更新时，会通知集群中其他机器更新缓存数据或清除缓存数据。这种方式存在的问题时缓存数据的容量受限于单一服务器的内存空间，而且当集群很大时，各个机器之间的通信代价也很大。

Memcached使用一种集中式的缓存集群管理，缓存和应用分离部署，缓存系统部署在一组专门的服务器上，应用程序通过一致性Hash等路由算法选择缓存服务器远程访问缓存数据，缓存服务器之间不通信，缓存集群的规模可以很容易实现扩容，可伸缩性更好。

2、异步操作

使用消息队列进行异步操作改善网站的可扩展性和性能。

不实用消息队列的情况下，用户的请求数据直接写写入数据库，在高并发的额情况下，对数据库造成很大的访问压力。

使用消息队列，用户请求的数据发送给消息队列后立即返回，再由消息队列的消费者线程从消息队列获取数据，异步写入到数据库中。

使用消息队列还能进行流量削峰。高并发的请求先提交给消息队列，再由消费者去慢慢消费。

由于数据写入消息队列后立即返回给用户，数据在后续的业务校验、写数据库等操作可能会失败，因此在使用消息队列进行业务异步处理后，需要适当修改业务流程进行配合，如订单提交后，订单数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单，甚至商品出库后，再通过电子邮件或SMS消息通知用户订单成功，以免交易纠纷。

3、使用集群

通过负载均衡，将访问分发到集群的多台服务器进行处理，可以横向扩展网站系统的整体性能。

4、代码优化

1）多线程

启动线程数=[ 任务执行时间/（任务执行时间 - IO等待时间）x CPU内核数]

最佳启动线程数和CPU数量成正比，和IO阻塞时间成反比。如果任务都是CPU计算型任务，那么线程数最多不超过CPU内核数，因为启动再多的线程，CPU也来不及调度。相反，如果任务是等待磁盘操作，网络响应，那么多启动线程有利于提高任务并发度，提高 系统吞吐能力，改善系统性能。

2）资源复用

资源复用主要由两种形式：单例模式（Singleton）和对象池（Object Pool）

3）数据结构

在不同场景中合理使用恰当的数据结构，灵活组合各种数据结构改善数据读写和计算特性可极大优化程序的性能。

4）垃圾回收

根据系统业务特点和对象生命周期，合理设置Young Generation 和 Old Generation 大小，尽量减少Full GC。

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

网站的高可用（Availability）描述网站可有效访问的特性。

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

1、网站可用性度量

网站不可用也称为网站故障，业界常用多少个9来度量网站的可用性。

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

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

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

2、网站可用性考核

一般使用故障分进行考核，故障分 = 故障时间（分钟）x 故障权重

故障分类权重如下：

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

5.2 高可用的网站架构

由于硬件故障是常态，网站的高可用架构设计的主要目的是保证服务器硬件故障时服务依然可用、数据依然保存并能被访问。

实现高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。

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

• 位于应用层的服务器会通过负载均衡设备组成一个集群，当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时，就将其从集群列表中剔除，并将请求分发到集群中其他可用的服务器上，从而实现网站可高用。

• 位于服务层的服务器和应用层的服务器类似，也是通过集群的方式实现高可用，只是这些服务器被应用层通过分布式服务调用框架访问，分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，并通过服务注册中心对提供服务的服务器进行心跳检测，发现有服务不可用，立即通知客户端程序修改服务访问列表，剔除不可用服务器

• 位于数据层的服务器情况比较特殊，数据服务器上存储着数据，为了保证服务器宕机时数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入到多台服务器上，实现数据冗余备份。当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。

此外，网站升级发布引起的宕机也属于网站不可用的范畴。

5.3 高可用的应用

应用层主要是处理网站应用的业务逻辑，其一个显著特点是应用的无状态性。

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

由于服务器不保存请求的状态，那么所有的服务器都是对等的。当任意一台或多台服务器宕机时，通过负载均衡将请求转发至集群中正常的服务器进行处理即可。

2、应用服务器集群的Session管理

应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有状态的，比如购物车记录用户的购买信息，社交网站记录用户的登录状态等。

Web应用中将这些多次请求修改使用的上下文对象称作会话（Session）。Session管理主要有以下几种手段：

1）Session复制。让集群中每台服务器都保存所有用户的Session信息。这种方法在规模很小时很方便，但是当集群规模较大时，需要在集群中进行大量的通信去同步Session，占用服务器和网络的大量资源。而且在用户量较大时，会出现服务器内存不够Session使用的情况。

2）Session绑定

利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上。

这种Session方案并不符合对系统高可用的要求，因为一旦某台服务器宕机，那么该机器上的Session也就不复存在了，用户切换到其他机器后因为没有Session而无法完成业务处理。因此很少有网站使用这个方法进行Session管理。

3）利用Cookie记录Session

将Session记录在客户端，每次请求服务器的时候，通过Cookie将Session放在请求中发送给服务器，服务器处理完请求后再将修改过的Session响应给客户端存储。

利用Cookie记录Session存在一些缺点，比如受Cookie大小限制，能记录的信息有限；每次请求响应都要传输Cookie，影响性能；如果用户关闭Cookie，访问就会不正常。

4）Session服务器

利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都是通过访问Session服务器，从而能保证系统的高可用、高伸缩性、高性能。

5.4 高可用的服务

可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务通常独立部署，被具体应用远程调用。可复用的服务和应用一样，也是无状态的服务，因此可以使用类似负载均衡的失效转移策略实现高可用的服务。

初次之外，还有如下几点高可用的服务策略：

1）分级管理。运维上将服务器进行分级管理，核心应用和服务优先使用更好的硬件。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至需要部署在不同地域的数据中心。

2）超时设置。由于服务器宕机、线程死锁等原因，可能导致应用程序对服务端的调用失去响应，进而导致用户请求长时间得不到响应，同时还占用应用程序资源，不利于及时将访问请求转移到正常的服务器上。可在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。

3）异步调用。通过消息队列等异步方式完成，避免一个服务失败导致真个应用请求失败的情况。

4）服务降级。在网站访问高峰期，服务可能会因为大量的并发调用而性能下降，严重时可能会导致系统宕机。为了保证核心服务和功能的正常进行，需要对服务进行降级——拒绝服务（拒绝低优先级应用的调用）或关闭服务（关闭不重要的服务）。

5）幂等性

服务层必须保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。

5.5 高可用的数据

不同于高可用的应用和服务，由于数据存储服务器上保存的数据不同，当某台服务器宕机的时候，数据访问请求不能任意切换到集群中其他的机器上。

保证数据存储高可用的手段主要是数据备份和失效转移机制。失效转移是指当一个数据副本不可用时，快速切换访问数据的其他副本，从而保证系统可用。

对于缓存服务的高可用，主要有两个观点：

缓存服务需要实现和数据存储服务同样的高可用，即备份

缓存服务不是数据存储服务，缓存服务器宕机引起缓存数据丢失导致服务器负载压力过高应该通过其他手段解决，而不是提高缓存服务本身的高可用。对于缓存服务器集群中的单机宕机，在缓存服务器集群规模较大时，对系统的影响其实并不大。

1、CAP原理

数据持久性（Partition Tolerance，分区耐受性）、数据可用性（Availability）、数据一致性（Consistency）遵循如下的规律：