一種自適應(yīng)微服務(wù)追蹤系統(tǒng)

金越成

（上海金融期貨信息技術(shù)，上海 200122）

0 引言

單體架構(gòu)轉(zhuǎn)向微服務(wù)架構(gòu)不只是部署的變化，其會(huì)從業(yè)務(wù)分析、業(yè)務(wù)域劃分、服務(wù)開發(fā)、上線部署、線上運(yùn)維等多方面都帶來挑戰(zhàn)。微服務(wù)架構(gòu)分布式軟件系統(tǒng)具有以下特點(diǎn)：節(jié)點(diǎn)規(guī)模龐大、系統(tǒng)結(jié)構(gòu)與組件依賴關(guān)系復(fù)雜、規(guī)模不斷增長[1]。

尤其是在線上運(yùn)維中，出現(xiàn)異常報(bào)警的時(shí)候如何快速定位故障問題，單體架構(gòu)下直接查看日志分析就可以滿足，但是在微服務(wù)架構(gòu)中，一項(xiàng)業(yè)務(wù)通常需要經(jīng)過多個(gè)服務(wù)鏈條，如果依然沿用查看日志分析的方法，就需要登錄到不同的機(jī)器去查看日志，這無疑增加了工作難度，且如果有日志中心，看到的日志是多段的無法排序的。這樣就導(dǎo)致微服務(wù)架構(gòu)下出現(xiàn)了比較典型的兩個(gè)問題：

（1）一個(gè)請求經(jīng)過服務(wù)鏈條上的多項(xiàng)服務(wù)時(shí)，其中出現(xiàn)了一個(gè)調(diào)用失敗的問題，且只能判斷有異常，具體的異常是哪個(gè)服務(wù)引起的就需要進(jìn)入每一個(gè)服務(wù)里面看日志，這樣的排障效率是非常低的；

（2）一個(gè)請求經(jīng)過一系列服務(wù)之后最終返回錯(cuò)誤或者超時(shí)，但各服務(wù)都正常運(yùn)行，且無法判斷是哪個(gè)服務(wù)響應(yīng)時(shí)間過長，因此需要查看每個(gè)服務(wù)的日志文件，但無法確定服務(wù)調(diào)用的時(shí)間和時(shí)長[2]。

1 分布式跟蹤體系

1.1 分布式跟蹤體系簡介

谷歌在2010年4月發(fā)表了一篇論文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，介紹了分布式追蹤的幾個(gè)概念：

（1）追蹤Trace就是由分布的微服務(wù)協(xié)作所支撐的一個(gè)事務(wù)，一個(gè)追蹤包含為該事務(wù)提供服務(wù)的各個(gè)服務(wù)請求；

（2）跨度Span是事務(wù)中的一個(gè)工作流，一個(gè)Span包含了時(shí)間戳、日志和標(biāo)簽信息，而Span之間包含父子關(guān)系或者主從關(guān)系；

（3）跨度上下文Span Context是支撐分布式追蹤的關(guān)鍵，它可以在調(diào)用的服務(wù)之間傳遞，上下文的內(nèi)容包括諸如從一個(gè)服務(wù)傳遞到另一個(gè)服務(wù)的時(shí)間、追蹤的ID，還有其他需要從上游服務(wù)傳遞到下游服務(wù)的信息[3]。

（4）行業(yè)標(biāo)準(zhǔn)，OpenTracing是個(gè)標(biāo)準(zhǔn)化組織，提高了不同廠商間的互操作性，只要遵循OpenTracing標(biāo)準(zhǔn)，企業(yè)可以根據(jù)需要替換具體的追蹤產(chǎn)品。

（5）主流的分布式追蹤組件，zipkin、skywalking、jaeger都符合這個(gè)標(biāo)準(zhǔn)且具有很好的兼容性。

但這些產(chǎn)品的引入都對業(yè)務(wù)系統(tǒng)有侵入，需要應(yīng)用重新發(fā)版本，而且無法滿足所有需求，需要進(jìn)行二次開發(fā)。

1.2 設(shè)計(jì)目標(biāo)、場景

設(shè)計(jì)目標(biāo)：當(dāng)出現(xiàn)問題的時(shí)候能夠快速地定位；對業(yè)務(wù)透明，業(yè)務(wù)不需要強(qiáng)依賴；可擴(kuò)展，將來的運(yùn)維需求可以放在里面。

場景及存在的問題如下。

（1）場景1：可以迅速發(fā)現(xiàn)日志異常并定位發(fā)生點(diǎn)。

當(dāng)前問題：目前有HTTP層的應(yīng)答碼規(guī)范、微服務(wù)框架層有明確的錯(cuò)誤碼定義，但網(wǎng)關(guān)的錯(cuò)誤信息不夠詳細(xì)。

（2）場景2：將調(diào)用鏈信息和日志信息結(jié)合起來，迅速還原異常發(fā)生時(shí)的分布式場景。

當(dāng)前問題：微服務(wù)框架目前在Log記錄方面內(nèi)容比較詳細(xì)，會(huì)自動(dòng)記錄日志，但是在Trace方面存在短板。微服務(wù)框架埋點(diǎn)生成的trace日志，在排序方面難以滿足分布式需求(跨組件日志穿插)，在深度方面不夠深入，存在引入的第三方組件沒有支持的問題。

（3）場景3：可以迅速發(fā)現(xiàn)并定位性能問題。

當(dāng)前問題：目前最外層Controller層打印了耗時(shí)信息，但是內(nèi)部的調(diào)用關(guān)系（模塊間調(diào)用、中間件調(diào)用）和耗時(shí)信息缺乏，導(dǎo)致只能定位接口級別的性能問題，定位粒度較粗。保障有工具進(jìn)行了一些Metric的監(jiān)控（例如Redis），但基本是以分鐘為粒度去監(jiān)控，定位能力有限。

（4）場景4:希望能夠看到完整的線上依賴關(guān)系視圖。

當(dāng)前問題：目前的日志能夠體現(xiàn)依賴關(guān)系，但是存在如下問題，即只有部分系統(tǒng)升級到了新的日志版本，依賴關(guān)系不全，依賴關(guān)系的粒度比較粗(服務(wù)→URL,服務(wù)->URL)，無法形成端到端的URL級別的依賴關(guān)系（URL->URL）[4]。

（5）場景：對日志、追蹤等的完善版本盡快生效。

當(dāng)前問題：業(yè)務(wù)系統(tǒng)目前對于日志等組件是強(qiáng)依賴關(guān)系(依賴于微服務(wù)框架的整體升級)，由于業(yè)務(wù)系統(tǒng)本身的升級頻率不一、測試成本高等問題，很難推動(dòng)業(yè)務(wù)系統(tǒng)進(jìn)行微服務(wù)框架的整體升級，治理需求在線上系統(tǒng)的收斂速度慢、生效周期長。

（6）場景：避免應(yīng)用的版本對日志等治理組件強(qiáng)依賴。

當(dāng)前問題：目前由于是這種強(qiáng)依賴關(guān)系，導(dǎo)致應(yīng)用升級日志組件需要整體升級微服務(wù)框架。

（7）場景：架構(gòu)治理組件不能引起太多性能降低。

當(dāng)前問題；目前性能影響不大。

（8）場景：使用標(biāo)準(zhǔn)的模型，避免在設(shè)計(jì)上擠牙膏，定位到容器pod。

當(dāng)前問題：目前根據(jù)可見需求自己定義了一套trace體系，但是從演進(jìn)過程來看較SkyWalking提煉過的模型差距較大[5]。

1.3 創(chuàng)新點(diǎn)

（1）對業(yè)務(wù)完全無侵入引入Agent的方式。官方的Skywalking Agent需要修改pom添加對應(yīng)的包依賴及修改日志配置，應(yīng)用需要重新發(fā)版本。

（2）支持日志模型擴(kuò)展，通過日志中心能夠看出日志塊的調(diào)用順序。

2 自適應(yīng)微服務(wù)追蹤插件方案

2.1 Java Agent技術(shù)簡介

利用Java Agent實(shí)現(xiàn)業(yè)務(wù)無侵入的目標(biāo)，JVM1.5以后支持在主程序前運(yùn)行Agent和主程序運(yùn)行后運(yùn)行Agent兩種模式。

（1）啟動(dòng)時(shí)調(diào)用Instrumentation的loadClass AndCallPremain方法，在這個(gè)方法中會(huì)調(diào)用JavaAgent里MANIFEST.MF指定的Premain-Class類的premain方法。

（2）運(yùn)行時(shí)修改主要是通過JVM的attach機(jī)制來請求目標(biāo)JVM加載對應(yīng)的Agent，調(diào)用InstrumentationImpl的loadClassAndCallAgentmain方法，在這個(gè)方法中會(huì)調(diào)用JavaAgent中MANIFEST.MF指定的Agentmain-Class類的Agentmain方法。

2.2 Skywalking簡介

Skywalking是Apache孵化的產(chǎn)品，是專門為微服務(wù)架構(gòu)和云原生架構(gòu)系統(tǒng)而設(shè)計(jì)并且支持分布式鏈路追蹤的APM系統(tǒng)。其通過加載非侵入探針的方式收集應(yīng)用中的調(diào)用鏈路信息，并對采集的調(diào)用鏈路信息進(jìn)行分析，生成應(yīng)用間關(guān)系、服務(wù)間關(guān)系以及服務(wù)指標(biāo)。其支持多種語言，包括Java,.Net,PHP，Python，Node.js, C++。使用此系統(tǒng)需要在代碼的pom中顯示引入的依賴，然后在日志配置文件中使用相應(yīng)的插件，最大的問題是需要應(yīng)用升級發(fā)布新的版本。

2.3 實(shí)現(xiàn)原理

自適應(yīng)微服務(wù)追蹤插件的核心理念是業(yè)務(wù)無侵入，基于字節(jié)碼增強(qiáng)技術(shù)實(shí)現(xiàn)無侵入Agent服務(wù)治理能力，業(yè)務(wù)無需修改代碼即可實(shí)現(xiàn)服務(wù)追蹤、運(yùn)維等需求。自定義Agent作為JVM層的切面，在進(jìn)行跨組件調(diào)用的時(shí)候會(huì)記錄事件，在日志中打印調(diào)用鏈信息，然后異步上報(bào)到管理端。自定義Agent作為Skywalking Agent和業(yè)務(wù)代碼的橋梁，需要將應(yīng)用中顯示的依賴放在自定義Agent中，日志配置插件也不用顯示修改，在運(yùn)行時(shí)進(jìn)行動(dòng)態(tài)替換（圖1）。

圖1 Agent 示例

插件有以下核心優(yōu)勢：

（1）代碼無侵入、業(yè)務(wù)無感知，即業(yè)務(wù)無需對程序代碼做任何修改，只需在應(yīng)用啟動(dòng)項(xiàng)添加Agent參數(shù)即可；

（2）運(yùn)維需求下移，即運(yùn)維上請求進(jìn)出標(biāo)志位，日志分層需求下移到基礎(chǔ)設(shè)施層；

（3）模塊化設(shè)計(jì)，使業(yè)務(wù)可按需加載、卸載功能模塊及升級。

（4）日志模型擴(kuò)展，目的是實(shí)現(xiàn)通過日志中心查看日志能夠看出調(diào)用順序。

2.3.1 Trace 擴(kuò)展模型在日志中的應(yīng)用

TraceID：TraceID是一次請求唯一的標(biāo)識，被應(yīng)用日志和skywalking日志共用。

sqn：擴(kuò)展字段，用來標(biāo)識分布式環(huán)境下調(diào)用層級和調(diào)用順序。規(guī)則是從1開始順序遞增，每增減一個(gè)點(diǎn)號代表多一層調(diào)用，如1.1 是1.1.1的parent，2表示在1后面執(zhí)行的（圖2）。

圖2 模型擴(kuò)展

2.4 傳統(tǒng)環(huán)境到云環(huán)境的自適應(yīng)

在傳統(tǒng)環(huán)境中，每臺虛機(jī)都部署一個(gè)Agent客戶端，在應(yīng)用的啟動(dòng)腳本中添加引用Agent的腳本。對開發(fā)測試人員無感知，運(yùn)維人員線上運(yùn)維變更只需一鍵就可開啟所有應(yīng)用的追蹤。在容器環(huán)境中，Agent通過hostpath掛卷到node節(jié)點(diǎn)上，云平臺屏蔽了掛卷及啟動(dòng)加載的細(xì)節(jié)，對開發(fā)應(yīng)用透明。

實(shí)施步驟：

（1）啟動(dòng)腳本修改，-javaagent:/java_agent/leo_agent/myAgent.jar -javaagent:/java_agent/skywalking_agent/skywalking-agent.jar=agent.service_name=serviceName；

（2）配置文件修改，增加默認(rèn)skywalking collector的地址sky.coll.com:8080；

（3）選擇c o l l e c t o r 的存儲(chǔ)模式e s 7，配置elasticsearch的地址、用戶名、密碼；

（4）配置域名，在客戶端服務(wù)器上/etc/hosts配置域名sky.coll.com對應(yīng)的IP。

3 結(jié)語

傳統(tǒng)金融行業(yè)的特點(diǎn)是對安全性的要求特別高，這就導(dǎo)致了業(yè)務(wù)系統(tǒng)對升級基礎(chǔ)框架特別謹(jǐn)慎。由于應(yīng)用使用各個(gè)框架版本不同，甚至跨度很大，通過在基礎(chǔ)框架中的埋點(diǎn)打印運(yùn)維日志的功能實(shí)施難度太大，難以快速地在線上環(huán)境推動(dòng)調(diào)用鏈跟蹤落地。使用這種自適應(yīng)微服務(wù)追蹤技術(shù)可以解決以上問題，同時(shí)還可以提升線上環(huán)境排障效率，快速定位錯(cuò)誤。