整個分布式統(tǒng)計系統(tǒng)包括
1、API進(jìn)程，提供API業(yè)務(wù)服務(wù)，也就是業(yè)務(wù)接口，統(tǒng)計數(shù)據(jù)的生產(chǎn)者
2、API服務(wù)器的本地統(tǒng)計進(jìn)程，統(tǒng)計本地服務(wù)器API調(diào)用數(shù)據(jù)，次數(shù)、耗時等
3、匯總服務(wù)器，接收各個API服務(wù)器統(tǒng)計進(jìn)程的數(shù)據(jù)匯總，定時(1秒)發(fā)給瀏覽器渲染QPS曲線

流程：
1、API進(jìn)程每收到一個請求就給本地統(tǒng)計進(jìn)程發(fā)一個udp包，包含這次調(diào)用的接口名、耗時、錯誤日志等信息，統(tǒng)計進(jìn)程將對應(yīng)的請求接口請求次數(shù)＋1。
2、每個統(tǒng)計進(jìn)程定時(1秒)將統(tǒng)計進(jìn)程內(nèi)統(tǒng)計數(shù)據(jù)發(fā)送給匯總服務(wù)器，然后將QPS數(shù)據(jù)清零
3、匯總服務(wù)器也是類似的邏輯，收到各個統(tǒng)計進(jìn)程的統(tǒng)計數(shù)據(jù)后匯總計算，定時(1秒)推送給瀏覽器，然后數(shù)據(jù)清零。
4、瀏覽器收到匯總服務(wù)器的推送數(shù)據(jù)，渲染各個接口QPS曲線圖

性能瓶頸分析：
1、假設(shè)1000臺API服務(wù)器定時(1秒)給匯總服務(wù)器發(fā)送QPS數(shù)據(jù)，那么匯總服務(wù)器QPS僅為1000請求每秒，僅僅是內(nèi)存計算，完全沒問題
2、每臺API服務(wù)器上的統(tǒng)計進(jìn)程僅僅統(tǒng)計本機(jī)API調(diào)用量，單進(jìn)程處理udp請求可達(dá)幾萬PQS，所以統(tǒng)計進(jìn)程本身不會有瓶頸
3、所以這種架構(gòu)的QPS統(tǒng)計可以支持上千臺甚至上萬臺API的實時QPS統(tǒng)計不會有任何性能瓶頸。

其它數(shù)據(jù)統(tǒng)計：
以上是QPS實時統(tǒng)計，實際還有統(tǒng)計進(jìn)程還做了請求耗時、請求來源、失敗日志等等的統(tǒng)計，這些統(tǒng)計數(shù)據(jù)經(jīng)過加工緩存到內(nèi)存中，數(shù)據(jù)每一分鐘存儲一次磁盤。

查看歷史統(tǒng)計
當(dāng)我們要看某個時間段的統(tǒng)計數(shù)據(jù)時，利用IO復(fù)用技術(shù)給所有API服務(wù)器的統(tǒng)計進(jìn)程發(fā)送一個統(tǒng)計請求，每個API服務(wù)器將本地對應(yīng)的磁盤數(shù)據(jù)讀出(因為經(jīng)過預(yù)處理數(shù)據(jù)量很小)，經(jīng)過簡單的計算加工，發(fā)給匯總服務(wù)器，匯總服務(wù)器同樣利用IO復(fù)用，并發(fā)批量接收每個服務(wù)器的統(tǒng)計數(shù)據(jù)，然后匯總展示。整個過程實際就是分布式計算，結(jié)果匯總展示。

驗證
以上是QPS曲線圖＋統(tǒng)計服務(wù)的架構(gòu)，這種架構(gòu)已經(jīng)在高并發(fā)系統(tǒng)驗證過了，600-700臺workerman服務(wù)器，每天幾十億的請求量，能夠?qū)崟r查看系統(tǒng)各個接口調(diào)用量曲線，各個維度查詢接口調(diào)用情況，快速排查錯誤日志，非常穩(wěn)定好用。

配幾個圖：

[attach]460[/attach] QPS曲線，請求量最大的接口 11W/S

[attach]461[/attach]
失敗QPS，哪些接口上一秒報錯量多少，錯誤日志調(diào)用棧一目了然

[attach]448[/attach]接口失敗分布

[attach]449[/attach]請求來源

付費求開源