不管什麽性質的業務，吞吐量的本質是木桶原理，能跑多大量取決於木桶最短的那個板，腦袋裏是不是立刻可以出現木桶的那個模型，哈哈！！換句話說，當有能力提高短板的高度時，業務的吞吐量就會有所上升，但同樣有個邊際效應，經過多次的優化後，當再次提高短板的成本非常非常大，而付出後提高的量很低時，那就不要較勁了，直接加服務器吧。

言歸正傳，先解釋一下單機QPS跑不上去的現象，具體表現就是高過一個點後錯誤率增加、時延增大，很顯然遇到短板了，那麽這個短板在哪呢，開發過來二話不說要求加服務器，難道作為應用運維就直接向老板要麽？服務器或許已經夠多了，用戶總量你心中知道沒有多少，用戶增量也沒多加多少，用戶體驗沒增加多少，但業務上服務器成本卻像一個無底洞一樣，需要不停的增加擴容，那麽這個時候就該靜下心分析一下了，到底是什麽原因導致業務跑不上去？負責任的說，運維這個職務給公司省錢就是給公司掙錢了，這個數字還特別可觀。

一、系統本身

分析的整體方法是由淺入深、層層深入，先看服務器本身的指標有沒有遇到短板，這個層面的分析也是相對最容易的，在配置層面（ulimit相關例如fd等）檢查沒有問題後，從下面四個方面進行分析。

1、cpu

cpu粗面上看有兩個指標，當前使用率和負載，使用率反應的是當前cpu使用的情況，而負載反應的是cpu任務的隊列情況，也就是說任務排隊情況。一般cpu使用率在70%一下，負載在0.7*核心數以下，cpu的指標就算正常。

也有例外情況，得詳細分析cpu細致使用指標，恰巧被我遇到過，阿裏雲的ecs，整體cpu利用率不高，但業務不上量，和曉峰查後cpu0的軟中斷極高，單核經常到100%，繼續查後發現網絡中斷都在cpu0上，無法自動負載，網卡不支持多隊列，cpu0的單核瓶頸造成了業務整體瓶頸。

cpu用滿的解決辦法很簡單，查程序沒有bug、無大的優化空間後，那就是加機器或者換cpu類型的機器，cpu我好像沒有單加過。

2、內存

內存常規看的是使用率。這個在做cdn的小文件緩存時遇到過，當時用的是ats，發現程序經常重啟，業務跟著抖動，後查日誌發現OOM，當內存快要被占滿的時候，kernel直接把ats的進程給殺掉了，然後out of socket memory，當時留的截圖如下

同樣，在應用程序層面沒有大的優化空間，那就加內存吧！！

3、IO

IO主要指的是硬盤IO，我一般用iostat -kdx 1看後面的比率，當一只超過50%，且偶發到100%，這說明磁盤肯定是到瓶頸了。

這個在新浪做圖片業務時遇到過，是一個源站的裁圖業務，在設計上為了避免重復裁圖，在本地硬盤上還存了一份近7天的圖，由於用python寫的，沒有像JVM那種管理內存的機制，所有的IO都在硬盤上。有一天業務突然掛了，和開發查了2個多小時未果，中間調整了各種參數，緊急擴容了兩臺機器依然不起作用，服務的IO高我們是知道的，查看IO粗數據和歷史差不多，就沒往那方面深考慮，艷波後來請來另外一個業務的開發徐焱同學，經驗頗多，查後當機立斷使用掛載內存的方式替換掉硬盤的IO操作，IO立馬下來了，服務恢復。

IO問題也得綜合的解決，一般從程序邏輯到服務器都要改造，程序上把重IO的邏輯放在內存，服務器上加SSD吧。

4、網絡

網絡主要是看出、入口流量，要做好監控，當有一天網絡千兆網卡流量曲線跑平了，那麽業務就出問題了。

之前在運維圖片業務時遇到過網卡跑滿的情況，是一個圖片（小文件）的源站存儲業務，突然就開始告警，各種5XX，查後5XX並無規律，後看網卡發現出流量跑滿了，雖然網卡是千兆不是萬兆，但按道理就cdn的幾個邊緣節點過來回個源，不至於跑滿，將文件拿出來分析後發現問題，開發的同學為了使用方便，將新聞app的apk升級包的大文件放到這個業務上了，很坑！！

網卡的解決方式很多，做bond和換萬兆（交換機要支持），當前的情況我們後來改了業務邏輯，大於多少M上傳時自動去大文件服務了。

二、程序代碼

當查了cpu、內存、IO、網絡都沒什麽問題時，就可以和開發好好掰扯掰扯了，為什麽服務器本身沒什麽壓力，量卻跑不上去，不要以為開發寫的程序都很優良，人無完人何況是人寫出來的程序呢？很多時候就是程序或技術架構本身的問題跑不上去量，這個過程我們還是要協助開發分析技術架構的，是不是程序cpu和內存使用的不合理，是不是可以跑一下多實例，把某些邏輯比較重的點做下埋點日誌，把執行的全過程apm數據跑出來進行分析，等等。

三、服務架構、業務邏輯

發展至今，微服務架構設計已成為大型互聯網應用的標配，各模塊間通過HTTP、RPC等相互依賴、相互調用，如果查完服務器、程序依然沒有問題，再往深處走就得協同開發分析邏輯、架構了，這也是微服務架構下的一個特色，不是因為服務器的某個短板造成了業務瓶頸，而是某個模塊的短板造成了整個業務吞吐量上不去，這個很好理解，甚至有很多接口用的是公網公共服務的接口。

在操作上，從一次完整請求的角度，從頭到尾理一遍外部依賴的上下遊資源和調用關系，外部資源包括api接口、DB等，然後在每個點做埋點日誌，將數據進行分析，我們在線上用這種方法不知道分析出了多少瓶頸，如果程序沒有做很好的降級熔斷，由於程序本身的執行是堵塞的，一個接口慢影響到整個請求，進而QPS上來後請求變慢錯誤數增高的例子很多，在這種情況下，如果瓶頸的接口是別的部門或公網資源，加多少服務器都解決不了問題，進行結構改造吧。

好了，寫到這，希望對遇到問題不知如何下手的你有所幫助！！

查看更多請到博主原創站：運維網咖社（www.net-add.com）

微服務架構下業務單機QPS跑不上去應從哪些角度分析