944
京東金融
從人肉運維到智能運維，京東金融服務監控的進階之路
人肉階段的運維，理想與現實有天壤之別，同時還有背不完的鍋，填不完的坑。人工、自動、智能運維相互交疊是當前運維領域的現狀，智能運維是大勢所趨，但真正的落地實踐並不多。
在由 51CTO 主辦的第十四期“Tech Neo”技術沙龍活動中，資深架構師沈建林分享了京東金融的服務監控、服務治理等方麵的應用與技術實現。
為什麼要做服務監控？
業務規模不斷擴大、微服務化、頻繁變更這三方麵現實需求，是做服務治理和監控的重要原因。
為保證這三方麵的正常進行，需要做很多事，重點包括如下幾點：
如何快速發現問題？采用哪些技術？
如何梳理服務依賴？麵對京東過萬的服務，如何進行梳理，具體實現過程是怎麼樣的？
如何判斷依賴合理性？微服務之間相互依賴，采用什麼樣方式判斷依賴是否合理？
如何實現實時容量規劃？傳統的方式是在 618 前兩月進行封網，不允許上線，利用這段時間進行線上壓測，得到應用的容量，隨後根據現實情況進行擴容。
這樣的方式耗時耗力，所有研發不讓上線，成本很難評估。現在的做法是基於曆史數據，機器學習，自動運算，那具體是如何實現的？
如何判斷故障影響範圍？也就是故障定位問題，如何能知道哪個節點發生故障，響應了哪些業務？
如何實現業務級監控？京東金融會和很多第三方支付機構打交道，如何去監控和合作夥伴之間交易的服務質量？
綜上都是服務監控要完成的使命，下麵我們先從服務監控設計原則、自主監控的基本要素、服務依賴關係梳理、調用鏈分析、容量規劃、根源分析等方麵來看看服務監控的應用。
服務監控的應用實踐
01
服務監控設計原則
服務監控與治理軟件的設計原則主要有以下五個方麵：
微內核。設計產品時把內核設計的非常小，稱之為微內核。采用 Plugin 模式，所有功能采用微內核方式，把自己也當做第三方去擴展，這樣的產品，不管是開源或商用，別人擴展時也會更加便捷。
樂觀策略。不能因為監控影響業務，一旦影響業務采用拋棄策略，監控項要全部異步處理。通過 SoftReference(軟引用)的方式，在內存吃緊的時候優先釋放掉監控本身所占用的內存。
零侵入。簡化研發使用，實現業務、中間件、監控完全獨立。
約定大於配置。自動發現：部署規範，配置規範默認返回碼、描述。
動態路由。日誌傳輸節點遠程控製，無限擴容。
02
自主監控三劍客
做自主監控有三個最基本要素，分別是調用量、性能、成功率。後期的一些監控擴展，都是基於這三個指標。
如下圖，是監控的細節：
如圖中所示，紅顏色的線條被稱之基線，通過波動可知當前這個服務的響應時間、調用量、成功率等情況。基線計算很複雜，基於以前曆史數據，利用異常檢測算法，推算當前的量應該是多少。
如下圖，是監控分層的細節展示：
如圖中所示，每一條線都可以下鑽，鑽進去就可看到某個應用裏有哪些類正在被監控，進一步下鑽可以看到方法、IP 級別。
當出現某一台服務器故障，影響整個響應時間時，從 IP 級別的圖中就可以快速定位，看到是哪個 IP 出現了問題。
03
服務依賴關係梳理
分享服務梳理方法之前，先來了解如下兩個概念：
依賴強度。指服務之間的依賴關係強弱。比如購物必須要交易，交易必須經過支付後才發貨，交易對支付就是強依賴，支付係統出故障，交易也不能幸免。
依賴頻度。指對某一個服務的調用次數，調用頻繁，就是高頻依賴。
基於這兩個概念，可以進一步對方法、應用和業務線之間的依賴關係進行分析，如下是某場景依賴關係的全拓撲圖：
從圖中，可以很清晰的看到整個調用的拓撲，所有應用相互之間的依賴強度，通過連線之間的數字來描述應用之間的依賴頻度。
如下，是依賴關係的主流程圖：
把弱依賴及依賴頻度較小的應用去掉以後，可以看到主流程，主流就是核心係統，如果出現故障，影響會非常大。
04
調用鏈分析
如下圖，是調用鏈分析：
這是整個服務監控中相對重要的環節，當觸發一次請求，如用戶在京東購物，用戶付款這個動作要經過哪些 IP 來處理，IP 上有哪些方法進行處理，通過哪些協議去調用，耗時是多少，每一次調用都要跟蹤，每天有千億以上類似的調用。
整個調用鏈都處於監控中，如出現故障，告警就會通過短信、郵件的方式把鏈接推送給運維人員。運維人員點開鏈接就可知曉故障位置，同時還有一些工具輔助處理問題。
05
容量規劃
容量規劃方麵，傳統的方式是應用上線之前做壓測，但很多時候一上線容量就變了，導致之前設置的數據都是沒有意義了。
如下圖，是現在的實時容量規劃方式：
如上圖左側所示，在 618，雙 11 等大促時，把這些拓撲圖實時數據和性能指標都擺放在大屏上，當水位、響應時間等任何一個指標出現異常，運維人員就會及時發現問題，並快速進行問題解決。
如下圖，是服務訪問慢，出現異常的快速定位案例：
當服務訪問慢時，係統會計算到 IP 上的指標，很多時候是一兩台服務器過慢，可通過郵件看到是哪個服務器出問題。
點開郵件鏈接，就可以看到從什麼時間開始慢，什麼時間結束，平均的響應時間是否偏高。進一步下鑽，可看到什麼樣的問題導致響應時間偏高，這裏會引用一些智能故障分析工具。
06
根源分析
根源分析可基於自動學習的拓撲關係、數據庫與應用的關係、應用與 IP 的關係等確定性因素來做，如下圖，是一個非常典型的磁盤 IO 導致日誌打印慢的問題。
這樣因一台機器由於打印日誌排隊造成堵塞，導致後麵好多應用出現調用性能下降的簡單問題。如果沒有根源分析，要靠人為分析去定位根本原因還是非常困難的。
綜上所述是服務監控的應用，下麵我們從日誌采集方案對比、分布式服務跟蹤的挑戰、整體技術架構等方麵來看看技術實現。
服務監控的技術實現
01
日誌采集方案對比
所有的服務監控是基於一條日誌，日誌采集方案有很多。如下圖所示，分為四個階段：
最原始的階段，是業務各自監控，自己編寫監控邏輯，業務上埋點，輸出自己的監控日誌。
第二階段，是業務與監控耦合，提供公共的監控 API，通過 API 的方式自動產生這條日誌。
第三階段，是中間件與監控的耦合，通過中間件埋點方式來產生這條日誌。
第四階段，是業務、中間件、監控無耦合，采用 APM 或流量鏡像分析的方式。
流量鏡像分析，是從設備上把流量鏡像下來，分析服務之間的關係，但存在的問題是，流量分析出來的是一個結果，當應用調整或服務依賴發生變化，結果會受到很大影響。APM 是目前主流的方式。
02
分布式服務跟蹤的挑戰
在分布式追蹤上，我們碰到了一些問題，這裏主要分享如下三方麵：
跨線程。在設計過程中，服務被訪問時，可能會啟動新線程去處理，跨線程去追蹤會有些難度。
以 Java 語言舉例來說，同線程之內，可借助現有 ThreadLocal 非常方便的去追蹤。如某個服務有一部分代碼邏輯是放在另一個線程上執行的，就要去修改 JDK 對線程的一些實現邏輯。
跨協議。通常情況下，追蹤鏈都很長，一個正常的交易要由很多應用串起來，提供服務。這時就要跨很多協議如 RPC、HTTP、JMS、AMQP 等去追蹤。
擴展性。當新增協議、與其他企業框架不同怎麼辦？這需要自定義的擴展性描述語言來解決。
03
服務監控平台的整體技術架構
如下圖，是服務監控平台的整體技術架構：
服務監控平台的核心是產生日誌的 Agent，采用 Java Bytecode 的方式進行自動增強。由統一的 Config Server 下發監控指令，Agent 在應用啟動時或者運行時動態增強需要監控的方法。
日誌產生後由路和模塊決定發送到哪裏，可以是本地磁盤、消息隊列、Collector 等。隨後進行流水計算，實時匯聚結果，存入 NoSQL，然後由頁麵進行展示。
作者：王雪燕
編輯：陶家龍、孫淑娟
沈建林
京東金融集團資深架構師
曾在多家知名第三方支付公司任職係統架構師，致力於基礎中間件與支付核心平台的研發，主導過 RPC 服務框架、數據庫分庫分表、統一日誌平台，分布式服務跟蹤、流程編排等一係列中間件的設計與研發，參與過多家支付公司支付核心係統的建設。現任京東金融集團資深架構師，負責基礎開發部基礎中間件的設計和研發工作。擅長基礎中間件設計與開發，關注大型分布式係統、JVM 原理及調優、服務治理與監控等領域。
最後更新：2017-10-08 06:45:03