當(dāng)顧客在蘇寧易購(gòu)下單出現(xiàn)異常時(shí)，問題究竟出在會(huì)員系統(tǒng)、價(jià)格系統(tǒng)、庫(kù)存系統(tǒng)、支付系統(tǒng)……？技術(shù)人員面對(duì)復(fù)雜的系統(tǒng)構(gòu)成與系統(tǒng)交互，如果在缺乏有效的監(jiān)控機(jī)制情況下，想準(zhǔn)確高效的定位問題是很困難的。

我們可以想象到一般大促保障的場(chǎng)景：系統(tǒng)負(fù)責(zé)人和技術(shù)人員在現(xiàn)場(chǎng)通過拉取業(yè)務(wù) / 系統(tǒng)日志進(jìn)行問題排查，耗費(fèi)大量工時(shí)后才發(fā)現(xiàn)根因，僅僅是一條 SQL 語(yǔ)句遲遲沒有返回導(dǎo)致。

但究竟是什么原因?qū)е碌哪?？是網(wǎng)絡(luò)問題、數(shù)據(jù)庫(kù)服務(wù)端問題、還是客戶端問題？……由于大促保障需要的是 時(shí)效性，如何能夠 快速發(fā)現(xiàn)問題并精準(zhǔn)定位根因所在 成為關(guān)鍵，因此蘇寧云跡調(diào)用鏈監(jiān)控系統(tǒng)（以下簡(jiǎn)稱 HIRO）應(yīng)運(yùn)而生。

把用戶發(fā)起的每次請(qǐng)求生成一個(gè)全局 ID（以下統(tǒng)稱為 TraceId），通過它們將不同系統(tǒng)采集的日志按照時(shí)序和調(diào)用邏輯串起來，組成一條條鏈路，這就是 調(diào)用鏈。調(diào)用鏈監(jiān)控系統(tǒng)就是用這種技術(shù)來理解系統(tǒng)行為用于分析性能問題的一種工具。

調(diào)用鏈監(jiān)控系統(tǒng)是基于網(wǎng)絡(luò)調(diào)用日志的分布式跟蹤系統(tǒng)，它可以分析網(wǎng)絡(luò)請(qǐng)求在各個(gè)分布式系統(tǒng)之間的調(diào)用情況，從而得到處理請(qǐng)求的調(diào)用鏈上的入口 URL、應(yīng)用、服務(wù)的調(diào)用關(guān)系，從而找到請(qǐng)求處理瓶頸，定位錯(cuò)誤異常的根源位置。

同時(shí)，業(yè)務(wù)方也可以在調(diào)用鏈上添加自己的業(yè)務(wù)埋點(diǎn)日志，使各個(gè)系統(tǒng)的網(wǎng)絡(luò)調(diào)用與實(shí)際業(yè)務(wù)內(nèi)容得到關(guān)聯(lián)。

在實(shí)際應(yīng)用中，每一個(gè)請(qǐng)求過來后，會(huì)經(jīng)過多個(gè)業(yè)務(wù)系統(tǒng)并留下足跡，并產(chǎn)生對(duì)各種 Cache 或 DB 的訪問，但是這些分散的數(shù)據(jù)對(duì)于問題排查，或是流程優(yōu)化都幫助有限。

對(duì)于這么一個(gè)跨進(jìn)程 / 跨線程的場(chǎng)景，匯總收集 并 分析海量日志 就顯得尤為重要。具體要求能夠做到：

• 追蹤每個(gè)請(qǐng)求的完整調(diào)用鏈路

• 收集調(diào)用鏈路上每個(gè)服務(wù)的性能數(shù)據(jù)

• 計(jì)算性能數(shù)據(jù)和比對(duì)性能指標(biāo)（SLA）

• 在出現(xiàn)故障后能精確的給出有問題的鏈路詳情并且精確報(bào)警甚至給出解決此故障的一般性方法。

• 應(yīng)用運(yùn)行時(shí)突然發(fā)現(xiàn)執(zhí)行某一個(gè)服務(wù)耗時(shí)很長(zhǎng)，此時(shí)希望能夠有一種方式定位運(yùn)行時(shí)代碼各個(gè)部分的耗時(shí)，以確定耗時(shí)點(diǎn)在什么地方

• 應(yīng)用運(yùn)行時(shí)一切正常，絕大部分情況下服務(wù)運(yùn)行都非常順暢，但有用戶反饋，當(dāng)傳入 xxx 參數(shù)時(shí)，服務(wù)響應(yīng)非常緩慢，此時(shí)希望能夠有一種方式針對(duì)特定的方法入?yún)碛^察代碼執(zhí)行情況

• 一個(gè)業(yè)務(wù)邏輯比較復(fù)雜的程序方法，在運(yùn)行時(shí)無法確定具體調(diào)用了哪些邏輯以及調(diào)用時(shí)序，此時(shí)希望能夠有一種方式詳細(xì)地展現(xiàn)出方法執(zhí)行的具體邏輯、時(shí)序等

中間件研發(fā)中心從 2015 年開始著手研究調(diào)用鏈的相關(guān)技術(shù)，截至 2017 年 7 月底 HIRO 已經(jīng)承載了 530 個(gè)系統(tǒng)，其中核心系統(tǒng)超過 60 個(gè)。

HIRO 能夠分析分布式系統(tǒng)的每一次系統(tǒng)調(diào)用、消息發(fā)送和數(shù)據(jù)庫(kù)訪問，從而精準(zhǔn)發(fā)現(xiàn)系統(tǒng)的瓶頸和隱患。目前每天經(jīng)過 HIRO 分析的鏈路總量超過億條，監(jiān)控日志峰值達(dá) 500 萬消息 / 秒。

HIRO 有如下特性：

• 它是基于字節(jié)碼、日志的分布式跟蹤系統(tǒng)

• 侵入性低，安全穩(wěn)定

• 基于大數(shù)據(jù)分析

• 安裝部署簡(jiǎn)單，Agent 自動(dòng)升級(jí)

• 每次請(qǐng)求都生成全局唯一的 TraceId，通過 TraceId 將不同系統(tǒng)采集的日志串在一起，組成調(diào)用鏈

• 支持對(duì)部分 C/C++ 系統(tǒng)場(chǎng)景的調(diào)用穿透

• 支持業(yè)界主流的 Java 應(yīng)用服務(wù)器，包括：WildFly、WebSphere Application Server、WebLogic、Tomcat 等

• 支持多種數(shù)據(jù)庫(kù)和緩存，包括：MySQL、Oracle、DB2、Redis 等

• 支持消息中間件 Kafka，MQ（JMS Base）

• 支持蘇寧內(nèi)部 RPC 框架（RSF）

HIRO 整體分為四層，從底層到前端分別是：

• 第一層：在各應(yīng)用服務(wù)器上埋點(diǎn) Agent 并用 Flume 采集所有埋點(diǎn)的日志

• 第二層：用 Spark 對(duì)日志進(jìn)行分析和統(tǒng)計(jì)

• 第三層：把計(jì)算結(jié)果保存在 Elasticsearch 中

• 第四層：前端 Portal 的展示

具體架構(gòu)如下圖所示：

與之相對(duì)應(yīng)的，HIRO 內(nèi)部共分為三大塊，分別是 Agent、Spark 實(shí)時(shí)計(jì)算和 Spark 離線計(jì)算。其各部組件如圖所示：

在前端請(qǐng)求到達(dá)服務(wù)器時(shí)，應(yīng)用容器在執(zhí)行實(shí)際業(yè)務(wù)處理之前，會(huì)先執(zhí)行埋點(diǎn)邏輯。埋點(diǎn)邏輯為這個(gè)前端請(qǐng)求分配一個(gè)全局唯一的 TraceId，然后把它放在一個(gè)調(diào)用上下文對(duì)象中，該對(duì)象會(huì)存儲(chǔ)在 ThreadLocal 里面。

調(diào)用上下文里還有一個(gè) ID 非常重要，在 HIRO 中被稱作 RpcId，它用于區(qū)分同一個(gè)調(diào)用鏈下的 多個(gè)網(wǎng)絡(luò)調(diào)用 的發(fā)生順序和嵌套層次關(guān)系。

當(dāng)執(zhí)行業(yè)務(wù)處理時(shí)需要發(fā)起 RPC 調(diào)用時(shí)，蘇寧 RPC 遠(yuǎn)程服務(wù)框架 (以下簡(jiǎn)稱 RSF) 會(huì)首先從當(dāng)前線程 ThreadLocal 上面獲取之前 HIRO 設(shè)置的調(diào)用上下文。

然后，把 RpcId 遞增一個(gè)序號(hào)。在 HIRO 里使用多級(jí)序號(hào)來表示 RpcId，比如前端剛接到請(qǐng)求之后的 RpcId 是 0，那么它第一次調(diào)用 RPC 服務(wù) A 時(shí)，會(huì)把 RpcId 改成 0.1。之后，調(diào)用上下文會(huì)作為附件隨這次請(qǐng)求一起發(fā)送到遠(yuǎn)程的 RSF 服務(wù)器。

RSF 服務(wù)端收到這個(gè)請(qǐng)求之后，會(huì)從請(qǐng)求附件里取出調(diào)用上下文，并放到當(dāng)前線程 ThreadLocal 上面。

如果服務(wù) A 在處理時(shí)，需要調(diào)用另一個(gè)服務(wù)，這個(gè)時(shí)候它會(huì)重復(fù)之前提到的操作，唯一的差別就是 RpcId 會(huì)先改成 0.1.1 再傳過去。

服務(wù) A 的邏輯全部處理完畢之后，RSF 在返回響應(yīng)對(duì)象之前，會(huì)把這次調(diào)用情況以及 TraceId、RpcId 都打印到它的訪問日志之中，同時(shí)會(huì)從 ThreadLocal 清理掉調(diào)用上下文。

下圖展示的是埋點(diǎn)和生成日志的時(shí)序關(guān)系：

下圖展示的是多個(gè)系統(tǒng)間的調(diào)用關(guān)系：

輸出日志時(shí)面臨如下挑戰(zhàn)：

• 需要減少對(duì)業(yè)務(wù)線程的影響，降低資源消耗

• QPS 越高日志產(chǎn)生越快，監(jiān)控?cái)?shù)據(jù)就越多

對(duì)此，HIRO 的解決方案如下：

• 異步線程寫日志

• 無鎖循環(huán)日志，按秒刷新

• 對(duì)日志大小做限制，對(duì)調(diào)用鏈做采樣，不破壞調(diào)用鏈構(gòu)成

• 日志文件按大小滾動(dòng)，自動(dòng)清理

調(diào)用鏈的日志分散在調(diào)用經(jīng)過的各個(gè)服務(wù)器上，離線分析需要將同一條鏈路上的日志匯總在一起。HIRO 用 Flume 去采集全量的日志，經(jīng)過 Kafka 集群，最終全量存儲(chǔ)在 HDFS 中。

由于實(shí)時(shí)收集的日志上的鏈路都是分散的、斷斷續(xù)續(xù)的，這時(shí)需要通過 SparkStreaming 的計(jì)算功能，把相同的 TraceId 的鏈路分揀出來，組裝成一條完整的鏈路。

下面給出了一個(gè)典型的調(diào)用鏈圖示（由于鏈路太過龐大只能截取一小部分）：

根據(jù)重組后鏈路中的應(yīng)用、服務(wù)以及相互間關(guān)系進(jìn)行數(shù)據(jù)建模，將分析出來的數(shù)據(jù)在應(yīng)用層面和服務(wù)層面上統(tǒng)計(jì)出錯(cuò)誤數(shù)、訪問量、最大耗時(shí)和平均耗時(shí)、依賴度等。

同時(shí)利用  Elasticsearch 可以對(duì) DB、Redis、RSF、ESB 做大盤分析，還可以統(tǒng)計(jì)出各個(gè)應(yīng)用的報(bào)表和對(duì)比統(tǒng)計(jì)。

下圖展示了一條鏈路分析后統(tǒng)計(jì)的數(shù)據(jù)：

下圖展示了 DB 分析的結(jié)果：

下圖展示了應(yīng)用數(shù)據(jù)報(bào)表統(tǒng)計(jì)的結(jié)果

上圖是蘇寧生產(chǎn)環(huán)境的某一條實(shí)際鏈路。用戶收到告警：某個(gè)應(yīng)用訪問失敗。通過 HIRO，可以清晰地看到該應(yīng)用當(dāng)前一條鏈路的詳情，這是因?yàn)榈讓拥囊粋€(gè) HTTP 請(qǐng)求返回 404 導(dǎo)致訪問失敗。

HIRO 不僅僅是用來做問題定位，還可以防范問題。如下圖所示，HIRO 管理員發(fā)現(xiàn)易購(gòu)上的一條交易耗時(shí)較長(zhǎng)引起警覺，通過 HIRO 的深入排查 沒有發(fā)現(xiàn)鏈路上有問題。

但是謹(jǐn)慎起見把該耗時(shí)數(shù)據(jù)發(fā)給業(yè)務(wù)方，并提出是否由于配置不當(dāng)或者當(dāng)前系統(tǒng)壓力過大導(dǎo)致耗時(shí)過長(zhǎng)的疑問，業(yè)務(wù)方根據(jù)此思路排查系統(tǒng)修改了相關(guān)參數(shù)后，耗時(shí)恢復(fù)到正常水平，避免了可能發(fā)生的系統(tǒng)故障。

當(dāng)用戶懷疑系統(tǒng)的業(yè)務(wù)流程有問題或者不是用戶預(yù)想的調(diào)用場(chǎng)景，HIRO 也可以派上用場(chǎng)。如下圖所示，前臺(tái)銷售系統(tǒng)數(shù)據(jù)處理有問題，客戶懷疑是否是調(diào)用流程出錯(cuò)，用 HIRO 查看拓?fù)浜螅l(fā)現(xiàn)調(diào)用少了一層，很快就定位到是哪段代碼的 bug 并及時(shí)修復(fù)。

HIRO 可以統(tǒng)計(jì)出服務(wù)調(diào)用的次數(shù)，用戶能看到應(yīng)用是否有大量無用調(diào)用的情況，從而反向檢查代碼，提高代碼的品質(zhì)。

如下圖所示，Redis 應(yīng)用性能下降，經(jīng)過 HIRO 的分析，發(fā)現(xiàn)是某個(gè)應(yīng)用短期內(nèi)頻繁訪問導(dǎo)致的，經(jīng)過代碼分析，最終找到根本原因：業(yè)務(wù)邏輯出錯(cuò)了，bug 修復(fù)后問題隨之解決。

如果對(duì)同一個(gè)前端入口的多條調(diào)用鏈做匯總統(tǒng)計(jì)，也就是說，把這個(gè)入口 URL 下面的所有調(diào)用按照調(diào)用鏈的樹形結(jié)構(gòu)全部疊加在一起，就可以得到一個(gè)新的樹形結(jié)構(gòu)（如下圖所示）。這就是入口下面所有依賴的調(diào)用路徑的情況。

這種分析能力對(duì)于復(fù)雜的分布式環(huán)境調(diào)用關(guān)系的梳理尤為重要。傳統(tǒng)的調(diào)用統(tǒng)計(jì)日志是按固定時(shí)間窗口預(yù)先做了統(tǒng)計(jì)的日志，上面缺少了鏈路細(xì)節(jié)導(dǎo)致沒辦法對(duì)超過兩層以上的調(diào)用情況進(jìn)行分析。

例如，后端數(shù)據(jù)庫(kù)就無法評(píng)估數(shù)據(jù)庫(kù)訪問是來源于最上層的哪些入口，每個(gè)前端系統(tǒng)也無法清楚確定當(dāng)前入口由于大促活動(dòng)流量翻倍，會(huì)對(duì)后端哪些系統(tǒng)造成多大的壓力，需要分別準(zhǔn)備多少機(jī)器。有了 HIRO，這些問題就會(huì)迎刃而解。

HIRO 在蘇寧才剛剛起步，但是已經(jīng)向用戶展示了其強(qiáng)大的功能。為了進(jìn)一步滿足用戶對(duì) HIRO 的需求，未來 HIRO 將陸續(xù)完善和提供如下功能：

• 進(jìn)一步優(yōu)化實(shí)時(shí)數(shù)據(jù)的處理機(jī)制，使得時(shí)延更低，達(dá)到真正的實(shí)時(shí)

• 完善實(shí)時(shí)的錯(cuò)誤發(fā)現(xiàn)及報(bào)警機(jī)制，進(jìn)一步提高發(fā)現(xiàn)問題的及時(shí)性

• 接入更多的中間件，進(jìn)一步豐富調(diào)用鏈內(nèi)容，使調(diào)用鏈更長(zhǎng)更完整

• 借助深度學(xué)習(xí)算法，充分運(yùn)用數(shù)據(jù)挖掘技術(shù)把 HIRO 產(chǎn)出的數(shù)據(jù)價(jià)值化，力爭(zhēng)在更多維度上提供出有價(jià)值的分析數(shù)據(jù)

• 提供各種 API 接口，將 HIRO 數(shù)據(jù)開放出來，方便用戶可以構(gòu)建自己的調(diào)用鏈系統(tǒng)，從而達(dá)到對(duì)業(yè)務(wù)監(jiān)控的效果

朱健榮，現(xiàn)任職于蘇寧云商 IT 總部。主要負(fù)責(zé)中心產(chǎn)品推廣和技術(shù)保障工作。在蘇寧，經(jīng)歷了多次 818、雙 11 等大促保障工作，深知應(yīng)用系統(tǒng)的穩(wěn)定對(duì)電商平臺(tái)的重要性?，F(xiàn)正在和研發(fā)團(tuán)隊(duì)一起建設(shè)應(yīng)用系統(tǒng)監(jiān)控層整體解決方案，已經(jīng)落地的產(chǎn)品有服務(wù)端和調(diào)用鏈監(jiān)控、智能告警和決策分析平臺(tái)等。

今日薦文

點(diǎn)擊下方圖片即可閱讀

京東金融私有云 HTTPS 性能優(yōu)化實(shí)踐

---