微服务架构下业务单机QPS跑不上去应从哪些角度分析

瓶颈分析是应用运维老生常谈的一个事儿，常常作，今天总结一下，但愿对你有所帮助。

无论什么业务，吞吐量的本质是木桶原理，能跑多大量取决于木桶最短那个板（脑壳里是不马上出现了木桶模型，哈哈）！！换句话说，当有能力提升短板的高度时，业务的吞吐量就会上升，但一样有个边际效应，通过屡次的优化后，当再次提升短板的成本很是很是大，而提升的量却很低时，那就不要较劲了，直接加服务器吧。

言归正传，先讲一下QPS跑不上去的现象，表现就是高过一个点后错误率增长、响应时间变长、用户体验变差，带来的反作用就是用户的流失，很显然是遇到瓶颈了，那么瓶颈在哪儿，咱们怎么分析呢？

开发二话不说要求加服务器，做为应用运维不过脑子直接向老板要么？服务器或许已经够多了，用户总量你心中知道没有多少，用户增量也没多少，但业务上对服务器的需求却像无底洞同样，须要不停的扩容再扩容，其实这个时候就该静下心来分析一下了，究竟是什么缘由致使吞吐量跑不上去？负责任的说，运维给公司省钱就是给公司挣钱了，抓到点上这个数字还特别的可观，总结后，通常瓶颈问题从下面三个维度来分析。

1、机器自己

分析的总体方法是由浅入深、层层深刻，先看服务器自己的指标有没有遇到短板，这个层面的分析也是相对最容易的，在配置层面（ulimit相关例如fd等）检查没有问题后，从下面四个方面进行分析。

一、cpu

cpu粗面上看有两个指标，当前使用率和负载，使用率反应的是当前cpu使用的状况，而负载反应的是cpu任务的队列状况，也就是说任务排队状况。通常cpu使用率在70%如下，负载在0.7*核心数如下，cpu的指标就算正常。

也有例外状况得分析cpu的详细指标，在运维小米消息系统的一个模块时，服务器用的是阿里云的ecs，总体cpu利用率不到30%，但业务就是跑不上量，和肖坤同窗查后发现cpu0的软中断极高，单核常常打到100%，继续查后发现网络中断都在cpu0上没法自动负载，和阿里云工程师确认后是所在机型不支持网卡多队列形成的，最终定位cpu的单核瓶颈形成了业务总体瓶颈，以下图：

cpu用满的解决办法简单粗暴，在程序无bug的前提下，换机型加机器，cpu自己没单独加过。

附一篇排查cpu问题的博文：4核服务器cpu使用率10%负载飙到23.5故障排查

二、内存

内存常规看的是使用率。这个在作cdn的小文件缓存时遇到过，当时用的是ats，发现程序常常重启，业务跟着抖动，查日志后发现系统OOM了，当内存快要被占满的时候，kernel直接把ats的进程给杀掉，而后报out of socket memory，留的截图以下：

一样，在应用层没有优化空间时，那就加内存吧！！

三、IO

IO主要指硬盘，通常用iostat -kdx 1看各类指标，当 %util超过50%，且偶发到100%，这说明磁盘确定是到瓶颈了。

要进一步查看是否因为IO问题形成了系统堵塞能够用vmstat 1 查看，下图b对应因IO而block的进程数量。

这个在新浪作图片业务时遇到过，是一个源站的裁图业务，设计上为了不重复裁图，在本地硬盘上存了一份近7天的数据，因为用python写的，没有像JVM那种内存管理机制，全部的IO都在硬盘上。有一天业务忽然挂了，和开发查了2个多小时未果，中间调整了各类参数，紧急扩容了两台机器依然不起做用，服务的IO高咱们是知道的，查看IO数据和历史差很少，就没往那方面深考虑，后邀请经验颇多的徐焱同窗参与排查，当机立断使用挂载内存的方式替换掉硬盘的IO操做，IO立马下来了，服务恢复。

IO问题也得综合的解决，通常从程序逻辑到服务器都要改造，程序上把重IO的逻辑放在内存，服务器上加SSD吧。

四、网络

网络主要是看出、入口流量，要作好监控，当网卡流量跑平了，那么业务就出问题了。

一样在运维图片业务时遇到过网卡跑满的状况，是一个图片（小文件）的源站业务，忽然就开始各类5XX告警，查后5XX并没有规律，继而查网卡发现出口流量跑满了，继续分析，虽然网卡是千兆的，但按理就cdn的几个二级回源点回源，不至于跑满，将文件大小拿出来分析后，发现开发的同窗为了省事儿，将带有随机数几十M的apk升级包放这里了，真是坑！！

网卡的解决方式不少，作bond和换万兆网卡（交换机要支持），当前的状况咱们后来改了业务逻辑，大于多少M时强制走大文件服务。

2、程序代码

当查了cpu、内存、IO、网络都没什么问题，就能够和开发好好掰扯掰扯了，为何服务器自己没什么压力，量却跑不上去，不要觉得开发写的程序都很优良，人无完人况且是人写出来的程序呢？不少时候就是程序或技术架构自己的问题跑不上去量，这个过程运维仍是要协助开发分析代码逻辑的，是否是程序cpu和内存使用的不合理，是否是能够跑一下多实例，把某些逻辑比较重的地方作下埋点日志，把执行的全过程apm数据跑出来进行分析，等等。

一个典型用运维手段解决代码瓶颈的案例详见博文：记一次HttpDns业务调优——fastcgi-cache性能提高5倍

3、逻辑架构

发展至今，微服务架构设计已成为大型互联网应用的标配，各模块间经过HTTP、RPC等相互依赖调用，若是查完服务器、程序依然没有问题，再往深处走就得协同开发分析逻辑架构了，这也是微服务系统下的一个特点，不是由于服务器或者程序bug形成了业务瓶颈，而是某个模块的短板形成了整个业务吞吐量上不去，这个很好理解，甚至有不少接口用的是公网公共服务。

具体分析上，从一次完整请求的角度，从头至尾理一遍外部依赖的上下游资源和调用关系，外部资源包括api接口、DB、队列等，而后在每一个点作埋点日志，将数据进行分析，咱们在线上用这种方法不知道分析出了多少瓶颈，若是程序没有作很好的降级熔断，因为程序自己的执行是堵塞的，一个接口慢影响到整个请求，进而QPS上来后请求变慢错误数增高的例子不少，在这种状况下，若是瓶颈的接口是别的部门或公网资源，加多少服务器都解决不了问题，进行改造吧，下图是运维门户业务时作的依赖接口超时监控，性能差的接口一目了然：

好了，写到这，但愿对遇到问题不知如何下手的你有所帮助！！

查看更多请到博主原创站：运维网咖社（www.net-add.com）