如何在一分鐘內(nèi)實(shí)現(xiàn)微服務(wù)系統(tǒng)下的架構(gòu)可視化

為什么需要架構(gòu)可視化

隨著企業(yè)進(jìn)行微服務(wù)架構(gòu)改造，系統(tǒng)架構(gòu)復(fù)雜度越來越高，架構(gòu)變化日益頻繁，微服務(wù)改造后的實(shí)際架構(gòu)模型可能與預(yù)期已經(jīng)產(chǎn)生了巨大差異，架構(gòu)師或系統(tǒng)運(yùn)維人員很難準(zhǔn)確記憶所有資源實(shí)例的構(gòu)成和交互情況；其次，系統(tǒng)架構(gòu)在動態(tài)演化過程中可能引入了一些不可靠的因素，比如弱依賴變強(qiáng)依賴、局部容量不足、系統(tǒng)耦合過重等，給系統(tǒng)的穩(wěn)定性帶了極大的安全隱患。所以我們每次在面對系統(tǒng)改造、業(yè)務(wù)大促以及穩(wěn)定性治理工作之前，都會通過梳理架構(gòu)圖的方式，呈現(xiàn)系統(tǒng)架構(gòu)中個組件之間的交互方式，架構(gòu)可視化能夠清晰的協(xié)助我們識別架構(gòu)中存在的問題以及建立高可用的系統(tǒng)。

Daniel Woods 在講微服務(wù)時時的一張架構(gòu)圖

架構(gòu)可視化后，可以給我們帶來以下幾點(diǎn)但不局限于此的優(yōu)勢：

• 確定系統(tǒng)邊界

一張好的架構(gòu)圖，應(yīng)該明確系統(tǒng)所包含的各個組件以及各個組件之間的核心調(diào)用關(guān)系，這些組件的集合就是系統(tǒng)的處理邊界，系統(tǒng)架構(gòu)的邊界在一定程度上也反映了業(yè)務(wù)域的邊界。

• 架構(gòu)問題識別

基于高可用的架構(gòu)準(zhǔn)則，結(jié)合可視化的架構(gòu)圖，可以評估架構(gòu)可能存在的安全風(fēng)險，比如系統(tǒng)在容災(zāi)、隔離以及自愈維度下的健壯性。其次，一些架構(gòu)鏈路可視化工具(比如鷹眼)在實(shí)際工作中確實(shí)大大提高了開發(fā)者排查與定位問題的效率。

• 提高系統(tǒng)可用性

有了系統(tǒng)架構(gòu)的上下游依賴關(guān)系圖，在故障發(fā)生時，開發(fā)人員可以借助依賴數(shù)據(jù)快速定位到問題的來源，極大縮短問題修復(fù)時間（MTTR）。借助架構(gòu)圖，我們還可以梳理出系統(tǒng)中存在的強(qiáng)弱依賴，在業(yè)務(wù)高峰期對弱依賴進(jìn)行降級，或者針對系統(tǒng)依賴的各個組件進(jìn)行故障模擬，以評測系統(tǒng)整體在面對局部故障的可靠性。

常見架構(gòu)可視化的做法

我們熟知的架構(gòu)圖是靜態(tài)的停留在PPT上的，很多時候我們的架構(gòu)已經(jīng)發(fā)生了非常大的變化，但是我們還在使用那張看上去很經(jīng)典卻早已過時的架構(gòu)圖。長時間使用與實(shí)際架構(gòu)不符的架構(gòu)圖對線上架構(gòu)的認(rèn)知的危害是巨大的，我們需要在腦海中不斷更新對系統(tǒng)架構(gòu)的視圖，以保持對系統(tǒng)架構(gòu)的敏感度。每年的大促或者重大系統(tǒng)改造成為我們梳理系統(tǒng)架構(gòu)、對架構(gòu)進(jìn)行重新認(rèn)知的機(jī)會，此刻我們需要通過各種工具查看系統(tǒng)的各個組件分布以及不同組件的內(nèi)部與外部的依賴關(guān)系，這種梳理架構(gòu)圖的方法是最常用的方式，權(quán)且稱之為“手工繪制法”。

手工經(jīng)常干的事情，就有追求效率的同學(xué)使用計算機(jī)系統(tǒng)帶來的自動化手段幫助自己做這件事情，比如我們常常看到的基于數(shù)據(jù)埋點(diǎn)的微服務(wù)可視化解決方案，這類架構(gòu)可視化手段通常在分布式追蹤、APM等監(jiān)控領(lǐng)域使用較多，下圖為某APM產(chǎn)品提供的應(yīng)用維度架構(gòu)可視化方案：

我們稱這種可視化方式為“埋點(diǎn)式感知法”，架構(gòu)組件的識別是依賴關(guān)鍵的核心類檢測與埋點(diǎn)，此種方案存在以下弊端：

• 語言相關(guān)性：
  只要是系統(tǒng)埋點(diǎn)，與語言相關(guān)的特征基本就拜托不了，需要針對不同語言提供不同的依賴包；

• 不易維護(hù)：
  因?yàn)槭菍诵念惖臋z測，當(dāng)組件包做了重大變更時，需要同步變更；

• 不易擴(kuò)展：
  因?yàn)槭强蛻舳俗R別方案，客戶端一旦開放出去，新組件的支持只能等待用戶更新組件；

• 規(guī)模受限：
  客戶端識別的另一個缺點(diǎn)是算法受限，服務(wù)端進(jìn)行識別，可以借助大數(shù)據(jù)分析等手段更有效準(zhǔn)確的識別；

還有一種自動化架構(gòu)感可視化方法，我們稱之為“無界架構(gòu)感知”，是一種語言無關(guān)性的架構(gòu)識別方案，其采用采集用戶主機(jī)上的進(jìn)程和容器的元數(shù)據(jù)、監(jiān)控數(shù)以及網(wǎng)路數(shù)據(jù)的最最基礎(chǔ)的數(shù)據(jù)，在服務(wù)端構(gòu)建架構(gòu)圖。

架構(gòu)可視化還能怎么做

為了最大限度上降低用戶進(jìn)行架構(gòu)可視化的成本，我們采用了應(yīng)用無侵入的方式微服務(wù)進(jìn)行可視化，通過采集進(jìn)程數(shù)據(jù)與網(wǎng)絡(luò)調(diào)用數(shù)據(jù)，構(gòu)建進(jìn)程間的網(wǎng)絡(luò)調(diào)用關(guān)系，構(gòu)建微服務(wù)的架構(gòu)信息。用戶只需要安裝我們AHAS?Agent探針，即可完成架構(gòu)可視化操作；對于阿里云云原生系統(tǒng)，我們提供了自動化安裝方式，而無需登錄機(jī)器。

如何讓架構(gòu)可視化更有效

我們同樣認(rèn)為架構(gòu)可視化的有效性跟人的認(rèn)知層次有關(guān)，架構(gòu)可視化的重點(diǎn)是確定該工具是否更好的支持自頂向下方法、自下而上方法或者兩者的結(jié)合。開發(fā)者更關(guān)心應(yīng)用維度上的架構(gòu)，架構(gòu)師或者管理者更關(guān)心整體系統(tǒng)架構(gòu)。所以需要針對不用的使用者提供不同層次的架構(gòu)可視化視角。理想的架構(gòu)圖需要支持宏觀維度以及不斷下鉆下的微觀視角，我們對架構(gòu)進(jìn)行了分層設(shè)計，目前分為進(jìn)程層、容器層和主機(jī)層，后期我們可能會繼續(xù)上擴(kuò)或者下鉆支持地域?qū)踊蛘叻?wù)層。

下圖為一臺阿里云ECS部署了微服務(wù)應(yīng)用安裝AHAS探針之后的可視化三層架構(gòu)界面：

• 應(yīng)對架構(gòu)的可變性

沒有哪家科技公司的系統(tǒng)架構(gòu)是一成不變的，系統(tǒng)架構(gòu)會隨著系統(tǒng)的版本迭代不斷進(jìn)行演化。所以對架構(gòu)可視化操作，還需要具備隨著時間的推移可對架構(gòu)信息進(jìn)行自動更新已經(jīng)回溯的能力。在我們提供的架構(gòu)感知產(chǎn)品中默認(rèn)架構(gòu)圖會隨著時間自動刷新，同時支持對歷史的回溯，你可以選擇歷史中的某一刻查看架構(gòu)信息，比如，重大版本的變更時，發(fā)布前與發(fā)布后的系統(tǒng)架構(gòu)是否發(fā)生了違背一些高可用原則的問題，抑或排查是否出現(xiàn)了不該有的依賴問題。

• 架構(gòu)可視化的核心

軟件架構(gòu)可視化的核心點(diǎn)是尋找在軟件體系結(jié)構(gòu)中有意義和有效的元素視圖以及這些元素之間的關(guān)系。我們認(rèn)為一款優(yōu)秀的軟件架構(gòu)可視化產(chǎn)品應(yīng)該幫助用戶排除掉不重要的信息，給用戶呈現(xiàn)出對他們有價值的視圖，特別是在微服務(wù)架構(gòu)下龐大而復(fù)雜的調(diào)用關(guān)系鏈場景中。這里面的核心點(diǎn)是有意義和有效，要做到這兩點(diǎn)，首先需要識別什么是有意義和有效的元素和關(guān)系，我們在此領(lǐng)域做的事情歸納起來就是“識別”，識別機(jī)器上的每個進(jìn)程是什么，發(fā)生的網(wǎng)絡(luò)調(diào)用遠(yuǎn)端是什么，唯有知曉了這些元素是什么我們才有理由和依據(jù)來判斷是否對用戶有意義以及其在用戶架構(gòu)中的重要程度。

• 架構(gòu)可視化中的元素識別

在梳理了大量架構(gòu)圖，我們發(fā)現(xiàn)用戶關(guān)心的架構(gòu)元素主要分為三類：1. 自己的應(yīng)用服務(wù)；2. 應(yīng)用對外部的資源依賴；3. 服務(wù)器本身的信息。 應(yīng)用對外部資源的依賴通常以其它應(yīng)用和通用中間件或者存儲服務(wù)兩種形式存在。故我們將需要識別的進(jìn)程分為：應(yīng)用服務(wù)和常見的組件服務(wù)（比如Redis、MySQL等），這些組件服務(wù)又分為用戶自建的服務(wù)和使用公有云提供的服務(wù)，特別是對于Cloud Native應(yīng)用來說，云服務(wù)的識別顯得格外重要。

目前，我們提供了20種阿里云云服務(wù)的識別以及包含MySQL、Redis、Tomcat等常見的21種三方服務(wù)組件，此組件庫還在不斷擴(kuò)張中，目的就是最大限度的知曉架構(gòu)中的元素到底是什么。

圖中展示了通過識別服務(wù)識別出來的Nginx、Redis組件以及阿里云中的Mysql服務(wù)和AHAS服務(wù)

圖中展示了節(jié)點(diǎn)詳情的請求流向以及節(jié)點(diǎn)的監(jiān)控等基本信息

圖中展示了識別的主機(jī)上的部分進(jìn)程信息

有了架構(gòu)可視化還能做什么

架構(gòu)可視化不是目的，只是實(shí)現(xiàn)系統(tǒng)高可用性的手段。借助架構(gòu)感知采集到的架構(gòu)數(shù)據(jù)，在識別了用戶使用的組件（我們對MySQL、Redis、MQ等的統(tǒng)稱)后，我們借助這些組件以及與組件匹配的故障庫，可以給用戶自動推薦這些組件可能遇到的故障，配合我們提供的評測服務(wù)讓用戶更方便地對組件進(jìn)行各種故障的模擬與演練，以提高系統(tǒng)的健壯性。其次，通過架構(gòu)感知識別Java Application 應(yīng)用，如果發(fā)現(xiàn)其負(fù)載較高，配合我們提供的限流降級（阿里巴巴開源的Sentinel商業(yè)版）功能，為服務(wù)的持續(xù)可用性保駕護(hù)航。

借助架構(gòu)感知進(jìn)行系統(tǒng)限流配置

我們對AHAS的定位是一款數(shù)據(jù)分析型的高可用保障產(chǎn)品，幫助云原生架構(gòu)系統(tǒng)實(shí)現(xiàn)高可用能力的提升。架構(gòu)可視化是我們給用戶提供的高效運(yùn)維和管控的窗口，我們期望通過豐富的云原生數(shù)據(jù)體系配合架構(gòu)圖的可視化以及可操作性，建立起以應(yīng)用為中心的運(yùn)維一體化平臺。在未來，我們會加強(qiáng)與其它云服務(wù)的集成，比如監(jiān)控、容器服務(wù)，以豐富架構(gòu)感知的數(shù)據(jù)維度；其次，會在數(shù)據(jù)的深度挖掘和智能化消費(fèi)上投入更多精力，真正讓數(shù)據(jù)成為企業(yè)的核心價值，讓數(shù)據(jù)成為保障業(yè)務(wù)的穩(wěn)定性的利器。