隨著互聯(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)系每天都在變化绞佩。
如何實時看清系統(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)的容量，如下圖：
智能告警
根源告警分析是基于網(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)用越可能是根源『窨茫現(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ā)展席函，從而成為運維的核心競爭力铐望。
原文來自：51CTO技術(shù)棧
作者：沈建林，京東金融集團資深架構(gòu)師茂附，曾在多家知名第三方支付公司任職系統(tǒng)架構(gòu)師正蛙，致力于基礎(chǔ)中間件與支付核心平臺的研發(fā)，主導(dǎo)過 RPC 服務(wù)框架营曼、數(shù)據(jù)庫分庫分表乒验、統(tǒng)一日志平臺，分布式服務(wù)跟蹤蒂阱、流程編排等一系列中間件的設(shè)計與研發(fā)锻全，參與過多家支付公司支付核心系統(tǒng)的建設(shè)。現(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)域。
