如何在實現微服務系統下的架構可視化

這篇文章將為大家詳細講解有關如何在實現微服務系統下的架構可視化，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

為什么需要架構可視化

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

cdn.com/cb3ded9bf6b7f30c859cf2290aebbdd161416782.png">

Daniel Woods 在講微服務時時的一張架構圖

架構可視化后，可以給我們帶來以下幾點但不局限于此的優勢：

• 確定系統邊界

一張好的架構圖，應該明確系統所包含的各個組件以及各個組件之間的核心調用關系，這些組件的集合就是系統的處理邊界，系統架構的邊界在一定程度上也反映了業務域的邊界。

• 架構問題識別

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

• 提高系統可用性

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

常見架構可視化的做法

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

手工經常干的事情，就有追求效率的同學使用計算機系統帶來的自動化手段幫助自己做這件事情，比如我們常常看到的基于數據埋點的微服務可視化解決方案，這類架構可視化手段通常在分布式追蹤、APM等監控領域使用較多，下圖為某APM產品提供的應用維度架構可視化方案：

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

• 語言相關性：
  只要是系統埋點，與語言相關的特征基本就拜托不了，需要針對不同語言提供不同的依賴包；

• 不易維護：
  因為是對核心類的檢測，當組件包做了重大變更時，需要同步變更；

• 不易擴展：
  因為是客戶端識別方案，客戶端一旦開放出去，新組件的支持只能等待用戶更新組件；

• 規模受限：
  客戶端識別的另一個缺點是算法受限，服務端進行識別，可以借助大數據分析等手段更有效準確的識別；

還有一種自動化架構感可視化方法，我們稱之為“無界架構感知”，是一種語言無關性的架構識別方案，其采用采集用戶主機上的進程和容器的元數據、監控數以及網路數據的最最基礎的數據，在服務端構建架構圖。

架構可視化還能怎么做

為了最大限度上降低用戶進行架構可視化的成本，我們采用了應用無侵入的方式微服務進行可視化，通過采集進程數據與網絡調用數據，構建進程間的網絡調用關系，構建微服務的架構信息。用戶只需要安裝我們AHAS Agent探針，即可完成架構可視化操作；對于阿里云云原生系統，我們提供了自動化安裝方式，而無需登錄機器。

如何讓架構可視化更有效

我們同樣認為架構可視化的有效性跟人的認知層次有關，架構可視化的重點是確定該工具是否更好的支持自頂向下方法、自下而上方法或者兩者的結合。開發者更關心應用維度上的架構，架構師或者管理者更關心整體系統架構。所以需要針對不用的使用者提供不同層次的架構可視化視角。理想的架構圖需要支持宏觀維度以及不斷下鉆下的微觀視角，我們對架構進行了分層設計，目前分為進程層、容器層和主機層，后期我們可能會繼續上擴或者下鉆支持地域層或者服務層。

下圖為一臺阿里云ECS部署了微服務應用安裝AHAS探針之后的可視化三層架構界面：

• 應對架構的可變性

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

• 架構可視化的核心

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

• 架構可視化中的元素識別

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

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

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

圖中展示了節點詳情的請求流向以及節點的監控等基本信息

圖中展示了識別的主機上的部分進程信息

有了架構可視化還能做什么

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

借助架構感知進行系統限流配置

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

關于如何在實現微服務系統下的架構可視化就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。