很多人認(rèn)為，在微服務(wù)架構(gòu)下，可視化變得不重要了，因?yàn)榘l(fā)生問(wèn)題時(shí)，服務(wù)會(huì)自動(dòng)降級(jí)、熔斷，容器會(huì)自動(dòng)隔離、重生，似乎一切都可以自動(dòng)化。然而很多實(shí)施了微服務(wù)改造的IT組織發(fā)現(xiàn)，隨著應(yīng)用和服務(wù)數(shù)量的不斷增加，調(diào)用關(guān)系越來(lái)越復(fù)雜，遇到疑難雜癥還是需要運(yùn)維強(qiáng)力支持，而且運(yùn)維好微服務(wù)這個(gè)龐然巨獸，可視化至關(guān)重要。

本文將探討在分布式、微服務(wù)環(huán)境下的各種可視化實(shí)踐以及我們?cè)谶@個(gè)領(lǐng)域的探索和成果，全文分為四個(gè)部分：

1. 什么是微服務(wù)
2. 微服務(wù)環(huán)境下運(yùn)維的挑戰(zhàn)
3. 微服務(wù)可視化的最佳實(shí)踐
4. 全新的探索：IT數(shù)字地圖

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

1 什么是微服務(wù)

很多人了解微服務(wù)都是從Martin Fowler的這篇文章開(kāi)始的：

在這篇文章中，Martin Fowler首次提出了微服務(wù)概念，并給出了簡(jiǎn)單易懂的闡述：“微服務(wù)是一種架構(gòu)模式，將一個(gè)大型應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合。每個(gè)服務(wù)運(yùn)行在獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級(jí)通信協(xié)議，并能被獨(dú)立和自動(dòng)化部署。”

簡(jiǎn)而言之，微服務(wù)應(yīng)用要具備三個(gè)特征：Small，Independently 和Automated。這三個(gè)特征所支撐的核心目標(biāo)是：快！讓?xiě)?yīng)用迭代更快、部署更快、發(fā)布更快！

2 微服務(wù)環(huán)境下，運(yùn)維的挑戰(zhàn)

然而馬克思辯證唯物主義告訴我們，為解決某個(gè)問(wèn)題而誕生的新事物，在流行并占據(jù)統(tǒng)治地位后，必然會(huì)出現(xiàn)它的負(fù)面影響。軟件開(kāi)發(fā)同樣遵循這個(gè)規(guī)律。隨著企業(yè)進(jìn)行微服務(wù)架構(gòu)改造，單體式應(yīng)用被打碎，傳統(tǒng)涇渭分明的垂直應(yīng)用架構(gòu)逐漸演變成一張巨大的服務(wù)調(diào)用網(wǎng)絡(luò)，應(yīng)用的邊界變得模糊，調(diào)用關(guān)系也越來(lái)越復(fù)雜。

在微服務(wù)環(huán)境下，運(yùn)維面臨更大的壓力：

• 調(diào)用鏈條變長(zhǎng)，系統(tǒng)出現(xiàn)問(wèn)題時(shí)，如何在復(fù)雜的服務(wù)調(diào)用關(guān)系中快速定位到出錯(cuò)的節(jié)點(diǎn)？
• 應(yīng)對(duì)突發(fā)流量需求，應(yīng)對(duì)哪些服務(wù)擴(kuò)容？
• 單服務(wù)容量變更后，如何評(píng)估對(duì)系統(tǒng)整體性能容量的影響？
• 微服務(wù)拆分導(dǎo)致故障點(diǎn)增多，如何進(jìn)行故障預(yù)防和故障演練？

如何應(yīng)對(duì)？瀏覽CNCF發(fā)布的云原生產(chǎn)品工具全景圖，我們發(fā)現(xiàn)有一類名叫“Observability”（“可觀察性”）的工具種類，包含prometheus、Grafana、Dynatrace、Datadog、Graphit、Librato等眾多工具。它們的主要職責(zé)，就是讓運(yùn)維團(tuán)隊(duì)更容易理解和駕馭微服務(wù)環(huán)境，即使服務(wù)集群的組成節(jié)點(diǎn)、依賴關(guān)系、流量分布以及外部邊界等都在快速變化，運(yùn)維團(tuán)隊(duì)依然能夠通過(guò)高度可視化系統(tǒng)，準(zhǔn)確掌握系統(tǒng)的運(yùn)行狀態(tài)。因?yàn)镺bservability貫串整個(gè)云原生體系，足以證明“可觀察性”在云原生體系中極高的地位。

本文不打算熬述這些工具的全部功能和技術(shù)原理，只挑選了一些可視化方面的優(yōu)秀實(shí)踐進(jìn)行剖析，并從中總結(jié)出管理微服務(wù)所需的可視化方案。

3 微服務(wù)可視化的最佳實(shí)踐

3.1 調(diào)用鏈路圖

在一次800多人的開(kāi)發(fā)者調(diào)研中，當(dāng)回答“構(gòu)建一個(gè)高可用的分布式系統(tǒng)，您遇到的三個(gè)最大的難題是什么？”時(shí)，57%的開(kāi)發(fā)者選擇了鏈路追蹤。為什么呢？

舉個(gè)簡(jiǎn)單的例子，有一天我發(fā)財(cái)了，一高興給海春轉(zhuǎn)100億，但是在轉(zhuǎn)賬時(shí)，我的手機(jī)銀行卡死了！于是我給銀行客服打電話，客服一聽(tīng)也慌了，立即call后臺(tái)運(yùn)維。

運(yùn)維人員怎么排查呢？對(duì)分布式系統(tǒng)的一次請(qǐng)求往往要調(diào)用多個(gè)服務(wù)，每個(gè)服務(wù)可能由不同的團(tuán)隊(duì)開(kāi)發(fā)，使用不同的編程語(yǔ)言，部署在不同的主機(jī)或容器上，分布在不同的數(shù)據(jù)中心。要查清楚一次訪問(wèn)請(qǐng)求失敗到底是哪個(gè)服務(wù)導(dǎo)致是非常復(fù)雜的事情。

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

所謂調(diào)用鏈路圖，就是從單筆交易請(qǐng)求視角，將該請(qǐng)求經(jīng)過(guò)的所有服務(wù)接口以鏈路形式展現(xiàn)出來(lái)，同時(shí)展示每個(gè)服務(wù)接口調(diào)用的耗時(shí)和處理結(jié)果。最常見(jiàn)的可視化形式是瀑布流，以Zipkin為例：

通過(guò)這張圖，運(yùn)維人員能夠清晰看到我這筆巨額轉(zhuǎn)賬請(qǐng)求的總耗時(shí)、調(diào)用了哪些服務(wù)接口、先后順序是怎樣的、每個(gè)服務(wù)接口的耗時(shí)和返回結(jié)果，這樣就能快速判斷出是卡在哪個(gè)接口了。

不過(guò)調(diào)用鏈路圖也不一定非長(zhǎng)成瀑布流的樣子，比如Rocketbot就覺(jué)得瀑布流有很多問(wèn)題，比如在時(shí)間線中顯示接口名就不行，因?yàn)槿绻麜r(shí)間線較長(zhǎng)，則上下游接口隔的很遠(yuǎn)，調(diào)用順序就不直觀，而如果時(shí)間線太短，又顯示不下接口名。另外瀑布流也無(wú)法體現(xiàn)接口調(diào)用的協(xié)議類型。

為了解決這些問(wèn)題，Rocketbot結(jié)合了瀑布流和樹(shù)狀圖的特點(diǎn)，提供了一種更現(xiàn)代化的UI界面。具體做法是將服務(wù)接口與時(shí)間線剝離，效果如下：

這種效果已經(jīng)非常棒了，不過(guò)Skywalking的最新版本中，又出現(xiàn)了一種更奇葩的展現(xiàn)形式?？傮w思路與Rocketbot類似，但采用了上下布局。這樣的好處是頂部的時(shí)間線更長(zhǎng)，因此能顯示更大的時(shí)間窗口，中部的拓?fù)鋱D讓服務(wù)接口調(diào)用順序更加清晰。同時(shí)用不同的顏色標(biāo)識(shí)不同的服務(wù)類型，讓人更容易理解服務(wù)接口的依賴關(guān)系，具體效果如下：

Skywalking的可視化好不好見(jiàn)仁見(jiàn)智，不過(guò)有些實(shí)用功能還是不錯(cuò)的，比如，可以高亮出最慢的五個(gè)span（點(diǎn)擊Top 5 of slow span按鈕）：

還可以高亮出children最多的五個(gè)span（子children越多，服務(wù)調(diào)用就越慢）：

在這個(gè)截圖中，有一個(gè)包含13個(gè)children的span，這些children都是數(shù)據(jù)庫(kù)訪問(wèn)，所以難怪這么慢！

總結(jié)一下：

從上面的例子我們會(huì)發(fā)現(xiàn)，如果要做單筆交易追蹤，那么調(diào)用鏈路圖是不可或缺的可視化工具，但由于數(shù)據(jù)粒度較細(xì)，需要一定的開(kāi)發(fā)經(jīng)驗(yàn)，而且還要有traceId才能生成鏈路圖，所以使用起來(lái)不是很方便。它就像一個(gè)精致的外科手術(shù)刀，主要面向軟件開(kāi)發(fā)或測(cè)試人員做交易追蹤及鏈路優(yōu)化，不太適用于運(yùn)維人員。

3.2 調(diào)用拓?fù)鋱D

運(yùn)維人員需要什么圖呢？與外科手術(shù)不同，一線運(yùn)維更像門(mén)診，他們每天都要面對(duì)大量告警，雖然大部分告警不用特別關(guān)注，可一旦有疑似業(yè)務(wù)交易問(wèn)題時(shí)，就必須盡快完成故障確認(rèn)和定界，為二、三線團(tuán)隊(duì)做進(jìn)一步診斷和處置留出時(shí)間（金融機(jī)構(gòu)普遍要求30分鐘內(nèi)解決故障）。因此，一線運(yùn)維不用手術(shù)刀，他們需要更簡(jiǎn)單、更直接（甚至粗暴）的故障診斷工具，而服務(wù)調(diào)用拓?fù)鋱D就是他們最重要的工具之一。

所謂調(diào)用拓?fù)鋱D，就是從更宏觀的交易類型視角，將涉及的服務(wù)組件、組件調(diào)用關(guān)系以及外部依賴以有向圖的形式展示出來(lái)，同時(shí)呈現(xiàn)每個(gè)服務(wù)的聚合指標(biāo)（如，每分鐘的交易量和成功率、平均響應(yīng)時(shí)間等），從而幫助運(yùn)維人員定界故障。

舉一個(gè)相對(duì)真實(shí)的例子，有一天我給海春轉(zhuǎn)200塊錢(qián)，不幸的是我的手機(jī)銀行被卡住了，于是我給銀行客服打電話，銀行客服很淡定，讓我等幾分鐘后再試。后來(lái)鐘宏、任磊、大圣、王導(dǎo)、娜姐等眾人在轉(zhuǎn)賬時(shí)都出現(xiàn)掛死現(xiàn)象，這時(shí)銀行客服覺(jué)得不對(duì)勁了，向IT服務(wù)臺(tái)報(bào)警。一線運(yùn)維接到告警后，會(huì)在第一時(shí)間打開(kāi)“跨行轉(zhuǎn)賬”服務(wù)拓?fù)?，我們以Appdynamics為例：

這個(gè)調(diào)用拓?fù)鋱D非常簡(jiǎn)單直接，不需要交易流水和traceId，也不需懂代碼調(diào)用邏輯，只需要輸入交易類型（比如，跨行轉(zhuǎn)賬、網(wǎng)銀登陸），就能獲得完整的服務(wù)拓?fù)浜兔總€(gè)服務(wù)的業(yè)務(wù)統(tǒng)計(jì)指標(biāo)。比如上圖我們發(fā)現(xiàn)Transfer-Fulfillment服務(wù)發(fā)生了交易成功率告警，那么就有可能是這個(gè)服務(wù)異常導(dǎo)致大量用戶轉(zhuǎn)賬失敗。

總結(jié)一下：

雖然調(diào)用鏈路圖和調(diào)用拓?fù)鋱D都用于分布式鏈路追蹤，但調(diào)用鏈路圖更像手術(shù)刀，能夠從單筆交易視角展現(xiàn)服務(wù)接口的調(diào)用順序和處理時(shí)長(zhǎng)。而調(diào)用拓?fù)鋱D更像門(mén)診，直接從交易類型的宏觀角度展現(xiàn)服務(wù)的調(diào)用順序和統(tǒng)計(jì)指標(biāo)。所以，它們有各自的適用場(chǎng)景和用戶群體。

不過(guò)，不管是門(mén)診還是外科手術(shù)，都是事后排查。這肯定不夠，我們還需要定期對(duì)應(yīng)用進(jìn)行全方位的大保健，從而在問(wèn)題發(fā)生前識(shí)別安全風(fēng)險(xiǎn)和故障隱患，這就需要更全局性的視圖，一個(gè)能夠體現(xiàn)分布式、微服務(wù)系統(tǒng)的整體架構(gòu)和運(yùn)維保障狀態(tài)的視圖。

3.3 應(yīng)用架構(gòu)可視化

應(yīng)用架構(gòu)圖是指從應(yīng)用系統(tǒng)視角，展示應(yīng)用系統(tǒng)包含的所有服務(wù)節(jié)點(diǎn)、部署單元、依賴的外部服務(wù)。

通過(guò)在應(yīng)用架構(gòu)圖上疊加管理和運(yùn)行數(shù)據(jù)，能夠幫助我們開(kāi)展監(jiān)控覆蓋率分析、安全納管率分析、架構(gòu)高可用分析、性能瓶頸分析、故障演練等各項(xiàng)運(yùn)維保障工作。

架構(gòu)可視化做的不錯(cuò)的是阿里云的AHAS產(chǎn)品，根據(jù)不同角色對(duì)架構(gòu)的關(guān)注重點(diǎn)不同，AHAS將架構(gòu)可視化分為三個(gè)層次，從上到下依次為：進(jìn)程層、容器層、主機(jī)層。

第一層：進(jìn)程層（也可以理解為服務(wù)層）

進(jìn)程層可以查看：

• 進(jìn)程狀態(tài)：CPU、內(nèi)存占用情況
• 進(jìn)程類型：主要分為Java應(yīng)用、Webf服務(wù)、消息隊(duì)列、數(shù)據(jù)庫(kù)、云服務(wù)等
• 網(wǎng)絡(luò)連接：包括入口連接（調(diào)用該進(jìn)程的所有進(jìn)程及端口）、出口連接（該進(jìn)程調(diào)用的所有進(jìn)程及其端口）

第二層：容器層

容器層可以查看：

• 容器信息：容器名稱、狀態(tài)、CPU、內(nèi)存占用情況、重啟次數(shù)、IP地址、容器端口、所屬主機(jī)等
• 網(wǎng)絡(luò)連接：包括入口連接（調(diào)用該容器的所有容器及端口）、出口連接（該容器調(diào)用的所有容器及端口）

第三層：主機(jī)層

主機(jī)層可以查看：

• 主機(jī)狀態(tài)：CPU、內(nèi)存占用情況
• 主機(jī)信息：主機(jī)名、OS版本
• 入口連接：調(diào)用該主機(jī)的所有主機(jī)及及端口
• 出口連接：該主機(jī)調(diào)用的所有主機(jī)及端口
• 容器鏡像：主機(jī)上存放的容器鏡像

不得不說(shuō)，AHAS架構(gòu)可視化是一款優(yōu)秀的產(chǎn)品，很大程度解決了分布式環(huán)境下應(yīng)用系統(tǒng)架構(gòu)的混沌不可知問(wèn)題。尤其在下面兩個(gè)方面要點(diǎn)贊：

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

當(dāng)然，再優(yōu)秀的產(chǎn)品也有瑕疵，我認(rèn)為這款產(chǎn)品最大的問(wèn)題是架構(gòu)布局能力較弱。畢竟架構(gòu)圖是給人看的，要符合人的視覺(jué)習(xí)慣。但AHAS在這方面做的不夠，比如，無(wú)法體現(xiàn)兩地三中心的地理結(jié)構(gòu)、無(wú)法按Web-App-DB的邏輯結(jié)構(gòu)組織架構(gòu)元素、沒(méi)有網(wǎng)絡(luò)分區(qū)、無(wú)法體現(xiàn)非云化組件、無(wú)法換圖標(biāo)等。

在這方面，客觀上說(shuō)優(yōu)锘的DMV在架構(gòu)布局方面就非常強(qiáng)，其繪圖的靈活性和便捷性甚至可以和Visio相媲美。比如下面是優(yōu)锘DMV繪制的網(wǎng)絡(luò)拓?fù)鋱D和應(yīng)用部署圖。

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

3.4 全景應(yīng)用墻

應(yīng)用架構(gòu)圖較好的滿足了單個(gè)應(yīng)用系統(tǒng)的運(yùn)維管控需求，但格局還是不夠。因?yàn)檫\(yùn)維不僅關(guān)注個(gè)別應(yīng)用的狀態(tài)，也要掌握所有應(yīng)用系統(tǒng)的保障和運(yùn)行狀態(tài)，這就需要全景應(yīng)用墻了。

所謂全景應(yīng)用墻，就是在一張巨大的“墻”上展示數(shù)據(jù)中心所有應(yīng)用系統(tǒng)及其運(yùn)行狀態(tài)。比如Servicenow的應(yīng)用墻：

這個(gè)應(yīng)用墻由一個(gè)個(gè)方塊組成，每個(gè)方塊表示一個(gè)應(yīng)用系統(tǒng)。方塊的顏色表示該應(yīng)用是否發(fā)生告警，方塊的大小則代表應(yīng)用使用的資源規(guī)模，規(guī)模越大，方塊的面積越大。

全景應(yīng)用墻常用來(lái)判斷是否出現(xiàn)全局性故障，如果互聯(lián)網(wǎng)出口、共享存儲(chǔ)、ESB等公共服務(wù)出現(xiàn)故障，應(yīng)用墻往往呈現(xiàn)祖國(guó)山河一片紅的“盛況”，此時(shí)千萬(wàn)別慌，不要花時(shí)間逐個(gè)檢查應(yīng)用系統(tǒng)，趕緊排查網(wǎng)絡(luò)和共享服務(wù)。

ServiceNow的應(yīng)用墻是我見(jiàn)過(guò)的第二棒的應(yīng)用墻，雖然如此優(yōu)秀，但也有幾個(gè)問(wèn)題：

1. 當(dāng)應(yīng)用系統(tǒng)量太多的時(shí)候不好顯示，尤其是大型金融機(jī)構(gòu)動(dòng)輒幾百個(gè)應(yīng)用系統(tǒng)的環(huán)境下
2. 業(yè)務(wù)領(lǐng)域和重要級(jí)別是比較重要的信息，但沒(méi)有很好的體現(xiàn)出來(lái)
3. 當(dāng)應(yīng)用有告警時(shí)，無(wú)法呈現(xiàn)告警應(yīng)用的業(yè)務(wù)指標(biāo)，也看不到與其他應(yīng)用的關(guān)聯(lián)關(guān)系

針對(duì)這些問(wèn)題，我們嘗試做了一些改進(jìn)：

1、取消了用面積表達(dá)IT資源規(guī)模，因?yàn)閷?duì)一線運(yùn)維而言，首要關(guān)心的是應(yīng)用有沒(méi)有告警，而不是資源的規(guī)模。同時(shí)，采用曲面屏設(shè)計(jì)，讓屏幕能夠容納更多的應(yīng)用。

2、引入了“重要性”和“業(yè)務(wù)領(lǐng)域”等多個(gè)信息維度，用于快速篩選出關(guān)鍵應(yīng)用系統(tǒng)。同時(shí)提供了多種呈現(xiàn)形式，比如應(yīng)用星系圖就能很好的表達(dá)核心應(yīng)用和外圍應(yīng)用的關(guān)系。

3、在全景應(yīng)用墻上，懸浮可顯示應(yīng)用的關(guān)系，點(diǎn)擊應(yīng)用就能查看應(yīng)用的APM數(shù)據(jù)和CMDB數(shù)據(jù)。

可視化的四個(gè)層次

CNCF告訴我們，在分布式微服務(wù)環(huán)境下，可視化將在運(yùn)維中扮演更重要的作用。通過(guò)分析國(guó)內(nèi)外優(yōu)秀的產(chǎn)品和實(shí)踐，我們發(fā)現(xiàn)可視化有脈絡(luò)可循，從微觀到宏觀可以分為四個(gè)層次，每個(gè)層次都有其適用場(chǎng)景和用戶角色：

這就是前面講述的所有內(nèi)容。到這兒本應(yīng)該結(jié)束了，但不知道大家發(fā)現(xiàn)沒(méi)有，有個(gè)地方似乎不太對(duì)？

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

能否在這些工具之上構(gòu)建一個(gè)統(tǒng)一的可視化界面，為用戶提供更加一致、方便和人性化的使用體驗(yàn)?zāi)兀?/p>

4 IT數(shù)字地圖

IT數(shù)字地圖是我們構(gòu)建統(tǒng)一IT管理界面的一個(gè)重要嘗試，這個(gè)想法最初來(lái)源于地圖。

在遠(yuǎn)古時(shí)代，人類渺小，世界遼闊。有了地圖，人類才得以認(rèn)知和征服了這個(gè)世界?，F(xiàn)代社會(huì)，數(shù)字地圖在人們?nèi)粘Ｉ钪邪l(fā)揮著日益重要的作用。每天我們都會(huì)使用地圖定位位置、探索周邊、規(guī)劃路徑，地圖已成為人們獲取各類生活信息的核心工具。

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

IT數(shù)字地圖充分借鑒了谷歌和百度地圖的設(shè)計(jì)思想，比如，分層設(shè)計(jì)、無(wú)縫縮放、局部加載、線路規(guī)劃和興趣點(diǎn)等等。

4.1 分層設(shè)計(jì)

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

所以IT世界地圖也借鑒此設(shè)計(jì)，我們將IT地圖分為四大層級(jí)：業(yè)務(wù)架構(gòu)層、應(yīng)用架構(gòu)層、部署架構(gòu)層、資源運(yùn)行層。

我們以金融行業(yè)為例：

第一層：業(yè)務(wù)架構(gòu)層

業(yè)務(wù)架構(gòu)是業(yè)務(wù)與IT的橋梁，定義了應(yīng)用系統(tǒng)的業(yè)務(wù)能力，從概念層面幫助IT人員了解應(yīng)用系統(tǒng)的定位、用途和重要性，在疊加APM監(jiān)控?cái)?shù)據(jù)后，也可以用來(lái)做多應(yīng)用告警時(shí)的故障定界，因此我們將其作為IT世界地圖最頂層圖層。

業(yè)務(wù)架構(gòu)圖的主要元素是業(yè)務(wù)領(lǐng)域、應(yīng)用系統(tǒng)以及應(yīng)用系統(tǒng)間的調(diào)用關(guān)系，示意如下：

第二層：應(yīng)用架構(gòu)層

應(yīng)用架構(gòu)用來(lái)描述應(yīng)用系統(tǒng)的功能邊界，定義了應(yīng)用系統(tǒng)由哪些服務(wù)組件構(gòu)成，以及它們之間如何分工、協(xié)作。

應(yīng)用架構(gòu)圖一般有兩種風(fēng)格，一種是按功能處理順序?qū)⑾到y(tǒng)分為Web前端、中間服務(wù)、后臺(tái)數(shù)據(jù)存儲(chǔ)，常見(jiàn)于傳統(tǒng)單體式應(yīng)用架構(gòu)。另一種是按業(yè)務(wù)類型劃分，比如支付服務(wù)、對(duì)賬服務(wù)、額度控制服務(wù)等，一般微服務(wù)應(yīng)用是這種風(fēng)格。

第三層：部署架構(gòu)層

部署架構(gòu)定義了應(yīng)用程序如何安裝、部署到現(xiàn)實(shí)的IT環(huán)境中，以及數(shù)據(jù)如何在網(wǎng)絡(luò)中傳遞和保存。

部署架構(gòu)圖應(yīng)該體現(xiàn)部署的物理位置、網(wǎng)絡(luò)分區(qū)、部署單元、集群模式、訪問(wèn)協(xié)議等等。

第四層：資源運(yùn)行層

資源運(yùn)行層用于展示應(yīng)用程序部署完成后形成的資源實(shí)例，包括容器、主機(jī)、DB實(shí)例、MQ實(shí)例、NAS存儲(chǔ)實(shí)例、FW實(shí)例、SSL實(shí)例等等。

4.2 無(wú)縫縮放和局部加載

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

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

4.3 線路規(guī)劃 vs. 鏈路追蹤

只有無(wú)縫縮放和局部加載還不夠，為了增加IT數(shù)字地圖的使用價(jià)值，我們實(shí)現(xiàn)了鏈路追蹤功能。

鏈路追蹤的設(shè)計(jì)參考了數(shù)字地圖的路徑規(guī)劃功能。在數(shù)字地圖中，我們只要輸入目的地，數(shù)字地圖就會(huì)自動(dòng)規(guī)劃出行路線。同樣，在IT數(shù)字地圖中，我們只要輸入交易碼或TraceId，就能在地圖中現(xiàn)實(shí)完整的調(diào)用路徑。

4.4 興趣點(diǎn)(POI)

光有路徑還不夠，我們?cè)谂耪蠒r(shí)還需要查看路徑中每個(gè)節(jié)點(diǎn)的信息。

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

我們?cè)贗T數(shù)字地圖中也引入了POI。每個(gè)POI都是一個(gè)IT管理對(duì)象，它包括四類信息：配置信息、指標(biāo)信息、告警信息和工單信息。這些信息對(duì)于鏈路追蹤、性能優(yōu)化、變更分析非常重要。

4.5 IT數(shù)字地圖的邊界

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

我們認(rèn)為，IT數(shù)字地圖應(yīng)該定位成開(kāi)放的地圖服務(wù)，就像百度、高德地圖一樣，既能獨(dú)立使用，也能嵌入到美團(tuán)外賣(mài)、滴滴打車等應(yīng)用中，這是IT數(shù)字地圖與其他運(yùn)維可視化工具最大的區(qū)別。

對(duì)此，我們給出了三條產(chǎn)品原則，以確保IT數(shù)字地圖能夠按照既定的設(shè)想成長(zhǎng)：

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

基于這個(gè)設(shè)計(jì)原則，IT數(shù)字地圖的功能架構(gòu)如下：

具體功能就不多說(shuō)了，這是我們?cè)贗T數(shù)字地圖方面的一些實(shí)踐，目前還處于起步階段，還有很大的優(yōu)化空間，歡迎大家批評(píng)指正。

寫(xiě)在最后的話

在IT管理領(lǐng)域，IT數(shù)字地圖是全新的探索，國(guó)內(nèi)外沒(méi)有類似產(chǎn)品可以借鑒。我們?yōu)槭裁匆鲞@種前無(wú)古人的事情？

正如任正非所言：“我們對(duì)客戶需求的理解不能狹窄,不要以為客戶說(shuō)出來(lái)的是需求. 其實(shí)客戶需求是一種邏輯學(xué)和哲學(xué),是人性的持續(xù)激活與成長(zhǎng),是人類文明發(fā)展的必然趨勢(shì)?！?/p>

我們認(rèn)為，IT數(shù)字地圖能夠給枯燥、繁瑣、危險(xiǎn)的運(yùn)維環(huán)境中帶來(lái)一絲人性，符合運(yùn)維發(fā)展的必然趨勢(shì)。雖然現(xiàn)在只是一個(gè)遙遠(yuǎn)的夢(mèng)想，但優(yōu)锘愿意為此奉獻(xiàn)自己的智慧和青春。可視化是一個(gè)偉大的事業(yè)，路漫漫其修遠(yuǎn)兮，吾等上下而求索。