所謂應用導圖，就是分布式應用內部組件的拓撲圖，該拓撲圖包含了組件連接成的網絡和節點間的信息交互。AppDynamics、OpenTracing以及Netsil等工具內部都使用了多種不同的應用導圖繪制方法，近期有文章針對這些方法進行了綜述。
可以把應用導圖看做一個圖，組件對應圖的節點，而組件間的交互對應圖的邊。這里說的組件，可以單指進程(同一機器內部)以及計算實例，或者二者的組合。如果是前者，進程間通信(IPC)就是圖的邊，而這種通信又是架構在后者構成的網絡之上。應用導圖有很多重要特征，例如執行實例分組、提供應用級別的詳細信息和錯誤率等關鍵度量指標的可視性等。
應用導圖之所以重要，主要是因為對內部組件的觀測、獲取組件的依賴信息等，都離不開應用導圖。應用導圖可以快速定位問題根因，加快甄別監控和告警中的關鍵路徑，同時，在數據驅動能力規劃和潛在的安全問題方面，應用導圖也可以發揮作用。
上述的文章總結了具體實踐中導圖的兩種常用制作方法，即靜態方法和動態方法，并詳述了動態方法。通過追蹤各種組件間的請求路徑，導圖生成軟件可以繪制出分布式應用的應用導圖。動態跟蹤技術包含了端到端跟蹤方式和個體跟蹤方式。
應用性能管理(APM)工具和代碼儀表盤SDK等工具都屬于端到端(E2E)跟蹤軟件，對這類工具來說，要么需要提供本地軟件代理，要么能夠直接修改遠程應用源碼，二者必選其一。AppDynamic、Dynatrace以及New Relic通過對代碼做profiling和跟蹤事務處理路徑來創建導圖。對APM工具來說，只要有新技術棧出現，就需要對其增加支持，這對新技術棧的廣泛傳播帶來了較大的挑戰。OpenTracing、Datadog APM以及AWS X-Ray這三個工具在發送請求時，會把唯一ID和元數據夾裹到請求消息的頭部，來搜集組件間的相關性，以協助完成導圖的構建。
端到端跟蹤方式雖然可以跟蹤到請求的精準路徑，但代價巨大，因為追蹤過程中會產生海量的數據，入侵威脅也會在路徑集成時被引入，因為入侵不會影響到性能，所以這種入侵也不易被察覺。但是像Zipkin等工具已經專注于分析性能的微小波動了。
個體追蹤(也指Ingress和Egress)有兩類數據源，即日志文件跟蹤和系統級跟蹤，這兩類數據源相比動態方法中的技術棧來說波動較小，較為穩定。由于工作在網絡層，個體跟蹤技術可以把在網絡上通信的組件一一進行繪制，也可以處理那些通過E2E方式不能追蹤到的組件。但是，這種方法也有弊端，那就是由于其內在的低層次特征，在請求的生命周期內產生的特定數據包的上下文對于這種追蹤方式來說并不明顯，而且獲取上下文的復雜性對于不同的應用軟件來說不一樣。所以這種方法對經過加密的調用請求無能為力，同時，為了找到數據和上層業務內部事務執行過程之間的相關性，引入深度的包檢測機制是非常必要的。
查看英文原文：A Comparison of Mapping Approaches for Distributed Cloud Applications
京公網安備 11010502049343號