4.17-线上-技术沙龙问题汇总答疑

前言

本周六晚受邀，参加了由数列科技主办的线下直播技术沙龙——高可用&性能技术沙龙。分享过程中，参与沙龙的同学们提了很多问题，碍于很多问题口头描述解释不清，因此写了这篇文章，对这些同学提出的问题做一个解答。当然，回答仅限于我个人的角度，仅供参考。

Question

1、大数据平台性能测试工具推荐哪些？侧重集群性能方面？@杨杨

2、什么场景适合做生产环境的全链路压测？

3、如何定位性能瓶颈？@AIS.Chang

4、目前工作中，压测环境更新维护成本特别高，有没有环境维护方便建议优化的点？@馒头大王.Manju

(背景：压测环境资源有限，只能更新当前需求涉及的服务，但每次都会出现配置不对、缺少库表字段的情况)

5、数据库压测有没有什么好的建议？@新

6、压测和生产环境不是同等配置，是否有方案或公式在结论中给出本次性能环境结果能否满足上线要求？@Hinn

7、全链路不改造底层区分流量，数据库不做影子库，算全链路压测么？@Hinn

8、只有测试团队来做，全链路压测可以实现怎么样的模式？@Hinn

9、性能测试需要强烈的代码能力么？@未名同学

10、kafka消费者服务怎么做性能测试和调优？@Aron

Answer

PS：由于很多问题的point都很类似，因此我会针对这些点抽取共性来答疑，请各位知悉。

1、全链路压测相关问题......

1）什么场景适合做生产环境的全链路压测？

• 全链路压测不是银弹，更不是万能。它只适合某些具有特定业务需求的公司，能否实施取决于是否具有合适的组织管理能力和对应的技术架构；
• 一般来说小公司没有特别复杂的业务场景和高并发，全链路压测落地又是个比较复杂的技术工程，因此不是很建议小公司搞全链路压测，特别是自研，我更推荐找成熟的商业产品，比如数列；
• 全链路压测，特别是生产全链路压测，成本和风险相对比较大，而且涉及到的底层改造等问题，需要合适的契机才能推动，否则会比较困难；
• 什么场景适合做生产全链路压测？举一些场景：线上故障频发&性能稳定性问题凸出，业务场景复杂且调用链路比较长，基础技术设施建设尚可，有高并发场景等，这些场景适合做全链路压测；

2）只有测试团队来做，全链路压测可以实现怎么样的模式？

这个问题可以从2个点来出发，试着探寻一下：

1）首先是技术储备问题，一般来说测试团队的开发运维架构能力相对较弱，而全链路压测又需要基础技术设施齐全，且需要合适的契机才能落地，需要自上而下的推动；

2）第二个是成本问题，自研的话就是造轮子，可能轮子更适合自己，但ROI需要评估；

看完上面2点，然后可以结合起来进行评估，是否有足够的技术储备，基础技术设施建设是否齐全，是否有自上而下的推动，是否有足够的成本预算等；

其次，全链路压测如果不上生产进行，测试的结果最终和线上是有比较大的gap的。如果只能由测试团队推动，我更建议在独立等配的压测环境进行单接口&单链路&混合链路压测验证。

3）全链路不改造底层区分流量，数据库不做影子库，算全链路压测么？

首先回答问题：算。

业内对全链路压测并没有定性的标准解释，在我看来全链路压测这个概念如果能解决问题，它就是全链路压测。

至于底层改造，流量识别和影子库，有下面几个方案可以参考：

• 底层改造：可以通过服务隔离&网络隔离等手段，通过单独的VPC和网关等设施来做到；
• 流量识别：可以通过特定发压的流量引擎IP添加白名单，来解决流量识别问题；
• 影子库表：业内有公司是通过生产库表的特定字段来做区分，然后数据清洗来解决脏数据问题；

2、如何定位性能瓶颈？

性能问题定位和分析一直是个很大的topic，我的理解就是：具体问题具体解决。为什么这么说呢？每个公司技术设施，流程各方面都不一样，每个技术同学的技术栈和擅长的点也不同，更不要提业务场景的巨大差异。这些都会影响所谓的“性能分析”。那么如何解决这个问题，下面几个点可以参考：

• 经验主义：通过大量的试错实践来快速分析；
• 自上而下：出问题从请求发起端开始排查，然后到网关-应用层-中间件缓存队列-DB乃至于操作系统配置；
• 从局部到整体：性能问题往往是多个原因引起的，一个个快速判断排除，最终找到根因。

3、数据库压测有没有什么好的建议？

1）选择专业合适的数据库压测工具；

2）压测场景一定要选择合适的，比如：

• 典型的读场景：包括条件查、全表差、多表关联等；
• 典型的写场景：比如insert、update等；
• 考虑特殊场景：比如分库分表垂直拆分和数据同步等情况；
• 匹配业务场景：DB最终还是要支撑业务的，挑选典型的业务场景来压测；

4、性能测试需要强烈的代码能力么？

老实说，性能测试做的多了，到了深水区是需要代码能力的。

但性能测试又是一个需要广度和深度的领域，比较卷（自己卷自己），精力有限。因此我更推荐能做到代码走查、code review、熟悉编程语言的基础和一些特性，能做到CRUD就差不多了。

最后补充一句，性能测试其实路子挺窄的，测试开发是未来的方向，不要过于追求技术（听听就好）。

5、kafka消费者服务怎么做性能测试和调优？

这个问题挺有意思，我曾经面试时候也被问到过，先不回答如何压测和调优，先看看下面几点：

• 消息队列的原理&生产者和消费者的特点（发送和订阅消费）&队列的特性（先进先出）；
• 具体的业务场景和压测需求是什么？这个需要具体且明确；

想明白上述几点，压测和调优实际上就不是难题了（凡尔赛了）。。。。。。

其实有个更有意思的问题：如果生产环境MQ积压了，需要快速恢复业务，你会怎么做？提问的同学可以考虑下这个问题，也许面试会问到哦。。。

6、大数据平台性能测试工具推荐哪些？侧重集群性能方面？

• 首先，压测工具的选型和特点，是否支持所谓大数据平台的协议或者特点；
• 其次，压测需要的大量测试数据，是个需要考虑解决的问题；
• 然后，集群可以承载更大的负载，如何用工具发起这么大的负载（看低一点）；

提问的同学，可以自己思考并尝试下。。。

7、目前工作中，压测环境更新维护成本特别高，有没有环境维护方便建议优化的点？

记得昨天回答这个问题的时候，我提到了下面几点：

• 是否有CICD制品库等比较成熟的技术体系？
• 环境管理维护是否有规范的的操作流程和明确的责任边界？
• 自动化和审批流是否比较高效？

其实这个问题说到根本，就是单独的压测环境和生产如何等比配置、DDL变更及时性、代码分支、快速发布扩容机制、压测前的check机制（提测准入标准）等问题。

推荐看看这篇文章：线下环境为何不稳定？

8、压测和生产环境不是同等配置，是否有方案或公式在结论中给出本次性能环境结果能否满足上线要求？

首先回答问题：没有方案和公式来证明测试结果能满足线上要求！

昨天的分享中有提到过，线上线下环境的差异性带来结果的不确定性，以及如何描述一个性能问题。如果环境配置等前置条件都不满足，又怎么能保证数据的正确性呢？

• 性能测试的目的就是：探测瓶颈+容量规划；
• 压测环境的压测只能用来衡量系统的处理能力（TPS&RT&成功率等）；
• 新服务上线压测主要是发现并解决明显性能问题（没加索引&慢SQL&缓存命中率&OOM&死锁&超卖）；
• 长远来说性能测试是稳定性保障的一个环节或者说一个部分。

结语

相比于3.20那一次的答疑，这次的有些问题，我反而没有给出明确的答案，因为它们本身就没有标准答案。

很多问题或者遇到的疑惑，需要大家自己去探索。正如我在分享的最后一个topic里讲的：成长是一个闭环，需要学习-实践-试错-复盘-不断优化。

上述的答疑中留了一些问题，相关同学如果感兴趣，可以尝试思考如何解决它们。

如果有机会，我们下次再见！