很多人認為，在微服務架構下，可視化變得不重要了，因為發生問題時，服務會自動降級、熔斷，容器會自動隔離、重生，似乎一切都可以自動化。然而很多實施了微服務改造的IT組織發現，隨著應用和服務數量的不斷增加，調用關系越來越復雜，遇到疑難雜癥還是需要運維強力支持，而且運維好微服務這個龐然巨獸，可視化至關重要。

本文將探討在分布式、微服務環境下的各種可視化實踐以及我們在這個領域的探索和成果，全文分為四個部分：

1. 什么是微服務
2. 微服務環境下運維的挑戰
3. 微服務可視化的最佳實踐
4. 全新的探索：IT數字地圖

全文約8千字，閱讀需要20分鐘。

1 什么是微服務

很多人了解微服務都是從Martin Fowler的這篇文章開始的：

在這篇文章中，Martin Fowler首次提出了微服務概念，并給出了簡單易懂的闡述：“微服務是一種架構模式，將一個大型應用程序劃分成一組小的服務，服務之間互相協調、互相配合。每個服務運行在獨立的進程中，服務與服務間采用輕量級通信協議，并能被獨立和自動化部署。”

簡而言之，微服務應用要具備三個特征：Small，Independently 和Automated。這三個特征所支撐的核心目標是：快！讓應用迭代更快、部署更快、發布更快！

2 微服務環境下，運維的挑戰

然而馬克思辯證唯物主義告訴我們，為解決某個問題而誕生的新事物，在流行并占據統治地位后，必然會出現它的負面影響。軟件開發同樣遵循這個規律。隨著企業進行微服務架構改造，單體式應用被打碎，傳統涇渭分明的垂直應用架構逐漸演變成一張巨大的服務調用網絡，應用的邊界變得模糊，調用關系也越來越復雜。

在微服務環境下，運維面臨更大的壓力：

• 調用鏈條變長，系統出現問題時，如何在復雜的服務調用關系中快速定位到出錯的節點？
• 應對突發流量需求，應對哪些服務擴容？
• 單服務容量變更后，如何評估對系統整體性能容量的影響？
• 微服務拆分導致故障點增多，如何進行故障預防和故障演練？

如何應對？瀏覽CNCF發布的云原生產品工具全景圖，我們發現有一類名叫“Observability”（“可觀察性”）的工具種類，包含prometheus、Grafana、Dynatrace、Datadog、Graphit、Librato等眾多工具。它們的主要職責，就是讓運維團隊更容易理解和駕馭微服務環境，即使服務集群的組成節點、依賴關系、流量分布以及外部邊界等都在快速變化，運維團隊依然能夠通過高度可視化系統，準確掌握系統的運行狀態。因為Observability貫串整個云原生體系，足以證明“可觀察性”在云原生體系中極高的地位。

本文不打算熬述這些工具的全部功能和技術原理，只挑選了一些可視化方面的優秀實踐進行剖析，并從中總結出管理微服務所需的可視化方案。

3 微服務可視化的最佳實踐

3.1 調用鏈路圖

在一次800多人的開發者調研中，當回答“構建一個高可用的分布式系統，您遇到的三個最大的難題是什么？”時，57%的開發者選擇了鏈路追蹤。為什么呢？

舉個簡單的例子，有一天我發財了，一高興給海春轉100億，但是在轉賬時，我的手機銀行卡死了！于是我給銀行客服打電話，客服一聽也慌了，立即call后臺運維。

運維人員怎么排查呢？對分布式系統的一次請求往往要調用多個服務，每個服務可能由不同的團隊開發，使用不同的編程語言，部署在不同的主機或容器上，分布在不同的數據中心。要查清楚一次訪問請求失敗到底是哪個服務導致是非常復雜的事情。

但再難查也得查啊，100億啊。怎么查？用鏈路圖！

所謂調用鏈路圖，就是從單筆交易請求視角，將該請求經過的所有服務接口以鏈路形式展現出來，同時展示每個服務接口調用的耗時和處理結果。最常見的可視化形式是瀑布流，以Zipkin為例：

通過這張圖，運維人員能夠清晰看到我這筆巨額轉賬請求的總耗時、調用了哪些服務接口、先后順序是怎樣的、每個服務接口的耗時和返回結果，這樣就能快速判斷出是卡在哪個接口了。

不過調用鏈路圖也不一定非長成瀑布流的樣子，比如Rocketbot就覺得瀑布流有很多問題，比如在時間線中顯示接口名就不行，因為如果時間線較長，則上下游接口隔的很遠，調用順序就不直觀，而如果時間線太短，又顯示不下接口名。另外瀑布流也無法體現接口調用的協議類型。

為了解決這些問題，Rocketbot結合了瀑布流和樹狀圖的特點，提供了一種更現代化的UI界面。具體做法是將服務接口與時間線剝離，效果如下：

這種效果已經非常棒了，不過Skywalking的最新版本中，又出現了一種更奇葩的展現形式。總體思路與Rocketbot類似，但采用了上下布局。這樣的好處是頂部的時間線更長，因此能顯示更大的時間窗口，中部的拓撲圖讓服務接口調用順序更加清晰。同時用不同的顏色標識不同的服務類型，讓人更容易理解服務接口的依賴關系，具體效果如下：

Skywalking的可視化好不好見仁見智，不過有些實用功能還是不錯的，比如，可以高亮出最慢的五個span（點擊Top 5 of slow span按鈕）：

還可以高亮出children最多的五個span（子children越多，服務調用就越慢）：

在這個截圖中，有一個包含13個children的span，這些children都是數據庫訪問，所以難怪這么慢！

總結一下：

從上面的例子我們會發現，如果要做單筆交易追蹤，那么調用鏈路圖是不可或缺的可視化工具，但由于數據粒度較細，需要一定的開發經驗，而且還要有traceId才能生成鏈路圖，所以使用起來不是很方便。它就像一個精致的外科手術刀，主要面向軟件開發或測試人員做交易追蹤及鏈路優化，不太適用于運維人員。

3.2 調用拓撲圖

運維人員需要什么圖呢？與外科手術不同，一線運維更像門診，他們每天都要面對大量告警，雖然大部分告警不用特別關注，可一旦有疑似業務交易問題時，就必須盡快完成故障確認和定界，為二、三線團隊做進一步診斷和處置留出時間（金融機構普遍要求30分鐘內解決故障）。因此，一線運維不用手術刀，他們需要更簡單、更直接（甚至粗暴）的故障診斷工具，而服務調用拓撲圖就是他們最重要的工具之一。

所謂調用拓撲圖，就是從更宏觀的交易類型視角，將涉及的服務組件、組件調用關系以及外部依賴以有向圖的形式展示出來，同時呈現每個服務的聚合指標（如，每分鐘的交易量和成功率、平均響應時間等），從而幫助運維人員定界故障。

舉一個相對真實的例子，有一天我給海春轉200塊錢，不幸的是我的手機銀行被卡住了，于是我給銀行客服打電話，銀行客服很淡定，讓我等幾分鐘后再試。后來鐘宏、任磊、大圣、王導、娜姐等眾人在轉賬時都出現掛死現象，這時銀行客服覺得不對勁了，向IT服務臺報警。一線運維接到告警后，會在第一時間打開“跨行轉賬”服務拓撲，我們以Appdynamics為例：

這個調用拓撲圖非常簡單直接，不需要交易流水和traceId，也不需懂代碼調用邏輯，只需要輸入交易類型（比如，跨行轉賬、網銀登陸），就能獲得完整的服務拓撲和每個服務的業務統計指標。比如上圖我們發現Transfer-Fulfillment服務發生了交易成功率告警，那么就有可能是這個服務異常導致大量用戶轉賬失敗。

總結一下：

雖然調用鏈路圖和調用拓撲圖都用于分布式鏈路追蹤，但調用鏈路圖更像手術刀，能夠從單筆交易視角展現服務接口的調用順序和處理時長。而調用拓撲圖更像門診，直接從交易類型的宏觀角度展現服務的調用順序和統計指標。所以，它們有各自的適用場景和用戶群體。

不過，不管是門診還是外科手術，都是事后排查。這肯定不夠，我們還需要定期對應用進行全方位的大保健，從而在問題發生前識別安全風險和故障隱患，這就需要更全局性的視圖，一個能夠體現分布式、微服務系統的整體架構和運維保障狀態的視圖。

3.3 應用架構可視化

應用架構圖是指從應用系統視角，展示應用系統包含的所有服務節點、部署單元、依賴的外部服務。

通過在應用架構圖上疊加管理和運行數據，能夠幫助我們開展監控覆蓋率分析、安全納管率分析、架構高可用分析、性能瓶頸分析、故障演練等各項運維保障工作。

架構可視化做的不錯的是阿里云的AHAS產品，根據不同角色對架構的關注重點不同，AHAS將架構可視化分為三個層次，從上到下依次為：進程層、容器層、主機層。

第一層：進程層（也可以理解為服務層）

進程層可以查看：

• 進程狀態：CPU、內存占用情況
• 進程類型：主要分為Java應用、Webf服務、消息隊列、數據庫、云服務等
• 網絡連接：包括入口連接（調用該進程的所有進程及端口）、出口連接（該進程調用的所有進程及其端口）

第二層：容器層

容器層可以查看：

• 容器信息：容器名稱、狀態、CPU、內存占用情況、重啟次數、IP地址、容器端口、所屬主機等
• 網絡連接：包括入口連接（調用該容器的所有容器及端口）、出口連接（該容器調用的所有容器及端口）

第三層：主機層

主機層可以查看：

• 主機狀態：CPU、內存占用情況
• 主機信息：主機名、OS版本
• 入口連接：調用該主機的所有主機及及端口
• 出口連接：該主機調用的所有主機及端口
• 容器鏡像：主機上存放的容器鏡像

不得不說，AHAS架構可視化是一款優秀的產品，很大程度解決了分布式環境下應用系統架構的混沌不可知問題。尤其在下面兩個方面要點贊：

1. 分層設計原則：軟件架構可視化的核心點是尋找在軟件體系結構中有意義的元素及關系，一款優秀的軟件架構可視化產品應該幫助用戶排除掉不重要的信息，給用戶呈現出對他們有價值的元素，特別是在微服務架構下龐大而復雜的調用關系鏈場景中。所以，阿里云將架構分為進程層、容器層、主機層是很有必要的。
2. 架構感知能力：為了最大限度上降低架構圖的繪制和維護成本，阿里云通過采集用戶主機上的進程和容器的元數據、監控數據以及網路數據，實現架構圖的自動構建。不過要使用這個功能就必須將應用部署在阿里云上，還要安裝AHAS Agent。

當然，再優秀的產品也有瑕疵，我認為這款產品最大的問題是架構布局能力較弱。畢竟架構圖是給人看的，要符合人的視覺習慣。但AHAS在這方面做的不夠，比如，無法體現兩地三中心的地理結構、無法按Web-App-DB的邏輯結構組織架構元素、沒有網絡分區、無法體現非云化組件、無法換圖標等。

在這方面，客觀上說優锘的DMV在架構布局方面就非常強，其繪圖的靈活性和便捷性甚至可以和Visio相媲美。比如下面是優锘DMV繪制的網絡拓撲圖和應用部署圖。

上面兩張圖，架構元素可以根據需要顯示在任意位置，以符合各種布局需求。多個架構元素可以組合成集群。另外，DMV還提供豐富的架構模板，只要輸入應用系統名稱，就能根據模板的布局規則自動生成架構圖。

3.4 全景應用墻

應用架構圖較好的滿足了單個應用系統的運維管控需求，但格局還是不夠。因為運維不僅關注個別應用的狀態，也要掌握所有應用系統的保障和運行狀態，這就需要全景應用墻了。

所謂全景應用墻，就是在一張巨大的“墻”上展示數據中心所有應用系統及其運行狀態。比如Servicenow的應用墻：

這個應用墻由一個個方塊組成，每個方塊表示一個應用系統。方塊的顏色表示該應用是否發生告警，方塊的大小則代表應用使用的資源規模，規模越大，方塊的面積越大。

全景應用墻常用來判斷是否出現全局性故障，如果互聯網出口、共享存儲、ESB等公共服務出現故障，應用墻往往呈現祖國山河一片紅的“盛況”，此時千萬別慌，不要花時間逐個檢查應用系統，趕緊排查網絡和共享服務。

ServiceNow的應用墻是我見過的第二棒的應用墻，雖然如此優秀，但也有幾個問題：

1. 當應用系統量太多的時候不好顯示，尤其是大型金融機構動輒幾百個應用系統的環境下
2. 業務領域和重要級別是比較重要的信息，但沒有很好的體現出來
3. 當應用有告警時，無法呈現告警應用的業務指標，也看不到與其他應用的關聯關系

針對這些問題，我們嘗試做了一些改進：

1、取消了用面積表達IT資源規模，因為對一線運維而言，首要關心的是應用有沒有告警，而不是資源的規模。同時，采用曲面屏設計，讓屏幕能夠容納更多的應用。

2、引入了“重要性”和“業務領域”等多個信息維度，用于快速篩選出關鍵應用系統。同時提供了多種呈現形式，比如應用星系圖就能很好的表達核心應用和外圍應用的關系。

3、在全景應用墻上，懸浮可顯示應用的關系，點擊應用就能查看應用的APM數據和CMDB數據。

可視化的四個層次

CNCF告訴我們，在分布式微服務環境下，可視化將在運維中扮演更重要的作用。通過分析國內外優秀的產品和實踐，我們發現可視化有脈絡可循，從微觀到宏觀可以分為四個層次，每個層次都有其適用場景和用戶角色：

這就是前面講述的所有內容。到這兒本應該結束了，但不知道大家發現沒有，有個地方似乎不太對？

理想上，這四層的可視化UI應該合成一個整體，但現在每個工具（不管是開源或商業）都是獨立的，可視化模塊與數據采集、分析緊耦合，比如，你要用Appdynamics的拓撲圖，就得用他的Agent，你喜歡AHAS的架構圖，就得上阿里云，你想用ServiceNow的應用墻，就要用它的SaaS服務。而且不同工具的數據無法互通，界面難以跳轉。原本我們希望引入可視化工具來提升運維效率，卻建設了一大堆分散獨立的工具，以及由此帶來的更多的數據孤島和操作手冊。

能否在這些工具之上構建一個統一的可視化界面，為用戶提供更加一致、方便和人性化的使用體驗呢？

4 IT數字地圖

IT數字地圖是我們構建統一IT管理界面的一個重要嘗試，這個想法最初來源于地圖。

在遠古時代，人類渺小，世界遼闊。有了地圖，人類才得以認知和征服了這個世界。現代社會，數字地圖在人們日常生活中發揮著日益重要的作用。每天我們都會使用地圖定位位置、探索周邊、規劃路徑，地圖已成為人們獲取各類生活信息的核心工具。

既然地圖在人們生活中能夠扮演如此重要的作用，那么在IT的世界，我們能否利用IT數字地圖來幫助我們更好的認知和管理這個世界呢？基于這個想法，我們開展了IT數字地圖的嘗試。

IT數字地圖充分借鑒了谷歌和百度地圖的設計思想，比如，分層設計、無縫縮放、局部加載、線路規劃和興趣點等等。

4.1 分層設計

我們知道，電子地圖是有層級的，一般分為：國家級、省級、市級和街道級。這種分層的好處不言而喻，信息簡潔易懂。

所以IT世界地圖也借鑒此設計，我們將IT地圖分為四大層級：業務架構層、應用架構層、部署架構層、資源運行層。

我們以金融行業為例：

第一層：業務架構層

業務架構是業務與IT的橋梁，定義了應用系統的業務能力，從概念層面幫助IT人員了解應用系統的定位、用途和重要性，在疊加APM監控數據后，也可以用來做多應用告警時的故障定界，因此我們將其作為IT世界地圖最頂層圖層。

業務架構圖的主要元素是業務領域、應用系統以及應用系統間的調用關系，示意如下：

第二層：應用架構層

應用架構用來描述應用系統的功能邊界，定義了應用系統由哪些服務組件構成，以及它們之間如何分工、協作。

應用架構圖一般有兩種風格，一種是按功能處理順序將系統分為Web前端、中間服務、后臺數據存儲，常見于傳統單體式應用架構。另一種是按業務類型劃分，比如支付服務、對賬服務、額度控制服務等，一般微服務應用是這種風格。

第三層：部署架構層

部署架構定義了應用程序如何安裝、部署到現實的IT環境中，以及數據如何在網絡中傳遞和保存。

部署架構圖應該體現部署的物理位置、網絡分區、部署單元、集群模式、訪問協議等等。

第四層：資源運行層

資源運行層用于展示應用程序部署完成后形成的資源實例，包括容器、主機、DB實例、MQ實例、NAS存儲實例、FW實例、SSL實例等等。

4.2 無縫縮放和局部加載

用過谷歌地圖的同學都知道可以通過縮放操作實現圖層切換，體驗是那么的順暢、自然。但只有看過《Google Maps的故事》才知道，這背后依靠的技術是Clipmapping。Clipmapping能把不同分辨率的圖像合并起來，在用戶進行縮放操作時提供“無縫”的體驗。1999年，Michael Jones、Chris等人首次將Clipmapping技術應用到地圖上（他們稱其為City-Fly），當時所有人都震驚了，原來地圖還可以做得這么炫！不過，除了炫酷外，City-Fly還實現了地圖數據的局部加載功能，即，用戶不必下載所有的數據就可以看到自己感興趣的內容，這就是“弱水三千，只取一瓢”。對于地圖這樣的海量數據而言，這項技術再合適不過了。

受到谷歌地圖的啟發，我們也投入大量精力研究如何將Clipmapping技術應用到IT數字地圖上。但現實地圖和IT地圖有一個巨大的差別，那就是現實世界中的物體有真實坐標且相對固定，所以不同比例的圖像可以事先繪制好。而IT世界的物體沒有坐標，還隨時在變！所有物體的位置都要用算法自動生成！在經過大量的實驗和挫折后，我們改變了Clipmapping的實現方法，將現實世界“下層坐標決定上層布局”的邏輯改成了IT世界“上層布局決定下層坐標”的邏輯。后來又經過無數次驗證，終于研發出適用于IT數字地圖的無縫縮放和局部加載技術，我們稱其為IT-Fly。

4.3 線路規劃 vs. 鏈路追蹤

只有無縫縮放和局部加載還不夠，為了增加IT數字地圖的使用價值，我們實現了鏈路追蹤功能。

鏈路追蹤的設計參考了數字地圖的路徑規劃功能。在數字地圖中，我們只要輸入目的地，數字地圖就會自動規劃出行路線。同樣，在IT數字地圖中，我們只要輸入交易碼或TraceId，就能在地圖中現實完整的調用路徑。

4.4 興趣點(POI)

光有路徑還不夠，我們在排障時還需要查看路徑中每個節點的信息。

借鑒數字地圖中POI（Point of Interest）的設計思想，一個POI可以是一棟房子、一個商鋪、一個郵筒、一個公交站等。每個POI包含四方面信息，名稱、類別、坐標。

我們在IT數字地圖中也引入了POI。每個POI都是一個IT管理對象，它包括四類信息：配置信息、指標信息、告警信息和工單信息。這些信息對于鏈路追蹤、性能優化、變更分析非常重要。

4.5 IT數字地圖的邊界

要在日常工作中使用IT數字地圖，就必須滿足不同管理場景的數據和功能需求。這就引出一個新問題，你的功能邊界在哪里？

我們認為，IT數字地圖應該定位成開放的地圖服務，就像百度、高德地圖一樣，既能獨立使用，也能嵌入到美團外賣、滴滴打車等應用中，這是IT數字地圖與其他運維可視化工具最大的區別。

對此，我們給出了三條產品原則，以確保IT數字地圖能夠按照既定的設想成長：

1. IT數字地圖只做數據可視化，不介入數據采集、處理和分析（這些能力由專業的運維工具提供）；
2. 為了降低構建成本、提升地圖效用，應重點打造的輔助功能包括：數據建模、數據接入、數據整合及大數據存儲能力，只有打通各個專業運維工具的數據孤島，才能實現一站式的數據可視化服務；
3. IT數字地圖應提供豐富的可視化API和URL調用能力，以方便其他運維工具使用并在此基礎上開發定制化功能。

基于這個設計原則，IT數字地圖的功能架構如下：

具體功能就不多說了，這是我們在IT數字地圖方面的一些實踐，目前還處于起步階段，還有很大的優化空間，歡迎大家批評指正。

寫在最后的話

在IT管理領域，IT數字地圖是全新的探索，國內外沒有類似產品可以借鑒。我們為什么要做這種前無古人的事情？

正如任正非所言：“我們對客戶需求的理解不能狹窄,不要以為客戶說出來的是需求. 其實客戶需求是一種邏輯學和哲學,是人性的持續激活與成長,是人類文明發展的必然趨勢。”

我們認為，IT數字地圖能夠給枯燥、繁瑣、危險的運維環境中帶來一絲人性，符合運維發展的必然趨勢。雖然現在只是一個遙遠的夢想，但優锘愿意為此奉獻自己的智慧和青春。可視化是一個偉大的事業，路漫漫其修遠兮，吾等上下而求索。