网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
精准的容量评估：基于线上全链路的性能压测和监控，我们会清晰的看到流量洪峰来临时，每个业务的流量情况，就可以有针对性的做出容量评估，提高系统资源的利用率。
端到端的全链路巡检，第一时间发现故障并快速定位问题：基于全链路压测，我们可以做到完全的端到端检测，发现业务集群中的性能瓶颈，及时定位并解决问题，不产生遗留死角。
建立公司的性能运营体系，将运动式的性能优化演化为自发的日常性能优化：当全链路压测体系建立起来后，就可以作为常规的测试手段来进行日常测试，使性能测试常态化，规范化。
03哪些业务场景适合做
不知道大家注意到没，现在落地了全链路压测的公司，基本上都是电商公司，都存在高强度的交易和支付高并发场景。因为全链路平台的搭建是个高成本的活动，所以我们要思考哪些场景合适引入全链路测试，主要有以下几种场景：
有强并发的支付交易场景：包含各类大促场景，目前全链路压测的落地实际多出于此类头部公司，例如淘宝、有赞、滴滴、美团等。
需求正常迭代完成，并测试通过，上线后又出现各种各样的系统故障的情况，可以适当引入全链路压测。这种情况一般是由于线上线下的硬件资源配置相差较大，在线下无法正确评估性能资源的使用情况引起的。
04基础技术组件
既然全链路压测有这么多优点，我们是不是可以大力的推广落地呢？这也是很多面试官喜欢问这个问题的由来。但我们清楚，任何一种技术都不是银弹，能解决所有问题。在文章开头我们提到了，全链路压测对于整个公司技术有较高的要求，需要公司全体研发人员一起配合，才能有效的落地，否则就是空中楼阁。团队在落地全链路压测时，至少需要考虑以下几个问题:
① 如何得到业务部门的支持？
全链路压测平台不单单是测试部门，或者说测试中台的事，它基本上会涉及到公司所有的核心业务（如果不是，那也没必要做），这需要业务部门的技术配合和改造，那么，在KPI已经很紧张的情况下，如何说服业务部门配合你做改造呢？从某些方面来说，这个并不会影响他们自己部门的KPI，改造的不好，反而还会影响业务，风险较大。
② 如何做好数据隔离？
在生产环境上做压测，绝对不能对真实用户的数据造成影响，那么就需要做好数据隔离，业务侧的系统需要能够识别哪些是真实流量，哪些是压测流量。目前业内通用的做法有两种：流量标识或者影子数据库，这都需要对业务代码做改造。
③ 流量如何分发？
想要实现全链路压测，那么压力的发起就不能照搬单体性能测试那样，通过自己写脚本来发起压测。需要通过研发并发能力更强，可控性更高的方式，来发起流量。目前业内主流的方式是基于Netty框架做改造，通过NIO的方式发起流量。流量的来源一般是录制上线的真实请求并对数据加以清洗。这需要通过改造中间件来实现。
④ Mock服务能否支持
在全链路的压测过程中，必然会接触到第三方的服务（短信、支付、第三方接口等等），如何有效的拦截这些服务并返回正确的数据。而且还不能让Mock服务成为压测中的性能瓶颈，对Mock服务自身的性能要求也会很高。
⑤ 数据监控是否到位？
在全链路压测的过程中，是否能够建立起有效的、全方位的监控机制，能够第一时间发现问题？是否有分级、分层监控方案？当发现TPS上不去后，是否能够方便的定位到大致是哪里出了问题？否则全链路压测开展起来就没太大的意义。
⑥ 应急团队是否配置到位？
毕竟是在生产上做压测，如果某个服务被压跨了，是否有足够的应对方案，如果发生不可逆的故障（中间件很容易压出问题，如数据库宕机、MQ数据堆积、Redis穿透等等），运维团队是否能够有效支撑到位，快速恢复业务呢？
通过以上问题，可以看出，落地全链路测试，涉及到研发的各个部门，并不是测试人员单方面的事，甚至于可以说和测试人员没什么直接的关系。当我们想要落地全链路时，我们需要考虑清楚团队是否有足够的底层技术来支持。
05小结
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
5748
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
