整体分类

目前来看，压测可以分为这四类：

1. 业务无关的中间件压测
2. 业务有关的中间件压测
3. 基于 http 的业务压测
4. 其他类型的业务压测

业务无关的中间件压测

为什么要做？

一个业务系统中，会使用到很多中间件，例如 kafka、mongodb、mysql、redis、etcd 等等，往往这些中间件都承载着非常重要的职责，有些是作为 数据存储/管理，有些作为 消息传递，有些作为 状态维护，因此，这些中间件本身的 稳定性、性能 是一个会明显对业务系统有较大影响的存在。

当我们需要验证系统的稳定性和性能时，中间件就是不可避免要关注的部分。

一般来说，常用的流行开源中间件，只要使用场景得当，性能和稳定性不会是大问题，另外，在万物上云的大背景下，这类中间件会由云厂商提供 SLA，稳定性上有保证。因此，对中间件压测的优先级往往会放得比较低，再加上任务紧，到最后，也基本都不会再单独做中间件的压测 (基本会和业务压测一起就验证了)。

上面的方法在很多情况下是没啥大问题的。但如果要做中间件性能优化，则必须要知道 benchmark 的值，再对比业务压测结果，找到优化方向。

怎么做？

• 工具体系
• 指导手册

业务有关的中间件压测

为什么要做？

1. 如果做了业务无关的中间件压测了，还有必要做业务有关的中间件压测吗？

当然要，这样才能认识到真实业务场景中对中间件的需求如何。业务中的使用方式形态各异，往往和我们使用 benchmark 得到的数据有很大差异，业务有关的压测才能更加真实反映出中间件的容量。
另外，通过对 benchmark 和 业务压测数据 反复做比较，才更容易得出 “为什么业务使用方式下的性能差这么多” 的答案。

2. 如果做了业务压测，还有必要做业务有关的中间件压测吗？

不一定，如果这个中间件仅用于做过的业务，那么不做单独的压测，问题也不大。如果这个中间件被多个业务使用，那么只要业务压测没有真实覆盖整体的场景，就需要做。很好理解，一个redis-cluster被多个模块(或者子系统)使用，但压测仅做了某个某块的，如何能回答“这个redis-cluster能支撑整个系统多少访问” 这个问题呢？

怎么做？

1. 整体思路为：根据业务访问情况，构造数据和请求。
2. 周边工具链
   1. 中间件观测工具
   2. 业务发压项目的设计 (数据模式、观测性)

对于 http 的压测

1. 和接口管理、接口测试相结合
2. 封装 jmeter？

对于其他类型的压测

1. 可扩展式设计
2. 平台提供平台性功能，具体实现自行开发
   1. 压测配置管理
   2. 压测计划管理
   3. 压测流程、报告管理
3. 工具类提供
   1. 中间件压测最佳实践
   2. 流量录制、流量回放等最佳实践
   3. http、websocket、rpc、dubbo 压测最佳实践

整体的压测

为什么要做？

软件项目是一个耦合的系统，系统瓶颈可能造成整个系统的瘫痪，对于一个持续增长的项目而言，“这个项目在当前的架构下，技术层面的上限在哪里?” 这个问题是比较重要的，尤其是对那些被认为会获得快速增长项目。为了回答好这个问题，我们只有通过压测模拟用户量，用实验的方式得到答案。

“技术层面的上限” 实际上不是一个完整的阶段，它还包括着 如果遇到某些瓶颈，又如何能尽可能小成本地提升这个上限？

所以，我们可以这样认为什么是压测：
压测是一个 通过模拟不同场景下大量用户访问的方式，找到“根据系统负载情况，逐步调整系统的架构，以达到持续、正常提供服务”的路径 的体系。

怎么做？

• 压测目标清晰
  明确压测目标是一切的开始，目标一定要足够清晰才能指导后续的行动。不论是个人还是团队，清晰的目标都是一件事情能够推行下去的基础，否则，“价值感缺失”将会极大降低效率，甚至让整个行动夭折。

• 指标体系完善
  压测的主要流程就是在特定场景的压力下，通过分析各项指标，找到各类不合理的证据，从而推动架构的改进。可以说，指标体系是压测人员的眼睛。

• 梳理指标体系有哪些方面

• 基于这一节做 check list

• 场景梳理清晰

• 得到链路支持

• 工具给力

• 流程清晰，问题跟踪到位

做到什么程度？

• 目标是什么？
  • 回答线上容量问题
  • 找到架构优化方向
• 有什么难点？
  • 指标体系，完善的监控指标需要付出很大精力
  • 统合综效，全局优化往往需要打破局部最优
  • 跨团队沟通，链路压测涉及到的跨团队协作沟通需要具备很强的动员能力和项目管理能力
  • 在生产环境中的压测，涉及到众多数据的细节敲定，避免影响线上数据
  • 以压测工具选型开始的压测流程体系建立及维护
• 交付的是什么？
  • 用让人信服的报告，回答线上容量问题
    • 当前架构能支撑的用户数？
    • 为了提升最大qps，需要做的操作流程有什么？
    • 预案完备(发现过程、操作过程、验收过程)，通过演练熟练掌握操作
    • 找到了多少个架构问题，提出了多少架构问题的优化方案，评估这些优化带来的业务价值有多大？
    • 中间件使用合理性？
    • 服务伸缩性是否提升？
    • 服务稳定性、可扩展性是否提升？
    • 资源成本是否降低？
  • 压测的工程化体系建立
    • 流程是否清晰、交付是否明确？
    • 有多少文档输出？
    • 有多少分享输出？
    • 压测工具体系建设如何？
    • 他人上手压测的难度如何？

文档直通车

• WIP-kafka的高吞吐原因
• 压测的一些思考
• 性能工程的储备知识
• 如何做好压测
• 简单的性能测试方案
• 关于磁盘和网络的性能的问题
• 记一次服务性能的调优排查

---

Never say there is nothing beautiful in the world anymore. There is always something to make you wonder in the shape of a tree, the trembling of a leaf.
— Albert Schweitzer