金融服務智能運維的實踐

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

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

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

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

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

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

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

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

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