云原生集成開發環境——TitanIDE
通過網頁在任何地方更安全、更高效地編碼2023-02-02
587
原文作者:leyu.樂魚創新產品總監 陳曉露
了解CloudOS或Methodot的童鞋可能都知道,平臺中有個概念——架構圖。
· 平臺中的架構圖究竟是什么?
· 平臺中的架構圖跟應用開發中的架構圖是什么關系?
這篇文章,我給大家解釋一下。
架構圖的由來
你可能聽說過3D打印,也可能了解3D打印。舉個例子,為了生產一輛汽車,先為汽車建個模,大小、樣式、各個組成部分的材料等等,描述完整。然后把“模型”和“原材料”給到一個3D打印機,打印機就能打印出一輛汽車。
這樣的話,汽車生產的關鍵就是建立模型了。
那么,軟件應用的生產能否也采取類似于3D打印的方式呢?你可能猜到了,跟上面的例子類比,CloudOS平臺的架構圖就相當于汽車模型。(PS:先介紹一下,Methodot是CloudOS的SaaS版。)
平臺中真實的架構圖,一個電商應用的架構圖:
說起來,我們的架構圖一開始叫藍圖,后來我們的客戶反饋,藍圖這個名字太大了,不太貼切,我們經過討論后就改為架構圖了。有意思的是,改了之后,有其他客戶反饋,還是叫藍圖比較好。
平臺中的架構圖與開發人員理解的架構圖有什么關系?
很顯然,CloudOS平臺的架構圖可以一鍵“打印”成應用,并且圖上的元素都能產生實際的作用,而開發人員畫的架構圖僅僅是一張圖。
平臺中的架構圖與k8s yaml有什么關系 ?
不懂K8s的童鞋可以跳過本段。懂K8s的童鞋可能會說,這個架構圖,不就是k8s yaml的圖形化展示嗎?并不盡然,CloudOS平臺的架構圖是k8s yaml的超集:
1. 架構圖有組件與組件之間的關系:帶箭頭的連線。這個連線不僅是視覺上的一個標記,它有實際的意義:
· 連線在架構圖中會影響部署過程中的組件部署順序。
· 平臺可以基于連線做組件之間的訪問控制,比如:有連線才能訪問。
· 平臺支持API調用控制,比如:允許A組件調用B組件10個API中的2個API。
2. 架構圖的組件比yaml中的一個部署單元有著更豐富的信息:
· 代碼組件,包括代碼庫信息、技術棧信息等。
· API信息。
· 組件負責人信息。
· 組件描述信息。
3. 架構圖有group的概念,比如有3個組件同屬于1個業務域,這3個組件可以建一個gruop。
4. 架構圖的組件有位置信息,體現了一個應用的技術架構中的組件層級。
可以這么理解,CloudOS平臺的架構圖部署成應用時,會先轉化成K8s yaml,然后部署到K8s中。
平臺中的架構圖有什么作用?
先來說說比較具體的作用,主要有如下幾點:
· 平臺中的應用都由架構圖部署而成,那么應用的實際架構與架構圖是對應的,不會存在黑盒子。在很多公司的項目中,人員的更迭會導致應用的實際架構無人知曉,迭代開發時戰戰兢兢,生怕帶來不可預知的后果,使用我們平臺后,這個問題將會被徹底解決。
· 應用架構可視化,可視化的價值是很大的,無論是用來匯報、評審、學習都非常重要,是企業的重要資產。傳統的架構圖靠手繪,一段時間后,手繪的架構圖與實際的技術架構會出現很大偏差。
· 架構變更可回溯。架構圖的每一次修改都會歸檔為歷史記錄,我們可以回溯每一次變更。
· 架構圖可以一鍵部署成應用。這個能力對微服務的應用太有幫助了,一般一個應用會有好幾套環境:生產環境、測試環境、開發環境、預發布環境、有的還有特性分支開發環境。比如,有個應用有30個微服務,傳統方式下,每部署一套新的環境出來都是巨大的工作量和資源消耗。但基于一鍵部署的能力,這個事情變得非常簡單。
· 封裝K8s。K8s的學習成本很高,而架構圖上的配置封裝了K8s,開發人員不需要懂K8s,就可以輕易將應用部署到K8s上,充分利用K8s的能力。
· Design once and run anywhere。一處開發,交付到任何云。架構圖設計一次,將整個應用完整描述,部署的時候,直接部署到任何云,比如阿里云、騰訊云、自己公司的私有云。
其實,一言以蔽之,架構圖的作用體現的就是云原生的本質——以應用為中心。什么叫以應用為中心?就是完整的描述應用,然后一鍵部署成應用,可以交付到任何地方。底層資源只是應用的附屬,底層資源的生命周期跟應用完全綁定,創建應用時自動創建資源,應用負載高時自動擴資源,應用銷毀時自動回收資源,開發人員完全不用關注底層資源。而在我們平臺上,應用的完整描述就是可視化的架構圖。
再來暢想一下,有了這張架構圖,是不是能發揮更多的作用?應用開發過程的所有協作活動是不是可以基于這張圖?應用開發過程的所有活動的入口是不是也可以基于這張圖?比如執行測試、比如代碼評審。
平臺的架構圖是什么?
最后,咱們來給平臺的架構圖做個定義:以應用為中心,完整描述應用技術架構,能夠直接部署成應用并交付到任何地方的一張圖。