全链路压测系统

背景：在日常开发的过程中，开发更多的关注在功能开发上，对于接口性能与服务能力关注较少，但是无论是对内还是对外提供接口与服务，都应该明白的给出服务能力界限的说明，而且需要对方给出调用量的评估，这样才能在一定程度上做到心中有数，从而维护系统的安全。压测系统不是一蹴而就的，据了解业内大公司的压测系统基本经过了几轮迭代，而且耗时基本需要3年。

1. 思路

压测系统的设计最后会走上类似阿里双十一、微信等全链路压测的道路，但是这两个系统都是花费了至少3年的时间打磨完成，所以我们也分四大步走：
1.提供压测的url、ip+port+协议栈 +参数，来进行简单的分布式压测，（预期完成时间2018年上半年)
2.改造目前项目的上下游路由机制（目前使用的是L５，但是L５不具备准备的流量分配机制），使得能方便快速的切换流量到单台机器上，从而得出单台机器的负载上限。（预期完成时间2018年下半年)
3.复制目前项目单日所有用户的流量，清洗后进行重放，来大规模的压测整个系统，目的是在大流量的压力下发现系统瓶颈与隐藏故障点。（预期完成时间2019年全年)
4.压测常规化，定时的来进行流量压测，完成自动化压测系统的进化。（预期完成时间2020年上半年)

2. 同类型产品分析

2.1 压测大师

压测大师可以很方便的实现第一步，但是具备如下缺点：
1.被压测机器的负载不能很方便的展示出来，最关键的是需要在被压测机器上装个软件，路径较长
2.压测大师对每个Url的并发上限为200，虽然可以通过开启白名单的方式来提升，但是感觉还是不太方便。
3.最主要的一点是，压测大师是一个独立的系统，虽然能大概cover住我们的第一步，但是对于我们的长期目标来说并不能很好的满足。

3. 压测架构图

模块介绍：
web controler: 显示与控制模块，显示压测的结果数据与agent的负载数据、agent的状态数据、dispatch模块的分发状态。
Manager：任务管理模块，通过从web controler获取任务配置，然后进行任务分配与启动停止。
Register: agent节点注册模块，可以获取agent的空闲繁忙状态，一般是分布式节点，推荐使用zk
dispatch: 文件分发模块，将提交的任务文件通过dispatch模块分发到各agent机器中。
agent: 真实的压测发起模块，从dispatch模块获取压测文件，从manager获取启停命令。
monitor: 监控统计模块，agent的负载信息上报至monitor模块。
MQ: agent获取压测结果，将其写入MQ
Collector: 收集器模块，将压测结果与agent的负载信息汇聚处理。
DB/DR：信息储存模块，存储web controler需要显示的各项数据。