為什麼需要架構可視化
随着企業進行微服務架構改造，系統架構複雜度越來越高，架構變化日益頻繁，微服務改造後的實際架構模型可能與預期已經産生了巨大差異，架構師或系統運維人員很難準确記憶所有資源執行個體的構成和互動情況；其次，系統架構在動态演化過程中可能引入了一些不可靠的因素，比如弱依賴變強依賴、局部容量不足、系統耦合過重等，給系統的穩定性帶了極大的安全隐患。是以我們每次在面對系統改造、業務大促以及穩定性治理工作之前，都會通過梳理架構圖的方式，呈現系統架構中個元件之間的互動方式，架構可視化能夠清晰的協助我們識别架構中存在的問題以及建立高可用的系統。
（Daniel Woods 在講微服務時時的一張架構圖）
架構可視化後，可以給我們帶來以下幾點但不局限于此的優勢：
-
确定系統邊界
一張好的架構圖，應該明确系統所包含的各個元件以及各個元件之間的核心調用關系，這些元件的集合就是系統的處理邊界，系統架構的邊界在一定程度上也反映了業務域的邊界。
-
架構問題識别
基于高可用的架構準則，結合可視化的架構圖，可以評估架構可能存在的安全風險，比如系統在容災、隔離以及自愈次元下的健壯性。其次，一些架構鍊路可視化工具(比如鷹眼)在實際工作中确實大大提高了開發者排查與定位問題的效率。
-
提高系統可用性
有了系統架構的上下遊依賴關系圖，在故障發生時，開發人員可以借助依賴資料快速定位到問題的來源，極大縮短問題修複時間（MTTR）。借助架構圖，我們還可以梳理出系統中存在的強弱依賴，在業務高峰期對弱依賴進行降級，或者針對系統依賴的各個元件進行故障模拟，以評測系統整體在面對局部故障的可靠性。
常見架構可視化的做法
我們熟知的架構圖是靜态的停留在PPT上的，很多時候我們的架構已經發生了非常大的變化，但是我們還在使用那張看上去很經典卻早已過時的架構圖。長時間使用與實際架構不符的架構圖對線上架構的認知的危害是巨大的，我們需要在腦海中不斷更新對系統架構的視圖，以保持對系統架構的敏感度。每年的大促或者重大系統改造成為我們梳理系統架構、對架構進行重新認知的機會，此刻我們需要通過各種工具檢視系統的各個元件分布以及不同元件的内部與外部的依賴關系，這種梳理架構圖的方法是最常用的方式，權且稱之為“__手工繪制法__”。
手工經常幹的事情，就有追求效率的同學使用計算機系統帶來的自動化手段幫助自己做這件事情，比如我們常常看到的基于資料埋點的微服務可視化解決方案，這類架構可視化手段通常在分布式追蹤、APM等監控領域使用較多，下圖為某APM産品提供的應用次元架構可視化方案：
我們稱這種可視化方式為“__埋點式感覺法__”，架構元件的識别是依賴關鍵的核心類檢測與埋點，此種方案存在以下弊端：
- 語言相關性：隻要是系統埋點，與語言相關的特征基本就拜托不了，需要針對不同語言提供不同的依賴包；
- 不易維護：因為是對核心類的檢測，當元件包做了重大變更時，需要同步變更；
- 不易擴充：因為是用戶端識别方案，用戶端一旦開放出去，新元件的支援隻能等待使用者更新元件；
- 規模受限：用戶端識别的另一個缺點是算法受限，服務端進行識别，可以借助大資料分析等手段更有效準确的識别；
還有一種自動化架構感可視化方法，我們稱之為“__無界架構感覺__”，是一種語言無關性的架構識别方案，其采用采集使用者主機上的程序和容器的中繼資料、監控數以及網路資料的最最基礎的資料，在服務端建構架構圖。
我們設計架構可視化的理念
為了最大限度上降低使用者進行架構可視化的成本，我們采用了無界架構感覺-應用無侵入的方式微服務進行可視化，通過采集程序資料與網絡調用資料，建構程序間的網絡調用關系，建構微服務的架構資訊。使用者隻需要安裝我們AHAS Agent探針，即可完成架構可視化操作；對于阿裡雲雲原生系統，我們提供了自動化安裝方式，而無需登入機器。
核心本質
軟體架構可視化的核心點是尋找在軟體體系結構中有意義和有效的元素視圖以及這些元素之間的關系。我們認為一款優秀的軟體架構可視化産品應該幫助使用者排除掉不重要的資訊，給使用者呈現出對他們有價值的視圖，特别是在微服務架構下龐大而複雜的調用關系鍊場景中。這裡面的核心點是__有意義__和__有效__，要做到這兩點，首先需要識别什麼是有意義和有效的元素和關系，我們在此領域做的事情歸納起來就是“__識别__”，識别機器上的每個程序是什麼，發生的網絡調用遠端是什麼，唯有知曉了這些元素是什麼我們才有理由和依據來判斷是否對使用者有意義以及其在使用者架構中的重要程度。
在梳理了大量架構圖，我們發現使用者關心的架構元素主要分為三類：
- 自己的應用服務；
- 應用對外部的資源依賴；
-
伺服器本身的資訊。
應用對外部資源的依賴通常以其它應用和通用中間件或者存儲服務兩種形式存在。故我們将需要識别的程序分為：應用服務和常見的元件服務（比如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