技术岛

官方总是喜欢留一个小坑,提供了python示例代码,也提供了java示例,就是没有提供php代码,折腾了许久,真的要抓狂了!

sleep5

这几天同事对图书云很感兴趣,想着使用java对图书云进行一次重构。也有团队成员认为不需要。但是从工程化的角度出发,我们在重构的路上回不了头,就开始准备java项目自动构建。为了节省创业成本,我们的服务器配置是比较低的,我们的第一个目标就是,在自己的电脑上配置好自动构建。

不过,经过这2天的折腾,对于在windows上构建java项目,再部署到linux上运行,算是摸到一条路子。pipeline脚本没有精修,无数次尝试,踩坑的结果。

以下jenkinsfile是实战能正常跑,可以将jar包从windows传输到linux的。

初始压测环境

1.yue.maES-9100-9200-93002.yue.malogstash-zookerper-2182stormui-8080nimbus-166273.yue.makafka-9092redis-637054.yue.mamysql5.7-33065.yue.maiis、filebeat、LogGenerator服务、WebGenerator站点6.yue.maiis、filebeat、LogGenerator服务、WebGenerator站点7.yue.ma压测客户端8.yue.ma压测客户端

以上机器均为8核16G内存,[1-8].yue.ma为脱敏host,仅做示例

压测优化思路

依据120万条日志/分钟的要求,我们通过ES查看工具,配合自己写的ES入库速率实时分析显示工具,实时观察入库速度,未达到要求,就分析,调整,直到满足目标。

日志生成

我们采用了服务生成日志、站点生成日志两种不同的方式,分别代别了实时业务中的场景。LogGenerator服务生成服务类日志,WebGenerator站点生成站点日志,站点的日志生成需要压测机器发起大量的请求。有同事基于jmeter做好了压测工具。

优化后的压测环境

1.yue.maES-9100-9200-9300logstash-2.yue.malogstash-zookerper-2182stormui-8080nimbus-166273.yue.makafka-9092redis-637054.yue.mamysql5.7-3306logstash-5.yue.maiis、filebeat、LogGenerator服务、WebGenerator站点6.yue.maiis、filebeat、LogGenerator服务、WebGenerator站点7.yue.ma压测客户端8.yue.ma压测客户端

实时优化措施

历史经验

优化LogStash批量写调整ES模板

没有设计任何场景与验证,直接向同事打听到去年压测的经验。

压测结论

测压解读,我们压到40万长日志/分钟的时候,就停止了进一步压测。依据长短日志的压测优化经验,日志系统的吞吐量可以通过调整kafka、logstash、ES的节点数来适应目标容量要求。Kafka的节点数大概为每分钟日志量的大小除以每分钟带宽满载的传输量,Logstash的数量可以观察消费堆积情况,增加数量。本次压测的经验是将kafka中topic的partion数量配置为logstash消费线程数,这样子,每个logstash都能保持工作状态。然后,每种topic的日志量占比不尽相同,可以在实战中进一步优化配置。ES侧的优化未进行,依据这次优化的经验,同样可从日志传输量与带宽角度,推测出ES节点数要求。有一个合理的初始配置,再在初始配置的基础上进行优化。

干货

kafka的图形管理工具,是开源WEB管理工具

ES入库速率实时分析显示工具,这个工具是DIY的,能实时显示当前入库到ES的日志速度,感兴趣的可以留言索取。

本次压测收集到的命令集合,感兴趣的可以留言索取

LogGenerator服务,感兴趣的可以留言索取

WebGenerator站点,感兴趣的可以留言索取

非链路日志(普通日志)

如果没有链路的概念,那恭喜,您正在使用普通的日志。普通的日志没有链路标识,不同请求的日志可能穿插在一起,查看的时候不太好串起来,分析日志有点点眼花缭乱。尤其是出现线上问题的时候,面对一团无序的日志,心急如焚。如果站点业务机有10台,定位日志的范围,也成为一个不太愉快的时候。若是多线程的服务日志,日志穿插得眼花缭乱。非链路日志(普通日志)在实时排查问题的过程中,存在的最大问题就是定位分析问题,简单的示例如下图,日志穿插在一起,不易分析同一个请求的情况。

我收到一个请求,参数是我收到一个请求,参数是我收到一个请求,参数是我收到一个请求,参数是我收到一个请求,参数是用户账号BBB未认证单链路日志

当我看到有同事使用GUID将日志请求串在一起的时候,我就这应该算是单链路日志了。站点的单次请求或服务的业务操作日志能够很好的被标识出来,在分析日志的时候,需要搜索同GUID的日志,请能定位到一个请求或作业的日志,不用提心其他日志的干扰。单链路日志对于分析单个站点或单个服务的日志情况,还是很有帮忙。我们已经能从日志中挑出日志,专注于重点日志。

请求3fba452e-d9c9-45ee-96cb-19280fa59673我收到一个请求,参数是请求b3a45dec-7667-4822-b7b9-7db1eec11a8b我收到一个请求,参数是请求3e2f3851-9491-4f97-a47c-53d1001278ba我收到一个请求,参数是请求6180a2f7-d9bf-4612-9d23-c5e6d46a079d我收到一个请求,参数是请求26a9d771-f2f3-47fa-b810-d3071a1d98ca我收到一个请求,参数是请求3fba452e-d9c9-45ee-96cb-19280fa59673用户账号BBB未认证全链路日志

全链路日志在单链路日志的基础上进行跨站点,跨服务逻辑的日志追踪。分我们排查问题的时候,往往是一个完整业务排查,不单是涉及一个站点的,可能需要顺藤摸瓜,一点一点回溯。单链路日志对此就无能为力了。所以引身出了全链路日志,我们需要为每个完整的请求分配一个追踪id,称之为TraceId,这个追踪id将在业务站点间流转,将业务日志串起来。当我们查看日志的时候,可以完整得看到业务日志的流转明细。同样的道理,服务日志在入口处,也将分配一个完整的TraceId,标识出完整的日志。

一、支付宝新旧产品变迁,支付宝bug无情打脸

提示语定格在“系统异常,请稍后再试”!

二、让人无语的机器人客服时代

每次与支付宝打交道都有一种想吐血的节奏,支付宝客服不知道哪里来的自信,总会将我引导到一个机器人客服系统,答非所问,提工单,工单让我找商服,找到商服,商服就是一个自动回复机器人。技术人工客服问半闰,又给我导向了商服,商服又是一个没完没了的自动回复,真的把人气得要吐血。什么AI什么智能机器人,都是忽悠人。若非工作需要,把阿里系的所有东西全卸载都不解气。技术人工客服唯一有用的一点就是,回复了一个问题,在哪里更新手机安全支付产品密钥,只有支付宝的人才知道,到底是什么产品,到底哪里是密钥更新的,这个答复,还是不错的。于是,我求证了一个密钥的问题,到底是使用java版密钥,还是非java版密钥,客服答复我,使用什么语言就使用什么密钥。听起来是那么的开心,我感觉不会掉坑里了。

三、支付宝支付密钥系统BUG确认

在我满腔怒气不受控制的情况下,我自己在钉钉群里圈了支付宝的对接人,将支付宝后台报错页面发过去,把人工客服答复,把商户机器人答复统统发过去,直接告诉TA,我已经吐血了。我知道钉钉对接群里有很多人,很从同事,我也顾及不了这么多。从上午开始,到下午,换电脑、换浏览器、清缓存、简直就是被耍了一天。支付宝最终确认是自己的系统问题。于是拉了一个小群,让我配合他们进行进一步的排查与处理问题,我到是非常关心更新密钥的事情,于是就接着配合。

四、一个低级的支付宝系统BUG

原以为支付宝出现了重大的系统BUG,新旧产品有重大的兼容问题。实际上却是支付宝产品的调整。更新密钥要求先入驻开放平台,从支付宝排查的结果来看,当点击查看开发者公钥时,会提示“系统异常,请稍后再试”,实际的请求情况如下

五、小心翼翼的掉支付宝的坑里

前面有提到为了防止生成密钥出问题导致我们的业务中断,特意向客服求证了密钥需要生成什么版本的密钥。在支付宝提供的密钥生成工具里,我们可以看如下图所示的提示。

六、支付宝产品密钥防坑总结

支付宝的产品可以划分为新老产品,老的产品采用用md5加密,也有采用rsa密钥加密(1024位)。老的rsa密钥在mapi网关产品密钥中管理。老产品是没有开放平台应用的概念,sdk调用也不需要传appId,新产品需要在开放平台后台配置,需要为每一个应用进行配置,sdk调用需要传appId。新产品密钥支付1027位、2048位。依据目前踩坑的经验来看,老产品的sdk采用的是PKCS8密钥,无论是java语言,还是.net语言都是使用PKCS8密钥。在更新密钥的时候,千万不能被支付宝提供的密钥工具所迷惑,老版本使用的是PKCS8,.Net也是使用PKCS8,支付宝的老版本demo就是这么提供!慎重,这是一个巨大的坑,一不小心,就会出线上生产事故,扣钱扣绩效,背黑锅,太容易掉坑里。

七、跨部门沟通

更新密钥是一件非常重要的事情,协调不同部门的人一起完成一件神坑不断的事情,非常虐心。大家都有手上的活,自然会影响到他人的工作。一点都不影响到别人,那是表面上的友好,其实换位思考也是,背着支付宝的黑锅来回找要验证码、要财务登陆,换浏览器尝试,打断了别人工作,换谁都会有点情绪。我的目标是将支付宝手机安全密钥更新好,别人开心不开心,不管,这是工作,有点耍赖了!人在江湖啊!

八、与支付宝沟通

8.1戏如支付宝

8.2老接口文档索取

有不少支付宝老产品已经没有公开的入口了,有的老接口文档如果能搜索到,那就是见鬼了,搜索到了,估计也会有一个收费码,要求付费10块钱才可以下载。对于老接口文档,可以向客服经理要,一定要提供签约的pid,具体的接口名称。一般大客户会有此服务,如果连客服经理都没有,说明不是支付宝的重要客户,基本上只有冷冷的机器人服务,你说什么都是很nice的自动回毛复,直到你放弃。

能在财务下班前更新好支付宝手机安全支付产品密钥,虽然过程是那么煎熬与不顺,想想事办成了,还是有些开心。我跟同事聊了聊,觉得这个密钥更新是一个必踩的坑,想想就扎心,这么多同行要更新密钥,这么多同行要踩坑!如果有幸看到,希望你能收藏起来,好好看看,也许能避免一场无辜的线上支付事故!

对于一个公司而言,不仅是为正常用户提供服务,也要防范不法分子利用公司的平台进行诈骗,保护公司的名誉与声望。虽然不良青年占比很少,却是公司很为头疼的事情。支付产品一直是不良青年的切入点,与不良青年的斗争,建立在数据凭证上,每一笔支付流水的都是诉讼的核心凭证,凭证对应到具体的自然人,对助于公司进行司法诉讼,维护平台的声望,打击不法份子。

新版支付产品报文

我们熟悉面向过程编程,也了解面向对象编程,在我们日常研发的过程中,往往需要我们采用编程手段将一些固化的业务逻辑采用代码的方式程序化。我们能很好的完成一个又一个新功能,还能随着业务的增长,不断的调整代码适应新的业务。

然而有的时候,我们会发现,我们所掌握的面向过程编程与面向对象编程,解决不了我们编程中的困境。于是,通过引入几个真实的案例,介绍一下面向商务编程的方式与优点。

真实案例一:对接阿里短信

从短信对接的历史来看,通常都是传手机号与短信内容,阿里的玩法改变成了手机号、短信模板、参数。依据传统的做法,我们需要为两百多个短信模板配置阿里短信模板,还要做参数映射。依据阿里短信模板的审核流程来看,基本上是没有尽头的项目了。短信内容审核老是被打回来,参数不能过多,完全是一个无底的黑洞。针对我们业务的短信,要转化成阿里的短信参数,挑战还是很大,改造切入点还不少,还不能完全确保万无一失,使用维护管理都是一个挑战。采用面向商务的编程方式,由商务出马,结果一切变得那么顺利,谈妥一个万能参数,兼容了我们的短信平台,无需切入修改代码,新增一个短信服务商的实现。

真实案例二:网银直连

很多人以为网银直连一个技术问题,一直在寻找技术解决方案,其实网银直连、转账到银行卡等产品,都不是技术问题了,而是商务问题。所谓的大客户服务,就是别人享受不了的服务,你却能享受。这不是一个技术领域的问题,而是商务之间的互动。偶尔有人问我网银直连怎么接,我都感觉就像一个诡异的灰色游戏。

真实案例三:支付费率

传统的编程方式是不需要考虑支付费率的,无旨是一个冷凉凉的参数。面向商务编程,会要考虑,一年流水多少,5个点一年能省多少钱。一个简单的例子,如果率费是1%,一年200亿流水,手续费是多少?如果率费能到0.5%,又能省多少?

真实案例四:短信监控

一般我们接入短信,就是简单的把短信送到运营商,然后就了事了。如果我们按面向商务编程的思维方式再思考一下,月底怎么对账?哪条短信成功了,哪条短信失败了?这钱花得冤不冤?

作为甲方,我们经历一场凌晨短信通道异常的煎熬,这个时候正是多数人睡梦中。我们却睡梦中惊醒。短信通道异常,用户无法收到短信,我们非常被动。出了什么问题,哪个环节出了问题,我们如何处理?见到问题后,我们首先排查了自身短信服务的情况,均无问题,于是问题的重点在短信服务商出了问题。下面详细介绍一下我们排查问题的关键要素与处理方案,最后我们来分析乙方如何答复,阐述了为什么我只打50分,连及格分也没有给。

短信流水

我们能看到的短信流水是乙方提供的流水,仅代表了短信被乙方收到,乙方将短信送到移动电信联通运营商的过程与结果,完全是在黑盒子里。比较尴尬的是乙方不提供短信回执,整个流程就变得不可监控,无法预知了。我方收到的流水均是乙方返回的成功流水,对于短信的真实发送状态,完全没有了参考意义。

紧急预案

非常幸运的是我们接入了多个短信平台,对于某个短信平台出现异常问题,我们采取了快速的通道切换措施。面对紧急情况,我们关心的是业务如何快速恢复可用状态,短信服务商如不能给出一份具有负责感的短信故障分析报告,估计是很难切回去。表面上大家一团和气,似乎不是什么大问题,作为甲方,一群人半夜无眠,也许都没有人愿意再切回去了。

短信数据核对

乙方如何答复

出现这种事故,乙方如何争取甲方切回通道呢?一份详尽的报告与整改措施是必不可少的,切记,不要一份甩锅的事故报告,把自己的责任推得一干二净的。至少从一个甲方的角度考虑,问题这么久,乙方有没有机制自动发现问题自动修复。如何避免重复问题的产生?若答复踩不到要点,让甲方爸爸怎么安心开启通道。

后记

做为甲方爸爸,我在想什么,乙方要好好想想,现在短信平台太多了,竞争那么激烈,我们程序又能做通道切换,服务不好,就切走了。估计乙方看不到我写的东东,还在纳闷,为什么给了一份“专业”的事故报告,我们也没有在群里生气,通道却没有再切回去。

近期做压测优化时,特意选用了无侵入式代码注解方式[OutputCache(Duration=300)]对接口做了5分钟缓存。依据业务预期,5分钟的缓存能确保我们的接口顺利通过压测。就在满怀信心等着通过的报告时,却被打脸了。

报告显示,在前2分钟,接口返回都正常无错误,接下来就出现了错误返回。仔细想想,这个问题在于,缓存失效的一瞬间,大量的请求穿透过去,导致请求直接压到了需要保护的后端服务。

于是,采用lock的方式,防止缓存击穿!

protectedstaticobjectsysncObject=newobject();

//开缓存了,防止缓存失效的时候发现穿透效应lock(sysncObject){//原来的业务逻辑}

经过lock处理后,压测顺利通过。目前没有发现,OutputCache的Cache保护措施,只能使用DIY进行击穿保护。

THE END
1.避免信息爆炸构建完美的消息提醒系统首先要明确的是,什么是消息提醒系统?简单来说,它是一套程序或者功能,用来通知用户有新的事件发生,比如新邮件到达、新朋友请求、即时聊天中的未读信息等。这些提醒可以通过声音、振动、屏幕亮度变化等形式展现给用户。好的消息提醒系统能够帮助我们及时了解重要的事情,而不至于错过关键机会;坏的则可能导致连续不断的声音https://www.ly6b8v3c.cn/shu-ma/551311.html
2.智慧生活需要智慧硬件了解和配置你的Raglon65设备随着5G技术不断完善,以及更多应用场景逐渐被开辟,比如增强现实(AR)、虚拟现实(VR)等领域,骁龙865作为一个支持这些创新需求的核心硬件,将会进一步推动移动互联网向前发展,为我们的未来带来无限可能。 芯片巨变,软件优化之路——应用程序对Raglon 65设备适配挑战与机遇 https://www.d9xmz5u1j.cn/ke-ji/530608.html
3.测试/测试开发八股——找大厂测试实习基础篇测试八股线程数:根据实际需求设定总共有多少个线程参与压测。 Ramp-Up Period:多少秒启动完所有线程。 循环次数:定义要执行的循环次数。 调度器:如果选中了这个选项,需要在配置中进行相关设置。 ②判断压测机可运行的线程数 通过逐步增加线程数,观察压测机CPU的使用情况,以及JMeter的响应时间。当发现CPU稳定且响应时间随线程数https://blog.csdn.net/weixin_45928096/article/details/136400578
4.项目实战10压测机带宽打满,堆机器才是王道然后根据波形图特征进行合理的推测。(一开始可能很懵逼,阅图无数后会有一些感觉) 1. 因为经常会被业务方挑战是压测机的问题,所以就想先加一个集群来压测,以确认是压测机的问题,还是压测链路的问题,亦或是业务方的问题。 压测结果:两个集群,各1500并发,QPS值总共6k https://cloud.tencent.com/developer/article/1791991
5.python编写短信测压网站python压测websocketpython 编写短信测压网站 python压测websocket Websocket协议压测记录 背景: 公司的行情系统是采用的websocket协议,有请求和订阅两种方式向服务器申请最新行情信息。请求方式是一次的,订阅方式是建立连接后,服务器定时向客户端推送行情信息。 初步测试方案: 因考虑到websocket是双工通讯,是长连接,并且本次压测的性能指标是https://blog.51cto.com/u_16099276/10857411
6.新一代垃圾回收器ZGC的探索与实践线上运行 & 全量部署:要求线上机器已安装JDK 11,有3种方式: 新申请默认安装JDK 11的虚拟机:试用JDK 11时可用这种方式;全量部署时,如果新申请机器数量过多,可能没有足够机器资源。 通过手写脚本给存量虚拟机安装JDK 11:不推荐,业务同学过多参与到运维当中。 https://www.528045.com/article/d10c0b06b3.html
7.性能测试PTS销售指南学习笔记可以模拟各种客户端,各种浏览器,各种移动端,从全世界各地发起流量,压测对象可以是公有云,专有云,自建idc以及vpc网络就是阿里云上面的内部网络。 1、非阿里云客户能用吗? 可以,无论客户是公有云/专有云/混合云/自建IDC,无论什么云厂商 只要在公网可访问就能通过PTS来压测。阿里云上的客户有另外的好处就是可以做https://developer.aliyun.com/article/1085961
8.mts是什么短信应用的作用是什么?即开即用,不限账号数 无限邮箱容量4GB超大附件 ¥0.00 免费试用 会打字就会建站 3300+模板,30000+企业选择 立即购买 并发用户数是什么? 并发用户数是什么? 压测是需要模拟用户实际业务操作的真实使用场景,并发用户数是模拟一定数量用户操作的一个配置。 例如,游戏网站某个时间点进行竞技活动,那么这个时候对设备的https://support.huaweicloud.com/topic/831437-4-M
9.短信轰炸机网页版在线短信轰炸机免费短信云呼轰炸机欢迎使用我们的短信轰炸服务,这是一个先进的在线平台,使用户能够同时向多个收件人发送大量短信,为企业、组织和个人提供了一个强大的工具,可以接触他们的目标受众,推广他们的产品或服务,并提高他们的客户参与度,具有用户友好的界面、高送达率和实时报告功能,使其成为促销活动、事件通知、约会提醒等各种用例的理想解决方案https://www.brightbikerebel.com/
10.易打单双11商家打单发货指南3. 提前准备备用打印机 大促单量暴增,建议您多配备几台打印机和备用电脑,保证正常打单。 4. 提前做好人员培训 打单人员提前培训,熟悉易打单的打单流程和常用功能。 5. 提前设置好快递单模版、宝贝简称等 提前设置好快递单、发货单、备货单的打印样式和模版。 https://card.weibo.com/article/m/show/id/2309404828880723902909
11.虚拟机可以建网站游戏测试是什么意思_CSS学习 新闻来源:网络整理 2023-3-4共有:3580浏览 游戏测试是什么意思?这些其实都是一个意思:让玩家进游戏帮忙测试 前面的修饰词都是游戏公司自己加的 不过也说一下大致的一个概念 也不能算是概念 压测:目的是测试下服务器以及一些地图的承载能力 玩家会在哪里因为人多卡的要死要活的 不收https://www.gzit.cn/theme/2676502.html
12.统一身份认证有什么用认证文件有什么用途?便宜云服务器帮助中心为你分享云计算行业信息,包含产品介绍、用户指南、开发指南、最佳实践和常见问题等文档,方便快速查找定位问题与能力成长,并提供相关资料和解决方案。本页面关键词:统一身份认证有什么用。http://support.ceden.cn/?topic/97616-1-T
13.教你提高接口性能的18种方案,用了直接提升100倍。耗时操作,考虑用异步处理,这样可以降低接口耗时。 假设一个转账接口,匹配联行号,是同步执行的,但是它的操作耗时有点长,优化前的流程: 为了降低接口耗时,更快返回,你可以把匹配联行号移到异步处理,优化后: 除了转账这个例子,日常工作中还有很多这种例子。比如:用户注册成功后,短信邮件通知,也是可以异步处理的~ https://maimai.cn/article/detail?fid=1781282995&efid=Ydq-Gt2478kKUM5-4UOLjA
14.告别传统压测:全链路压测在中通的实践分享链路大图首先需要梳理出链路调用大图,刚开始不需要太细,但需要对入口/出口/应用名/数据库/缓存/中间件/资金影响/邮件/短信等,类似这样的一些关键信息能梳理到,因为保密手册的原因,具体的链路图,这里就不放出了,可以用本文最上面的《压测流量链路示意图》进行脑补。 https://xie.infoq.cn/article/cc37b94311d35b68aa8db9ab1
15.速云短信测压4.0.6破解版/短信电话测压程序员阿鑫速云短信测压4.0.6破解版_短信电话测压 此版说明 去除收费,去除软件暗桩 使用必看 这个软件暗桩较多(有锁机暗桩,写入文件暗桩,无限弹Dos窗口暗桩等),尽管补丁已经处理了但可能仍有遗漏,为了保护电脑的安全,尽量在虚拟机下使用(需要使用去虚拟化的虚拟机,没有去虚拟化的虚拟机可以站内搜索) https://www.cxyax.com/?post=743
16.大话性能测试:JMeter实战所以,在这里作者建议学习测试的同学优先掌握JMeter工具,本书意在分享作者系统梳理在工作中积累的JMeter常见的实战经验和一些技巧,让大家能够拿来即用,快速应用于自己的实际工作任务中。 3.测试数据构造 在压测之前,需要在数据库中准备好一定量的铺垫存量数据,有些比较复杂的数据会涉及多张表的关联关系,需要利用代码去https://www.epubit.com/bookDetails?id=UB78128d0789cad
17.GitHuberyajf/awesome堡垒机 安全扫描 工单 应用进程管理 微服务框架 性能分析 抓包工具 接口管理 数据管道 文件管理系统 文档 时序数据库 机器镜像 流量回放 测试压测 消息队列 混沌测试 物联网 终端命令行工具 虚拟化 运维管理平台 运维自动化 配置中心 防火墙 项目管理 Backup 此类目收录项目 5 个。 RepositoryLicenseStarCreatedAhttps://github.com/eryajf/awesome-ops/
18.短信网关平台短信软件接入短信验证码短信群发网关压测数据 按TPS 2000条/秒 测试短信数量 1亿 配置如下 CPU+内存 16核32G 占用存储 300G 带宽 根据流量计费 最低成本(阿里云包年,计算型,动态计算带宽) 按TPS 4000条/秒 测试短信数量 1亿 配置如下 CPU+内存 32核64G 占用存储 500G 带宽 根据流量计费 https://www.smswg.com/
19.消息队列在测试开发中的应用思路在压测服务系统的设计中,为了增加吞吐和并发能力,需要架设压测集群,这时数据处理和性能统计会出现单点问题(如jmeter的设计,当分布式集群过大时,master压力过大而死机),可在压测执行机和性能统计机器之间架设消息队列,作为消息传输媒介的同时,让消息队列缓存数据,缓解性能统计机器的压力。 https://www.jianshu.com/p/c5ca087d8113