金融服務(wù)智能運(yùn)維的實(shí)踐

1、 金融服務(wù)智能運(yùn)維的實(shí)踐人工階段的運(yùn)維，理想與現(xiàn)實(shí)有天壤之別，同時(shí)還有背不完的鍋，填不完的坑。人工、自動(dòng)、智能運(yùn)維相互交疊是當(dāng)前運(yùn)維領(lǐng)域的現(xiàn)狀，智能運(yùn)維是大勢(shì)所趨，但真正的落地實(shí)踐并不多。為什么要做服務(wù)監(jiān)控？業(yè)務(wù)規(guī)模不斷擴(kuò)大、微服務(wù)化、頻繁變更這三方面現(xiàn)實(shí)需求，是做服務(wù)治理和監(jiān)控的重要原因。為保證這三方面的正常進(jìn)行，需要做很多事，重點(diǎn)包括如下幾點(diǎn)：如何快速發(fā)現(xiàn)問(wèn)題？采用哪些技術(shù)？如何梳理服務(wù)依賴？面對(duì)京東過(guò)萬(wàn)的服務(wù)，如何進(jìn)行梳理，具體實(shí)現(xiàn)過(guò)程是怎么樣的？如何判斷依賴合理性？微服務(wù)之間相互依賴，采用什么樣方式判斷依賴是否合理？如何實(shí)現(xiàn)實(shí)時(shí)容量規(guī)劃？傳統(tǒng)的方式是在 618 前兩月進(jìn)行封網(wǎng)，不允許上

2、線，利用這段時(shí)間進(jìn)行線上壓測(cè)，得到應(yīng)用的容量，隨后根據(jù)現(xiàn)實(shí)情況進(jìn)行擴(kuò)容。這樣的方式耗時(shí)耗力，所有研發(fā)不讓上線，成本很難評(píng)估?，F(xiàn)在的做法是基于歷史數(shù)據(jù)，機(jī)器學(xué)習(xí)，自動(dòng)運(yùn)算，那具體是如何實(shí)現(xiàn)的？如何判斷故障影響范圍？也就是故障定位問(wèn)題，如何能知道哪個(gè)節(jié)點(diǎn)發(fā)生故障，響應(yīng)了哪些業(yè)務(wù)？如何實(shí)現(xiàn)業(yè)務(wù)級(jí)監(jiān)控？京東金融會(huì)和很多第三方支付機(jī)構(gòu)打交道，如何去監(jiān)控和合作伙伴之間交易的服務(wù)質(zhì)量？綜上都是服務(wù)監(jiān)控要完成的使命，下面我們先從服務(wù)監(jiān)控設(shè)計(jì)原則、自主監(jiān)控的基本要素、服務(wù)依賴關(guān)系梳理、調(diào)用鏈分析、容量規(guī)劃、根源分析等方面來(lái)看看服務(wù)監(jiān)控的應(yīng)用。服務(wù)監(jiān)控的應(yīng)用實(shí)踐1、服務(wù)監(jiān)控設(shè)計(jì)原則服務(wù)監(jiān)控與治理軟件的設(shè)計(jì)原則主要

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

4、功率。后期的一些監(jiān)控?cái)U(kuò)展，都是基于這三個(gè)指標(biāo)。如下圖，是監(jiān)控的細(xì)節(jié)：如圖中所示，紅顏色的線條被稱之基線，通過(guò)波動(dòng)可知當(dāng)前這個(gè)服務(wù)的響應(yīng)時(shí)間、調(diào)用量、成功率等情況?；€計(jì)算很復(fù)雜，基于以前歷史數(shù)據(jù)，利用異常檢測(cè)算法，推算當(dāng)前的量應(yīng)該是多少。如下圖，是監(jiān)控分層的細(xì)節(jié)展示：如圖中所示，每一條線都可以下鉆，鉆進(jìn)去就可看到某個(gè)應(yīng)用里有哪些類正在被監(jiān)控，進(jìn)一步下鉆可以看到方法、IP 級(jí)別。當(dāng)出現(xiàn)某一臺(tái)服務(wù)器故障，影響整個(gè)響應(yīng)時(shí)間時(shí)，從 IP 級(jí)別的圖中就可以快速定位，看到是哪個(gè) IP 出現(xiàn)了問(wèn)題。3、服務(wù)依賴關(guān)系梳理分享服務(wù)梳理方法之前，先來(lái)了解如下兩個(gè)概念：依賴強(qiáng)度。指服務(wù)之間的依賴關(guān)系強(qiáng)弱。比如購(gòu)物必

5、須要交易，交易必須經(jīng)過(guò)支付后才發(fā)貨，交易對(duì)支付就是強(qiáng)依賴，支付系統(tǒng)出故障，交易也不能幸免。依賴頻度。指對(duì)某一個(gè)服務(wù)的調(diào)用次數(shù)，調(diào)用頻繁，就是高頻依賴?；谶@兩個(gè)概念，可以進(jìn)一步對(duì)方法、應(yīng)用和業(yè)務(wù)線之間的依賴關(guān)系進(jìn)行分析，如下是某場(chǎng)景依賴關(guān)系的全拓?fù)鋱D：從圖中，可以很清晰地看到整個(gè)調(diào)用的拓?fù)?，所有?yīng)用相互之間的依賴強(qiáng)度，通過(guò)連線之間的數(shù)字來(lái)描述應(yīng)用之間的依賴頻度。如下，是依賴關(guān)系的主流程圖：把弱依賴及依賴頻度較小的應(yīng)用去掉以后，可以看到主流程，主流就是核心系統(tǒng)，如果出現(xiàn)故障，影響會(huì)非常大。4、調(diào)用鏈分析如下圖，是調(diào)用鏈分析：這是整個(gè)服務(wù)監(jiān)控中相對(duì)重要的環(huán)節(jié)，當(dāng)觸發(fā)一次請(qǐng)求，如用戶在京東購(gòu)物，用戶

6、付款這個(gè)動(dòng)作要經(jīng)過(guò)哪些 IP 來(lái)處理，IP 上有哪些方法進(jìn)行處理，通過(guò)哪些協(xié)議去調(diào)用，耗時(shí)是多少，每一次調(diào)用都要跟蹤，每天有千億以上類似的調(diào)用。整個(gè)調(diào)用鏈都處于監(jiān)控中，如出現(xiàn)故障，告警就會(huì)通過(guò)短信、郵件的方式把鏈接推送給運(yùn)維人員。運(yùn)維人員點(diǎn)開鏈接就可知曉故障位置，同時(shí)還有一些工具輔助處理問(wèn)題。5、容量規(guī)劃容量規(guī)劃方面，傳統(tǒng)的方式是應(yīng)用上線之前做壓測(cè)，但很多時(shí)候一上線容量就變了，導(dǎo)致之前設(shè)置的數(shù)據(jù)都是沒有意義了。如下圖，是現(xiàn)在的實(shí)時(shí)容量規(guī)劃方式：如上圖左側(cè)所示，在 618，雙 11 等大促時(shí)，把這些拓?fù)鋱D實(shí)時(shí)數(shù)據(jù)和性能指標(biāo)都擺放在大屏上，當(dāng)水位、響應(yīng)時(shí)間等任何一個(gè)指標(biāo)出現(xiàn)異常，運(yùn)維人員就會(huì)及時(shí)發(fā)

7、現(xiàn)問(wèn)題，并快速進(jìn)行問(wèn)題解決。如下圖，是服務(wù)訪問(wèn)慢，出現(xiàn)異常的快速定位案例：當(dāng)服務(wù)訪問(wèn)慢時(shí)，系統(tǒng)會(huì)計(jì)算到 IP 上的指標(biāo)，很多時(shí)候是一兩臺(tái)服務(wù)器過(guò)慢，可通過(guò)郵件看到是哪個(gè)服務(wù)器出問(wèn)題。點(diǎn)開郵件鏈接，就可以看到從什么時(shí)間開始慢，什么時(shí)間結(jié)束，平均的響應(yīng)時(shí)間是否偏高。進(jìn)一步下鉆，可看到什么樣的問(wèn)題導(dǎo)致響應(yīng)時(shí)間偏高，這里會(huì)引用一些智能故障分析工具。6、根源分析根源分析可基于自動(dòng)學(xué)習(xí)的拓?fù)潢P(guān)系、數(shù)據(jù)庫(kù)與應(yīng)用的關(guān)系、應(yīng)用與 IP 的關(guān)系等確定性因素來(lái)做，如下圖，是一個(gè)非常典型的磁盤 IO 導(dǎo)致日志打印慢的問(wèn)題。這樣因一臺(tái)機(jī)器由于打印日志排隊(duì)造成堵塞，導(dǎo)致后面好多應(yīng)用出現(xiàn)調(diào)用性能下降的簡(jiǎn)單問(wèn)題。如果沒有根源

8、分析，要靠人為分析去定位根本原因還是非常困難的。綜上所述是服務(wù)監(jiān)控的應(yīng)用，下面我們從日志采集方案對(duì)比、分布式服務(wù)跟蹤的挑戰(zhàn)、整體技術(shù)架構(gòu)等方面來(lái)看看技術(shù)實(shí)現(xiàn)。服務(wù)監(jiān)控的技術(shù)實(shí)現(xiàn)1、日志采集方案對(duì)比所有的服務(wù)監(jiān)控是基于一條日志，日志采集方案有很多。如下圖所示，分為四個(gè)階段：最原始的階段，是業(yè)務(wù)各自監(jiān)控，自己編寫監(jiān)控邏輯，業(yè)務(wù)上埋點(diǎn)，輸出自己的監(jiān)控日志。第二階段，是業(yè)務(wù)與監(jiān)控耦合，提供公共的監(jiān)控 API，通過(guò) API 的方式自動(dòng)產(chǎn)生這條日志。第三階段，是中間件與監(jiān)控的耦合，通過(guò)中間件埋點(diǎn)方式來(lái)產(chǎn)生這條日志。第四階段，是業(yè)務(wù)、中間件、監(jiān)控?zé)o耦合，采用 APM 或流量鏡像分析的方式。流量鏡像分析，是從

9、設(shè)備上把流量鏡像下來(lái)，分析服務(wù)之間的關(guān)系，但存在的問(wèn)題是，流量分析出來(lái)的是一個(gè)結(jié)果，當(dāng)應(yīng)用調(diào)整或服務(wù)依賴發(fā)生變化，結(jié)果會(huì)受到很大影響。APM 是目前主流的方式。2、分布式服務(wù)跟蹤的挑戰(zhàn)在分布式追蹤上，我們碰到了一些問(wèn)題，這里主要分享如下三方面：跨線程。在設(shè)計(jì)過(guò)程中，服務(wù)被訪問(wèn)時(shí)，可能會(huì)啟動(dòng)新線程去處理，跨線程去追蹤會(huì)有些難度。以 Java 語(yǔ)言舉例來(lái)說(shuō)，同線程之內(nèi)，可借助現(xiàn)有 ThreadLocal 非常方便的去追蹤。如某個(gè)服務(wù)有一部分代碼邏輯是放在另一個(gè)線程上執(zhí)行的，就要去修改 JDK 對(duì)線程的一些實(shí)現(xiàn)邏輯?？鐓f(xié)議。通常情況下，追蹤鏈都很長(zhǎng)，一個(gè)正常的交易要由很多應(yīng)用串起來(lái)，提供服務(wù)。這時(shí)就要跨很多協(xié)議如 RPC、HTTP、JMS、AMQP 等去追蹤。擴(kuò)展性。當(dāng)新增協(xié)議、與其他企業(yè)框架不同怎么辦？這需要自定義的擴(kuò)展性描述語(yǔ)言來(lái)解決。3、服務(wù)監(jiān)控平臺(tái)的整體技術(shù)架構(gòu)如下圖，是服務(wù)監(jiān)控平臺(tái)的整體技術(shù)架構(gòu)：服務(wù)監(jiān)控平臺(tái)的核心是產(chǎn)生日志的 Agent，采用 Java Byt