從傳統服務鏈監控到端到端流程監控技術實現
今天談下服務鏈監控和端到端流程監控。對于服務鏈監控有開源的類似zipkin，skywalking開源工具可以實現完整的服務鏈監控功能，但是采用這些工具的一般都需要在JVM啟動的時候注入探針Jar包，進行訪問攔截。而本方法則是一個自己規約實現服務鏈監控，整體的思路和方法實際和我們常說的服務鏈監控是一致的。
服務鏈監控實現
SkyWalking監控圖
服務鏈監控基本概念與場景說明
服務鏈監控APM（Application Performance Management）即應用性能管理，屬于IT運維管理（ITOM）范疇。主要是針對企業關鍵業務的IT應用性能和用戶體驗的監測、優化，提高企業IT應用的可靠性和質量，保證用戶得到良好的服務，降低IT總擁有成本（TCO）。
在網絡環境下，一次獨立的服務請求往往需要涉及到多個服務。由于應用或服務構建在不同的軟件模塊上，這些軟件模塊，有可能是由不同的團隊開發、使用不同的編程語言來實現，而且有可能部署在不同的硬件環境中，橫跨多個不同的數據中心。因此，就需要一些可以幫助理解系統行為、用于分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題。
服務鏈監控是通常應用于APM，即將實際應用性能和相關服務的調用關系以服務鏈方式串聯起來，以便分析和定位實際影響到最終應用性能的關鍵服務，并進行后續處理。
分布式環境下的服務鏈監控基本模型如下：
圖片
其中，在上圖中有幾個比較重要的概念。
- Span：基本工作單元，一次鏈路調用創建一個span，通過一個XX位ID標識它，一般是UUID較為方便。當然，Span中還可以有其他的數據，例如描述信息、時間戳等。
- Trace：類似于樹結構的Span集合，表示一條調用鏈路，存在唯一標識。
服務鏈監控場景說明
如果需要在復雜的網絡環境上下文中理解分布式系統的行為，就需要監控那些橫跨了不同的應用、不同的服務器之間的關聯動作。在多系統、多模塊、多服務構成的架構系統中，幾乎每一個前端請求都會形成一個復雜的分布式服務調用鏈路。
一個服務請求的完整調用鏈路可能如下圖所示：
圖片
即在前臺功能頁面，點擊提交單據按鈕的時候，需要調用業務內部多個服務接口，同時也需要調用到外部系統提交的服務接口，實現完整的業務功能邏輯。那就需要對整個服務調用鏈進行監控。
那么，在業務規模不斷增大、服務不斷增多以及頻繁變更的情況下，面對復雜的調用鏈路就帶來一系列問題：
- 如何快速發現問題？
- 如何判斷故障影響范圍？
- 如何梳理服務依賴以及依賴的合理性？
- 如何分析鏈路性能問題以及實時容量規劃？
有了服務鏈監控，我們能夠做到：
- 提供鏈路追蹤，故障快速定位：可以通過結合業務日志快速定位錯誤信息。
- 可視化：各個階段耗時，進行性能分析。
- 依賴優化：各個調用環節的可用性、梳理服務依賴關系以及優化。
- 數據分析，優化鏈路：可以得到用戶的行為路徑，匯總分析應用在很多業務場景。
業務場景驗證和關鍵技術實現
在這里，我們舉一個業務報賬單單據提交功能來進行說明和驗證。業務人員在報賬平臺填寫報賬申請單，填寫完成后進行提交，具體涉及到如下操作步驟。
- 進行數據完整性校驗（調用供應商有效性校驗接口，調用賬戶有效性校驗服務）
- 調用預算校驗和扣減（調用預算校驗服務，調用預算扣減子服務）
- 調用申請單保存服務，進行申請單保存
- 調用工作流平臺提供的工作流啟動服務接口進行流程啟動
圖片
服務鏈監控的使用規范
a.在接口服務調用中增加TRACE_ID信息
需要在接口服務調用的輸入中增加TRACE_ID字段，作為服務鏈跟蹤使用。
b. TRACE_ID組成說明
一個用于服務鏈監控的TRACE_ID的生成，由以下信息所構成。
概述：UUID+ SPANID +SPANID+SPANID 組成
說明：UUID為每一個服務調用鏈，生成一個獨立唯一的UUID值
SPANID：SPANID為01、02順序編碼，服務調用每進一層增，即增加一層SPANID
圖片
依據上述規則，生成的一個參考如下：
TRACE_ID：550e8400-e29b-41d4-a716-446655440000.01.01.02
c. 服務鏈監控參考實現偽代碼
根據前述業務場景例證的說明，下面以報賬服務的調用鏈路來說明，如何使用TRACE_ID來進行服務鏈的監控。
1. 業務系統所有的子方法調用都需要增加TRACE_ID參數進行傳遞，子方法調用下一級子方法的時候生成新的TRACE_ID值，即TRACE_ID的定義是遞歸的。
TRACE_ID = TRACE_ID + SPANID
2. SPANID按服務調用的順序進行兩位編碼，每次步長增加1，諸如01、02、 …. 99
參考下述偽代碼，描述了前述的監控實現過程：
public String ApplySubmit()
{
//通過工具類生成UUID
String uuid = utils.generateUUID();
//調用數據檢查服務，通過UUID + SPANID 拼接出每次服務請求的TraceID
Boolean r1 = this.DataValidateSrv(params, uuid + ”.01”);
//調用預算檢查服務
Boolean r2 = this.BudgetValidateSrv(params, uuid + “.02”);
//調用單據保存服務
Boolean r3 = this.BillSaveSrv(params, uuid + “.03”);
//調用啟動工作流服務
Boolean r4 = this.StartWorkFlow(params, uuid + “.04”);
//結果返回處理
String result;
return result;
}對于需要進行跟蹤的下一級服務，也需要依照同樣的原則進行處理：
public String DataValidateSrv(params, TraceID)
{
//調用供應商檢查服務，通過TRACEID + SPANID 拼接出每次服務請求的TraceID
this.VendorValidateSrv(params, TraceID + ”.01”);
//調用銀行賬戶檢查服務
this.BankAccountValidateSrv(params, TraceID + “.02”);
//結果返回處理
String result;
///
return result;
}d.監控日志的記錄
由于在前臺操作觸發的后臺服務調用操作中，有可能調用注冊在集成平臺上的服務，也可以調用業務系統內部的服務接口，因此，要做到全面的服務鏈監控需要對兩部分的日志都進行記錄。
- ESB總線服務：平臺會記錄服務日志，調用時間消耗；業務系統也可以同時記錄。
- 業務系統內部服務：集成平臺無法記錄，必須由業務系統自己記錄。
服務日志需要同時記錄服務調用時間消耗、服務ID、服務名稱、TRACE_ID、輸入、輸出信息。具體代碼參考如下：
//數據檢查服務方法
Void DataValidSrv(params, TRACE_ID);
{
//獲取開始時間
Time StartTime = System.GetCurrentTime();
//獲取入口參數
Map inputParams = this.method.getParams();
//供應商檢查，實際為UUID.01.01
this.VendorValidSrv(params,TRACE_ID.01);
//銀行賬戶檢查
this.BankValidSrv(params,TRACE_ID.02);
Map outPutParamorData = this.method.getOutPutParams();
Time EndTime = System.GetCurrentTime();
LogSericeData(ServiceID, ‘DataValidSrv’, StartTime , EndTime, inputParams, outPutParams);
}注：業務系統也可以采用類似AOP模式進行調用信息攔截后統一記錄。
服務鏈監控的展示
圖片
對于服務鏈監控，集成平臺可以根據記錄的TRACE_ID信息進行關聯，形成服務鏈展示樹，業務系統提供UUID值，即可以查看到完整的服務調用鏈，并看到每個服務實例調用的時間。當然，對于服務鏈監控仍然可以參考上篇博文中談到的進行可視化的圖形樹狀結構展示。
當前為了展示方便，主流的服務鏈監控基本都是參與表格+樹狀展開的模式進行展示。
端到端流程監控
基于接口的跨系統流程概述
在這里的端到端流程監控特指跨系統交互業務流程，即一個完整的端到端流程跨越多個系統，多個系統之間通過接口交互來實現協同。一個完整的端到端流程如下：
圖片
如上圖，一個完整的企業內部自建電商平臺，在完成一個B端客戶的訂單下達，執行和交付的時候，需要跨越電商平臺，CRM系統，物流平臺，SAP-ERP系統和第三方支付平臺，第三方的物流平臺來共同完成。
那么在下達一個訂單后，當前的流程究竟走到了哪里？是否已經完成支付，訂單是否已經傳遞到ERP系統，訂單是否已經安排配送，訂單當前的物流配送是否完成，訂單是否已經被客戶簽收等，整合是上面端到端流程里面的關鍵接口交互點。
即：如果一個接口點正常執行完，那么說明業務流已經走到下個階段。
而對于類似上圖的跨多個系統的端到端流程，我們往往希望跟蹤一個訂單當前執行到哪個階段，具體什么狀態，那么核心的關鍵字就是訂單編號，可以看到后續的支付，物流，配送，訂單執行等相關接口，接口的輸入信息中都會有訂單編號這個關鍵字。
跨系統交互流程建模
可視化接口交互流程設計
從前面分析可以看到，可以通過接口交互分析來倒推流程。因此我們可以對接口交互流程進行可視化設計和建模。同時對所有的接入注冊到ESB服務總線進行管理。
由于接口服務都通過ESB服務總線進行封裝代理后接入，因此理論上說從實際業務服務調用實例數據和日志中是可以反推出來端到端的業務流程的，也就是可以通過服務實例和服務鏈的監控來間接的監控跨系統的業務流轉是否正常。
簡單來說，比如一個采購訂單，基于一個采購訂單號，我們實際上可以通過服務監控數據來分析到該訂單是否已經從采購系統導入到ERP，是否已經進行了報賬申請，是否已經進行了付款等，實際上這些信息從服務實例日志中都可以提取出來。
要完成這件事情，實際上有兩個關鍵點要做，即首先要對服務鏈本身進行進行服務鏈流程建模，其次是能夠對采集的日志的輸入輸出中能夠抓取出結構化的關鍵業務字段信息。只要做到這兩點，我們就很容易實現可視化的跨系統服務鏈監控功能。
在前面我們做ESB服務設計器的時候，已經已經剝離了原流程引擎中進行服務編排或可視化流程建模的能力。實際上這里的設計本身也就是一個多個服務編排設計的過程，將多個服務編排設計到一起。注意在這個過程中還需要允許有分支，也允許并行。服務鏈監控最終形成的也是一個完整的服務鏈監控樹。只是這個監控樹的形成是通過可視化的服務組合編排工具來實現的而已。
針對不同的跨系統業務監控，都需要針對不同場景設計不同的服務監控模型。
比如現在設計一個采購訂單服務鏈監控模型，我們可以對該模型進行簡化，具體如下通過建模工具形成如下模型樹。合同導入服務-》采購訂單導入服務-》采購接收服務-》報賬申請服務-》應付發票導入服務-》付款服務。
我們完全可以采用流程設計和建模工具來完成上圖的流程模型，當然如果采用類似支持BPMN標準的流程建模工具還可以進一步完成跨系統交互流程圖。
在這個跨系統交互流程圖中，銜接各個業務系統的仍然是相互之間的接口和服務，我們仍然是按照一個核心單據為基本元素來進行設計，比如項目編號，合同編號，采購訂單編號等。以這個編號來完成整個跨系統端到端流程的分析。
在建模的過程中，兩個系統間的連接線就是關鍵的接口服務，但是由于不是直接的服務間的連接，因此仍然需要建立服務之間的關聯性。比如我們整體跨系統監控都是以采購訂單號來進行跟蹤的話，我們就需要定義采購訂單這個元素在每一個接口服務中對應的XML-Element的位置，以確保這些服務之間本身能夠關聯起來。
整體我們看到實現的思路和服務鏈監控基本相同。
仍然是先根據業務關鍵字查詢功能，精確查詢出相關的服務實例數據。然后將服務實例數據映射到流程圖上面，形成流程圖實例。對于已經成功運行的服務標注為綠色，對于接口調用失敗的服務標注為紅色，對于還沒有執行到的服務標注為灰色。
同時更加有意義的事情是，我們完全可以來動畫效果模擬這個跨系統接口交互流程。即能夠動態的看到各個接口被觸發和調用的前后順序。同時看到前后接口觸發的大致時間間隔信息。通過這種實現能夠很方便我們實現圍繞核心業務對象的端到端流程監控能力。
當然這是一種變通的端到端流程監控實現思路，核心是先進行流程建模，然后再通過業務關鍵字檢索功能動態搜索匹配的服務日志調用數據，再對流程圖進行實例化解析。由于采用了Solr全文檢索能力，這個比我們完全自頂向下的來進行端到端流程監控實現更加高效。
業務日志采集和監控查詢
圖片
在前面有篇文章我們專門談到過基于Solr進行業務關鍵字查詢和報文日志全文檢索。而這個功能本身剛好用到服務鏈監控里面。即我們不再需要對服務運行報文數據全部進行結構化數據，而只需要對這些數據建立元數據索引信息，有了索引后Solr基本就可以快速的檢索和定位到具體的服務。
對于當前的服務日志，我們已經完成了將Blob結構的數據準實時的采集并提取索引信息，進入到Solr庫，實現了基于業務關鍵字的服務實例查詢能力，而原來我們只能基于服務實例號進行服務日志的查詢。
基于Solr查詢速度相當快，基本都是10多毫秒就能快速完成服務日志的檢索能力。在Solr實現了索引數據的創建，基于業務關鍵字的查詢能力后，接下來分析如何和服務鏈監控進行整合。
舉例來說，對于采購訂單服務鏈監控，進入該功能后我們直接輸入采購訂單號，然后基于訂單號我們做如下事情。
- 首先找到采購訂單服務鏈監控流程模板，然后基于流程模板知道涉及哪些服務。
- 找到流程模板中維護的Xpath檢索項
- 基于Xpath檢索項找的信息，拼裝Solr查詢關鍵字，然后進行Solr查找到對應服務日志記錄。
- 將服務日志記錄提取出來對應到流程實例具體的活動節點上面。
- 完成流程實例圖的顯示。
當我們點擊線條的時候可以查看到詳細的每筆接口服務調用日志信息。具體參考圖如下：
圖片
以上即是一個完整的基于Solr和ESB總線結合來實現端到端流程監控的一個技術實現思路。該功能已經在我們自研的ESB服務總線和IPaaS管控治理平臺得到實現，并得到很好的展現效果。
