程序设计思考

压测带来的开发设计思考

最近也是在做压测相关工作，主要负责的是流量扩增那一段，再加上和其他伙伴一起对接联调的工作内容，感觉到我们的路由项目在设计上还是很好的，还是比较容易就能够增加压测功能。当然也有一些其他伙伴以及自己总结出来的想法，在此做个记录，以后如果有机会开新项目可以加以验证。

 

之前做的项目是个客服呼出系统，但是保险行业毕竟是传统行业，所以业务诉求以及数据流量没那么大，对于压测这件事，显然也没有那么重视，更多的是针对某个简单功能或者整体做个很简单的压力测试，甚至都没有，所以更多的情况下都是跑到生产环境去验证程序抗压能力，就算有了问题也不会有太大影响。

但是来了京东之后就不一样了，迭代速度快，性能要求高，流量压力大，特别是节日带来的压力翻倍，是对系统稳定性和高可用性的巨大考验，所以压测不仅仅是在项目上线前要有，而且是在一段时间后的稳定变更后需要进行压测，双11和618之前更是需要进一步进行压测分析来排查隐患，这就需要保证压测可以“随时”、“随地”、“随机组合”，并且不会影响到其他部门或者内部某个模块。又由于测试（高可用保证团队？）团队不熟悉技术层面以及业务层面的东西，不可能由测试伙伴来开发开启压测来排查问题，所以压测是由开发团队来完成的，针对于所需要测试的功能的开发是要付出成本的，所以代码的可开发性越好，显然带来的工作量越小。

 

对于路由系统，目前我所了解到的开发压测功能有几个要关注的点：

一是线上的消息能够进行测试标记并进行翻倍处理推送到后方系统中，3倍、5倍、7倍、10倍等；

二是针对于不同的topic，要能够针对某个或者某几个，或者是几个特定topic的组合，用来模拟繁杂众多的外部系统传递消息topic的实际隐藏场景，那个系统突然蹦跳憋了很大量的消息，会不会影响到路由计算的准确性，会不会产生部分洪峰击垮我们的服务器、数据库、redis、es等等，会不会诱发某些代码逻辑的欠缺导致bug产生；

三是要在压测的同时能够保证测试流量不会打到别人的系统中，不会打到我们的正常数据库中（申请独立的与生产环境完全相同的数据库用以测试），要能够保证如果真的出现了问题，对线上数据有影响能够及时快速的追回正常数据。

 

相应的以后如果要开发一个互联网行业这样的新的系统要注意什么呢？特别是流量大、稳定性要求高、对压测需求是必不可少的。

 

应该要注意：

1.消息入口处要有相关接口扩展，保证流量增加的组合设计、打标、翻倍、核心数据的随机取样用以作为传参（顾前）

2.向内部其他系统转发或者传递要能够支持单独调度统一调度控制流量方向（顾左）

3.向外部其他系统转发相关信息要能阻拦控制流量类型（顾右）

4.向数据库的写入，es的写入等要能支持流量流向控制（顾后）