【51CTO.com原創(chuàng)稿件】隨著互聯(lián)網(wǎng)+時(shí)代的到來(lái)，京東金融業(yè)務(wù)規(guī)模不斷擴(kuò)大，業(yè)務(wù)場(chǎng)景也不斷創(chuàng)新。但是，業(yè)務(wù)變化之快超乎想象，相應(yīng)的 SOA 及微服務(wù)架構(gòu)日趨深入，服務(wù)數(shù)量不斷膨脹，線上環(huán)境日益復(fù)雜，服務(wù)依賴關(guān)系每天都在變化。

[[194932]]

• 如何實(shí)時(shí)看清系統(tǒng)的容量水位，為容量評(píng)估和系統(tǒng)擴(kuò)容提供客觀依據(jù)?
• 當(dāng)故障發(fā)生時(shí)，如何精確判斷影響范圍?
• 如何確定每一次交易過(guò)程中，每個(gè)系統(tǒng)處理耗時(shí)分別是多少?
• 每個(gè)系統(tǒng)在處理一筆交易時(shí)，分別在數(shù)據(jù)庫(kù)、NoSQL、緩存、日志、RPC、業(yè)務(wù)邏輯上耗時(shí)多少?
• 如何快速確定系統(tǒng)的真正瓶頸點(diǎn)?

面對(duì)上述難題，本文將從智能容量評(píng)估與智能告警切入，為大家分享京東金融的運(yùn)維實(shí)踐。

智能容量評(píng)

應(yīng)用的容量評(píng)估是一個(gè)老大難問(wèn)題，目前也沒(méi)有一種簡(jiǎn)單而有效的方式，主要是通過(guò)壓測(cè)手段直接得到應(yīng)用單機(jī)*** QPS 的相關(guān)數(shù)據(jù)。

線下壓測(cè)

為了測(cè)試數(shù)據(jù)的相對(duì)真實(shí)性，在容量評(píng)估的線下壓測(cè)中一般通過(guò) tcpcopy 等工具，將線上的流量直接復(fù)制到測(cè)試服務(wù)器，在測(cè)試服務(wù)器出現(xiàn)瓶頸時(shí)得到應(yīng)用***的 QPS，再通過(guò)線上線下的換算系數(shù)推算出線上的應(yīng)用能承載的容量。

注：本圖片轉(zhuǎn)自tcpcopy官網(wǎng)

線上壓測(cè)

通過(guò)線下壓測(cè)的方式進(jìn)行容量評(píng)估的優(yōu)點(diǎn)是壓測(cè)過(guò)程對(duì)線上的環(huán)境幾乎沒(méi)有影響，但是過(guò)程比較繁瑣，耗時(shí)也較長(zhǎng)。所以以短平快為主要特色的互聯(lián)網(wǎng)公司更鐘愛(ài)通過(guò)線上的壓測(cè)來(lái)進(jìn)行容量評(píng)估。

如何進(jìn)行線上的壓測(cè)?

一般來(lái)說(shuō)，不管是通過(guò)集中的負(fù)載設(shè)備(如 F5、Radware 等)或是四七層的軟負(fù)載(LVS、Nginx、HAProxy 等)亦或是開(kāi)源的服務(wù)框架(如 Spring Cloud、DUBBO 等)都支持加權(quán)輪詢算法(Weighted Round Robin)。簡(jiǎn)單的說(shuō)就是在負(fù)載輪詢的時(shí)候，不同的服務(wù)器可以指定不同的權(quán)重。

線上壓測(cè)的原理就是逐漸加大某一臺(tái)服務(wù)器的權(quán)重，使這臺(tái)服務(wù)器的流量遠(yuǎn)大于其他服務(wù)器，直至該服務(wù)器出現(xiàn)性能瓶頸。這個(gè)瓶頸可能是 CPU、LOAD、內(nèi)存、帶寬等物理瓶頸，也可能是 RT、失敗率、QPS 波動(dòng)等軟瓶頸。

當(dāng)單機(jī)性能出現(xiàn)性能瓶頸時(shí)，工程師記下此時(shí)的應(yīng)用 QPS 就是單機(jī)容量，然后根據(jù)集群服務(wù)器數(shù)量很容易得到集群的容量。

如下 Nginx 的配置，使得服務(wù)器 192.168.0.2 的流量是其他服務(wù)器的 5 倍，假設(shè)此時(shí)服務(wù)器 192.168.0.2 出現(xiàn)瓶頸，QPS 為 1000，那么集群容量為 3000。(假設(shè)負(fù)載沒(méi)有瓶頸)

http {    
upstream cluster {    
server 192.168.0.2 weight= 5;    
server 192.168.0.3 weight= 1;    
server 192.168.0.4 weight= 1;    
   }    
} 

容量計(jì)算

不管是線上還是線下的壓測(cè)，反映的都是壓測(cè)時(shí)的應(yīng)用容量。在互聯(lián)網(wǎng)快速發(fā)展的今天，程序版本迭代的速度驚人，針對(duì)每次版本的迭代、環(huán)境的變化都進(jìn)行一次線上的壓測(cè)是不現(xiàn)實(shí)的，也是不具備可操作性的。

那么換一種思路去思考，我們通過(guò)壓測(cè)去評(píng)估應(yīng)用的容量其實(shí)是因?yàn)槲覀儫o(wú)法知道具體的一個(gè)方法的耗時(shí)到底在哪里?也就是說(shuō)被壓測(cè)的對(duì)象對(duì)我們是一個(gè)黑盒子，如果我們想辦法打開(kāi)了這個(gè)黑盒子，理論上我們就有辦法計(jì)算應(yīng)用的容量，而且可以做到實(shí)時(shí)的應(yīng)用容量評(píng)估。

因此，迫切需要尋求另外一種解決問(wèn)題的思路：QPS 的瓶頸到底是什么?如果弄清楚了這個(gè)問(wèn)題，應(yīng)用的 QPS 就可以通過(guò)計(jì)算得到。

再結(jié)合下圖的耗時(shí)明細(xì)和應(yīng)用所處的運(yùn)行環(huán)境，我們就可以找到具體的瓶頸點(diǎn)。

舉一個(gè)簡(jiǎn)單的例子：

如果一個(gè)方法在一定采樣時(shí)間內(nèi)，平均 QPS 為 200，平均耗時(shí)為 100ms，耗時(shí)明細(xì)分析發(fā)現(xiàn)平均訪問(wèn)數(shù)據(jù)庫(kù) 6 次，每次耗時(shí) 10ms，也就是數(shù)據(jù)庫(kù)總耗時(shí) 60ms，其他均為業(yè)務(wù)邏輯耗時(shí) 40ms。如何確定應(yīng)用的容量呢?

假如數(shù)據(jù)庫(kù)連接池的***連接數(shù)為 30，執(zhí)行此方法的線程池***為 50(簡(jiǎn)單起見(jiàn)暫時(shí)不考慮線程的切換成本)，那么理論上數(shù)據(jù)庫(kù)的單機(jī)*** QPS 為 30*1000/60=500。

同理業(yè)務(wù)邏輯的單機(jī)*** QPS 為 50*1000/40=1250，顯然這個(gè)方法的瓶頸點(diǎn)在數(shù)據(jù)庫(kù)上，也就是這個(gè)方法的單機(jī)*** QPS 為 500。

然后，針對(duì)這個(gè)方法進(jìn)行優(yōu)化，數(shù)據(jù)庫(kù)每次訪問(wèn)的耗時(shí)降到了 5ms，平均訪問(wèn)次數(shù)變成了 4 次，也就是數(shù)據(jù)庫(kù)總耗時(shí)為 20ms，業(yè)務(wù)邏輯耗時(shí)依然是 40ms，此時(shí)數(shù)據(jù)庫(kù)的單機(jī)*** QPS 為 30*1000/20=1500。顯然此時(shí)的瓶頸點(diǎn)在業(yè)務(wù)邏輯上，也就是這個(gè)方法的單機(jī)*** QPS 為 1250。

上例為一個(gè)方法的單機(jī)*** QPS 推斷，結(jié)合其他方法做同理分析，依據(jù)計(jì)算出這個(gè)方法在整個(gè)應(yīng)用中對(duì)資源的占用比例就可以推算出整個(gè)應(yīng)用的單機(jī)*** QPS。

進(jìn)一步分析，業(yè)務(wù)邏輯耗時(shí)也就是總耗時(shí)去除了 IO 的耗時(shí)(如 RPC 遠(yuǎn)程調(diào)用、訪問(wèn)數(shù)據(jù)庫(kù)、讀寫(xiě)磁盤(pán)耗時(shí)等等)，業(yè)務(wù)邏輯耗時(shí)主要分為兩大部分：

• 線程運(yùn)行耗時(shí)(RUNNABLE)
• 線程等待耗時(shí)(BLOCKED、WAITING、TIMED_WAITING)

通過(guò)對(duì)業(yè)務(wù)邏輯耗時(shí)的分類(lèi)得知，真正消耗 CPU 資源的是線程運(yùn)行耗時(shí)，那么問(wèn)題就變成了我們?cè)趺茨玫竭\(yùn)行時(shí)間與等待時(shí)間的耗時(shí)比例了。

CPU 使用率(進(jìn)程、線程)可以通過(guò) proc 虛擬文件系統(tǒng)得到，此處不是本文重點(diǎn)，不展開(kāi)討論。不同環(huán)境還可以通過(guò)不同的特性快速得到這些數(shù)據(jù)。以 Java 應(yīng)用為例，我們可以從 JMX 中拿到線程執(zhí)行的統(tǒng)計(jì)情況，大致推算出上述的比例，如下圖所示：

繼續(xù)分析上面的例子，假設(shè)我們通過(guò)分析線程的運(yùn)行情況得知，運(yùn)行時(shí)間與等待時(shí)間為 1：1，此時(shí)進(jìn)程 CPU 的使用率為 20%，那么 CPU 指標(biāo)能支撐的單機(jī)*** QPS 為 200 * 100% / 20% = 1000，也就是這個(gè)方法的單機(jī)*** QPS 為 1000。同理可以推斷網(wǎng)絡(luò)帶寬等物理資源的瓶頸點(diǎn)。

一般來(lái)說(shuō)，業(yè)務(wù)邏輯耗時(shí)中，對(duì)于計(jì)算密集型的應(yīng)用，CPU 計(jì)算耗時(shí)的比例比較大，而 IO 密集型的應(yīng)用反之。

通過(guò)以上的數(shù)據(jù)，我們就可以實(shí)時(shí)評(píng)估系統(tǒng)的容量，如下圖：

應(yīng)用實(shí)時(shí)水位圖

智能告警

根源告警分析是基于網(wǎng)絡(luò)拓?fù)?，結(jié)合調(diào)用鏈，通過(guò)時(shí)間相關(guān)性、權(quán)重、機(jī)器學(xué)習(xí)等算法，將告警進(jìn)行分類(lèi)篩選，快速找到告警根源的一種方式。它能從大量的告警中找到問(wèn)題的根源，因此大大縮短了故障排查及恢復(fù)時(shí)間。

告警處理步驟

• 告警過(guò)濾(將告警中不重要的告警以及重復(fù)告警過(guò)濾掉)
• 生成派生告警(根源關(guān)聯(lián)關(guān)系生成各類(lèi)派生告警)
• 告警關(guān)聯(lián)(同一個(gè)時(shí)間窗內(nèi),不同類(lèi)型派生告警是否存在關(guān)聯(lián))
• 權(quán)重計(jì)算(根據(jù)預(yù)先設(shè)置的各類(lèi)告警的權(quán)重，計(jì)算成為根源告警的可能性)
• 生成根源告警(將權(quán)重***的派生告警標(biāo)記為根源告警)
• 根源告警合并(若多類(lèi)告警計(jì)算出的根源告警相同，則將其合并)
• 根據(jù)歷史告警處理知識(shí)庫(kù)，找到類(lèi)似根源告警的處理方案，智能地給出解決方案。

根源告警原理圖

舉例來(lái)說(shuō)：

假設(shè)多個(gè)系統(tǒng)通過(guò) RPC 進(jìn)行服務(wù)調(diào)用，調(diào)用關(guān)系如下：D 系統(tǒng)->C 系統(tǒng)-> B 系統(tǒng)-> A 系統(tǒng)。

當(dāng) A 系統(tǒng)查詢數(shù)據(jù)庫(kù)出現(xiàn)查詢超時(shí)后，告警會(huì)層層往前推進(jìn)，導(dǎo)致 B、C、D 系統(tǒng)均有 N 個(gè)超時(shí)告警產(chǎn)生。此時(shí)，ROOT 分析可以將告警進(jìn)行收斂，直接分析出根源告警為 A 系統(tǒng)訪問(wèn)數(shù)據(jù)庫(kù)異常，導(dǎo)致 A、B、C、D 多個(gè)系統(tǒng)異常。

這樣，就避免了處理人員和每個(gè)系統(tǒng)開(kāi)發(fā)人員溝通，輔助處理人員快速定位問(wèn)題根源、提高了平均解決時(shí)間(MTTR)。如下圖所示：

根源告警調(diào)用鏈關(guān)系

根源告警明細(xì)表

根源告警分析主要分為強(qiáng)關(guān)聯(lián)分析與機(jī)器學(xué)習(xí)兩類(lèi)。

a.強(qiáng)關(guān)聯(lián)數(shù)據(jù)分析

強(qiáng)關(guān)聯(lián)指的是已知確定的關(guān)聯(lián)關(guān)系。如：

• 應(yīng)用之間的調(diào)用鏈關(guān)系
• 數(shù)據(jù)庫(kù)與應(yīng)用服務(wù)器
• 網(wǎng)絡(luò)設(shè)備與網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)設(shè)備與應(yīng)用服務(wù)器
• 宿主機(jī)與虛擬機(jī)關(guān)系等

若在同一個(gè)時(shí)間窗內(nèi)，有多個(gè)強(qiáng)關(guān)聯(lián)的設(shè)備或應(yīng)用服務(wù)器同時(shí)告警，則大概率認(rèn)為告警之間存在關(guān)聯(lián)關(guān)系。

在權(quán)重算法中，有一個(gè)重要的規(guī)則，鏈路上存在連續(xù)的告警可能存在關(guān)聯(lián)，越靠后的應(yīng)用越可能是根源?，F(xiàn)在我們根據(jù)例子，分別計(jì)算各類(lèi)根源告警。

繼續(xù)使用上面的例子，D 應(yīng)用->C 應(yīng)用->B 應(yīng)用->A 應(yīng)用->數(shù)據(jù)庫(kù)異常的情況。

• 首先是計(jì)算數(shù)據(jù)庫(kù)根源告警。根據(jù)數(shù)據(jù)庫(kù)關(guān)聯(lián)關(guān)系，會(huì)派生數(shù)據(jù)庫(kù)類(lèi)型的數(shù)據(jù)庫(kù)告警、A 應(yīng)用告警。還會(huì)派生一條應(yīng)用類(lèi)型的 A 應(yīng)用數(shù)據(jù)庫(kù)異常告警。

根據(jù)數(shù)據(jù)庫(kù)派生告警以及數(shù)據(jù)庫(kù)與應(yīng)用的關(guān)聯(lián)關(guān)系及權(quán)重，可以得出數(shù)據(jù)庫(kù)異常導(dǎo)致 A 應(yīng)用查詢超時(shí)。

• 接下來(lái)是計(jì)算應(yīng)用根源告警。根據(jù)調(diào)用關(guān)系，我們先計(jì)算出連續(xù)多個(gè)應(yīng)用告警的鏈路。當(dāng)前 D->C->B->A 四個(gè)應(yīng)用都有派生告警，滿足此規(guī)則。
• 然后，找到最靠后的告警應(yīng)用，也就是 A 應(yīng)用。列舉時(shí)間窗口內(nèi)所有 A 應(yīng)用的派生告警(可能存在多種派生告警，根據(jù)權(quán)重計(jì)算根源)，將權(quán)重***的派生告警標(biāo)記為根源告警。

比如：A 系統(tǒng)內(nèi)部有 2 種類(lèi)型派生告警，分別是數(shù)據(jù)庫(kù)告警、GC 告警。

根據(jù)權(quán)重計(jì)算規(guī)則，數(shù)據(jù)庫(kù)告警為 90，GC 告警 10，也就是說(shuō)數(shù)據(jù)庫(kù)異常告警權(quán)重***。這時(shí)由于數(shù)據(jù)庫(kù)根源告警和調(diào)用鏈根源告警一致，會(huì)將兩種類(lèi)型的告警合并。***得出結(jié)論：數(shù)據(jù)庫(kù)異常導(dǎo)致 A、B、C、D 系統(tǒng)告警。

b.機(jī)器學(xué)習(xí)根源分析

強(qiáng)關(guān)聯(lián)數(shù)據(jù)分析是對(duì)已知告警的關(guān)聯(lián)關(guān)系，直接進(jìn)行根源告警分析。但是有些時(shí)候，關(guān)聯(lián)關(guān)系是未知的。這時(shí)就需要通過(guò)機(jī)器學(xué)習(xí)算法，找到告警之間的隱含聯(lián)系，再進(jìn)行根源告警預(yù)測(cè)。

目前，主要進(jìn)行了兩類(lèi)機(jī)器學(xué)習(xí)實(shí)踐。

1、關(guān)聯(lián)規(guī)則算法

關(guān)聯(lián)規(guī)則算法主要進(jìn)行了 Apriori 算法和 FPGrowth 兩類(lèi)算法的實(shí)踐。這兩類(lèi)功能相似，都可以發(fā)現(xiàn)頻繁項(xiàng)集。經(jīng)過(guò)實(shí)測(cè)，F(xiàn)PGrowth 比 Apriori 更高效一些。

我們按一定的時(shí)間間隔劃分時(shí)間窗，計(jì)算每個(gè)時(shí)間窗內(nèi)，各種告警一起出現(xiàn)的頻率，找出各類(lèi)告警之間的關(guān)聯(lián)。最終可按分析出的關(guān)聯(lián)關(guān)系，生成根源告警。

關(guān)聯(lián)規(guī)則算法的優(yōu)點(diǎn)在于理解和實(shí)現(xiàn)起來(lái)比較簡(jiǎn)單。缺點(diǎn)是效率比較低，靈活度也不夠高。

2、神經(jīng)網(wǎng)絡(luò)算法

循環(huán)神經(jīng)網(wǎng)絡(luò)(簡(jiǎn)稱 RNN)是一個(gè)和時(shí)間序列有關(guān)系的神經(jīng)網(wǎng)絡(luò)，對(duì)單張圖片而言，像素信息是靜止的，而對(duì)于一段話而言，里面的詞的組成是有先后的，而且通常情況下，后續(xù)的詞和前面的詞有順序關(guān)聯(lián)。

這時(shí)候，卷積神經(jīng)網(wǎng)絡(luò)通常很難處理這種時(shí)序關(guān)聯(lián)信息，而 RNN 卻能有效地進(jìn)行處理。

隨著時(shí)間間隔的增大，RNN 對(duì)于后面時(shí)間的節(jié)點(diǎn)相比前面時(shí)間節(jié)點(diǎn)的感知力將下降。解決這個(gè)問(wèn)題需要用到 LongShort Term 網(wǎng)絡(luò)(簡(jiǎn)稱 LSTM)，它通過(guò)刻意的設(shè)計(jì)來(lái)避免長(zhǎng)期依賴問(wèn)題。LSTM 在實(shí)踐中默認(rèn)可以記住長(zhǎng)期的信息，而不需要付出很大代價(jià)。

對(duì)于某類(lèi)故障引起的大量告警之間，存在著時(shí)間相關(guān)性。將歷史派生告警作為輸入，將根源告警類(lèi)型作為輸出。通過(guò) LSTM 提取派生告警特征，建立告警相關(guān)性分析模型。這樣就可以實(shí)時(shí)將符合特征的派生告警，劃分到同一類(lèi)根源告警中，幫助用戶快速定位問(wèn)題。

需要說(shuō)明的是金融本身的業(yè)務(wù)特點(diǎn)決定了對(duì)第三方存在依賴性，因此告警本身的隨機(jī)性較大，客觀上導(dǎo)致學(xué)習(xí)樣本的質(zhì)量不高，需要長(zhǎng)期的積累和修正才能達(dá)到比較好的效果，因此對(duì)于根源告警，如果有條件取到強(qiáng)關(guān)聯(lián)關(guān)系，建議使用強(qiáng)關(guān)聯(lián)分析，能達(dá)到事半功倍的效果。

結(jié)語(yǔ)

智能運(yùn)維是目前運(yùn)維領(lǐng)域被炒得最火的詞匯之一，但是個(gè)人認(rèn)為沒(méi)有一個(gè)智能運(yùn)維的產(chǎn)品是放之四海而皆準(zhǔn)，智能運(yùn)維需要在真實(shí)的環(huán)境中不斷的磨合，才能達(dá)到我們預(yù)期的效果。

隨著人工智能在運(yùn)維領(lǐng)域的不斷嘗試與探索，未來(lái)在運(yùn)維領(lǐng)域中的異常檢測(cè)與智能報(bào)警及自動(dòng)化容量規(guī)劃與分配必將得到快速的發(fā)展，從而成為運(yùn)維的核心競(jìng)爭(zhēng)力。

[[194936]]

沈建林

京東金融集團(tuán)資深架構(gòu)師

曾在多家知名第三方支付公司任職系統(tǒng)架構(gòu)師，致力于基礎(chǔ)中間件與支付核心平臺(tái)的研發(fā)，主導(dǎo)過(guò) RPC 服務(wù)框架、數(shù)據(jù)庫(kù)分庫(kù)分表、統(tǒng)一日志平臺(tái)，分布式服務(wù)跟蹤、流程編排等一系列中間件的設(shè)計(jì)與研發(fā)，參與過(guò)多家支付公司支付核心系統(tǒng)的建設(shè)?，F(xiàn)任京東金融集團(tuán)資深架構(gòu)師，負(fù)責(zé)基礎(chǔ)開(kāi)發(fā)部基礎(chǔ)中間件的設(shè)計(jì)和研發(fā)工作。擅長(zhǎng)基礎(chǔ)中間件設(shè)計(jì)與開(kāi)發(fā)，關(guān)注大型分布式系統(tǒng)、JVM 原理及調(diào)優(yōu)、服務(wù)治理與監(jiān)控等領(lǐng)域。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】

編輯：王雪燕、陶家龍、孫淑娟