压测如同照妖镜 妖怪哪里逃！ 业务代码、核心代码、机器配置通通无处遁形 藏得再深，藏得再久，也逃不出压测的猛烈攻击！压测实战分享是这阵子感触比较深的！压测在于暴力，在于并发，在于无情。一个铁的事实标准摆在面前，从配置到代码，从业务到核心，从cpu到硬盘，从网络到逻辑，方方面面，能争取一秒算一秒，能榨一毫秒算一毫秒！压测能把潜伏在系统里的深层Bug暴露出来，经典到格致，让人难以忘却所在所闻！下面从几个方面分享一下。
一、压测反推工程结构
压测与代码工程结构的千丝万缕关系。从压测的角度来看，代码至少要分成两部分，一是可控代码，简单的说，就是项目中的业务代码，因为是自己写的，所以可控性很强，压测的时候，可以针对性优化；二是不可控代码，像调用的第三方接口，这种没法自主控制。如图示，agent中存放与第三方交互的代理类。压测的时候，区分开可控代码与不可控代码。可控的代码就自己优化 ，不可控的代码，如果是公司团队提供的，就去沟通一下吧，对于外部公司的Agent，那真的是超级不可控了，直接忽略吧。在工程结构上来分析，建议Agent的异常要及时抓住并记一条神奇的【甩锅】日记，看看日志，就能快速定伴Agent对应的团队人员，找到快速处理问题。最好，把第三方的交互统一加上try-catch，记下异常。这样子，可控与不可控就划得很清楚了。
二、不要迷信核心代码
使用核心代码公共类库是一件很开心的事情，省下很多不必要的时候，省下的不仅是时间，更是一堆堆重复代码，可以让人关注业务。然后，千万不要迷信核心类库的代码，所谓有人的地方就有江湖，有代码的地方就有Bug。
这次压测，压到一个神奇的核心库Bug。具体表现为,controller捕获了2%左右的失败，有时候又没有错，这个错误一直在0%到2%的样子。为了查这个压测失败的问题。查看失败日志，能定位到Ip获取环节。但是不知道为什么会失败，断点调试，一切都是正常的，只是压测的时候，总能重现异常。
难道核心库有问题？这个简直不敢想，对于核心库，一直以来都是膜拜啊，拿来用，没有想过核心库会有Bug。但是面对压测的数据，又没法排除核心库的嫌疑，只能对核心库代码进行排查了。
如果构建核心库的时候，把源代码打进去，我觉得对于使用者来讲，绝对是一个福音。可惜我面对的这个核心库没有，还好之前把源代码打进去了。单个调试一切显示正常，压根调试不出任何问题。简单就是诡异到头了。
肿么办，抓掉几根头发后，突然灵光一闪。直接把代码Copy出来，将ip获取的代码逻辑加上步骤日志，从第一步到第六步，一一打出来，进行压测，日志显示，所ip获取的时候，步骤都是正常的。但是期间能出现还是出现了异常。看步骤的话,从request中取ip的代码逻辑并没有出现bug。面对诡异的压测结果，那就再想想。
看样子，从reqeust中取ip的逻辑没有问题，那就把取ip的地方加上try-catch抓一下日志。果真发现Bug了，使用ip的时候，出现了ip为空，导致异常了。
再往回看代码，发现static,发现new，一下子，抓到了Bug，这可是14年种下的bug，19年才来杀。这段代码的bug，可以描述为static误用。来来，展示一下bug的样子，希望你不要写出这种级别的bug，不好发现，不好杀，sonarqube查不出来，普通使用，一切正常，只有压测才会现形。花了8个小时才杀，不要问我为什么花了这么多时间。当核心代码在sonarqube的检查下，呈现出很多bug，很多坏外道。核心类库，想说爱你不容易~
static误用示范public class Ip{private string address;private int ipNumber;private Ip ip;private Ip(){//sonarqube说禁止外面创建实例}public static getIp(Request reqeust){ip = new Ip();.......//相信我，这里是复杂的ip识别与获取逻辑......}public String getIpString(){return ip.address;}}
压测的时候，不要迷信核心类库，把工程分成三大块，业务代码，核心类库，agent，对应三种不可控级别的代码。业务代码自己搞定，核心类库慎重的找人处理，并[AT]尽量多的人，Agent找人处理或者直接排除掉。
三、压测与机器配置
机器本身配置不行的话，压测就凉凉了。同事测试了机器硬盘读写性能，发现硬盘读写就把时间消耗没了，更不要谈压测业务代码了。提供一台标准的压测机器，是合理的前提。压测不过，不仅仅是代码，这一压，也得看机器本身性能。
压测就像一面照妖镜，英雄不问出处，是驴是马，拉出来溜溜就知道了。面对事实的标准，如何才能将压测做得更好呢？
1、压测环境与压测要匹配
在一个标准性能环境下，达到一个预期的压测值。这个标准环境，比如cpu,硬盘读写性能，可以是一个标准的。或者拿一个基准接口进行压测定值，先测算出环境本身适合的压测值。这样子，压测才能正常的进行。
2、压测环境最好有多个
接口多，接口要一个一个压，一个环境不好并行压。能有多个环境最好。不知道下次压测能不能实现，毕竟要有机器。
3、核心类库必过压测
核心类库都过不了压测的，放在核心类库里，这个有点点坑啦。又要用核心类库，又要过压测，没解。核心类库打上源代码，压测的时候，还可以用源代码进行压测调试。但是希望是通过压测的才放进核心类库，不要等业务代码进行压测的时候，再来找出核心类库的Bug.
4、核心类库必过sonarqube
为什么又扯到sonarqube，其实这个工具的强大之处在于，能分析出很多坏味道与bug，人不同于工具，工具在于将所有可性能全面覆盖分析，人没人注意到的地方，sonarqube可以注意到。这次压测就发现，核心库代码的规范性，并没有想像的美好。sonarqube找出了一堆坏味道，还有bug.
这次压测实战，感觉收获还是很大的。对于工程结果的理解，对于异常的捕获处理，对于核心库的优化改进，都有了新的认识，对于压测，也有了自己一套方案。希望你也能从中学到宝贵的经验！
关注公众号，我的经验就是你的经验！
