微服務架構可視化平臺實踐

爲何須要架構可視化

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

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

 

架構可視化後，能夠給咱們帶來如下幾點但不侷限於此的優點：

• 肯定系統邊界
  一張好的架構圖，應該明確系統所包含的各個組件以及各個組件之間的核心調用關係，這些組件的集合就是系統的處理邊界，系統架構的邊界在必定程度上也反映了業務域的邊界。
• 架構問題識別
  基於高可用的架構準則，結合可視化的架構圖，能夠評估架構可能存在的安全風險，好比系統在容災、隔離以及自愈維度下的健壯性。其次，一些架構鏈路可視化工具(好比鷹眼)在實際工做中確實大大提升了開發者排查與定位問題的效率。
• 提升系統可用性
  有了系統架構的上下游依賴關係圖，在故障發生時，開發人員能夠藉助依賴數據快速定位到問題的來源，極大縮短問題修復時間（MTTR）。藉助架構圖，咱們還能夠梳理出系統中存在的強弱依賴，在業務高峯期對弱依賴進行降級，或者針對系統依賴的各個組件進行故障模擬，以評測系統總體在面對局部故障的可靠性。

常見架構可視化的作法

咱們熟知的架構圖是靜態的停留在PPT上的，不少時候咱們的架構已經發生了很是大的變化，可是咱們還在使用那張看上去很經典卻早已過期的架構圖。長時間使用與實際架構不符的架構圖對線上架構的認知的危害是巨大的，咱們須要在腦海中不斷更新對系統架構的視圖，以保持對系統架構的敏感度。每一年的大促或者重大系統改形成爲咱們梳理系統架構、對架構進行從新認知的機會，此刻咱們須要經過各類工具查看系統的各個組件分佈以及不一樣組件的內部與外部的依賴關係，這種梳理架構圖的方法是最經常使用的方式，權且稱之爲「__手工繪製法__」。

手工常常乾的事情，就有追求效率的同窗使用計算機系統帶來的自動化手段幫助本身作這件事情，好比咱們經常看到的基於數據埋點的微服務可視化解決方案，這類架構可視化手段一般在分佈式追蹤、APM等監控領域使用較多，下圖爲某APM產品提供的應用維度架構可視化方案：

咱們稱這種可視化方式爲「__埋點式感知法__」，架構組件的識別是依賴關鍵的核心類檢測與埋點，此種方案存在如下弊端：

• 語言相關性：只要是系統埋點，與語言相關的特徵基本就拜託不了，須要針對不一樣語言提供不一樣的依賴包；
• 不易維護：由於是對核心類的檢測，當組件包作了重大變動時，須要同步變動；
• 不易擴展：由於是客戶端識別方案，客戶端一旦開放出去，新組件的支持只能等待用戶更新組件；
• 規模受限：客戶端識別的另外一個缺點是算法受限，服務端進行識別，能夠藉助大數據分析等手段更有效準確的識別；

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

咱們設計架構可視化的理念

爲了最大限度上下降用戶進行架構可視化的成本，咱們採用了無界架構感知-應用無侵入的方式微服務進行可視化，經過採集進程數據與網絡調用數據，構建進程間的網絡調用關係，構建微服務的架構信息。用戶只須要安裝咱們AHAS Agent探針，便可完成架構可視化操做；對於阿里云云原生系統，咱們提供了自動化安裝方式，而無需登陸機器。

核心本質

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

在梳理了大量架構圖，咱們發現用戶關心的架構元素主要分爲三類：

1. 本身的應用服務；
2. 應用對外部的資源依賴；
3. 服務器自己的信息。 
   應用對外部資源的依賴一般以其它應用和通用中間件或者存儲服務兩種形式存在。故咱們將須要識別的進程分爲：應用服務和常見的組件服務（好比redis、mysql等），這些組件服務又分爲用戶自建的服務和使用公有云提供的服務，特別是對於Cloud Native應用來講，雲服務的識別顯得格外重要。

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

    （圖中展現了 經過識別服務識別出來的nginx、redis組件以及阿里雲中的Mysql服務和AHAS服務）

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

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

架構分層

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

架構回溯

沒有哪一個系統的架構是一成不變的，系統架構會隨着系統的版本迭代不斷進行演化。因此對架構可視化操做，還須要具有隨着時間的推移可對架構信息進行自動更新已經回溯的能力。在咱們提供的架構感知產品中默認架構圖會隨着時間自動刷新，同時支持對歷史的回溯，你能夠選擇歷史中的某一刻查看架構信息，好比，重大版本的變動時，發佈前與發佈後的系統架構是否發生了違背一些高可用原則的問題，抑或排查是否出現了不應有的依賴問題。

可見可得

架構可視化解決了可見的問題，但當咱們從架構圖中發現了問題須要解決時，架構圖還應該給咱們提供便利的可交互操做入口，讓咱們能夠完成問題發現與解決的閉環。好比經過架構感知監控到了某個應用的流量很是大，咱們須要對應用進行限流或者預案，那麼經過架構圖，咱們應該是能夠完成咱們指望執行的操做。在架構圖中融入能夠交互的運維操做，讓咱們從看到到操做，再到問題恢復後體如今圖中，這就像計算機發展史上從命令行視圖到窗口視圖的轉變。

咱們對架構可視化的定位

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

（白屏化安裝AHAS探針）

（如何藉助架構感知進行系統限流配置）

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

產品體驗鏈接：https://www.aliyun.com/product/ahas

原文連接