高性能（瞬时响应）

1. 性能测试

1.1测试指标

• 响应时间

应用执行一个操作需要的时间，发出请求到数据响应

• 并发数

系统能够同时处理请求的数目，这个数字也反映了系统的负载特性

• 吞吐量

单位时间内系统处理的请求数量，提现系统处理的整体能力，TPS（每秒事物数）是吞吐量常用的一个量化指标

• 性能计数器

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

1.2测试方法

• 性能测试 预期指标

• 负载测试 安全临界值，持续增加访问压力，系统处理能力下降（系统最大负载点）

• 压力测试 继续施加压力直至系统崩溃，获得系统最大压力承受能力（系统崩溃点）

• 稳定性测试 系统维持较长一段时间来检测系统是否稳定

2.性能优化

2.1 web前端性能优化

• 浏览器访问优化

减少HTTP请求、使用浏览器缓存、启用压缩、CSS上JS下、减少Cookie传输

• CDN加速

• 反向代理

2.2 应用服务器性能优化

• 分布式缓存

缓存是介于数据访问者和数据源之间的一种高速存储，当数据需要多次读取的时候，用于加快读取速度。

缓存本质是一个内存Hash表，关键指标是缓存命中率。

缓存分为通读缓存和旁路缓存，

通读缓存给客户端返回缓存资源，请求未命中缓存时获取实际数据，客户端只连接通读缓存，代理缓存、反向代理缓存、CDN缓存都是通读缓存

旁路缓存通常是一个独立的键值对，应用先访问缓存，未命中，访问数据源，对象缓存属于旁路缓存

分布式缓存的一致性Hash算法，https://xie.infoq.cn/article/f6adf127695ae36266adbbba0

技术栈各个层次的缓存

合理使用缓存：频繁修改的数据、缓存雪崩、缓存穿透、缓存预热、缓存失效时间（容忍一定时间的数据不一致和脏读）

Redis VS Memcached



• 异步操作

使用消息队列将调用异步化，可改善网站扩展性（参考后续内容），也可改善网站性能



不使用消息队列，数据直接写入数据库，高并发情况下，对数据库造成巨大压力，同时响应延迟加剧。使用消息队列后，请求数据发送给队列后直接返回，消息队列的消费者进程异步写入数据，响应延迟可以得到改善。

消息队列可以削峰，通过异步，将短时间高并发事物消息存储在消息队列中，削平高峰期的并发事物。

需要注意的时要最终保证数据一致性。

任何可以晚点做的事情都应该晚点再做。

• 使用集群

使用负载均衡构建集群，避免单一服务器因负载压力过大而响应过慢

• 代码优化

多线程、资源复用、数据结构、垃圾回收

2.3 存储性能优化

高可用（万无一失）

网站可有效访问特性，网站硬件故障是常态，所以高可用架构设计的主要目标就是保证服务器硬件故障 时服务以然可用、数据依然保存并能够访问。主要手段数据和服务的冗余备份及失效转移。

1. 可用性度量

业界用多少个9来衡量网站的可用性，如QQ的可用性是4个9，即QQ服务99.99%可用，一年中大约53分钟不可用

1. 高可用应用

应用层主要处理网站应用的业务逻辑，也称为业务逻辑层

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

对于应用服务器集群，实现这种服务器可用状态的实时监测、自动转移失败任务的机制是i负载均衡。应用访问量非常小，一台服务器提供服务绰绰有余，但为了服务高可用，使用负载均衡至少部署两台

• session服务器

3.高可用服务

可复用的服务，为业务产品提供基础公共服务。实现手段：

• 负载均衡

• 分级管理

运维上将服务器进行分级管理，核心应用和服务优先使用更好的硬件，同时服务部署上也进行必要的隔离，避免故障的连锁反应。

• 超时设置

服务宕机、线程死锁可能导致应用程序对服务端的调用失去响应，导致用户请求长时间得不到响应，同事还占用应用程序资源

• 异步调用

应用对服务调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败

• 服务降级

拒绝服务及关闭服务

• 幂等性设计

应用调用服务失败后，会重试，服务要防止应用重复调用

4.高可用数据

保证数据存储高可用的手段主要是数据备份和失效转移机制

5.软件质量

6.监控

伸缩性（永无止境）

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

1. 伸缩性设计

• 根据功能进行物理分离实现伸缩，不同服务器部署不同的功能

纵向分离（分层）、横向分离（业务分离）

• 单一功能通过集群实现伸缩，不同服务部署相同服务

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

负载均衡可以实现网站的伸缩性，还可以改善网站的可用性

先贴个网络模型图



• HTTP重定向负载均衡器

优点：比较简单

缺点：浏览器需两次请求，性能较差，重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限

• DNS域名解析负载均衡器

优点：将负载均衡的工作转交给DNS,省掉了网站管理维护的麻烦，同时DNS支持基于地理位置的域名解析，即将域名解析成距离用户地理最近的一个服务器地址，可加快用户访问，改善性能

缺点：DNS缓存会导致服务下线后，DNS仍将请求发到下线服务

• 反向代理负载均衡

转发请求在HTTP协议层面，也叫应用层负载均衡，七层负载均衡

优点：部署简单

缺点：其是所有请求和响应的中转站，其性能可能会成为瓶颈

• IP负载均衡

在网络层通过修改请求目标地址进行负载均衡

优点：数据分发在内核完成，较反向代理（在应用程序中分发数据）有更好的处理性能

缺点：所有请求和响应都经过该均衡器，集群的最大响应吞吐量受制于负载均衡服务器的网卡带宽（下载或视频难以满足）

• 数据链路层负载均衡

在链路层修改ma地址

大型网站使用最广的一种负载均衡手段，linux平台选lvs

负载均衡算法：轮询（默认）、加权、

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

不同于应用服务器集群的伸缩性设计，不能简单使用负载均衡器，因为不同服务器中缓存数据不同，请求要先找到缓存请求数据的服务器，新上线服务器没有缓存任何数据，下线服务器还缓存着热点数据，新加入缓存服务器后，缓存数据要被尽可能访问到是集群伸缩性设计的最主要目标。

基于虚拟节点的一致性Hash算法，上文有实现链接。

4.数据存储服务器集群

数据存储服务器集群的伸缩性对数据的持久性和可用性提出了更高的要求

• MySQL主从复制



• MySQL主主复制

主主复制的两个数据库不能并发写入

复制只增加了数据的读并发能力，没有增加写并发能力和存储能力

更新表结构会导致巨大延迟

• 数据分片

扩展性（随需应变）

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

扩展性是系统架构设计层面的开闭原则，架构设计考虑未来功能扩展，当系统增加新功能时，不要对现有系统的结构和代码进行修改。开发低耦合的系统是软件设计的终极目标之一，分层和分割也是模块化设计的重要手段，独立模块部署在独立服务器上。

模块分布式部署后具体的聚合方式有分布式消息队列和分布式服务。

1. 分布式消息队列构建异步调用架构降低系统耦合性

消息队列的好处：实现异步处理，提升处理性能、更好的伸缩性、削峰填谷、失败隔离和自我修复（生产者和消费者互相不受对方失败影响）、解耦

• 点对点模型

• 发布订阅模型

• 事件驱动架构

• 主要MQ产品比较

1）RabbitMQ 性能好，社区活跃

2）ActiveMQ 影响比较广泛，可跨平台，使用Java开发，对Java比较友好

3）RocketMQ 是阿里推出的一个开源产品，也是使用Java开发，性能比较好，可靠性也比较高

4）Kafka，Linkedln出品的，Scala开发，专门针对分布式场景进行了优化，因此分布式的伸缩性比较好

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

分布式服务是降低系统耦合性的另一个重要手段。如果说分布式消息队列通过消息对象分解系统耦合性，不同子系统处理同一个消息，那么分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用

• WebService与企业级分布式服务

• 分布式服务框架设计

Dubbo、SpringCloud

3. 可扩展数据结构

安全性（固若金汤）

1. 加密

2. 信息过滤与反垃圾

3. 风险控制