天機閣——全鏈路跟蹤系統設計與實現

由架構師的修煉之路發表于手機遊戲
2022-01-04

簡介鏈路跟蹤系統：鏈路跟蹤是天機閣的核心，它負責採集、儲存和分析 rpc 呼叫的 trace 資料、指標資料和日誌資料，實現快速故障定位、鏈路梳理的功能，見圖 6 的藍色部分

傳說中天機閣裡有一臺掌控世間一切的機器，萬物執行由此產生。本文的“天機閣”是一個基於鏈路跟蹤的監控系統，後臺開發人員能夠透過“天機閣”洞察“天機”，快速解決問題。

為了支撐日益增長的龐大業務量，業界大量使用微服務架構。服務按照不同的維度進行拆分，網際網路應用構建在不同的軟體模組集上，這些軟體模組可能是由不同的團隊開發、可能使用不同的程式語言來實現、可能布在了幾千臺伺服器，橫跨多個不同的資料中心，分散式系統變得日趨複雜。

如何快速進行故障定位？如何準確進行容量評估？如何動態展示服務的鏈路？如何進行系統性能最佳化？這是分散式系統給後臺開發同學帶來的四大挑戰。業界都是透過鏈路跟蹤系統來解決以上問題，然而騰訊在鏈路跟蹤方面比較欠缺。為了填補此空白，“天機閣”系統橫空出世。

“天機閣”透過採集、儲存、分析分散式系統中的 trace 資料、指標資料和日誌資料，完成全鏈路跟蹤，從而解決上述問題。目前天機閣接入了 1200+ 個服務，trace 資料上報峰值 500 萬 / 分鐘，指標資料上報峰值 1。3 億 / 分鐘，日誌資料每天 30T。如此海量的資料天機閣是怎樣處理的？天機閣的鏈路跟蹤是怎樣實現的？又是怎樣做到低侵入，低開銷的？這些問題本文將一一為您揭秘。

背景

微服務崛起讓系統越來越複雜

如摘要所述，企鵝電競也採用微服務架構。圖 1 是企鵝電競首頁介面的依賴關係圖，這張圖大家可能看不清楚，看不清楚才是正常的，因為系統依賴的服務太多了。這種情況下一個請求涉及幾十個服務，若其中某個關鍵服務出現了失敗，只知道有異常，但具體的異常在哪個服務引起的就需要進入每一個服務裡面看日誌，這樣的處理效率是非常低的。

圖 1：企鵝電競首頁介面拓撲圖

後臺開發的痛

微服務的好處不用多說，然而微服務也是一把雙刃劍，其壞處就是系統太複雜，後臺開發者面臨著以下四大問題。

1、故障定位難：一次請求往往需要涉及到多個服務，這些服務很可能是由多個團隊負責的。一旦出問題，只知道有異常，但具體的異常在哪個服務引起的就需要進入每一個服務裡面看日誌，這樣的處理效率是非常低的。最壞的情況可能要拉上多個團隊一起定位。

2、容量評估難：企鵝電競每個月都就有好幾場推廣活動。活動形式還經常變化，導致流量入口經常不同。企鵝電競有 500 多個模組，不同入口的流量導致各模組的 qps 增量是不同的，容量評估是一件難事。接入天機閣之前，企鵝電競的每次大型上量活動都需要 2 個開發同學花一整天的時間來做容量評估，事倍功半。

3、鏈路梳理難：一個新人加入後臺團隊，他在這個微服務體系中接手一個模組，根本不知道自己身在何處，不知道自己的系統被誰依賴了，也不知道自己的系統下游依賴哪些服務，需要看文件，一行行根據程式碼來分析，費時費力。

4、效能分析難：一個服務依賴於後臺多個服務，如果某介面的耗時突然增加，開發得從自己開始，逐步分析各依賴介面的耗時情況。

業界解決方案

業界都是用分散式鏈路跟蹤系統來解決上述問題。Dapper 是谷歌生產環境下的分散式跟蹤系統，算得上各大鏈路跟蹤系統的鼻祖。2010 年穀歌發表了 Dapper 的論文，之後各大網際網路公司紛紛參照 dapper 的思想推出各自的鏈路跟蹤系統。包括 Twitter 的 Zipkin，韓國人的 pinpoint，Apache 的 HTrace，阿里的鷹眼 Tracing、京東的 Hydra、新浪的 Watchman 等。

我們的出路

騰訊在鏈路跟蹤這塊比較薄弱，需要儘快填補這個空白。以上幾款鏈路跟蹤系統都各自滿足了鏈路追蹤的功能，但落實到我們自己的生產環境中時，這些 Trace 系統存在諸多問題。谷歌“dapper”和阿里“鷹眼”並不開源。Pinpoint 和 zipkin 已經開源，然而 pinpoint 透過位元組碼注入的方式實現呼叫攔截和資料收集，僅能用於 java 伺服器，Zipkin 沒有 C++ 的版本，並且功能不夠用。最終我們選擇用 zipkin 的協議，參照阿里鷹眼的架構自建一套騰訊內通用的鏈路跟蹤系統 —— 天機閣。

天機閣介紹

天機閣是什麼

天機閣是一個以分散式鏈路跟蹤為核心的監控系統。它透過採集、儲存、分析分散式系統中的呼叫事件資料，再結合壓測資料和 TNM2 資料，實現故障診斷、容量評估以及系統梳理等多種功能，大大降低開發人員的運維挑戰，見圖 2。資料採集架構圖見圖 11。

圖 2：天機閣功能示意圖

注：“呼叫事件資料”包括“trace 資料”、“指標資料”、“日誌資料”三種。

trace 資料——指鏈路跟蹤的 span 資料，主要用於鏈路跟蹤、還原、繪製拓撲圖。

指標資料——指 rpc 的模調資料，包括分鐘級別的 rpc 請求量、成功率、延時分佈、錯誤碼分佈等等。

日誌資料——業務日誌。

天機閣有些啥功能

1。故障定位：天機閣利用跟蹤資料，可以還原呼叫鏈，再結合日誌資料，可以快速實現故障定位。例如：使用者投訴他的影片點贊數不對，開發同學可以根據使用者 qq 號碼找到投訴使用者的請求 trace。檢視 trace 詳情就能很清楚的看到該請求在獲取點贊結果的時候超時了，開發同學可以迅速完成定位並處理。Ui 介面見圖 3。

圖 3：trace 跟蹤 ui 介面

2。鏈路梳理：有了跟蹤資料，畫出業務拓撲圖就是水到渠成，圖 4 是企鵝電競某服務的拓撲圖。

圖 4： rpc 呼叫生成樹

3。容量評估：天機閣的鏈路跟蹤系統，能拿到各服務的呼叫拓撲圖。指標資料統計模組能拿到 rpc 指標資料，tnm2 系統能獲得服務的部署資訊，根據這些資訊。壓測系統能壓測出各 svr 的性瓶頸。根據以上資料，天機閣能精確的評估出各服務的部署是否合理。若遇到大型活動，開發者只需提供入口介面的 qps 增量，天機閣就能預估出後續各依賴服務的 qps 增量，並給出推薦擴容資料。

圖 5：容量評估結果

4。效能分析：天機閣的壓測系統能壓測出單服務的效能資料，結合鏈路跟蹤以及指標統計資料，能很好的分析出整個系統的效能瓶頸，找出最佳化方向。

5。其他功能：除以上 4 個功能外，天機閣還有實時告警，過載保護，名字服務，指標資料查詢等多個實用功能，歡迎大家到天機閣系統體驗。體驗地址：http：//tjg。oa。com （天機閣擔心資料被意外修改或者洩漏，許可權沒有全員開放，感興趣的同學可以找 alexzeng 申請許可權）。

天機閣總體架構

天機閣包含鏈路跟蹤、壓測系統、容量管理系統、名字服務四大系統，總體架構見圖 6。

鏈路跟蹤系統：鏈路跟蹤是天機閣的核心，它負責採集、儲存和分析 rpc 呼叫的 trace 資料、指標資料和日誌資料，實現快速故障定位、鏈路梳理的功能，見圖 6 的藍色部分。

壓測系統：提供自動壓測能力，目的是找出各服務的效能瓶頸，見圖 6 左上角。

容量管理系統：本系統結合 trace 資料、指標資料、壓測資料和 tnm2 資料，實現精準的容量評估功能，見圖 6 粉色部分。

名字服務：這個就不多說了。

圖 6：天機閣總體架構

鏈路跟蹤的技術實現

鏈路跟蹤的原理

Rpc 呼叫場景說明

首先來看一個簡單的 rpc 呼叫鏈場景（見圖 7），一個請求透過接入層 cgi 呼叫下游的 svr1，然後 svr1 先呼叫服務 svr2，拿到結果後再呼叫 svr3，最後組合 svr2 和 svr3 的結果，透過 cgi 返回給使用者。這裡發生了 3 次 rpc，我們用①②③④⑤⑥表示了 RPC 的順序，怎麼做到跟蹤還原呢？

簡單地說，天機閣利用 rpc 框架，在每次 rpc 的起點和終點進行資料上報。用 Jstorm 對上報的資料進行實時處理並存入 hbase。管理端分析 hbase 資料進行視覺化展示，以達到鏈路跟蹤的目的。

圖 7：簡單的 rpc 呼叫場景

trace 上報資料說明

在天機閣跟蹤樹結構中，每個服務介面是一個節點，節點之間的連線就是 span（跨度）。Span 是鏈路跟蹤系統中的主要資料結構，它記錄了 rpc 主調節點和被調節點之間的關係。 Span 包含資料如下：

traceID：一次業務請求會分配一個唯一的 TraceID， rpc 的時候，框架會透過帶內資料的方式吧 TraceID 傳遞到下游 svr，本請求涉及的所有 rpc 上報的 span 擁有同一個唯一的 2。 TraceID，系統可以透過 TraceID 把所有 rpc 的 span 關聯起來，形成一個 span 集合。

SpanID：span 的 ID，每個合併 span 在一個 traceId 下有唯一的 SpanID。為了方便後續處理，一個 rpc 的“主調 span”和“被調 span”擁有相同的 spanID，見圖 8 相同顏色的 span 的 spanID 相同。

parentID：父 span 的 id，rpc 呼叫有層級關係，所以 span 作為呼叫關係的儲存結構，也有層級關係，就像圖 8 所示，跟蹤鏈是採用跟蹤樹的形式來展現的，樹的根節點就是呼叫的頂點。所以，頂級 span 的 parentId=0，拿圖 8 所展現的例子來說，cgi 請求 svr1 的 span 就是頂級 span，spanID=1，parentid=0。 svr1 請求 svr2 的 span 是頂級 span 的子 span，spanID=2，parentid=1。而 svr1 請求 svr3 的也是定級 span 的子 span，spanID=3，parent=1。很顯然 span2 和 span3 是平級關係。這樣就可以把 rpc 集合還原成呼叫樹了。

Event（事件）：除了呼叫樹，開發者還很關心 rpc 的時間關係以及耗時資訊。為此，我們定義了 4 個 rpc 日誌事件：

a。 client 傳送資料：client send 簡稱 cs

b。 client 收到回包：client recv 簡稱 cr

c。 server 收到資料：server recv 簡稱 sr

d。 server 傳送回包：server send 簡稱 ss

“主調 span”會包含 cs 和 cr 的時間點， “被調 span”會上報 sr 和 ss 時間點。“合併 span”擁有以上 4 個事件時間點。有了這些時間點，幾乎所有階段的耗時都可以計算出來。

Name：介面名字，記錄本次 rpc 呼叫是 server 的哪個介面。

Result：呼叫結果，rpc 的返回值，一般 0 標識成功。

Caller：主調資訊，包括主調 svr 名字，IP

Callee：被調資訊，包括被調 svr 名字，IP、port

其他資訊： span 結構體中，還會儲存一些方便分析問題的其他資訊，但這些資訊不影響鏈路跟蹤，這裡就不詳述了。

trace 上報過程說明

說到這裡，大家對 span 的印象可能還是有點模糊不清，於是我們繼續拿圖 7 的服務呼叫來舉例，如果我們將圖 7 的應用接入天機閣，將會看到圖 8 的效果

圖 8：span 上報細節

一個完整 span 既包含 client 資料，也包含 server 資料，所以一個完整 span 要分兩次上報。rpc 的起點上報的資料稱為“主調 span”，rpc 的終點上報資料稱為“被調 span”， “主調 span”和“被調 span”也叫子 span。子 span 在 jstorm 實時計算的時候，合併成“合併 span”儲存到 hbase，上報過程見圖 8。圖中一共 3 次 rpc，共上報 6 個子 span，這 6 個子 span 在計算層合併成 3 個合併 span，詳細過程如下：（前方高能預警，這個過程比較複雜，對上報過程不感興趣的同學可以跳過）。

a。第 1 個子 span：cgi 在發起 rpc 前，生成一個 client span， traceId=111111， spanid=1， parented=0（沒有父 span）。並將這 3 個 ID 透過帶內資料的方式傳遞給 svr1。等 cgi 收到 svr1 的回包後，補全 span 的事件時間：cs=t1， cr=t12，並上報主調 span。見圖 10 中 cgi 上報的“主調 span”。

b。第 2 個子 span：svr1 從請求資料中解出 client span，生成一個“被調 span”， “被調 span”的三個 ID 跟起點 span 一樣，traceId=111111， spanid=1， parented=0。 Svr1 傳送回包給 cgi 後，就補全時間時間 sr=t2， ss=t11，並上報“被調 span”，見圖 10 中 svr1 上報的“被調 span”。

c。第 3 個子 span：svr1 在發起 svr2 的 rpc 前，生成一個 client span， traceId=111111， spanid=2（每個“主調 span”生成一個新的 spanid）， parented=1（以本 svr 的“被調 span”的 id 當 parentId）。並將這 3 個 ID 透過帶內資料的方式傳遞給 svr2。等 cgi 收到 svr2 的回包後，補全 span 的事件時間：cs=t3， cr=t6，並上報“主調 span”。見圖 10 中 svr1 上報的 spanid=2 的“主調 span”。

d。第 4 個子 span：svr2 參照第 2 步，上報 spanid=2 的被調 span。

e。第 5 個子 span：svr1 參照第 3 步，上報 spanid=3 的主調 span。

f。第 6 個子 span：svr3 參照第 4 步，上報 spanid=3 的被調 span。

trace 還原說明

天機閣可以從 hbase 中查出所有 spanid=111111 的 span。再透過 spanid 和 praentID，可以還原呼叫樹。還能計算各種耗時。例如：

Cgi 的請求總耗時 = span1。cr - span1。cs = t12 - t1

（注：span1 指 spanid=1 的“合併 span”）

圖中①的網路耗時 = span1。sr - span1。cs= t2 – t1

Svr1 的呼叫 svr2 的耗時 = span2。cr - span2。cs = t6-t3

Svr1 的呼叫 Svr3 的耗時 = span3。cr - span3。cs = t10-t7

時間差修正

需要注意的是，span 的時間戳精確到毫秒，各機器存在一定的時間誤差。這個誤差會導致耗時計算不太準確。天機閣透過以下辦法，在展示結果的時候進行透過以下兩步進行時間修正（參見圖 9）。

保證每個 span 的 cs，sr，ss，cr 四個時間點是嚴格順序的，也就是保證 t1

若 t1

t2=t1+（（t4-t1）-（t3-t2））/2 t3=t4-（（t4-t1）-（t3-t2））/2

注：以上修正是假設圖 9 中①的耗時跟②的耗時相當。實踐證明這個假設效果不錯。

圖 9：時間差修正

鏈路跟蹤架構

天機閣的架構跟阿里鷹眼 2016 年的架構類似，分為資料採集、實時計算、資料儲存、離線分析四層，詳情如圖 10。

圖 10：天機閣鏈路跟蹤架構

資料採集

天機閣資料採集了 trace 資料、指標資料、業務日誌三類資料。分別儲存在 hbase、habo、es 和磁碟四種儲存上，見圖 11。

圖 11：天機閣資料採集架構

trace 資料：就是 1 所說的 span 資料，主要用於鏈路跟蹤、還原。儲存在 hbase 中。

指標資料：包括介面緯度的成功數、失敗數、返回碼、耗時分佈等指標資料，儲存在 habo 系統中。

業務日誌：業務日誌分冷、熱兩類，冷資料包括全量日誌，儲存在磁碟上。熱資料指鏈路跟蹤被取樣且發生錯誤的日誌，熱資料儲存在 es 系統中。

這三個資料相互配合，可以較好的完成監控和故障定位。首先，Jstorm 實時計算“指標資料”，發現異常後生成告警資訊，開發同學點選告警資訊，開啟鏈路跟蹤檢視，可以找出故障點。再檢視跟告警相關的業務日誌，就能大致定位到告警原因（參見圖 3）。

資料採集的重點是要做到低侵入和低開銷，只有滿足以上兩個設計要點，業務才有可能選擇接入天機閣。這裡重點討論一下天機閣的“trace 資料”是怎麼做到低侵入，低開銷的。

低侵入：低侵入比較簡單，天機閣選擇在 srf 框架底層做文章。增值產品部統一使用 srf 框架，業務升級新的 srf 框架，僅重編就能無痛接入天機閣。

低開銷：這裡的開銷是指“正在被監控的系統在生成追蹤和收集追蹤資料的消耗導致系統性能下降”，我們希望把這個開銷降低到可以忽略的程度。 “trace 資料”採集最大的開銷在於建立和銷燬 span，根 span 的建立和銷燬需要損耗平均 205 納秒的時間，而同樣的操作在其他 span 上需要消耗 172 納秒。時間上的差別主要在於需要在根 span 上給這次跟蹤分配一個全域性唯一的 ID。減少 span 的生成，能大大的降低開銷。天機閣透過以下 4 個手段保證重要事件不錯過的前提下，儘量降低開銷。

1。取樣上報：鏈路跟蹤並不需要所有請求都上報，天機閣一開始取樣率為 1/1024。這個簡單的方案在高吞吐量的服務上非常有效。但是這個取樣率在低吞吐量服務的上，容易錯過重要事件，其實低吞吐量的服務能接受更高的取樣率。最後我們用一個取樣期望率來標識單位時間內取樣的追蹤。這樣一來，低流量低負載自動提高取樣率，而在高流量高負載的情況下會降低取樣率，使損耗一直保持在控制之下。（注意：這裡的取樣率要求一次請求的多次 rpc 要麼都取樣，要麼都不採樣，不然鏈路就串不起來，天機閣在請求入口處進行取樣，取樣標識透過帶內資料往下游傳遞，保證一次請求用同一個取樣標識。）

2。染色上報：天機閣支援染色上報機制，目前推薦用 uin 染色，公司內部的號碼都會被取樣上報。

3。出錯上報：鏈路跟蹤的初衷是幫助開發者定位、分析問題，那麼請求出錯就很有必要上報了。出錯上報需要注意兩點。

a。防止雪崩：如果後端服務故障，會導致前端所有請求都被上報，可能因為上報消耗大量的效能，導致服務雪崩。為此，天機閣的資料上報設定了一個上限，每秒上報超過 50 條，就不再上報。

b。逆向生成：為了降低開銷，未取樣的 rpc 是不會生成 traceID 和 SpanID 的。若未取樣的 rpc 發生錯誤，需要從後往前逆向構造呼叫關係。這種情況天機閣會幫父 span 生成一個 id，並透過回包把父 spanid 傳遞給主調。主調據此來構造呼叫關係。值得一提的是隻有發生錯誤的分支才上報，未發生錯誤的分支會遺漏，跟蹤樹退化成一條跟蹤線。不過這個退化後的跟蹤線足夠定位問題了。

4。共享記憶體無鎖上報：上報 api 將需要上報的 Span 透過 jce 序列化成二進位制，寫入本地共享記憶體無鎖佇列中，然後由 agent 來消費共享記憶體批次上報到 kafka，共享記憶體無鎖佇列使用的是即通開源的高效能無鎖共享記憶體佇列，效能可達 800w/s。天機閣的無鎖程式設計細節見 KM 文章：天機閣——說說無鎖（Lock-Free）程式設計那些事。

效能損失驗證：開啟天機閣上報後，實測 qps 下降低於 3%。測試 server 的邏輯是讀取 cmem 小資料（大約幾個位元組）返回，比較簡單的操作。在 cpu 消耗差不多的情況下，qps 下降 2。9% 左右，詳細資料見下表。如果業務邏輯更復雜，這個操作的消耗佔比會更低，效能損耗會更不明顯。

圖 12：效能驗證表

實時計算

為什麼選擇 Jstorm

天機閣的計算層任務主要包括以下兩點：

把同一個 rpc 的起點 span 和終點 span 合併成一個合併 span，並存儲到 hbase 中。

按分鐘粒度的時間視窗統計指標資料，若發現異常，則通知告警服務。

其中第 2 點的實時性要求高，適合選用用流式計算引擎。透過下表的對比，當初我們選擇了 Jstorm（其實現在 Flink 在多個方面已經比 Jstorm 做得更好，我們計劃後續替換才 Flink）。

實時計算的挑戰

作為監控系統，需要做到實時性，一致性和確定性。

實時性比較好辦，Jstorm 天生就能滿足此要求，目前天機閣可以在 3 分鐘左右發出告警，比模調系統快 2 到 3 分鐘。

所謂一致性，是指 jstorm 處理的資料與 agent 上報的資料一致。要求系統具備自愈能力，比如 jstorm 重啟後，資料能夠被重新計算，監控曲線不能掉下來。天機閣為保證一致性，採取了以下措施。

多地部署，做到異地容災。

利用 zookeeper 保證 master 只有一個。

啟用 ack 機制，保證每條資料被正確的處理一次。

注：啟用 ack 的弊端也很明顯：jstorm 記憶體消耗明顯增大，jstorm 處理效能也會下降。目前天機閣的 jstorm 叢集機器不足，暫時關閉了 ack 機制。

什麼是確定性？舉個例子，jstorm 發現某一分鐘的請求量突然陡降，這時候我應該發報警，還是不發報警，為什麼我很難做這個抉擇，因為我不知道監控的物件真的出了問題，還是監控系統本身的流計算部分出了問題，流計算系統是不是哪裡卡住了，還是資料收集通道出現了問題。天機閣實現了一個齊全度演算法來完成確定性保障，它與 Apache Flink 中採納的 Snapshot 演算法有些近似。天機閣上報的資料帶有日誌時間， Jstorm 的時間視窗以日誌時間為準，如果下一分鐘的的日誌已經超過一定數量，我們認為前一分鐘的資料到齊，可以發出告警。

儲存選型

透過圖 11 我們可以看出，鏈路跟蹤主要儲存三種資料：trace 資料、指標資料、日誌資料。

Trace 資料的儲存有以下要求，經過對比，我們選擇用 hbase 來儲存 trace 資料。

容量大：目前每天上報量 1T，隨和天機閣推廣，還會倍增。

生命週期：trace 資料短時間有用，我們只儲存最近 10 天的資料，希望過期資料能自動淘汰。

高併發：trace 資料寫多讀少，需要支援高併發寫入的儲存。

支援按 key 讀寫：支援 traceID 為 key 存取資料。

指標資料的資料量更大，高峰期達到 1 億條 / 分鐘。為了方便檢視，指標資料必須支援多維度賽選，我們最終選擇 habo 來儲存指標資料。

日誌資料我們儲存在硬碟中。為了方便查詢，我們把 trace 相關的熱日誌儲存在 es 中。

指標資料的資料量更大，高峰期達到 1 億條 / 分鐘。為了方便檢視，指標資料必須支援多維度賽選，我們最終選擇 habo 來儲存指標資料。

日誌資料我們儲存在硬碟中。為了方便查詢，我們把 trace 相關的熱日誌儲存在 es 中。

容量評估的技術實現

原 SNG 服務部署大量使用虛擬機器，擴縮容流程重，時間長，然而業務卻經常搞大活動，微服務架構複雜，每次大活動前，都需要耗費開發資源進行架構梳理以及容量評估。為了解決這個痛點，天機閣實現了兩個容量評估方式。

基於入口的容量評估。

基於業務指標的容量評估。

基於入口的容量評估

天機閣能實現精準容量評估，得益於以下幾個要點：

鏈路跟蹤：能自動梳理出某入口的後續依賴關係。

壓測系統：能獲得各 server 的容量瓶頸。

指標統計：各介面的實際 qps 等指標資料。

Tnm 系統：這裡可以查詢各模組部署情況，和各機器的 cpu 消耗情況。

有了以上資料，我們能計算出各模組當前的容量是多少。開發同學進行容量評估時，只需要指定入口模組的請求增量，天機閣就能結合鏈路跟蹤，較準確的評估出後續各依賴模組的請求增量。評估出這些模組是否需要擴容，要擴容多少。那麼如何計算出各模組的請求增量？原理見圖 13。

圖 13：鏈路跟蹤拓撲圖以及傳導係數

上圖是天機閣透過鏈路跟蹤繪製的一個拓撲圖。圖中 A、B、C、D……分別代表一個服務。

線條上的數字 4w，代表該介面被調的頻率。比如 A 服務，每秒被呼叫 4 萬次。其中 A 服務每秒呼叫 D 服務 2 萬次， D 服務總共被調 3。8 萬次每秒。

圖中綠色數字代表傳導係數，比如 A 到 D 的傳導係數是 0。5。因為 A 被請求 4w 次每秒，A 就會主動呼叫 D 服務 2 萬次每秒。有了拓撲圖和傳導係數，那麼就能很容易的根據入口評估出後續服務的請求增量。如圖 13，假如 A 的請求增加 2 萬 / 秒的請求量。那麼後續服務將會增加紅色字型所描述的請求增量，見圖 14。