微服務架構下業務單機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）