系統化服務構建-調用鏈管理

這篇文章探討應用開發中的調用鏈管理，涉及到的主要知識有日誌，接口及服務的定義，監控和微服務註冊。

調用鏈管理

調用鏈管理是服務架構中的一項基本職責，也是一項服務能力。主要使用TraceId和SpanId，跟蹤服務的調用依賴關係，串起整個服務調用路徑，方便上下游服務的監控，管理。

先不用說微服務這麼高大上的系統，一般的應用系統，在實現某項功能時，會涉及到各類外部依賴，或接口，或服務，或組件，整個調用鏈條的生命週期就是調用鏈管理。

關鍵概念

本文在談論調用鏈管理時，有幾個概念明確以下

上游服務（消費者）

上游服務是 調用者所依賴的服務的統稱，這裏的服務能夠是單獨的接口，也能夠是一組接口組成的功能集合。

實際上這裏有一個核心問題是如何定義服務。

從接口數量的緯度，不管單個接口，多個接口組成的功能集合，多個功能組成的組件，均可以叫作服務。

從服務必備的屬性來看，主要包括服務名（接口名），域名，URL（地址），方法和參數。

從微服務的概念緯度來看，服務包括提供者服務，和消費者服務。再深度一點，就涉及到服務註冊中心的相關理論了。

本小節的上游服務，特指提供者服務。

下游服務（調用方）

調用方就是服務消費者。

在某一項功能的調用鏈過程當中，調用方就不侷限在前端Js了，調用方更多的是下游服務。這裏涉及到計算機網絡的兩種通訊方式，C/S方式和 P2P（點對點對等方式）。

P2P點對點的核心解釋就是網絡上的計算節點既是服務的提供者，爲其它計算節點提供服務，又是消費者，依賴於其它服務。

LevelId

調用鏈的惟一編號，通常由首次調用的發起者生成，全局惟一。

上游服務異常

下游業務基於上游服務作業務，如何定義上游服務異常?

第一種狀況

上游地址錯誤，形成訪問異常，簡單來講，接口沒有返回，接口域名錯誤，接口地址錯誤404，http通道直接報錯

第二種狀況

上游地址域名正確，接口地址正確，可是服務中止了，接口返回Null，尤爲是基於Java的服務，有的人喜歡默認Null

以上兩種狀況 下游在處理時，能夠以 ["message"] 的形式，統必定義【上游服務異常】狀態碼，進行錯誤直接輸出，來標記服務沒有獲取到數據的狀況。基於一個準則，作對外輸出的統一化。

第三種狀況

上游服務訪問相應時間長，形成超時。

做爲調用方如何捕獲接口調用方的請求超時，是個值得研究的問題。

調用鏈管理的做用

進行調用鏈管理的目的是維護程序穩定，功能可用，保證應用系統的彈性。

經過調用鏈管理，能夠快速定位問題，經過自定義【上游服務異常】狀態碼的方式，定位問題出如今上游服務層面，仍是本服務的數據處理層面。

若是接口是跨部門調用的，那麼這就是其餘部門的責任了。責任更明確。

下面闡述下如何作調用鏈管理，主要包括生成鏈路Id，記錄請求輸出日誌，分析和預警。

生成鏈路Id

鏈路Id 由前端生成仍是後端生成？

圖片是公開資料的一張PPT

鏈路Id 由一次調用的入口方生成，不必定是前端。

如下代碼是YII2中鏈路Id生成示例

public static function createRequestId()
    {
        //$prefix = $module; 
        $prefix = Yii::$app->controller->module->id;
        session_create_id(date('YmdHis'));
        // 使用uniqid()方法建立惟一id
        $requestId = strtoupper(md5(uniqid($prefix, true)));
        return $requestId;
    }

記錄日誌

形式化描述監控模型

如下描述摘錄自一篇論文，文中的形式化描述的五元組的過程，實際上就是監控建模的過程。

一次追蹤有全局的 TraceId 來標識，追蹤中的每一個調用請求都有惟一的 LevelId， 爲了更好地描述後續概念，這裏咱們首先對每一個調用請求進行形式化描述。

LevelId就是上文中的TraceId或者鏈路Id

定義 五元組𝑅=(𝐿𝑒𝑣𝑒𝑙𝐼𝑑,𝑆𝑒𝑟𝑣𝑖𝑐𝑒,𝑀𝑒𝑡h𝑜𝑑,𝑃𝑎𝑟𝑎𝑚𝑠)來描述每一個請求信息 所包含的特徵信息，稱之爲特徵向量。LevelId 用來標識請求信息，LevelId 在一次追 蹤中惟一，爲多級編號。
Service 表示請求信息所請求的服務名稱，
Method 表示請求信息調用的方法名稱，
Params 表示請求信息所帶參數集合。

程序在每一個節點記錄日誌時，能夠藉助形式化描述的屬性，進行記錄，持久化方式能夠以日誌形式，也能夠用數據庫形式。

如何檢測請求超時？

第一種方式，藉助於HTTP等調用組件的超時參數設置

第二種方式，服務器（服務方）檢測時間差，客戶端（請求方）請求時間與服務器（服務方）時間的差值與超時時間作對比

當接口查詢不到數據時，接口code應該如何設計？

接口下游什麼時候應該直接輸出上游接口的message，或者說上游是否應該從新messgae。

參考一種實現方式，對於【上游服務異常】的狀態碼進行統一，而【Message】進行原樣輸出。

可是有一點須要保證，保證輸出到本系統的返回數據json結構是完整的，即符合

data
message
code

的結構，缺一不可。

不完整的輸出結構，就意味者更多的判斷邏輯和溝通。輸出完整的json結構，方便調用方的統一管理和維護通信協議的標準化，標準化就表明着低成本和高效率。

服務雪崩效應

多個服務層調用，基礎服務的故障可能會致使級聯故障，進而形成整個系統不可用的狀況，這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因「服務提供者」的不可用致使「服務消費者」的不可用,並將不可用逐漸放大的過程。

淘寶鷹眼是基於網絡調用日誌的分佈式跟蹤系統，它能夠分析網絡請求在各個分佈式系統之間的調用狀況，從而獲得處理請求的調用鏈上的入口URL、應用服務的調用關係，從而找到請求處理瓶頸，定位錯誤異常的根源位置。

監控作到業務無侵入

監控能作到業務無侵入，可插拔 就是最高境界了。常規的應用系統很難作到這一點，也鮮有能力維護。橫切關注點，邊車模式都是實現業務無侵入的一些嘗試方案。

橫切關注點

在軟件開發過程當中，橫切關注點指的是散佈於軟件應用中多處的功能，這些功能
與業務邏輯相分離（可是每每又會直接內嵌在應用的業務邏輯之中）。把這些橫切關
注點與業務邏輯進行解耦分離正是 AOP 要解決的問題。

常見的橫切關注點有操做日誌的生成、安全檢測、事務處理等等，分佈式追蹤中對於追蹤信息的採集記錄也能夠當作一個橫切關注點。

總結

本文圍繞調用鏈管理，對相關的概念和使用場景進行描述，整體來講，調用鏈管理也是有生命週期和通用實施策略的。

首先使用鏈路Id做爲串聯，在各個計算節點記錄完整的輸入輸出日誌。

其次對日誌進行一些常規分析，量化數據指標，對關鍵業務進行更加詳細的記錄和分析。
最後是及時的預警和反饋。

按照這樣的步驟，最基礎的調用鏈管理功能就完成了。若是要再深刻研究，主要的方向就是結合日誌，配合可視化UI，在分佈式鏈路跟蹤上。

---