3.分布式服务架构：原理、设计与实战 --- 服务化系统容量评估和性能保障

3.1 架构设计与非功能质量
	架构设计分为需求分析和整理,概要设计和详细设计等三个阶段.

	在需求分析和整理阶段梳理所有用例和场景,并抽象出系统面向的用户和角色,梳理对每个用户和角色应该提供的功能需求,非功能需求和限制.这里的非功能需求包括:高可用性,
高性能,可伸缩,可扩展,安全性,稳定性,健壮性,可测试性等.然后对功能性需求和非功能质量需求进行整理,识别核心需求和特色需求,最后,以核心需求和特色需求为根本展开架构设计.
	
	在概要设计阶段，根据需求分析和整理阶段产出的核心需求和特色需求，对整个系统进行模块划分，并定义良好的模块之间的关系和交互。

	在详细设计阶段，通常会使用多视图的方法来描述系统的架构，多视图包括：数据视图，逻辑视图，开发视图，进程视图，物理视图，性能视图，安全视图等。

	互联网架构权衡分析方法(ATAM)是评价软件架构的一种综合且全面的方法，它不仅可以揭示架构满足特定质量目标的情况，而且还可以使我们更清楚的认识到质量于目标之间
的制约和权衡。因为在系统分析阶段，对于一个功能会捕捉多个质量属性，质量属性之间可能是有关联的，还可能是互斥的，这需要具体问题具体分析。
	ATAM 是一个能够在项目开始实施之前评估架构是否能够满足这些非功能质量的方法论。这个方法论通过在架构设计的不同阶段提出不同的问题，来帮助架构设计人员发现架构
设计上的问题，并在实践中总结出架构设计的模式。


3.2 全面的非功能质量需求

	3.2.1 非功能质量需求的概述
	高性能：运行效率高，性价比高。
	可用性：持续可用性，缩短宕机时间，出错恢复，可靠性
	可伸缩性：垂直伸缩，水平伸缩
	可扩展性：可插拔，组件重用
	安全性：数据安全，加密，熔断，防攻击
	可监控性：快速发现，定位和解决
	可测试性：可灰度，可预览，可Mock，可拆解
	鲁棒性：容错性，可恢复性
	可维护性：易于维护，监控，运营和扩展
	可重用性：可移植性，解耦
	易用性：可操作性

	对于一个线上服务，高性能通常是指单点服务的吞吐量和响应时间；可用性以全年时间减去当年宕机时间，并用得到的差值除以全年时间得出，通常是表明服务质量的最核心
指标；可伸缩是指横向扩展的能力，也是随着节点的增加，服务能力能够随着节点增加而线性增加，如果不能，则也可以使用百分比来衡量；可扩展性通常是指架构上的灵活性
及可插拔性，将来可以不断的在系统上叠加新业务和新功能；安全性是指系统的安全保护措施，要防止攻击和数据泄露等。
	
	这里，可监控性是非常重要的；可测试性是指我们开发的服务一定要在不同的阶段有相应的方法和途径来测试，包括QA测试，准生产测试和生产测试等；对于不具备测试
条件的系统使用Mock等方法来解决；鲁棒性表明系统的容错性，健壮性和可灰度性；可维护性是指系统要易于监控，运营和扩展；可重用性指系统具有模块化，可移植性，
可通过迭代增加新功能的特性；易操作性指系统对用户友好，方面系统的各类用户使用。

	3.2.2 非功能质量需求的具体指标
		非功能质量需求的具体指标针对不同的系统主要分为4个部分：应用服务器，数据库，缓存和消息队列。

		1.应用服务器
			应用服务器主要关心每秒请求的峰值及对请求的响应时间等指标，通过这些指标可以评估我们需要的应用服务器数量。

			部署结构的相关指标如下：
			1.负载均衡策略
			2.高可用策略
			3.IO模型(NIO/BIO)
			4.线程池模型
			5.线程池中线程的数量
			6.是否多业务混合部署

			容量和性能相关指标如下：
			1.每天的请求量
			2.各接口的访问峰值
			3.平均的请求响应时间
			4.最大的请求响应时间
			5.在线的用户量
			6.请求的大小
			7.网卡的IO流量
			8.磁盘的IO负载
			9.内存的使用情况
			10.cpu的使用情况

			其他指标：
			1.请求的内容是否包含大对象
			2.GC收集器的选项和配置


		2.数据库
			根据应用层的访问量和访问峰值，计算出需要的数据库资源的吞吐量，每天的数据总量等。

			部署结构的相关指标：
			1.复制模型
			2.失效转移策略
			3.容灾策略
			4.归档策略
			5.读写分离策略
			6.分库分表(分片)策略
			7.静态数据和半静态数据是否使用缓存
			8.有没有考虑缓存穿透并压垮数据库的情况
			9.缓存失效和缓存数据预热的策略

			容量和性能的相关指标：
			1.当前的数据容量
			2.每天的数据增量(预估容量)
			3.每秒的读峰值
			4.每秒的写峰值
			5.每秒的事务量峰值

			其他指标：
			1.查询是否走索引
			2.有没有大数据量的查询和范围查询
			3.有没有多表关联，关联是否用到索引
			4.有没有所用悲观锁，是否可以改造成乐观锁，是否可以利用数据库内置行级锁
			5.事务和一致性级别
			6.使用的JDBC数据源类型及连接数等配置
			7.是否开启JDBC诊断日志
			8.有没有使用存储过程
			9.伸缩策略(分区表，自然时间分表，水平分库分表)
			10.水平分库分表的实现方法(客户端，代理，NoSQL)


		3.缓存
			根据应用层的访问量和访问峰值，通过评估热数据占比，计算缓存资源的大小并估算缓存资源的峰值，由此来计算所需缓存资源的数量，部署结构，高可用
		方案等。

			部署结构的相关指标：
			1.复制模型
			2.失效转移
			3.持久策略
			4.淘汰策略
			5.线程模型
			6.预热方法
			7.哈希分片策略

			容量和性能的相关指标：
			1.缓存内容的大小
			2.缓存内容的数量
			3.缓存内容的过期时间
			4.缓存的数据结构
			5.每秒的读峰值
			6.每秒的写峰值

			其他相关的指标：
			1.冷热数据比例
			2.是否有可能发生缓存穿透
			3.是否有大对象
			4.是否使用缓存实现分布式锁
			5.是否使用缓存支持的脚本(Lua)
			6.是否避免了Race Condition
			7.缓存分片方法(客户端，代理，集群)


		4.消息队列
			根据应用层的平均访问量和访问峰值，计算出需要消息队列传递的数据量，进而计算出所需要的消息队列资源的数量，部署结构，高可用方案等。

			部署结构相关的指标：
			1.复制模型
			2.失效转移
			3.持久策略

			容量和性能的相关指标：
			1.每天平均的数据增量
			2.消息持久的过期时间
			3.每秒的读峰值
			4.每秒的写峰值
			5.每条消息的大小
			6.平均延迟
			7.最大延迟

			其他指标：
			1.消费者线程池模型
			2.哈希分片策略
			3.消息的可靠投递
			4.消费者的处理流程和持久机制


3.3 典型的技术评审提纲
	3.3.1 现状
		1.业务背景
			1.项目名称
			2.业务描述
		2.技术背景
			1.架构描述
			2.当前的系统容量(系统调用量的平均值，请求响应时间的平均值等)
			3.当前系统调用量的峰值，最小和最大的请求响应时间

	3.3.2 需求
		1.业务需求
			1.要改造的内容
			2.实现的新需求

		2.性能需求
			1.预估系统的容量(预估系统调用量的平均值，预估请求响应时间的平均值)
			2.预估系统调用量的峰值，最小和最大的请求响应时间
			3.其他非功能质量，例如：安全性，可伸缩性等

	3.3.3 方案描述
		方案1：
			整个方案需要参考如3.2节所描述的相关指标来满足系统的非功能质量需求

		1.概述
			一句话概括方案的亮点，例如：双写，迁移，主从分离，分库分表，扩容，归档，接口改造等

		2.详细说明
			对方案的具体描述，文件描述不清楚的话可以结合图(如 UML，概念图，框图等)来说明，如果是改造方案，则最好突出有变动的地方。以下李珏了描述的
		角度。
			1.中间件架构(应用服务器，数据库，缓存，消息队列等)
			2.逻辑架构(模块划分，模块通信，信息留，时序等)
			3.数据架构(数据结构，数据分布，拆分策略，缓存策略，读写分离策略，查询策略，数据一致性策略)
			4.异常处理，容灾策略，灰度发布，上线方案，回滚方案

		3.性能评估
			1.给出方案的基准数据，并按性能需求评估需要使用的资源数量
			2.单机并发量
			3.单机容量
			4.单机吞吐量的峰值
			5.按照预估的性能需求，预估资源数量(应用服务器，缓存，存储，队列等)，伸缩方式和功能

		4.方案的优缺点
			列出方案的优缺点，优缺点要有确定性，不要有"存在一定风险"这种描述，即要量化，有明确的目标和结果。
			其他方案的描述如同方案1.

	3.3.4 方案对比
		对比可选方案，选择倾向的方案，并给出选择这种方案的理由。

	3.3.5 风险评估
		标识所选方案的风险，提出此风险发生时的应对策略，例如上线失败时的回滚策略。

	3.3.6 工作量评估 
		描述使用所选方案时需要做的具体工作，并评估开发，测试等细化任务需要的时间，形成可实施的任务计划表，计划表一般从项目计划和人员分配两个角度
	来管理项目。


3.4 性能和容量评估经典案例 
	3.4.1 背景 
		物流系统保护如下两个质量优先的需求：
		1.维护用户的常用地址，在下单时提供其地址列表
		2.下单时异步产生物流订单，物流系统后台通过第三方物流轮询拉去物流状态，已下单用户可查询订单的物流订单和物流记录

	3.4.2 目标数据量级 
		目标：
		1.用户量达到2亿，平均每天增长5w个
		2.平均的每天订单量为400w个，下单时间段集中在 9:00~23:00，促销时日订单量为1400w，50%的下单时间段集中在 19:30~20:30和22:00~23:00。
		
	3.4.3 量级评估标准 
		1.通用标准
			1.容量：按照峰值的5倍进行冗余计算
			2.用户的常用地址容量：按照30年计算
			3.数据物流订单的容量：时效性较强，按照3年计算
			4.第三方物流查询接口：吞吐量为5000/s

		2.MySQL
			1.单端口读：1000/s
			2.单端口写：700/s
			3.单表容量：5000w

		3.Redis
			1.单端口读：40000/s
			2.单端口写：40000/s
			3.单端口内存容量：32GB

		4.Kafka
			1.单机读：30000/s
			2.单机写：5000/s

		5.应用服务器
			1.请求量峰值：5000/s

	3.4.4 方案 
		方案1：最大性能方案
			由于整个电商网站刚刚上线，还无法清晰的确定数量级，所以根据行业内知名的电商的当前数量级来设计最大性能方案。

		需求1：用户常用地址
			1.整体流程
				1.提供restful服务来增加用户的常用地址
				2.提供resutful服务来获取用户的常用地址列表

			2.数据库资源评估
				1.读操作吞吐量
					在用户每次下单时拉取一次用户的地址列表，按照促销时日订单量1400w且50%的下单时间段集中在亮哥小时内计算：
					(1400w * 0.5)/(2 * 60 * 60) = 1000/s
					容量评估按照5倍冗余计算，读操作吞吐量峰值为 1000/s * 5 = 5000/s，需要5端口数据库服务读。
				2.写操作吞吐量
					假设每天新增的用户全部增加一次常用地址，并且在高峰期有20%的用户在下单时会增加一条常用地址：
					(1400w * 0.2 + 5w)/(2 * 60 * 60) = 400/s
					容量按照5倍冗余计算：
					400/s * 5 = 2000/s
					则需要3端口数据库服务写。
				3.数据容量
					当前有2亿用户，每天增长5w用户，平均每个用户有5个常用地址，30年后用户的常用地址表数量计算如下：
					(2亿 + 5 * 365 * 30) * 5 = 35亿
					容量按照5倍冗余：
					35亿 * 5 = 175亿

					则需要350张表容纳。

					根据以上读操作吞吐量，写操作吞吐量的评估，如果读写混合部署，则我们需要8个端口，可以使用8主8备；考虑使用读写分离，我们需要
				做主从部署，需要3主6从，与两倍数对齐，使用4主8从即可。
					根据表容量，我们需要350张表和2的指数对齐，选择512表，上面计算需要主库端口为4，考虑到将来端口扩展时不用拆分数据库，尽量设计更
				多的库，比如使用32个库。
					计算结果为：4端口 * 32库 * 4表，4主8从

			3.缓存资源评估
				为了提升用户下单体验，需要使用redis缓存活跃用户的常用地址。
				定义当天下单的用户为活跃用户，将活跃用户的地址缓存24小时，假定每天下单的用户平均为不同的用户，每个用户有5个地址，每个地址的大小为
			1kb左右，则缓存大小的计算如下：
				1400w * 5 * 1kb = 70GB
				按照5倍冗余：
				70GB * 5 = 350GB

				按照每台redis有32GB内存计算，则需要11台。根据数据库对数据存取的吞吐量的设计，11台机器完全可以满足 5000/s的读操作吞吐量和2000/s
			的写操作吞吐量。
				设计结果：11台，主从。

			4.应用服务器资源评估
				根据数据库的读操作吞吐量(5000/s)峰值和写操作吞吐量(2000/s)峰值计算，选择单台应用服务器即可，选择2台可以避免单点。
				计算结果：2台。

		需求2：物流订单和物流记录
			1.整体流程
				1.订单提交后，通过消息队列产生物流订单，物流订单消息稍后传入物流系统，物流系统消费物流订单消息后入库
				2.后台任务轮询未完成的物流订单，查询第三方物流接口状态，填写物流记录信息。按照每天产生1400w个订单，订单平均3天到货，第三方查询接口
				提供5000/s的吞吐量，则每次进行状态查询需要的时间计算如下：1400w * 3天/5000 = 2小时，即将任务定为2小时查询一次。
				3.提供restful获取物流订单信息
				4.提供restful获取物流记录信息

			2.数据库资源评估
				1.读操作评估
					在用户下单后三天到货，三天内50%的用户每天会查询一次物流订单和一次物流记录，计算如下：
					(1400w * 3 * 0.5)/(24 * 60 * 60) = 250/s
					按照5倍冗余：
					2 * 250/s * 5 = 2500/s
					即需要 3 端口数据库读操作。

				2.写操作评估
					用户每次下单时产生一次物流订单，按照促销时日订单量为 1400w，且50%的下单时间段几种在2小时内计算：
					(1400w * 0.5)/(2*60*60) = 1000/s
					按照每天产生1400w个订单，每个订单平均3天到货，每条物流订单产生8条物流记录，并且8条物流记录在3天内均匀产生，则物流记录写操作
				吞吐量计算如下：
					1400w*3*8/3/(24*60*60) = 1200/s
					按照5倍计算：
					(1000/s + 1200/s) * 5 = 11000/s
					则需要 16(15.7)端口数据库服务写。

				3.数据容量评估
					当前有2亿条物流订单积累，每天增加400w订单，则3年订单量为：
					2亿+400w*365*3 = 46亿
					按照5倍计算：
					46亿*5 = 230亿

					则需要460张表。物流记录表是物流订单的8倍，为 460*8=3680张表。
					根据以上读操作吞吐量和写操作吞吐量，如果读写混合部署，则共需要19端口，以及19主19备；如果考虑到读写分离，则我们需要16主16从。
					根据表容量，我们需要4680张表，和2的指数对齐后选择4096张表。上面的就散需要主库端口为16，考虑到将来端口扩展，应尽量设计更多的库。
				即使用32个库。
					设计结果：16端口*32库*8表，16主16从。

			3.消息队列评估
				为了让系统能够应对峰值的突增，我们采用消息队列kafka接收物流订单。
				根据上面对物流订单写操作的吞吐量的计算，考虑到5倍冗余后峰值为5000/s，通过单台kaka和单台处理器即可处理，考虑到单点，需要2台。
				如果峰值发生突增，则可以增加kafka集群节点来抗住写流量，处理机根据后端入库的性能来决定。例如写峰值增加10倍，达到50000/s，则需要10台kafka，
			每台kafka的读吞吐量可达到30000/s，理论上需要2台处理机，然后，处理机的瓶颈是后端入库的写操作，根据上面的计算，入库的写操作的峰值按照5000/s设计，
			因此，采用单台处理机即可。在这个场景下会有消息的堆积，但是最终会处理完毕并达到消峰的效果，考虑到单点，至少用2台kafka处理机。
				设计结果：2台kafka，2台处理机

			4.应用服务器评估
				根据数据库的读操作吞吐量(2500/s)峰值和写操作的吞吐量(11000/s)峰值计算，使用3台应用服务器即可。
				用于查询第三方接口的后台任务服务器，由于受到第三方接口5000/s吞吐量的限制，是用欧冠单台机器即可，2台避免单点。


		方案2：最小资源方案
			由于当前系统的线上数据量不多，增长量也不大，读操作吞吐量和写操作吞吐量时使用单台机器完全可以处理，暂时不考虑使用缓存和队列服务，但是保留使用缓存
		和消息队列时的接口，如果缓存和消息队列的资源可用，则可以通过开关切换。
			当前的数据量使用单库单表即可处理，然后，考虑到扩展性，暂时使用一个数据库端口，但是保留我们在最大性能方案中对数据库的分库分表。当读操作和写操作
		突增时，dba可以把库重新拆分到多个端口来抗住写请求流量。
			方案如下：
				1.用户常用地址
				设计结果：1端口*128库84表，1主1从
				2.物流订单和物流记录
				设计结果：1端口*512库*8表，1主1从

	3.4.5 小结 
		通过对比，我们倾向于使用最小资源方案，原因如下：
		1.当前线上流量并不大，使用最小资源方案可节省成本
		2.最小资源方案也充分考虑了数据库的分库分表，当读操作和写操作突增时，dba可以拆分库到不同的端口，也就是增加端口来应对。
		3.最小资源方案在应用层设计了开关，如果性能突增，则可以临时申请和开启缓存，消息队列


3.5 性能评估参考标准 
	3.5.1 常用的应用层性能指标参考标准 
		1.通用标准
			1.容量按照峰值的5倍冗余计算
			2.分库分表后的容量一般可存储30年的数据
			3.第三方查询接口吞吐量为5000/s
			4.单条数据库记录占用大约1kb的空间

		2.MySQL
			1.单端口读：1000/s
			2.单端口写：700/s
			3.单表容量：5000w条

		3.Redis
			1.单端口读：40000/s
			2.单端口写：40000/s
			3.单端口内存容量：32GB

		4.Kafka
			1.单机读：30000/s
			2.单机写：5000/s

		5.DB2
			1.单机读峰值：20000/s
			2.单机写峰值：20000/s
			3.单表容量：1亿条数据

	3.5.2 常用的系统层性能指标参考标准 
		1.寄存器和内存
			1.寄存器，L2,L3，内存，分支预测失败，互斥量加锁和解锁等耗时为纳秒级别
			2.内存随机读取可达30w次/s，顺序读取可达500w次/s
			3.内存每秒可以读取GB级别的数据
			4.读取内存中1MB的数据未250ns,为亚毫秒级

		2.磁盘IO
			1.普通的sata机械硬盘iops能达到 120次/s
			2.普通的sata机械硬盘顺序读取数据可达 100MB/s
			3.普通的sata机械硬盘随机读取数据可达 2MB/s
			4.普通的sata机械硬盘旋转半圈需要3ms
			5.普通的sata机械硬盘寻道需要3ms
			6.普通的sata机械硬盘在已经寻道后(找到了要读取的磁道，也找到了要读取的扇区)开始读取数据，读取一次数据真正的耗时为2ms
			7.FunsionIO卡(一种高的SSD硬盘套件)可达到百万级别的iops
			8.固态硬盘访问延迟：0.1~0.2ms,为压毫秒级别，和内存速度差不多。
			9.高端机器如IBM，华为等服务器配上高端的存储设备，可以达到每秒GB级别的数据读取，相当于普通内存的读取速度

		3.网络IO
			1.常见的千兆网卡的传输速度为 1000Mbit/s，即128Mbit/s
			2.千兆网卡读取1MB的数据：10ms

		4.数据库
			1.读写数据库中的一条记录在毫秒级别，短则几毫秒，多则几百毫秒，大于500ms一般认为超时。
			2.mysql在4核心，256GB内存的cpu中性价比最好，继续垂直扩展时由于体系结构的限制，成本开始增加，提升的性能开始减少，性价比开始降低。

		5.IDC
			1.同一机房网络来回：0.5ms
			2.异地机房来回：30~100ms
			3.同一机房的rpc服务调用为几个毫秒，有点为几十毫秒或者几百毫秒，一般设计500ms以上为超时时间。

		6.网站
			1.网页加载为秒级别
			2.UV:每日一共有多少用户来访问，用 cookie session 跟踪
			3.独立IP访问：每次有多少独立ip来访，同一个局域网可以看到同一个ip
			4.PV: 每日单独用户的所有页面访问量。如果每日uv为 50000000，那么每秒平均在线人数为 50000000/24/60/60=578人，还要知道这一秒内每个
			用户在干什么，如果每秒都在做查询操作，那么需要有一个能承受 578/s 吞吐量的机器
			5.某社交媒体每秒的写入量上万，每秒的请求量上百万，每天登陆的用户上亿，每天产生的数据量上千亿

		7.组合计算和估算
			1.普通SATA机器硬盘一次随机读取的时间为：3ms(磁盘旋转)+3ms(寻道)+2ms(存取数据延迟)=8ms
			2.普通SATA机器硬盘每秒随机读取：1000ms/8ms=125iops
			3.IOPS 代表磁盘每秒可以随机寻址多少次，随机读取速度取决于数据是如何存放的，如果数据按照块存放，每块4kb，每次读取10块，那么随机读取速度
			为：10*4kb*125次/s = 5MB/s
			4.一次读取内存的时间：1000ms/30w次/s=3ns
			5.cpu速度=10倍*内存速度=100倍*IO速度
			6.顺序读取普通SATA机械硬盘1MB的数据：20ms


3.6 性能测试方案的设计和最佳实践 
	3.6.1 明确压测目标 
		对于压测，我们要明确测试的目标，并且尽量让测试目标有量化的标准。
		假设资源恒定，响应时间和吞吐量，它们之间是互斥的。假设我们的系统为单线程处理，则响应时间和吞吐量的计算公式如下：
			吞吐量 = 1s/响应时间
		然后，我们所使用的系统的cpu有多个核心，多个核心的cpu通过linux多线程技术可以并行的处理任务，因此，上面的公式可以扩展为：
			吞吐量 = (1s/响应时间) * 并发数

		对一个通用的接口进行性能测试时，我们通常关注接口的响应时间，吞吐量和并发数，需要通过测试方法找到系统响应时间，吞吐量和并发数的最佳指标。对于
	web应用来说，我们还会关注同时在线的用户数，最大并发的用户数等。另外，性能测试团队应与业务团队明确测试范围，梳理测试系统的依赖关系，并确定测试系统
	的范围，以及需要对哪些系统使用挡板等。

		交易系统对外提供下单，下单查询，退款和退款查询4个接口，交易系统依赖于支付，账务系统和配置中心。由于支付系统依赖于渠道，而对接渠道是有成本的，
	因此为了做压测，我们对渠道设置了挡板，挡板的延迟反映了正常线上渠道系统的平均延迟。
		根据业务方对性能的描述，我们确定压测目标：
			1.交易系统对外能输出每秒300次交易
			2.平均响应时间为1s，最大响应时间为3s
			3.可伸缩能力达到80%以上
			4.连续24小时稳定运行

	3.6.2 压测场景设计和压测方案制定 
		1.业务模型分析
			首先，我们需要对业务模型进行分析，选择日常请求量比较大且路径覆盖范围较广的典型交易，建立性能测试的业务模型，确定各个接口请求量的占比。
			下单接口：60%
			下单查询：37%
			退款：1%
			退款查询：2%

		2.确定测试类型
			确定了测试的业务模型之后，我们需要确定测试类型。测试类型根据目标的不同，一般分为以下几种：
			1.基准测试
				是指对单线程下单接口的测试，主要用于调试测试脚本的正确性，以及查看每个接口在无压力情况下对每个请求的响应时间，这个数据作为后续复杂
			测试的基础数据。基准测试一般在几分钟内完成。
			2.容量测试
				是指检查系统能处理的最大业务量，在测试过程中采用梯度加压的方式不断的增加并发用户数，监控响应时间和系统资源的变化情况，响应时间曲线
			出现拐点的业务量就是系统能处理的最大业务量。容量测试一般在几十分钟内完成。
			3.负载测试
				负载测试用于在测试单个接口在不产生任务错误的情况下能够提供的最佳系统性能，从而得出单个接口在响应时间满足用户需求时的最大吞吐量和
			并发数。压力测试的目的是检查系统能够支持的最大的用户并发量，在测试过程中采用梯度加压的方式，不断增加并发数，监控响应时间和状态，当出现
			连接数平稳且系统开始超时或者出现错误时，便会出现系统性能指标的衰退点。负载测试一般在几十分钟内完成。
			4.混合业务测试
				混合业务测试是指按照业务流程的要求对接口调用按照比例进行编排，并采用一定的测试加压方式进行加压，获取系统对业务流程的最大出力能力，以及
			每个接口单独的处理能力。混合业务测试一般在几十分钟内完成。
			5.稳定性测试	
				在稳定性测试的过程中，按照混合测试的业务流程对系统施加合理的压力，并持续执行一定施加。针对系统的运行情况，判断系统是否健壮，是否在内存
			泄露，是否存在较多的上下文切换。最重要的是经过一定时间的稳定性测试，可以发现系统持续内隐藏的具有时间积累效应性质的bug。稳定性测试一般在
			12~24小时完成。
			6.异常测试	
				异常测试是指在依赖服务中断，网络中断，硬件故障等异常情况下，系统对业务的影响情况，例如系统对业务流程的处理是否产生不一致，系统设计的
			时效转移是否生效等。异常测试没有时间的要求和标准，只要看测试效果即可。

		3.确定加压方式
			1.瞬间加压
				瞬间加压指通过测试工具模拟大量的并发请求，同时将全量负载加压到目标系统的接口，主要考验系统对突然流量的处理能力，也考验系统是否设计了
			消峰功能和对瞬间大量负载的熔断，限流，隔离，失效转移，主要应用于秒杀，抢购，抢红包等场景。

			2.逐渐加压
				逐渐加压指模拟通用的线上系统压力。线上系统的压力在一定周期内大体为抛物线的趋势，例如在一天内，从早上开始，系统的压力会逐渐增加，直到
			晚上的黄金时间达到最大，然后逐渐下降。逐渐加压可以最大限度模拟这种负载压力的分布情况。

			3.梯度加压
				梯度加压与逐渐加压类似，但是加压目的不同，梯度加压的目的是通过逐渐增加用户并发数量，并观察系统的输出能力，找到最佳或者最大的系统负载，
			具体指在响应时间满足业务要求的情况下达到的最优或者最大的吞吐量和并发数。

		4.确定延迟方式
			我们通过测试工具模拟系统的真实负载，并对系统进行加压，实际上就是客户端机器上发送大量的请求到目标系统，那么我们如何发送请求呢？一般有下面
		3种方式：
			1.一个请求发送完毕立即发送下一个请求
			2.一个请求发送完毕后以间隔固定的时间再发送下一个请求
			3.以一定的时间间隔均匀的发送请求。

		5.压测方案和压测场景
			基准测试中每个接口的响应时间如下：
			下单接口：0.5s
			下单查询：0.2s
			退款：0.6s
			退款查询：0.2s

			在得到基准测试的响应时间后，我们开始使用梯度加压方式。由于系统的目标吞吐量为200/s，所以选择的吞吐量梯度测试为：100/s,200/s,300/s

			......

			由于现在的系统都是服务化系统后者微服务架构系统，所以我们找到系统最大的吞吐量和并发数后，需要验证系统是否具有可伸缩性。我们需要把服务部署在双
		节点上，对双节点同时加压，查看双节点的最佳吞吐量，响应时间和并发数。一般吞吐量在80%以上比较合适，越高越好，例如，单节点吞吐量在300/s,双节点
		在480/s以上。

			通常我们认为cpu和内存使用率在70%以下比较合理。然后，使用这个负载，让系统持续运行24小时来观察系统的稳定性，以确定系统没有出现超时，报错，内存
		溢出等错误，保证系统的稳定性。

	3.6.3 准备压测环境 
		1.压测环境的软硬件
			尽量与线上机器环境相同，不能比线上配置好。不推荐在一台机器上压测，推荐在多个客户端机器上同时对一台或者多台测试机器施压。

		2.压测脚本

		3.数据准备
			根据实际生产情况或者在起那么进行的系统容量评估，我们可以确定测试数据集的大小。

	3.6.4 压测的执行 
		我们可以从以下几方面来观察系统的资源占用情况。
		1.系统层面的指标：cpu,内存，磁盘IO,网络带宽，线程数，打开的文件句柄，线程切换和打开的socket数量等
		2.接口的吞吐量，响应时间和超时情况等
		3.数据库的慢sql,sql行读，锁等待，死锁，缓冲区命中情况和索引的使用情况等
		4.缓存的读写操作的吞吐量，缓存使用量的增加数量，响应时间和超时情况等
		5.消息队列的吞吐量变化情况，响应时间和超时情况等

		压测报告主要包含以下内容：
		1.压测过程中记录的压测数据
		2.分析是否满足既定的压测目标
		3.指出系统存在的瓶颈点
		4.提出系统存在的潜在风险
		5.对系统存在的瓶颈点和潜在的风险提出改进意见

	3.6.5 问题修复和系统优化 
		在压测团队发布压测报告后，业务方对压测报告中提到的瓶颈点和风险进行整改并优化系统，在修复问题后提交新版本，请求压测团队进行回归测试。


3.7 有用的压测工具 
	3.7.1 ab 
	3.7.2 jmeter 
	3.7.3 mysqlslap 
	3.7.4 sysbench 
	3.7.5 dd 
	3.7.6 LoadRunner 
	3.7.7 hprof