前言
云原生在國(guó)內(nèi)外發(fā)展得如火如荼，其實(shí)對(duì)云原生的理解，大家可能不盡相同。
有人認(rèn)為，云原生跟我沒關(guān)系，我用原來的方式就挺好。
有人認(rèn)為，云原生就是Kubernetes。
我們先來澄清一下云原生是什么？
云原生 = 微服務(wù) + DevOps + CICD + 容器云
云原生應(yīng)用技術(shù)架構(gòu)演進(jìn)方向
從技術(shù)架構(gòu)上來說，云原生的技術(shù)架構(gòu)應(yīng)該滿足如下特點(diǎn)：
1. 微服務(wù)。應(yīng)用的架構(gòu)應(yīng)該是微服務(wù)的，且是基于K8s的。
2. 韌性。應(yīng)用的各個(gè)服務(wù)應(yīng)該具有強(qiáng)韌性，即故障自愈能力。應(yīng)用部署在K8s上，且提供健康檢查接口，就能做到強(qiáng)韌性。
3. 彈性。應(yīng)用的各個(gè)服務(wù)應(yīng)該具有強(qiáng)彈性，能根據(jù)負(fù)載情況彈性伸縮。應(yīng)用是微服務(wù)的，各個(gè)服務(wù)是無狀態(tài)的，且應(yīng)用部署在K8s上，就能做到強(qiáng)彈性。
聽上去很容易做到，對(duì)于應(yīng)用服務(wù)而言，確實(shí)難度不大。但，技術(shù)架構(gòu)上還有另外的重要組成部分——中間件，想要做到韌性和彈性，還有較長(zhǎng)的路要走，云原生中間件的采用會(huì)越來越流行。
云原生應(yīng)用架構(gòu)管理演進(jìn)方向
由于采用微服務(wù)架構(gòu)，云原生應(yīng)用技術(shù)架構(gòu)會(huì)變得越來越復(fù)雜，包括橫向堆疊、縱向嵌套等多重組合、各種服務(wù)的配置、中間件的配置等等。
復(fù)雜是萬惡之源。復(fù)雜就需要有有效的手段來管理，人是這樣，架構(gòu)也是這樣。突然發(fā)現(xiàn)，我們好像沒有合適的手段來管理越來越復(fù)雜的技術(shù)架構(gòu)圖。傳統(tǒng)的方式有如下幾種：
1. 在架構(gòu)師或者研發(fā)leader的腦海里。
2. 架構(gòu)描述在文件上，紙質(zhì)的或者電子檔。
第一種方式，弊端很大，大腦是用來進(jìn)行高性能計(jì)算的，而不是用來存儲(chǔ)的，時(shí)間久一點(diǎn)，就沒人知道應(yīng)用的技術(shù)架構(gòu)了。更麻煩的是，如果架構(gòu)師離職，完全沒人知道應(yīng)用的技術(shù)架構(gòu)了。這時(shí)候，代碼改起來，研發(fā)童鞋戰(zhàn)戰(zhàn)兢兢，一不小心就踩中隱藏的雷線，想敏捷也敏捷不起來了。
第二種方式，聽上去很不錯(cuò)，很多團(tuán)隊(duì)也是這么干的，而實(shí)質(zhì)是，架構(gòu)文檔的更新總是落后于實(shí)際的應(yīng)用技術(shù)架構(gòu)，往往是應(yīng)用更新了好多個(gè)版本了，才去更新一下架構(gòu)文檔。并且，相對(duì)而言，敏捷不太看重文檔。這種方式跟第一種方式?jīng)]太大差別，五十步笑百步。
那有沒有更好的辦法呢？當(dāng)然！
我們稍微思考一下，第二種方式的弊端在于，技術(shù)架構(gòu)跟實(shí)際應(yīng)用不對(duì)應(yīng)，我們只需要找個(gè)辦法，讓技術(shù)架構(gòu)與實(shí)際應(yīng)用對(duì)應(yīng)起來就行了。參考一下3D打印技術(shù)，比如，我們要3D打印一個(gè)杯子，先用一個(gè)描述文件完整描述這個(gè)杯子，然后把這個(gè)文件以及原材料喂給一臺(tái)3D打印機(jī)，3D打印機(jī)就能打印出杯子。類似的，我們可以用一個(gè)描述文件來描述應(yīng)用的技術(shù)架構(gòu)，再把這個(gè)文件交個(gè)一個(gè)應(yīng)用的“3D打印機(jī)”（應(yīng)用部署引擎），然后就“打印”出應(yīng)用。要做到這些其實(shí)并不難，滿足這幾點(diǎn)就行了：
1. 應(yīng)用的技術(shù)架構(gòu)描述文件必須標(biāo)準(zhǔn)化。這樣才能被應(yīng)用部署引擎識(shí)別和執(zhí)行。
2. 應(yīng)用的部署和更新必須通過描述文件來執(zhí)行，確保一致性。
3. 應(yīng)用的技術(shù)架構(gòu)描述文件圖形化——架構(gòu)圖，所見即所得。
這么做了之后，還會(huì)帶來額外的好處：
1. 應(yīng)用的技術(shù)架構(gòu)描述文件，作為企業(yè)重要的數(shù)據(jù)資產(chǎn)，本身具有版本管理，方便追溯和交付任意版本的應(yīng)用。
2. 應(yīng)用的技術(shù)架構(gòu)圖一目了然，拉齊信息，方便團(tuán)隊(duì)成員對(duì)架構(gòu)的理解。
3. 基于可視化的技術(shù)架構(gòu)圖，還可以進(jìn)行任務(wù)分配、團(tuán)隊(duì)協(xié)作。
4. 架構(gòu)圖可以一鍵部署成應(yīng)用。這個(gè)能力對(duì)微服務(wù)的應(yīng)用太有幫助了，一般一個(gè)應(yīng)用會(huì)有好幾套環(huán)境：生產(chǎn)環(huán)境、測(cè)試環(huán)境、開發(fā)環(huán)境、預(yù)發(fā)布環(huán)境、有的還有特性分支開發(fā)環(huán)境。比如，有個(gè)應(yīng)用有30個(gè)微服務(wù)，傳統(tǒng)方式下，每部署一套新的環(huán)境出來都是巨大的工作量和資源消耗。但基于一鍵部署的能力，這個(gè)事情變得非常簡(jiǎn)單。
5. Design once and run anywhere。一處開發(fā)，交付到任何云。架構(gòu)圖設(shè)計(jì)一次，將整個(gè)應(yīng)用完整描述，部署的時(shí)候，直接部署到任何云，比如阿里云、騰訊云、自己公司的私有云。
對(duì)于沒有畫這種“架構(gòu)圖”的應(yīng)用，怎么辦？
我們能立刻想到的辦法是把架構(gòu)圖補(bǔ)起來，但如果記得不太清楚了，怎么辦？前面架構(gòu)管理的思路是從架構(gòu)圖到應(yīng)用，我們是不是想個(gè)辦法，來個(gè)逆向工程，從應(yīng)用到架構(gòu)圖？比如，提供一個(gè)工具，能基于運(yùn)行中的應(yīng)用，各服務(wù)和中間件的實(shí)際調(diào)用流量、調(diào)用日志、以及各服務(wù)的對(duì)應(yīng)代碼庫(kù)，自動(dòng)分析出應(yīng)用的技術(shù)架構(gòu)圖？應(yīng)用即架構(gòu)、架構(gòu)即應(yīng)用。
寫在最后
本文跟大家聊了云原生技術(shù)架構(gòu)的演進(jìn)方向、云原生架構(gòu)管理的演進(jìn)方向，我們的產(chǎn)品CloudOS/Methodot （CloudOS是私有云產(chǎn)品，Methodot是SaaS）正是沿著這個(gè)方向在做。
如果您也感興趣，歡迎大家體驗(yàn)。
CloudOS
企業(yè)云原生數(shù)字化創(chuàng)新平臺(tái)（CloudOS），為企業(yè)構(gòu)建敏捷創(chuàng)新的應(yīng)用研發(fā)環(huán)境，實(shí)現(xiàn)應(yīng)用研發(fā)可視化、敏捷化和技術(shù)平臺(tái)標(biāo)準(zhǔn)化，讓傳統(tǒng)應(yīng)用研發(fā)人員快速實(shí)現(xiàn)云原生應(yīng)用創(chuàng)新，加快企業(yè)數(shù)字化轉(zhuǎn)型。提供可視化操作界面，通過WEB頁(yè)面完成架構(gòu)設(shè)計(jì)、API管理、在線開發(fā)、API自動(dòng)化測(cè)試、多云發(fā)布、多云應(yīng)用調(diào)度、應(yīng)用運(yùn)維等云原生應(yīng)用全生命周期管理。支撐傳統(tǒng)應(yīng)用遷移上云，助力傳統(tǒng)應(yīng)用研發(fā)團(tuán)隊(duì)高效完成云原生應(yīng)用創(chuàng)新。
立即免費(fèi)體驗(yàn)>>
讓企業(yè)都能高效創(chuàng)新
企業(yè)云原生數(shù)字化創(chuàng)新平臺(tái)CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發(fā)者專屬一站式在線服務(wù)Methodot
