前言
本周六受邀,参加了由数列科技主办的线下沙龙——高可用&性能质量保障分享会。分享过程中,参与沙龙的同学们提了很多问题,碍于手机打字确实不太方便,因此写了这篇文章,对这些同学提出的问题做一个解答。当然,回答仅限于我个人的角度,仅供参考。
课程回放:高可用&性能质量保障分享会
Question
1、技术团队好与不好,怎么区分?@Jeffery
2、压测工具和方案应该如何选择?@一二
3、全链路压测为什么要在生产环境进行?脏数据如何处理?支付场景如何处理?@馒头大王-Manju
4、全链路压测,如果没有产品性能的baseline,如何设置并发量?@梧桐
5、生产全链路压测,如何保证生产环境可用,如何解决脏数据?@守正出奇
6、性能需求的准入规则如何理解?@不沾
7、流量模型建立的思路、前期准备、依赖的技术和工具如何了解?@不沾
8、热点数据预热怎么做?@大美丽与小旺仔
9、仿真环境如何搭建?相较于生产环境有哪些不足?生产压测如何保证不影响正常的业务?@泉眼无声
10、性能测试结果如何分析?没有满足业务需求如何处理?@久留
11、大促时候为什么不建议扩容?@暗夜
12、小公司如何落地自己的全链路压测平台?@Mike.liu
13、测试人员做全链路压测需要什么代码功底?@郑阳洋
14、如果压测没有覆盖到安全水位,如何借助已经压测的模型预测剩余的容量?@James-东方
15、证券交易所或者期货交易所这种金融行业是否适合全链路压测?@郑阳洋
16、影子表压测结束后还会在生产保留么?对生产的数据库是否会有影响?@虎魄2
17、如何根据自己公司的情况探索并建立适合自己公司的性能测试体系?@对方正在讲话...
Answer
PS:由于很多问题的point都很类似,因此我会针对这些点抽取共性来答疑,请各位知悉。
1、技术团队好与不好,怎么区分?
这是个因人而异的问题,每个人对工作的追求都有差异,对好团队的定义也有不同,我聊聊几个共性,供参考。
1)是否有技术文化?
所谓技术文化,在我看来就是对技术方案的选型&code review&编码风格&质量保障,有没有很好的落地实践。
2)是否有相对透明的绩效考评机制?
大部分人工作为了赚钱,职业规划其实比较虚。绩效考评机制能否做到相对透明和公平,是一个很重要的因素。
3)是否有明确的职位晋升空间和通道?
职级晋升、加薪永远是打工人最关心的一点。
4)你的leader是否能帮你成长?
这点其实很多人忽略了,但其实是最重要的。leader有一点很重要,向上顶住压力,向下争取利益。
2、压测工具和方案应该如何选择?
压测工具的选型,可以从三点来判断:
1)是否能快速便捷的安装部署并且支持分布式;
2)学习成本是否比较低,能让团队成员都能快速入门上手;
3)是否有完善活跃的社区或者团队持续更新优化;
压测方案,需要根据具体需求和实际情况制定,没有具有普适性的方案,基本只能靠经验和不断沟通来完善。
3、全链路压测相关的问题......
1)为什么要在生产环境进行?
- 模拟真实的业务场景;
- 节省环境的硬件成本;
- 节省搭建新环境的人力和时间资源;
- 长期来说,是一种生产巡检,类似于定期对生产环境的稳定性进行全面体检;
2)脏数据如何处理?
- 压测数据存储正式的业务表,通过特殊字段做区分,每次压测结束后进行清理;
- 影子库表方式的话,是通过特殊的标记将压测数据路由到对应的带特殊标识的中间件和DB,影子库一般和生产的业务DB在同一个实例,这种情况下数据预埋是将生产数据同步到影子库,然后进行脱敏处理;
3)支付场景如何处理?
- 调用三方支付的话,采用mock或挡板的方式(mock-server或者本地jar包方式);
- 如果是自己的支付服务,处理方式类似上述第二个问题,脏数据的处理;
4)如果没有产品性能的baseline,如何设置并发量?
- 业务需求一般都是模糊的,需要通过业务模型和流量模型来评估,然后和业务产品方不断沟通确认,需求都是不断沟通中聊出来的,没有一步到位的需求;
- 并发量的设置,取决于压测场景和策略,刚开始我建议通过梯度递增的方式不断加压,直到性能拐点或者出现资源告警等情况;
5)如何保证生产环境可用?
- 最稳妥的方式,选择流量低峰期(凌晨时间段)进行压测;
- 保证服务可用,需要有很多岗位的同学值班oncall,比如运维DBA研发测试等;
6)热点数据预热怎么做?
- 比如用户登录态的数据,比如用户的优惠券数据,都可以通过提前缓存到Redis,设置合理的过期时间来解决这个问题;
7)仿真环境如何搭建?相较于生产环境有哪些不足?生产压测如何保证不影响正常的业务?
- 仿真环境是全链路压测在生产落地的过渡环境,一般都是按照和生产环境1:1(比较贵)或者等比配置的方式来搭建;
- 不足之处在于没有实际的流量请求,请求需要自己构建,硬件各方面的配置以及参数和生产无法确保一致性。在业务场景复杂度和真实性上,有一定差异;
8)大促时候为什么不建议扩容?
- 一般大促时候,服务的扩容都是已经完成的动作。而且服务保护措施比如限流降级熔断,都配置好了。大促流量峰值时候扩容,会引起一连串的连锁反应,某些服务扩容了,下游如何按照比例扩容,限流阈值、熔断阈值都需要跟着改,但如何改?改多少?都是需要决策且风险巨大的;
9)小公司如何落地自己的全链路压测平台?
- 全链路压测不是银弹,更不是万能。它只适合某些具有特定业务需求的公司,能否实施取决于是否具有合适的组织管理能力和对应的技术架构;
- 一般来说小公司没有特别复杂的业务场景和高并发,全链路压测落地又是个比较复杂的技术工程,因此不是很建议小公司搞全链路压测,特别是自研,我更推荐找成熟的商业产品,比如数列;
- 至于全链路压测平台实际上没有解决技术问题,只是更适合多人协同和规范流程的标准化自动化;
10)测试人员做全链路压测需要什么代码功底?
- 代码能力只是一部分,或者说不是必须项。分下面几项来说:
- 如果机制完善,全链路压测比较成熟,自动化标准化做的比较好,不会代码也可以,只需要点启动按钮看监控即可;
- 如果从零开始自研,性能测试需要的技术广度和深度又有一定要求。比如:要对系统的技术架构、上下游调用、涉及的中间件、缓存、DB有一定的了解。对业务一定是要很熟悉的。还需要较为丰富的性能测试经验,否则有很多坑需要踩;
11)证券交易所或者期货交易所这种金融行业是否适合全链路压测?
- 我对证券或者期货交易业务不太熟悉,我说几点适合做全链路压测的场景,供参考:
- 具有高并发场景;
- 具有较为复杂的业务逻辑;
- 需要自上而下的支持(需要评估风险,是否允许犯错的空间);
4、性能需求的准入规则如何理解?
不是所有需求(接口、服务等)都需要压测,做功能测试都需要需求评审,性能也需要。一般来说,是否需要做性能测试,有如下几点参考:
1)是否具有并发场景(比如限时抢购-怕超卖);
2)是否需要写库(写数据一般都会加锁,行锁表锁悲观锁等等,不压测可能会出现锁等待超时);
3)业务逻辑是否复杂,是否有太多的依赖(分布式微服务架构SOP等很多都有复杂的依赖调用);
4)评估技术方案,是否有大量的循环、串行并行外部调用;
5)领导是否强要求(这个很奇葩,但真的有);
5、流量模型建立的思路、前期准备、依赖的技术和工具如何了解?
1)流量模型的建立,一般都是通过链路追踪+监控得到不同调用链路上的QPS及转化率,以及强弱依赖;
2)前期准备的话,完善的监控体系是必不可少的;
3)依赖的技术和工具,现在有很多开源的监控工具,skywalking、cat、pinpoint、Prometheus;
6、性能测试结果如何分析?没有满足业务需求如何处理?
1)压测结果如何分析,这是个很深很大的话题。简单来说,结果是否满足预期指标,是否存在资源不足&资源竞争&耗时太长&服务异常等情况;
2)没有满足业务需求,就想办法满足业务需求,通过扩容&升配&缓存&甚至优化代码的方式,去满足业务需求,并且留有一定冗余空间,做好线上灰度和服务保护(限流熔断降级——这个怎么了解,后面话题再聊);
7、如果压测没有覆盖到安全水位,如何借助已经压测的模型预测剩余的容量?
无法按照既有的压测结果评估实际的线上容量场景,所有的所谓预测方法论,都存在误差,敬畏生产环境的稳定性,敬畏故障。
8、如何根据自己公司的情况探索并建立适合自己公司的性能测试体系?
这个我其实分享过了,就下面这张图,照着做即可。有个小窍门:保护好自己,优先落地可行的方案。
从季到一搭建性能测试体系
团队期望
交付流程
交付痛点
业务
计划落地
技术
优化演进
环境搭建
落地实战
技术选型
结语
我只是按照问题回答问题,拆开来说,其中很多点都值得深入讨论,限于时间和篇幅,我们后续再见。
答疑仅供参考,不要照搬,要通过大量实践形成适合自己的方法论。