大型网站技术架构

高并发，大流量

高可用

海量数据

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

安全环境恶劣

需求快速变更，发布频繁

渐进式发展

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

• 初始阶段，多使用LAMP来搭建，All In One即所有资源存放在一台服务器上

• 应用服务和数据服务分离，有独立的数据库服务器

• 使用缓存改善网站性能（依据是二八定律：80%的业务访问集中在20%的数据上）

• 这里需要考虑哪些数据适合缓存

• 缓存可以是本地缓存，也可以是远程分布式缓存

• 需要考虑使用合理的缓存策略，防止透传

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

• 如果能通过增加一台服务器的方式来改善负载压力，就可以以同样的方式持续增加服务器来不断改善系统性能，从而实现系统的可伸缩性

• 这里需要考虑使用哪些负载均衡的策略

• 数据库读写分离

• 缓存中的数据，如果更新过快，那么会持续刷新缓存，从而降低性能

• 可以利用主流数据库提供的主从热备功能，通过配置两台数据库的主从关系，同时业内也有很多优秀的开源中间件如Atlas

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

• CDN和反向代理的基本原理都是缓存

• CDN部署在网络提供商的机房，用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据

• 反向代理部署在网站的中心机房，当用户的请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，那么就将其直接返回给用户

• CDN的重点：——《大型网站系统与Java中间件实践》

• 全局调度

• 缓存技术

• 内容分发

• 带宽优化

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

• 网站常用的数据库拆分手段是业务分库，即将不同业务的数据库部署到不同的物理服务器上

• 使用NoSQL和搜索引擎

• ES

• MongoDB

• 业务拆分，使用分而治之的手段将整个网站业务分成不同的产品线

• 这部分十分重要，道理很简单，但是执行起来的效果千差万别。

• 当下火热的微服务，也是基于这种思想。

• 技术实现方式也有很多

• SOA、服务化

• 中心化的 gataway方式

• 消息队列

• 不同服务访问同一个DB等

• 分布式服务

初始阶段，多使用LAMP来搭建，All In One即所有资源存放在一台服务器上

应用服务和数据服务分离，有独立的数据库服务器

使用缓存改善网站性能（依据是二八定律：80%的业务访问集中在20%的数据上）

• 这里需要考虑哪些数据适合缓存

• 缓存可以是本地缓存，也可以是远程分布式缓存

• 需要考虑使用合理的缓存策略，防止透传

这里需要考虑哪些数据适合缓存

缓存可以是本地缓存，也可以是远程分布式缓存

需要考虑使用合理的缓存策略，防止透传

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

• 如果能通过增加一台服务器的方式来改善负载压力，就可以以同样的方式持续增加服务器来不断改善系统性能，从而实现系统的可伸缩性

• 这里需要考虑使用哪些负载均衡的策略

如果能通过增加一台服务器的方式来改善负载压力，就可以以同样的方式持续增加服务器来不断改善系统性能，从而实现系统的可伸缩性

这里需要考虑使用哪些负载均衡的策略

数据库读写分离

• 缓存中的数据，如果更新过快，那么会持续刷新缓存，从而降低性能

缓存中的数据，如果更新过快，那么会持续刷新缓存，从而降低性能

• 可以利用主流数据库提供的主从热备功能，通过配置两台数据库的主从关系，同时业内也有很多优秀的开源中间件如Atlas

可以利用主流数据库提供的主从热备功能，通过配置两台数据库的主从关系，同时业内也有很多优秀的开源中间件如Atlas

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

CDN和反向代理的基本原理都是缓存

CDN部署在网络提供商的机房，用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据

反向代理部署在网站的中心机房，当用户的请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，那么就将其直接返回给用户

CDN的重点：——《大型网站系统与Java中间件实践》

• 全局调度

• 缓存技术

• 内容分发

• 带宽优化

• 全局调度

• 缓存技术

• 内容分发

• 带宽优化

全局调度

缓存技术

内容分发

带宽优化

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

• 网站常用的数据库拆分手段是业务分库，即将不同业务的数据库部署到不同的物理服务器上

网站常用的数据库拆分手段是业务分库，即将不同业务的数据库部署到不同的物理服务器上

使用NoSQL和搜索引擎

• ES

• MongoDB

ES

MongoDB

业务拆分，使用分而治之的手段将整个网站业务分成不同的产品线

• 这部分十分重要，道理很简单，但是执行起来的效果千差万别。

• 当下火热的微服务，也是基于这种思想。

• 技术实现方式也有很多

• SOA、服务化

• 中心化的 gataway方式

• 消息队列

• 不同服务访问同一个DB等

这部分十分重要，道理很简单，但是执行起来的效果千差万别。

当下火热的微服务，也是基于这种思想。

技术实现方式也有很多

• SOA、服务化

• 中心化的 gataway方式

• 消息队列

• 不同服务访问同一个DB等

SOA、服务化

中心化的 gataway方式

消息队列

不同服务访问同一个DB等

分布式服务

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

网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的。因此对于小型网站来说，最需要做的是位用户提供好的服务来创造价值，得到用户的认可，从而活下去，野蛮生长。

• 大型网站架构技术的核心价值是随网站所需灵活应对， 它是一个演化的过程

• 驱动大型网站技术发展的主要力量是网站的业务发展，是业务成就了技术，而不是相反。因此要摒弃为了技术而技术的套路

大型网站架构技术的核心价值是随网站所需灵活应对， 它是一个演化的过程

驱动大型网站技术发展的主要力量是网站的业务发展，是业务成就了技术，而不是相反。因此要摒弃为了技术而技术的套路

网站架构设计误区

• 一味追求大公司的解决方案

• 为了技术而技术

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

一味追求大公司的解决方案

为了技术而技术

企图用技术解决所有问题

2 架构模式

• 分层，这是在横向方向对系统进行切分

• 分层的挑战在于必须合理规划层次边界和接口

• 分层包括物理分层和逻辑分层两种

• 分割，这是在纵向方向对系统进行切分

• 将不同的功能和服务分割开来，包装秤高内聚低耦合的模块单元

• 分布式

• 分层和分割的目的在于小模块便于分布式部署

• 带来的问题：

• 1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；

• 2） 服务器越多，宕机的概率越大

• 常用的分布式方案：

• 1） 分布式应用和服务；

• 2） 分布式静态资源；

• 3） 分布式数据和存储；

• 4） 分布式计算；

• 5） 分布式配置、分布式锁、分布式文件系统。。。

• 集群，即多台服务器部署相同的应用，从而构成一个集群，通过负载均衡设备共同对外提供服务

• 即使访问量很小的分布式应用和服务，也至少要部署到两台服务器来构成一个小集群，这样可以提高系统的可用性

• 缓存，即将数据放在距离计算最近的位置以加快处理速度

• CDN

• 反向代理

• 本地缓存

• 分布式缓存

• 异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步进行协作

• 通常需要使用消息队列

• 带来的好处：

• 1） 提高系统可用性；

• 2） 加快网站响应速度；

• 3） 消除并发访问高峰

• 冗余

• 集群带来的必然结果

• 安全需求的必然结果

• 自动化，DevOps思维，尽量减少人工干预

• 自动化发布

• 自动化代码管理

• 自动化测试

• 自动化安全监测

• 自动化部署

• 自动化监控

• 自动化报警

• 自动化失效转移、恢复

• 自动化分配资源

• ......

• 安全

分层，这是在横向方向对系统进行切分

分层的挑战在于必须合理规划层次边界和接口

• 分层包括物理分层和逻辑分层两种

分层包括物理分层和逻辑分层两种

分割，这是在纵向方向对系统进行切分

• 将不同的功能和服务分割开来，包装秤高内聚低耦合的模块单元

将不同的功能和服务分割开来，包装秤高内聚低耦合的模块单元

分布式

• 分层和分割的目的在于小模块便于分布式部署

• 带来的问题：

• 1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；

• 2） 服务器越多，宕机的概率越大

• 常用的分布式方案：

• 1） 分布式应用和服务；

• 2） 分布式静态资源；

• 3） 分布式数据和存储；

• 4） 分布式计算；

• 5） 分布式配置、分布式锁、分布式文件系统。。。

分层和分割的目的在于小模块便于分布式部署

带来的问题：

• 1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；

• 2） 服务器越多，宕机的概率越大

1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；

2） 服务器越多，宕机的概率越大

常用的分布式方案：

• 1） 分布式应用和服务；

• 2） 分布式静态资源；

• 3） 分布式数据和存储；

• 4） 分布式计算；

• 5） 分布式配置、分布式锁、分布式文件系统。。。

1） 分布式应用和服务；

2） 分布式静态资源；

3） 分布式数据和存储；

4） 分布式计算；

5） 分布式配置、分布式锁、分布式文件系统。。。

集群，即多台服务器部署相同的应用，从而构成一个集群，通过负载均衡设备共同对外提供服务

• 即使访问量很小的分布式应用和服务，也至少要部署到两台服务器来构成一个小集群，这样可以提高系统的可用性

即使访问量很小的分布式应用和服务，也至少要部署到两台服务器来构成一个小集群，这样可以提高系统的可用性

缓存，即将数据放在距离计算最近的位置以加快处理速度

• CDN

• 反向代理

• 本地缓存

• 分布式缓存

CDN

反向代理

本地缓存

分布式缓存

异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步进行协作

• 通常需要使用消息队列

• 带来的好处：

• 1） 提高系统可用性；

• 2） 加快网站响应速度；

• 3） 消除并发访问高峰

通常需要使用消息队列

带来的好处：

• 1） 提高系统可用性；

• 2） 加快网站响应速度；

• 3） 消除并发访问高峰

1） 提高系统可用性；

2） 加快网站响应速度；

3） 消除并发访问高峰

冗余

• 集群带来的必然结果

• 安全需求的必然结果

集群带来的必然结果

安全需求的必然结果

自动化，DevOps思维，尽量减少人工干预

• 自动化发布

• 自动化代码管理

• 自动化测试

• 自动化安全监测

• 自动化部署

• 自动化监控

• 自动化报警

• 自动化失效转移、恢复

• 自动化分配资源

• ......

自动化发布

自动化代码管理

自动化测试

自动化安全监测

自动化部署

自动化监控

自动化报警

自动化失效转移、恢复

自动化分配资源

......

安全

3 大型网站核心架构要素

• 性能

• 一个性能问题可能会导致网站用户严重流失

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

• 可用性

• 没有网站可以完美的7*24运行

• 网站高可用结构的前提是必然会出现服务器宕机，儿高可用设计的目标是当服务器宕机时，服务或者应用依然可用

• 必要的手段是集群，即冗余

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

• 衡量标准：是否可以构建集群；是否可以方便的向集群中添加新的服务器

• 扩展性，直接关注网站的功能，保证可以快速响应需求变更

• 衡量标准： 网站增加新的业务产品时，是否对现有业务透明无影响

• 安全性

• 衡量标准： 针对现存和潜在的各种攻击和窃密手段，是否可以有效的应对

性能

• 一个性能问题可能会导致网站用户严重流失

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

一个性能问题可能会导致网站用户严重流失

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

可用性

• 没有网站可以完美的7*24运行

• 网站高可用结构的前提是必然会出现服务器宕机，儿高可用设计的目标是当服务器宕机时，服务或者应用依然可用

• 必要的手段是集群，即冗余

没有网站可以完美的7*24运行

网站高可用结构的前提是必然会出现服务器宕机，儿高可用设计的目标是当服务器宕机时，服务或者应用依然可用

必要的手段是集群，即冗余

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

• 衡量标准：是否可以构建集群；是否可以方便的向集群中添加新的服务器

衡量标准：是否可以构建集群；是否可以方便的向集群中添加新的服务器

扩展性，直接关注网站的功能，保证可以快速响应需求变更

• 衡量标准： 网站增加新的业务产品时，是否对现有业务透明无影响

衡量标准： 网站增加新的业务产品时，是否对现有业务透明无影响

安全性

• 衡量标准： 针对现存和潜在的各种攻击和窃密手段，是否可以有效的应对

衡量标准： 针对现存和潜在的各种攻击和窃密手段，是否可以有效的应对

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

不同视角下的网站性能

• 用户视角

• 主要是端到端的感觉

• 主要通过前段优化的手段来提升用户体验

• 开发人员视角

• 主要关注应用程序本身以及相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等

• 主要优化手段： 使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应、使用代码优化提升程序性能

• 运维人员视角

• 主要关注基础设施性能和资源利用率

• 主要优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用率

用户视角

• 主要是端到端的感觉

• 主要通过前段优化的手段来提升用户体验

主要是端到端的感觉

主要通过前段优化的手段来提升用户体验

开发人员视角

• 主要关注应用程序本身以及相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等

• 主要优化手段： 使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应、使用代码优化提升程序性能

主要关注应用程序本身以及相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等

主要优化手段： 使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应、使用代码优化提升程序性能

运维人员视角

• 主要关注基础设施性能和资源利用率

• 主要优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用率

主要关注基础设施性能和资源利用率

主要优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用率

性能测试指标

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

• 并发数，即系统能够同时处理的请求的数目，也反映了系统的负载特性

• 吞吐量，即单位时间内系统处理的请求数量，体现系统的整理处理能力

• 性能计数器， 描述服务器或者操作系统性能的一些数据指标

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

并发数，即系统能够同时处理的请求的数目，也反映了系统的负载特性

吞吐量，即单位时间内系统处理的请求数量，体现系统的整理处理能力

性能计数器， 描述服务器或者操作系统性能的一些数据指标

性能测试方法

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

• 负载测试，对系统不断的增加并发请求，知道系统的某项或者多项性能指标达到安全临界值

• 压力测试，超过安全负载的情况下，继续对系统增压，直到系统崩溃或者不能再处理任何请求

• 稳定性测试，在特定硬件、软件、网络情况下，给系统加载一定压力，是系统运行较长一段时间，来观察系统是否稳定

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

负载测试，对系统不断的增加并发请求，知道系统的某项或者多项性能指标达到安全临界值

压力测试，超过安全负载的情况下，继续对系统增压，直到系统崩溃或者不能再处理任何请求

稳定性测试，在特定硬件、软件、网络情况下，给系统加载一定压力，是系统运行较长一段时间，来观察系统是否稳定

Web前端优化

• 浏览器访问优化

• 减少http请求

• 使用浏览器缓存

• 启用压缩

• CSS放在页面最上面，Java放在页面最下面

• 减少Cookie传输

• CDN加速

• 反向代理

浏览器访问优化

• 减少http请求

• 使用浏览器缓存

• 启用压缩

• CSS放在页面最上面，Java放在页面最下面

• 减少Cookie传输

减少http请求

使用浏览器缓存

启用压缩

CSS放在页面最上面，Java放在页面最下面

减少Cookie传输

CDN加速

反向代理

应用服务器性能优化

• 分布式缓存

• 缓存从本质上来说，就是一个内存hash表

• 缓存需要缓存那些读写比很高、很少变化的数据，一般来说读写比在2:1以上时，缓存才有意义

• 应用程序读取数据时，首先到缓存中读取，如果缓存不存在或者已失效，再访问数据库，同时将新的数据放入缓存

• 缓存也需要注意缓存热点数据

• 缓存预热，在新启动的缓存系统中，在启动时就加载热点数据，这样启动后就可以直接使用

• 缓存穿透， 应用持续大量访问不存在的数据，因为这类数据不存在于缓存中，因此会大量访问数据库，从而降低性能

• 对于分布式缓存来说，目前有两类：

• 1）不同的缓存服务器之间进行通信，例如JBoss Cache；

• 2）不同缓存服务器之间不进行通信，例如Memcached

• 异步操作

• 一般会使用消息队列，带来的额外好处是会削平峰值

• 使用集群

分布式缓存

• 缓存从本质上来说，就是一个内存hash表

• 缓存需要缓存那些读写比很高、很少变化的数据，一般来说读写比在2:1以上时，缓存才有意义

• 应用程序读取数据时，首先到缓存中读取，如果缓存不存在或者已失效，再访问数据库，同时将新的数据放入缓存

• 缓存也需要注意缓存热点数据

• 缓存预热，在新启动的缓存系统中，在启动时就加载热点数据，这样启动后就可以直接使用

• 缓存穿透， 应用持续大量访问不存在的数据，因为这类数据不存在于缓存中，因此会大量访问数据库，从而降低性能

• 对于分布式缓存来说，目前有两类：

• 1）不同的缓存服务器之间进行通信，例如JBoss Cache；

• 2）不同缓存服务器之间不进行通信，例如Memcached

• 异步操作

• 一般会使用消息队列，带来的额外好处是会削平峰值

• 使用集群

缓存从本质上来说，就是一个内存hash表

缓存需要缓存那些读写比很高、很少变化的数据，一般来说读写比在2:1以上时，缓存才有意义

应用程序读取数据时，首先到缓存中读取，如果缓存不存在或者已失效，再访问数据库，同时将新的数据放入缓存

缓存也需要注意缓存热点数据

缓存预热，在新启动的缓存系统中，在启动时就加载热点数据，这样启动后就可以直接使用

缓存穿透， 应用持续大量访问不存在的数据，因为这类数据不存在于缓存中，因此会大量访问数据库，从而降低性能

对于分布式缓存来说，目前有两类：

• 1）不同的缓存服务器之间进行通信，例如JBoss Cache；

• 2）不同缓存服务器之间不进行通信，例如Memcached

1）不同的缓存服务器之间进行通信，例如JBoss Cache；

2）不同缓存服务器之间不进行通信，例如Memcached

异步操作

• 一般会使用消息队列，带来的额外好处是会削平峰值

一般会使用消息队列，带来的额外好处是会削平峰值

使用集群

代码优化

• 多线程

• 需要注意线程安全问题，方法：

• 1） 将对象设计成无状态对象；

• 2） 使用局部对象；

• 3） 并发访问资源时使用锁

• 资源复用

• 主要是单例和资源池（对象池）

• 数据结构，选择合适的算法

• 垃圾回收

• 合理设置垃圾回收策略

• 存储性能优化

• 机械硬盘 vs 固态硬盘

• B+树 vs LSM树

• RAID vs HDFS

多线程

• 需要注意线程安全问题，方法：

• 1） 将对象设计成无状态对象；

• 2） 使用局部对象；

• 3） 并发访问资源时使用锁

需要注意线程安全问题，方法：

• 1） 将对象设计成无状态对象；

• 2） 使用局部对象；

• 3） 并发访问资源时使用锁

1） 将对象设计成无状态对象；

2） 使用局部对象；

3） 并发访问资源时使用锁

资源复用

• 主要是单例和资源池（对象池）

主要是单例和资源池（对象池）

数据结构，选择合适的算法

垃圾回收

• 合理设置垃圾回收策略

合理设置垃圾回收策略

存储性能优化

• 机械硬盘 vs 固态硬盘

• B+树 vs LSM树

• RAID vs HDFS

机械硬盘 vs 固态硬盘

B+树 vs LSM树

RAID vs HDFS

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

网站可用性度量

• 网站不可用时间 = 故障修复时间点 - 故障发现时间点

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

• 一般以几个9来表示，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟

• 网站高可用架构的设计目标是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问

• 网站高可用架构的主要手段：数据和服务的冗余备份以及失效转移，一旦服务器宕机，就将服务切换至其他可用的服务器上。

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

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

• 一般以几个9来表示，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟

• 网站高可用架构的设计目标是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问

• 网站高可用架构的主要手段：数据和服务的冗余备份以及失效转移，一旦服务器宕机，就将服务切换至其他可用的服务器上。

一般以几个9来表示，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟

网站高可用架构的设计目标是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问

网站高可用架构的主要手段：数据和服务的冗余备份以及失效转移，一旦服务器宕机，就将服务切换至其他可用的服务器上。

高可用的应用

无状态应用： 应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任何一个服务器上，处理的结构都是相同的。

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

• 负载均衡： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上， 以提升整体的负载处理能力

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

• Session复制

• Session绑定

• 利用Cookie记录Session

• Session服务器

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

• 负载均衡： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上， 以提升整体的负载处理能力

负载均衡： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上， 以提升整体的负载处理能力

应用服务器集群的Session管理

• Session复制

• Session绑定

• 利用Cookie记录Session

• Session服务器

Session复制

Session绑定

利用Cookie记录Session

Session服务器

高可用的服务

• 分级管理

• 核心服务与非核心服务隔离

• 核心服务优先使用高性能服务器

• 超时设置

• 异步调用

• 必须满足可以使用异步调用方式

• 服务降级

• 幂等性设计

分级管理

• 核心服务与非核心服务隔离

• 核心服务优先使用高性能服务器

核心服务与非核心服务隔离

核心服务优先使用高性能服务器

超时设置

异步调用

• 必须满足可以使用异步调用方式

必须满足可以使用异步调用方式

服务降级

幂等性设计

• 服务高可用（高可靠）一直是美团外卖的第一要求，为了提高可用性，做了很多策略，包括并不限于上文提出的各种架构设计方案。

• 其实造成线上问题的很大一部分原因是由于发版造成的，也体现出了SOP的重要性。

• 关于降级与依赖隔离，可以考虑采用Hystrix实现自动降级与依赖隔离 。

• 服务高可用（高可靠）一直是美团外卖的第一要求，为了提高可用性，做了很多策略，包括并不限于上文提出的各种架构设计方案。

• 其实造成线上问题的很大一部分原因是由于发版造成的，也体现出了SOP的重要性。

• 关于降级与依赖隔离，可以考虑采用Hystrix实现自动降级与依赖隔离 。

• 服务高可用（高可靠）一直是美团外卖的第一要求，为了提高可用性，做了很多策略，包括并不限于上文提出的各种架构设计方案。

• 其实造成线上问题的很大一部分原因是由于发版造成的，也体现出了SOP的重要性。

• 关于降级与依赖隔离，可以考虑采用Hystrix实现自动降级与依赖隔离 。

服务高可用（高可靠）一直是美团外卖的第一要求，为了提高可用性，做了很多策略，包括并不限于上文提出的各种架构设计方案。

其实造成线上问题的很大一部分原因是由于发版造成的，也体现出了SOP的重要性。

关于降级与依赖隔离，可以考虑采用Hystrix实现自动降级与依赖隔离 。

高可用的数据

数据一旦出现问题，对于网站往往是毁灭性的打击，因此保护网站的数据就是保护企业的命脉。

• 主要手段：数据备份和失效转移

• 缓存服务高可用

主要手段：数据备份和失效转移

缓存服务高可用

• 观点一：缓存服务已经承担了业务中绝大多数的数据读取访问，因此需要同样保证高可用

• 观点二：缓存服务并不是数据存储服务，出现服务不可用导致数据丢失应从别的手段解决，而不是提高缓存服务本身高可用

• 缓存服务器集群中单机故障，集群规模较大时，数据丢失比例和数据负载压力影响很小。

• 观点一：缓存服务已经承担了业务中绝大多数的数据读取访问，因此需要同样保证高可用

• 观点二：缓存服务并不是数据存储服务，出现服务不可用导致数据丢失应从别的手段解决，而不是提高缓存服务本身高可用

• 缓存服务器集群中单机故障，集群规模较大时，数据丢失比例和数据负载压力影响很小。

• 观点一：缓存服务已经承担了业务中绝大多数的数据读取访问，因此需要同样保证高可用

• 观点二：缓存服务并不是数据存储服务，出现服务不可用导致数据丢失应从别的手段解决，而不是提高缓存服务本身高可用

• 缓存服务器集群中单机故障，集群规模较大时，数据丢失比例和数据负载压力影响很小。

观点一：缓存服务已经承担了业务中绝大多数的数据读取访问，因此需要同样保证高可用

观点二：缓存服务并不是数据存储服务，出现服务不可用导致数据丢失应从别的手段解决，而不是提高缓存服务本身高可用

缓存服务器集群中单机故障，集群规模较大时，数据丢失比例和数据负载压力影响很小。

• CAP原理： 一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Parition Tolerance）这三个条件

• 数据高可用含义：

• 1）数据持久性

• 同时写入数据副本

• 2）数据可访问性

• 多个副本可读

• 3）数据一致性

• 副本间数据一致

• 数据一致性分类：

CAP原理： 一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Parition Tolerance）这三个条件

数据高可用含义：

• 1）数据持久性

• 同时写入数据副本

• 2）数据可访问性

• 多个副本可读

• 3）数据一致性

• 副本间数据一致

1）数据持久性

• 同时写入数据副本

同时写入数据副本

2）数据可访问性

• 多个副本可读

多个副本可读

3）数据一致性

• 副本间数据一致

副本间数据一致

数据一致性分类：

• 1） 数据强一致；

• 2） 数据用户一致；

• 3） 数据最终一致

• 1） 数据强一致；

• 2） 数据用户一致；

• 3） 数据最终一致

• 1） 数据强一致；

• 2） 数据用户一致；

• 3） 数据最终一致

• 1） 数据强一致；

• 2） 数据用户一致；

• 3） 数据最终一致

1） 数据强一致；

2） 数据用户一致；

3） 数据最终一致

• 数据备份

• 冷备的优点是简单和廉价，成本和技术难度较低，缺点是不能保证数据最终一致

• 热备分为两种：

• 1） 异步热备；

• 2） 同步热备

• 失效转移

• 失效确认：

• 1） 心跳检测（Keepalived、Heartbeat）；

• 2） 应用程序访问失败报告

• 访问转移

• 数据恢复

数据备份

• 冷备的优点是简单和廉价，成本和技术难度较低，缺点是不能保证数据最终一致

• 热备分为两种：

• 1） 异步热备；

• 2） 同步热备

冷备的优点是简单和廉价，成本和技术难度较低，缺点是不能保证数据最终一致

热备分为两种：

• 1） 异步热备；

• 2） 同步热备

1） 异步热备；

2） 同步热备

失效转移

• 失效确认：

• 1） 心跳检测（Keepalived、Heartbeat）；

• 2） 应用程序访问失败报告

• 访问转移

• 数据恢复

失效确认：

• 1） 心跳检测（Keepalived、Heartbeat）；

• 2） 应用程序访问失败报告

1） 心跳检测（Keepalived、Heartbeat）；

2） 应用程序访问失败报告

访问转移

数据恢复

高可用网站的软件质量保证

• 网站发布，它的过程和服务器宕机效果箱单，其对系统可用性的影响也 类似

• 一般采取批量更新的方式进行，不会一次关掉集群中的全部服务器

• 自动化测试

• 一般使用Selenium来进行测试

• 预发布验证

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

• 代码控制

• 主干开发，分支发布

• 分支开发，主干发布，这是目前使用的主流方式

• 自动化发布

• 火车模型：将每个应用的发布过程看做一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，通过的项目继续坐着火车旅行，直到火车到达终点。

• 实际中，可能所有项目在途中都下车了，这样火车不得不回到原点，等待问题解决后再来一次

• 一种可能是火车上的重点项目如果失败，那么整趟火车需要返回

• 人的干预越少，自动化程度越高，引入故障的可能性就越小

• 灰度发布

• 大型网站都会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天你才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可

网站发布，它的过程和服务器宕机效果箱单，其对系统可用性的影响也 类似

• 一般采取批量更新的方式进行，不会一次关掉集群中的全部服务器

一般采取批量更新的方式进行，不会一次关掉集群中的全部服务器

自动化测试

• 一般使用Selenium来进行测试

一般使用Selenium来进行测试

预发布验证

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

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

代码控制

• 主干开发，分支发布

• 分支开发，主干发布，这是目前使用的主流方式

主干开发，分支发布

分支开发，主干发布，这是目前使用的主流方式

自动化发布

• 火车模型：将每个应用的发布过程看做一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，通过的项目继续坐着火车旅行，直到火车到达终点。

• 实际中，可能所有项目在途中都下车了，这样火车不得不回到原点，等待问题解决后再来一次

• 一种可能是火车上的重点项目如果失败，那么整趟火车需要返回

• 人的干预越少，自动化程度越高，引入故障的可能性就越小

火车模型：将每个应用的发布过程看做一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，通过的项目继续坐着火车旅行，直到火车到达终点。

实际中，可能所有项目在途中都下车了，这样火车不得不回到原点，等待问题解决后再来一次

一种可能是火车上的重点项目如果失败，那么整趟火车需要返回

人的干预越少，自动化程度越高，引入故障的可能性就越小

灰度发布

• 大型网站都会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天你才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可

大型网站都会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天你才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可

网站运行监控

• 监控数据采集

• 用户行为日志收集

• 服务器性能监控

• 运行数据报告

• 监控管理

• 系统报警

• 失效转移

• 自动优雅降级

监控数据采集

• 用户行为日志收集

• 服务器性能监控

• 运行数据报告

用户行为日志收集

服务器性能监控

运行数据报告

监控管理

• 系统报警

• 失效转移

• 自动优雅降级

系统报警

失效转移

自动优雅降级

6 永无止境 - 可伸缩性架构

网站伸缩性： 在不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力

网站伸缩性： 在不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力

网站架构的伸缩性设计

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

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

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

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

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

• HTTP重定向负载均衡

• DNS域名解析负载均衡

• 反向代理负载均衡

• IP负载均衡

• 数据链路层负载均衡

• 负载均衡算法

• 轮询

• 加权轮询

• 随机

• 最小链接

• 原地址散列

HTTP重定向负载均衡

DNS域名解析负载均衡

反向代理负载均衡

IP负载均衡

数据链路层负载均衡

负载均衡算法

• 轮询

• 加权轮询

• 随机

• 最小链接

• 原地址散列

轮询

加权轮询

随机

最小链接

原地址散列

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

• Memcached分布式缓存集群的访问模型

• 用程序通过Memcached客户端访问Memcached服务器集群，Memcached客户端主要由一组API、Memcached服务器集群路由算法、Memcached服务器集群列表以及通信模块构成

• 路由算法负责根据应用程序输入的缓存数据KEY计算得到应该将数据写入到Memcached的哪台服务器（写缓存）或者应该从哪台服务器读数据（读缓存）

• Memcached分布式缓存集群的伸缩性挑战

• 挑战主要针对路由算法，当集群扩容时，如何保证路由算法可以得到新加入的服务器？

• 解决方法： 在网站访问量最少的时候扩容，然后通过模拟请求的方法逐渐预热缓存，使得缓存服务器中的数据重新分布

• 分布式缓存的一致性Hash算法

Memcached分布式缓存集群的访问模型

• 用程序通过Memcached客户端访问Memcached服务器集群，Memcached客户端主要由一组API、Memcached服务器集群路由算法、Memcached服务器集群列表以及通信模块构成

• 路由算法负责根据应用程序输入的缓存数据KEY计算得到应该将数据写入到Memcached的哪台服务器（写缓存）或者应该从哪台服务器读数据（读缓存）

用程序通过Memcached客户端访问Memcached服务器集群，Memcached客户端主要由一组API、Memcached服务器集群路由算法、Memcached服务器集群列表以及通信模块构成

路由算法负责根据应用程序输入的缓存数据KEY计算得到应该将数据写入到Memcached的哪台服务器（写缓存）或者应该从哪台服务器读数据（读缓存）

Memcached分布式缓存集群的伸缩性挑战

• 挑战主要针对路由算法，当集群扩容时，如何保证路由算法可以得到新加入的服务器？

• 解决方法： 在网站访问量最少的时候扩容，然后通过模拟请求的方法逐渐预热缓存，使得缓存服务器中的数据重新分布

挑战主要针对路由算法，当集群扩容时，如何保证路由算法可以得到新加入的服务器？

解决方法： 在网站访问量最少的时候扩容，然后通过模拟请求的方法逐渐预热缓存，使得缓存服务器中的数据重新分布

分布式缓存的一致性Hash算法

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

• 数据存储服务器必须保证数据的可靠存储，任何情况下都必须保证数据的可用性和正确性

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

• 利用主从结构实现读写分离

• 根据不同业务的数据，放到不同的数据库集群中，即数据库分库

• 对于特别大的表，进行分片处理

• NoSQL数据库的伸缩性设计

• HBase

数据存储服务器必须保证数据的可靠存储，任何情况下都必须保证数据的可用性和正确性

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

• 利用主从结构实现读写分离

• 根据不同业务的数据，放到不同的数据库集群中，即数据库分库

• 对于特别大的表，进行分片处理

利用主从结构实现读写分离

根据不同业务的数据，放到不同的数据库集群中，即数据库分库

对于特别大的表，进行分片处理

NoSQL数据库的伸缩性设计

• HBase

HBase

7 随需应变 - 可扩展架构

可扩展性：在对现有系统影响最小的情况下，系统功能可持续扩展或者提升的能力

实现可扩展的手段：低耦合，高内聚

可扩展性：在对现有系统影响最小的情况下，系统功能可持续扩展或者提升的能力

实现可扩展的手段：低耦合，高内聚

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

• 事件驱动架构（Event Driven Architecture）

• 定义：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作。典型的场景是生产着消费者模型

• 分布式消息队列

事件驱动架构（Event Driven Architecture）

• 定义：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作。典型的场景是生产着消费者模型

定义：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作。典型的场景是生产着消费者模型

分布式消息队列

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

• 需要将超大型的、复杂系统查分成可独立部署的模块，从而降低耦合性

• Web Service与企业分布式服务

• Web Service比较臃肿，可以考虑使用REST

• 或者使用开源的解决方案，例如Dubbo

需要将超大型的、复杂系统查分成可独立部署的模块，从而降低耦合性

Web Service与企业分布式服务

• Web Service比较臃肿，可以考虑使用REST

• 或者使用开源的解决方案，例如Dubbo

Web Service比较臃肿，可以考虑使用REST

或者使用开源的解决方案，例如Dubbo

可扩展的数据结构

8 固若金汤 - 安全架构

典型攻击方式

• XSS攻击（跨站脚本攻击）

• 黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式

• 分类：

• 1） 反射型；

• 2） 持久型

• 解决方法：

• 1） 消毒；

• 2) HttpOnly

• 注入攻击

• 分类：

• 1） SQL注入攻击；

• 2） OS注入攻击

• 解决方法：

• 1） 消毒；

• 2） 参数绑定

• CSRF攻击（跨站点请求伪造）

• 攻击者通过跨站请求，以合法用户的身份进行非法操作

• 解决方法： 识别请求者身份：

• 1） 表单Token；

• 2） 验证码；

• 3） Referer check

• 其他攻击方式

• Error Code，可能显示异常堆栈，从而暴露危险信息，解决方法：使用统一的500页面

• HTML注释，注释可能会暴露危险信息，解决方法：code review或者自动扫描

• 文件上传，可能上传病毒文件，解决方法：设置上传文件白名单，只允许上传指定类型的文件

• 路径遍历， 在URL中使用相对路径，遍历系统未开放的目录和文件，解决方法： 将资源文件部署在独立的服务器上，使用独立域名

XSS攻击（跨站脚本攻击）

• 黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式

• 分类：

• 1） 反射型；

• 2） 持久型

• 解决方法：

• 1） 消毒；

• 2) HttpOnly

黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式

分类：

• 1） 反射型；

• 2） 持久型

1） 反射型；

2） 持久型

解决方法：

• 1） 消毒；

• 2) HttpOnly

1） 消毒；

2) HttpOnly

注入攻击

• 分类：

• 1） SQL注入攻击；

• 2） OS注入攻击

• 解决方法：

• 1） 消毒；

• 2） 参数绑定

分类：

• 1） SQL注入攻击；

• 2） OS注入攻击

1） SQL注入攻击；

2） OS注入攻击

解决方法：

• 1） 消毒；

• 2） 参数绑定

1） 消毒；

2） 参数绑定

CSRF攻击（跨站点请求伪造）

• 攻击者通过跨站请求，以合法用户的身份进行非法操作

• 解决方法： 识别请求者身份：

• 1） 表单Token；

• 2） 验证码；

• 3） Referer check

攻击者通过跨站请求，以合法用户的身份进行非法操作

解决方法： 识别请求者身份：

• 1） 表单Token；

• 2） 验证码；

• 3） Referer check

1） 表单Token；

2） 验证码；

3） Referer check

其他攻击方式

• Error Code，可能显示异常堆栈，从而暴露危险信息，解决方法：使用统一的500页面

• HTML注释，注释可能会暴露危险信息，解决方法：code review或者自动扫描

• 文件上传，可能上传病毒文件，解决方法：设置上传文件白名单，只允许上传指定类型的文件

• 路径遍历， 在URL中使用相对路径，遍历系统未开放的目录和文件，解决方法： 将资源文件部署在独立的服务器上，使用独立域名

Error Code，可能显示异常堆栈，从而暴露危险信息，解决方法：使用统一的500页面

HTML注释，注释可能会暴露危险信息，解决方法：code review或者自动扫描

文件上传，可能上传病毒文件，解决方法：设置上传文件白名单，只允许上传指定类型的文件

路径遍历， 在URL中使用相对路径，遍历系统未开放的目录和文件，解决方法： 将资源文件部署在独立的服务器上，使用独立域名

信息加密技术以及密钥管理

• 单项散列加密，包括MD5、SHA等

• 对称加密， 包括DES算法、RC算法等

• 非对称加密， 包括RSA算法等

• 密钥安全管理

• 将密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设置，对外提供加密和解密服务

• 将加解密算法放在应用系统中，密钥则放在独立服务器中，在存储时，将密钥切分成数片，分别存储在不同的介质中

单项散列加密，包括MD5、SHA等

对称加密， 包括DES算法、RC算法等

非对称加密， 包括RSA算法等

密钥安全管理

• 将密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设置，对外提供加密和解密服务

• 将加解密算法放在应用系统中，密钥则放在独立服务器中，在存储时，将密钥切分成数片，分别存储在不同的介质中

将密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设置，对外提供加密和解密服务

将加解密算法放在应用系统中，密钥则放在独立服务器中，在存储时，将密钥切分成数片，分别存储在不同的介质中

后记

在大型网站的建设中，千万不要一味遵循一些所谓的标准，因为有些标准的指定根本不是针对大型网站系统的。

不能为了技术而技术，能落地的架构才是好架构，架构设计不能堆砌概念和模式，不能面面俱到却不解决具体问题。

做架构设计的目的不是为了炫耀自己知道多少术语。

不要企图去设计一个大型网站

尤其很多传统企业进入互联网时，会试图在互联网领域开发一个大型网站复制其在传统行业的优势地位，但是互联网发展运行有其自己的规律，短暂的互联网历史已经一再证明这种企图是行不通的。

互联网没有门槛，谁都可以进来玩，但是进来后，最好把那些陈旧的思想和包袱放下。

互联网是一种精神，一种开发、分享、自由的精神；越是不计回报越是获得丰厚的回报。

架构师人在职场，需要处理好个人、团队、公司的利益。需要不断在工作中发现问题、解决问题，提升工作经验、知识技能和核心竞争力，扩大自身影响力。

新员工首先要做的事情是融入团队，等熟悉了情况，再寻找突破口，择机而动

新员工最不需要做的事情就是证明自己的能力。

把“我的问题”表述成“我们的问题”

给上司提封闭式问题，给下属提开放式问题

支出问题而不是批评人

用赞同的方式提出问题

在解决我的问题之前，先解决你的问题

适当的逃避问题

架构师领导艺术

关注人而不是产品

一群优秀的人做一件他们热爱的事，一定能取得成功

寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围

发掘人的优秀

是事情成就了人，而不是人成就了事

共享美好蓝图

共同参与架构

不要只有架构师一个人拥有架构

让其他人维护框架与架构文档

学会妥协

成就他人

SDCC 2017·深圳站之架构&大数据技术实战峰会将于2017年6月10-11日于深圳南山区中南海滨大酒店举行，集阿里、腾讯、百度、滴滴出行、Intel、微博、唯品会的资深架构师和一线实践者，纳知名研发案例，遇见苏宁云商大数据中心总监陈敏敏、Apache RocketMQ联合创始人冯嘉、饿了么大数据平台部总监毕洪宇等大牛。

票务火热，预购从速，团购立减1000元，更多嘉宾和详细议题敬请关注大会官网和票务点击阅读原文注册参会。

大会官网：http://bss.csdn.net/m/topic/sdcc_2017/shenzhen

SDCC 2017·深圳站之架构&大数据技术实战峰会将于2017年6月10-11日于深圳南山区中南海滨大酒店举行，集阿里、腾讯、百度、滴滴出行、Intel、微博、唯品会的资深架构师和一线实践者，纳知名研发案例，遇见苏宁云商大数据中心总监陈敏敏、Apache RocketMQ联合创始人冯嘉、饿了么大数据平台部总监毕洪宇等大牛。

票务火热，预购从速，团购立减1000元，更多嘉宾和详细议题敬请关注大会官网和票务点击阅读原文注册参会。

大会官网：http://bss.csdn.net/m/topic/sdcc_2017/shenzhen 返回搜狐，查看更多