【51CTO.com原創(chuàng)稿件】人肉階段的運(yùn)維，理想與現(xiàn)實(shí)有天壤之別，同時還有背不完的鍋，填不完的坑。人工、自動、智能運(yùn)維相互交疊是當(dāng)前運(yùn)維領(lǐng)域的現(xiàn)狀，智能運(yùn)維是大勢所趨，但真正的落地實(shí)踐并不多。

在由 51CTO 主辦的第十四期“Tech Neo”技術(shù)沙龍活動中，資深架構(gòu)師沈建林分享了京東金融的服務(wù)監(jiān)控、服務(wù)治理等方面的應(yīng)用與技術(shù)實(shí)現(xiàn)。

為什么要做服務(wù)監(jiān)控?

業(yè)務(wù)規(guī)模不斷擴(kuò)大、微服務(wù)化、頻繁變更這三方面現(xiàn)實(shí)需求，是做服務(wù)治理和監(jiān)控的重要原因。為保證這三方面的正常進(jìn)行，需要做很多事，重點(diǎn)包括如下幾點(diǎn)：

• 如何快速發(fā)現(xiàn)問題?采用哪些技術(shù)?
• 如何梳理服務(wù)依賴?面對京東過萬的服務(wù)，如何進(jìn)行梳理，具體實(shí)現(xiàn)過程是怎么樣的?
• 如何判斷依賴合理性?微服務(wù)之間相互依賴，采用什么樣方式判斷依賴是否合理?
• 如何實(shí)現(xiàn)實(shí)時容量規(guī)劃?傳統(tǒng)的方式是在618前兩月進(jìn)行封網(wǎng)，不允許上線，利用這段時間進(jìn)行線上壓測，得到應(yīng)用的容量，隨后根據(jù)現(xiàn)實(shí)情況進(jìn)行擴(kuò)容。這樣的方式耗時耗力，所有研發(fā)不讓上線，成本很難評估?，F(xiàn)在的做法是基于歷史數(shù)據(jù)，機(jī)器學(xué)習(xí)，自動運(yùn)算，那具體是如何實(shí)現(xiàn)的?
• 如何判斷故障影響范圍?也就是故障定位問題，如何能知道哪個節(jié)點(diǎn)發(fā)生故障，響應(yīng)了哪些業(yè)務(wù)?
• 如何實(shí)現(xiàn)業(yè)務(wù)級監(jiān)控?京東金融會和很多第三方支付機(jī)構(gòu)打交道，如何去監(jiān)控和合作伙伴之間交易的服務(wù)質(zhì)量?

綜上都是服務(wù)監(jiān)控要完成的使命，下面我們先從服務(wù)監(jiān)控設(shè)計原則、自主監(jiān)控的基本要素、服務(wù)依賴關(guān)系梳理、調(diào)用鏈分析、容量規(guī)劃、根源分析等方面來看看服務(wù)監(jiān)控的應(yīng)用。

服務(wù)監(jiān)控的應(yīng)用實(shí)踐

服務(wù)監(jiān)控設(shè)計原則

服務(wù)監(jiān)控與治理軟件的設(shè)計原則主要有五個方面，分別是微內(nèi)核、樂觀策略、零侵入、約定大于配置、動態(tài)路由。

• 微內(nèi)核。設(shè)計產(chǎn)品時把內(nèi)核設(shè)計的非常小，稱之為微內(nèi)核。采用Plugin模式，所有功能采用微內(nèi)核方式，把自己也當(dāng)做第三方去擴(kuò)展，這樣的產(chǎn)品，不管是開源或商用，別人擴(kuò)展時也會更加便捷。
• 樂觀策略。不能因為監(jiān)控影響業(yè)務(wù)，一旦影響業(yè)務(wù)采用拋棄策略，監(jiān)控項要全部異步處理。通過SoftReference(軟引用)的方式，在內(nèi)存吃緊的時候優(yōu)先釋放掉監(jiān)控本身所占用的內(nèi)存。
• 零侵入。簡化研發(fā)使用，實(shí)現(xiàn)業(yè)務(wù)、中間件、監(jiān)控完全獨(dú)立。
• 約定大于配置。自動發(fā)現(xiàn)：部署規(guī)范，配置規(guī)范默認(rèn)返回碼、描述。
• 動態(tài)路由。日志傳輸節(jié)點(diǎn)遠(yuǎn)程控制，***擴(kuò)容。

自主監(jiān)控三劍客

做自主監(jiān)控有三個最基本要素，分別是調(diào)用量、性能、成功率。后期的一些監(jiān)控擴(kuò)展，都是基于這三個指標(biāo)。如下圖，是監(jiān)控的細(xì)節(jié)：   

如圖中所示，紅顏色的線條被稱之基線，通過波動可知當(dāng)前這個服務(wù)的響應(yīng)時間、調(diào)用量、成功率等情況。基線計算很復(fù)雜，基于以前歷史數(shù)據(jù)，利用異常檢測算法，推算當(dāng)前的量應(yīng)該是多少。

如下圖，是監(jiān)控分層的細(xì)節(jié)展示： 

如圖中所示，每一條線都可以下鉆，鉆進(jìn)去就可看到某個應(yīng)用里有哪些類正在被監(jiān)控，進(jìn)一步下鉆可以看到方法、IP級別。當(dāng)出現(xiàn)某一臺服務(wù)器故障，影響整個響應(yīng)時間時，從IP級別的圖中就可以快速定位，看到是哪個IP出現(xiàn)了問題。

服務(wù)依賴關(guān)系梳理

分享服務(wù)梳理方法之前，先來了解兩個概念：依賴強(qiáng)度和依賴頻度。

• 依賴強(qiáng)度指服務(wù)之間的依賴關(guān)系強(qiáng)弱。比如購物必須要交易，交易必須經(jīng)過支付后才發(fā)貨，交易對支付就是強(qiáng)依賴，支付系統(tǒng)出故障，交易也不能幸免。
• 依賴頻度指對某一個服務(wù)的調(diào)用次數(shù)，調(diào)用頻繁，就是高頻依賴。

基于這兩個概念，可以進(jìn)一步對方法、應(yīng)用和業(yè)務(wù)線之間的依賴關(guān)系進(jìn)行分析，如下是某場景依賴關(guān)系的全拓?fù)鋱D：

從圖中，可以很清晰的看到整個調(diào)用的拓?fù)?，所有?yīng)用相互之間的依賴強(qiáng)度，通過連線之間的數(shù)字來描述應(yīng)用之間的依賴頻度。

如下，是依賴關(guān)系的主流程圖:

把弱依賴及依賴頻度較小的應(yīng)用去掉以后，可以看到主流程，主流就是核心系統(tǒng)，如果出現(xiàn)故障，影響會非常大。

調(diào)用鏈分析

如下圖，是調(diào)用鏈分析: 

這是整個服務(wù)監(jiān)控中相對重要的環(huán)節(jié)，當(dāng)觸發(fā)一次請求，如用戶在京東購物，用戶付款這個動作要經(jīng)過哪些IP來處理，IP上有哪些方法進(jìn)行處理，通過哪些協(xié)議去調(diào)用，耗時是多少，每一次調(diào)用都要跟蹤，每天有千億以上類似的調(diào)用。

整個調(diào)用鏈都處于監(jiān)控中，如出現(xiàn)故障，告警就會通過短信、郵件的方式把鏈接推送給運(yùn)維人員。運(yùn)維人員點(diǎn)開鏈接就可知曉故障位置，同時還有一些工具輔助處理問題。

容量規(guī)劃

容量規(guī)劃方面，傳統(tǒng)的方式是應(yīng)用上線之前做壓測，但很多時候一上線容量就變了，導(dǎo)致之前設(shè)置的數(shù)據(jù)都是沒有意義了。如下圖，是現(xiàn)在的實(shí)時容量規(guī)劃方式：

如上圖左側(cè)所示，在618，雙11等大促時，把這些拓?fù)鋱D實(shí)時數(shù)據(jù)和性能指標(biāo)都擺放在大屏上，當(dāng)水位、響應(yīng)時間等任何一個指標(biāo)出現(xiàn)異常，運(yùn)維人員就會及時發(fā)現(xiàn)問題，并快速進(jìn)行問題解決。

如下圖，是服務(wù)訪問慢，出現(xiàn)異常的快速定位案例：

當(dāng)服務(wù)訪問慢時，系統(tǒng)會計算到IP上的指標(biāo)，很多時候是一兩臺服務(wù)器過慢，可通過郵件看到是哪個服務(wù)器出問題。點(diǎn)開郵件鏈接，就可以看到從什么時間開始慢，什么時間結(jié)束，平均的響應(yīng)時間是否偏高。進(jìn)一步下鉆，可看到什么樣的問題導(dǎo)致響應(yīng)時間偏高，這里會引用一些智能故障分析工具。

根源分析

根源分析可基于自動學(xué)習(xí)的拓?fù)潢P(guān)系、數(shù)據(jù)庫與應(yīng)用的關(guān)系、應(yīng)用與IP的關(guān)系等確定性因素來做，如下圖，是一個非常典型的磁盤IO導(dǎo)致日志打印慢的問題。

這樣因一臺機(jī)器由于打印日志排隊造成堵塞，導(dǎo)致后面好多應(yīng)用出現(xiàn)調(diào)用性能下降的簡單問題。如果沒有根源分析，要靠人為分析去定位根本原因還是非常困難的。

綜上所述是服務(wù)監(jiān)控的應(yīng)用，下面我們從日志采集方案對比、分布式服務(wù)跟蹤的挑戰(zhàn)、整體技術(shù)架構(gòu)等方面來看看技術(shù)實(shí)現(xiàn)。

服務(wù)監(jiān)控的技術(shù)實(shí)現(xiàn)

日志采集方案對比

所有的服務(wù)監(jiān)控是基于一條日志，日志采集方案有很多，如下圖所示，分為四個階段：

最原始的階段，是業(yè)務(wù)各自監(jiān)控，自己編寫監(jiān)控邏輯，業(yè)務(wù)上埋點(diǎn)，輸出自己的監(jiān)控日志。

第二階段，是業(yè)務(wù)與監(jiān)控耦合，提供公共的監(jiān)控API，通過API的方式自動產(chǎn)生這條日志。

第三階段，是中間件與監(jiān)控的耦合，通過中間件埋點(diǎn)方式來產(chǎn)生這條日志。

第四階段，是業(yè)務(wù)、中間件、監(jiān)控?zé)o耦合，采用APM或流量鏡像分析的方式。流量鏡像分析，是從設(shè)備上把流量鏡像下來，分析服務(wù)之間的關(guān)系，但存在的問題是，流量分析出來的是一個結(jié)果，當(dāng)應(yīng)用調(diào)整或服務(wù)依賴發(fā)生變化，結(jié)果會受到很大影響。APM是目前主流的方式。

分布式服務(wù)跟蹤的挑戰(zhàn)

在分布式追蹤上，我們碰到了一些問題，這里主要分享三方面，分別是跨線程、跨協(xié)議、擴(kuò)展性。

• 跨線程。在設(shè)計過程中，服務(wù)被訪問時，可能會啟動新線程去處理，跨線程去追蹤會有些難度。以Java語言舉例來說，同線程之內(nèi)，可借助現(xiàn)有ThreadLocal非常方便的去追蹤。如某個服務(wù)有一部分代碼邏輯是放在另一個線程上執(zhí)行的，就要去修改JDK對線程的一些實(shí)現(xiàn)邏輯。
• 跨協(xié)議。通常情況下，追蹤鏈都很長，一個正常的交易要由很多應(yīng)用串起來，提供服務(wù)。這時就要跨很多協(xié)議如RPC、HTTP、JMS、AMQP等去追蹤。
• 擴(kuò)展性。當(dāng)新增協(xié)議、與其他企業(yè)框架不同怎么辦?這需要自定義的擴(kuò)展性描述語言來解決。

服務(wù)監(jiān)控平臺的整體技術(shù)架構(gòu)

如下圖，是服務(wù)監(jiān)控平臺的整體技術(shù)架構(gòu)：

服務(wù)監(jiān)控平臺的核心是產(chǎn)生日志的Agent，采用Java Bytecode的方式進(jìn)行自動增強(qiáng)。由統(tǒng)一的Config Server下發(fā)監(jiān)控指令，Agent在應(yīng)用啟動時或者運(yùn)行時動態(tài)增強(qiáng)需要監(jiān)控的方法。日志產(chǎn)生后由路和模塊決定發(fā)送到哪里，可以是本地磁盤、消息隊列、Collector等。隨后進(jìn)行流水計算，實(shí)時匯聚結(jié)果，存入NoSQL，然后由頁面進(jìn)行展示。

由于篇幅原因，很多內(nèi)容沒有一一整理，服務(wù)監(jiān)控應(yīng)用部分：調(diào)用來源分析、耗時分析、JVM監(jiān)控以及針對業(yè)務(wù)的一系列監(jiān)控模型，像分類、比值等。服務(wù)監(jiān)控技術(shù)實(shí)現(xiàn)部分：Agent采集內(nèi)容、調(diào)用鏈擴(kuò)展方式、自動監(jiān)控擴(kuò)展以及一些優(yōu)化小貼士。欲知更詳盡的內(nèi)容，請點(diǎn)擊 視頻觀看。

【講師簡介】

[[204907]]

曾在多家知名第三方支付公司任職系統(tǒng)架構(gòu)師，致力于基礎(chǔ)中間件與支付核心平臺的研發(fā)，主導(dǎo)過 RPC 服務(wù)框架、數(shù)據(jù)庫分庫分表、統(tǒng)一日志平臺，分布式服務(wù)跟蹤、流程編排等一系列中間件的設(shè)計與研發(fā)，參與過多家支付公司支付核心系統(tǒng)的建設(shè)?，F(xiàn)任京東金融集團(tuán)資深架構(gòu)師，負(fù)責(zé)基礎(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)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】