88微拍福利,18禁美女裸体无遮挡网站,av网站免费线看,美女高潮喷水40分钟全程露脸,另类亚洲春色校园小说

管理微服務(wù),從可視化談起
2020-10-10 by uino 10.4K 技術(shù)分享

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

本文將探討在分布式、微服務(wù)環(huán)境下的各種可視化實踐以及我們在這個領(lǐng)域的探索和成果,全文分為四個部分:

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

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

1 什么是微服務(wù)

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

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

簡而言之,微服務(wù)應(yīng)用要具備三個特征:Small,Independently 和Automated。這三個特征所支撐的核心目標是:快!讓應(yīng)用迭代更快、部署更快、發(fā)布更快!

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

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

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

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

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

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

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

3.1 調(diào)用鏈路圖

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

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

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

但再難查也得查啊,100億啊。怎么查?用鏈路圖!

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

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

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

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

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

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

還可以高亮出children最多的五個span(子children越多,服務(wù)調(diào)用就越慢):

在這個截圖中,有一個包含13個children的span,這些children都是數(shù)據(jù)庫訪問,所以難怪這么慢!

總結(jié)一下:

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

3.2 調(diào)用拓撲圖

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

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

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

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

總結(jié)一下:

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

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

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

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

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

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

第一層:進程層(也可以理解為服務(wù)層)

進程層可以查看:

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

第二層:容器層

容器層可以查看:

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

第三層:主機層

主機層可以查看:

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

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

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

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

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

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

3.4 全景應(yīng)用墻

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

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

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

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

ServiceNow的應(yīng)用墻是我見過的第二棒的應(yīng)用墻,雖然如此優(yōu)秀,但也有幾個問題:

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

針對這些問題,我們嘗試做了一些改進:

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

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

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

可視化的四個層次

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

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

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

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

4 IT數(shù)字地圖

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

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

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

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

4.1 分層設(shè)計

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

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

我們以金融行業(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)控數(shù)據(jù)后,也可以用來做多應(yīng)用告警時的故障定界,因此我們將其作為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)用來描述應(yīng)用系統(tǒng)的功能邊界,定義了應(yīng)用系統(tǒng)由哪些服務(wù)組件構(gòu)成,以及它們之間如何分工、協(xié)作。

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

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

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

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

第四層:資源運行層

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

4.2 無縫縮放和局部加載

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

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

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

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

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

4.4 興趣點(POI)

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

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

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

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

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

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

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

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

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

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

寫在最后的話

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

正如任正非所言:“我們對客戶需求的理解不能狹窄,不要以為客戶說出來的是需求. 其實客戶需求是一種邏輯學和哲學,是人性的持續(xù)激活與成長,是人類文明發(fā)展的必然趨勢?!?/p>

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