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

[[194932]]

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

面對上述難題，本文將從智能容量評估與智能告警切入，為大家分享京東金融的運維實踐。

智能容量評

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

線下壓測

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

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

線上壓測

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

如何進行線上的壓測?

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

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

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

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

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

容量計算

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

那么換一種思路去思考，我們通過壓測去評估應(yīng)用的容量其實是因為我們無法知道具體的一個方法的耗時到底在哪里?也就是說被壓測的對象對我們是一個黑盒子，如果我們想辦法打開了這個黑盒子，理論上我們就有辦法計算應(yīng)用的容量，而且可以做到實時的應(yīng)用容量評估。

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

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

舉一個簡單的例子：

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

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

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

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

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

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

• 線程運行耗時(RUNNABLE)
• 線程等待耗時(BLOCKED、WAITING、TIMED_WAITING)

通過對業(yè)務(wù)邏輯耗時的分類得知，真正消耗 CPU 資源的是線程運行耗時，那么問題就變成了我們怎么拿到運行時間與等待時間的耗時比例了。

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

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

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

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

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

智能告警

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

告警處理步驟

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

根源告警原理圖

舉例來說：

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

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

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

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

根源告警明細表

根源告警分析主要分為強關(guān)聯(lián)分析與機器學習兩類。

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

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

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

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

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

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

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

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

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

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

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

b.機器學習根源分析

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

目前，主要進行了兩類機器學習實踐。

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

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

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

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

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

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

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

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

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

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

結(jié)語

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

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

[[194936]]

沈建林

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

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

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

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