## 雲原生的本質和最終效果

要明白什麼是雲原生，就要先弄明白雲端計算是什麼有什麼問題，雲端計算將計算資源、網路、儲存等基礎設施統一管理，透過資源規模化和自動化管理，實現降低資源的成本和提高資源的管理效率，雲端計算本質上解決的是資源的自動化管理問題，但數字化和資訊化的關鍵在應用，雲端計算沒有解決應用的管理問題，應用的管理和運維是難題，對人依賴度很高，**雲原生的出現就是為了解決應用的管理問題，應用管理比資源管理複雜很多，涉及到應用開發、應用架構、應用交付和應用運維等應用層的管理，還要配合應用解決資源自動化管理問題，雲原生本質就是解決應用的自動化管理問題。**
![](https://grstatic.oss-cn-shanghai.aliyuncs.com/case/2022/09/13/16623088574185.jpg)

**從效果來看，雲原生的最終目標是讓開發者聚焦自己的業務，業務之外（基礎設施、應用架構、應用運維）的事情不用關心，只需要懂業務就能創造出自己想要的應用，並能按需交付客戶。**

## 使用 Kubernetes 落地雲原生困難重重

當前雲原生相關的技術很多，其中最關鍵是容器、微服務架構、Kubernetes ，他們顛覆式的解決了應用管理自動化問題。

- **容器技術解決了應用打包和部署自動化問題，透過容器打包保證了應用基礎環境的一致性，實現了一次打包，處處執行。同時容器可以定義應用執行資源，部署時按需佔用資源，實現從應用角度解決資源管理自動化。**

- **微服務架構解決了複雜應用的解耦和治理問題，當業務越大越複雜，微服務架構將業務拆分和解耦成多個模組，並透過服務治理實現微服務執行和管理的自動化。**

- **Kubernetes解決了應用編排和排程自動化問題，它是應用自動化管理最關鍵的拼圖，底層基於容器、SDN、SDS，能實現各型別應用和微服務部署和運維過程自動化。**

為了實現應用管理自動化，還有很多雲原生相關的技術，像SDN（網路自動化管理）、SDS（儲存自動化管理）、Helm（複雜應用交付自動化）、Service Mesh（無侵入擴充套件服務治理能力）、Monitoring（監控自動化）、Logging（日誌自動化）、Tracing（效能分析自動化）、Chaos engineering（容錯自動化）、Gateway（閘道器自動化）、SPIFFE （應用訪問安全自動化）等等，這些技術可以跟Kubernetes結合起來使用，解決應用各個運維特徵的管理自動化問題。

上面這些技術主要圍繞著Kubernetes，所以落地過程主要是Kubernetes落地，Kubernetes落地過程一般分為兩部分，Kubernetes的搭建和Kubernetes的使用。對於Kubernetes搭建，基於以上技術自主搭建完整的Kubernetes叢集非常複雜，既要學習這些技術還要了解他們的原理，最困難的是要把他們有機的組裝起來。不過大多公司有專職的維護工程師，可以抽出大把時間來學習和嘗試。或者，選擇公有云廠商提供的Kubernetes商業服務，所以，搭建Kubernetes是有路徑落地的。

相比搭建Kubernetes，Kubernetes的使用一般是開發人員，開發人員人數眾多，使用習慣和學習門檻決定了開發人員的接受度，而云原生平臺的使用不僅要改變開發習慣，還要學習很多新技術，落地過程困難重重。

1. **需要學習很多新概念和技術。** 雲原生相關的技術和概念有很多，光 Kubernetes就有很多新的概念和抽象，像Workload、Pod、Service、Ingress、ConfigMap、PV等，如果要用好還需要學習Kubernetes周邊的很多概念和技術。
1. **已有應用需要改造，開發習慣需要改變。** 已有的應用要執行在 Kubernetes上，需要會寫 Dockerfile 和 YAML，如果要改造成微服務架構，還需要按照框架的SDK改造程式碼，跟之前的開發習慣會有很大變化。

1. **如何將應用高效交付給客戶，Kubernetes及上面這些技術並沒有解決。**  應用只有交付給客戶才能產出價值，當前交付客戶的自動化程度不高，Kubernetes並沒有解決交付過程自動化的問題。在 To C的場景，業務頻繁迭代，交付的頻率很高，需要保質保量。在To B場景，交付更加複雜，不同的客戶有不同的要求，需要針對不同客戶有不同的交付模式，比如SaaS、私有交付、離線交付、個性化交付等，交付也是成本里的大頭。

## 應用抽象模型是雲原生可落地的關鍵（實現思路）

雲原生落地的難點在使用，如果能將雲原生底層複雜的技術包裝成開發者熟悉的應用層屬性和動作，開發者就不用學習新的概念和技術；如果能將業務跟運維能力解耦，跟微服務框架解耦，就能實現開發者按需擴充套件運維能力和切換微服務框架，實現對業務按需賦能；如果能實現根據不同客戶型別，自定義交付流程和自動化交付，就能大大降低交付成本，提升客戶滿意度；當以上三點都能解決，就可以讓開發者聚焦在業務本身，業務之外的事情不用關心，有更多精力關注客戶價值輸出。

**基於以上思考，透過應用抽象模型是個解決思路，對應用整體進行包裝和抽象，包含應用執行所需的全部執行定義，與底層技術和概念隔離。向上使用者不需要再學習和了解系統級概念和技術，應用內部把業務和擴充套件能力解耦，使用應用級概念開發和管理，需要擴充套件服務治理、運維、安全等能力時按需開啟外掛。向下則包裝Kubernetes的概念和抽象，遮蔽掉底層基礎設施的差異，實現應用抽象模型可以執行在各類基礎設施上。**

![](https://grstatic.oss-cn-shanghai.aliyuncs.com/case/2022/09/13/16626159240760.jpg)

應用抽象模版核心設計在三方面：
1. 應用級抽象
2. 架構充分解耦
3. 使用應用模版交付

### 應用級抽象能簡化理解和使用

**應用級抽象是“以應用為核心”的抽象模型，對使用者暴露應用級的概念、屬性和動作，底層Kubernetes和系統級的概念和技術，要麼完全實現自動化，要麼包裝成應用級的屬性和動作。**  為了實現靈活的應用編排和自動化排程，Kubernetes 定義了很多概念，提供豐富的擴充套件機制，並以YAML的方式跟它互動，Kubernetes的這些可程式設計的體驗，對管理和擴充套件Kubernetes的人來說，是非常好的特性，但對於普通開發者，門檻太高，並且很多概念和技術跟自己開發的業務並沒有直接關係，所以對於普通開發者來說需要更加友好的操作體驗，不需要學習就能使用。

![](https://grstatic.oss-cn-shanghai.aliyuncs.com/case/2022/09/13/16625298435470.jpg)

應用級抽象和Kubernetes概念 粗粒度的對應關係：

| 應用級屬性       | Kubernetes概念 |
|------------------|----------------|
| 應用執行環境     | Containers     |
| 應用執行屬性     | Workload       |
| 應用網路屬性     | SDN            |
| 應用儲存屬性     | SDS            |
| 應用對外服務屬性 | Ingress        |
| 應用對內服務屬性 | Service        |
| 應用外掛         | Pod            |
| 應用配置         | ConfigMap      |

**應用級抽象並不是要將Kubernetes概念全部隱藏起來，而是對於不同的使用者，職責不同展現不同的互動介面。** 對普通開發者職責是開發業務，只需要關心應用級的概念，提供應用級的操作介面。但對於雲原生平臺的管理人員，除了關心應用級的概念，還要關心Kubernetes的管理和維護，有能力的話還可以擴充套件平臺的能力，所以對於平臺管理人員，提供高階的暴露Kubernetes概念的操作介面，或者直接操作Kubernetes也可以管理平臺上的應用，透過這種方式也規避了，由於包裝概念產生的“黑箱”導致對平臺的可觀測性和可掌控性不足。

### 架構充分解耦，根據使用場景按需組合

基於應用級的抽象，應用模型透過標準的Kubernetes API實現跟基礎設施的解耦，所有符合標準Kubernetes API 的基礎設施都可以實現對接和部署，比如各公有云廠商的Kubernetes實現、K3s、KubeEdge等，透過這樣的解耦，開發者只需要關心業務和能力擴充套件，不用在關心基礎設施的差異，對接應用模型的應用不需要改動就能透明部署到公有云、私有云和邊緣裝置上，實現了應用級多雲。

通常在應用裡，還會包括一些跟業務無關的功能，他們的作用是為了讓應用更好的執行，比如：服務治理、微服務框架、運維工具、安全工具等，這些能力跟應用有強耦合關係的，需要改程式碼擴充套件能力，將這部分能力解耦，應用就只需要關注在業務了，而且擴充套件的能力有很強的複用性，其他應用也需要。

應用中擴充套件能力的解耦使用 Kubernetes 的 Pod，Pod中包含一個或多個容器，所有容器共享網路、儲存，應用執行在一個容器，擴充套件的能力透過擴充套件容器的方式執行，透過共享的網路和儲存實現了應用和擴充套件能力的解耦，這種解耦方式對業務完全無侵入，擴充套件的能力用外掛的形式包裝，就可以實現應用按需安裝和啟動外掛，根據網路流向和容器啟動順序可以定義幾種型別外掛：

| 外掛型別 | 說明                     |
|----------|--------------------------|
| 入口網路外掛 | 網路流量先到入口網路外掛，然後到業務容器。例如：閘道器、WAF、安全工具、限流   |
| 出口網路外掛 | 網路流量先到業務容器，然後到外掛容器。例如：負載均衡、斷路器、加密訪問 |
| 出入網路外掛 | 網路流量先到外掛容器，再到業務容器，再回到外掛容器。例如：Service Mesh proxy       |
| 旁路外掛     | 網路上旁路執行。例如：效能分析、監控 、呼叫鏈分析、日誌管理       |
| 初始化 外掛  | Pod的Init容器，Pod啟動先啟動Init容器。例如：資料庫初始化             |

![](https://grstatic.oss-cn-shanghai.aliyuncs.com/case/2022/09/13/16629874136151.jpg)

按照Pod機制實現的外掛只能擴充套件單個業務容器的能力，而要對應用擴充套件微服務架構能力，需要對每一個業務容器擴充套件服務治理的外掛，這跟Service Mesh的實現機制一致，Service Mesh的Data Plane需要對每個業務容器注入Proxy，對於完整應用就是擴充套件Service Mesh能力，對完整應用擴充套件的能力是應用級外掛，根據注入Proxy的差異可以支援多種型別的Service Mesh 實現，比如：Istio、Linkerd、Dapr，應用可以按需開啟Service Mesh 能力，或更換實現框架。當應用跟微服務架構解耦，每一個業務容器不再受微服務框架和開發語言限制，每個業務容器只需要專注業務本身，業務容器之間也同步實現瞭解耦。

**透過將架構充分的解耦，解耦後的業務、外掛、對接多雲的能力都能實現隨意組合，開發者選擇喜歡的開發語言開發業務元件，根據業務契約編排依賴關係，根據服務治理和執行穩定性要求，按需開啟Service Mesh外掛和其他運維外掛，執行的基礎設施環境，也根據實際需要自動對接。**

### 應用模版成為能力複用和應用交付的載體

應用模型以應用模版的形式具象化展現和儲存，應用由原始碼、容器映象和外掛拼裝而成，然後一鍵匯出成應用模版，應用模版設計主要圍繞使用者，讓使用者能用起來，讓應用交付併產出價值，從而拉動應用的迭代和開發。從使用體驗上，應用模版可以一鍵安裝和一鍵升級，透過“拖拉拽”的方式實現業務拼裝。應用模版有很強靈活性，應用模版支援不同顆粒度大小，模版和模版能拼裝出新的模版，新的模版還可以持續拼裝，顆粒的大小由使用者決定，由使用者賦予它意義。應用模版可以交付到相容Kubernetes API的分支版本，實現一鍵安裝和升級，或將應用模版存放到應用市場，實現即點即用的效果。

![](https://grstatic.oss-cn-shanghai.aliyuncs.com/case/2022/09/13/16629938514408.jpg)

**應用模版需要具備四個特點：**
* **模組化，可以形成可複用的能力單元，按需拼裝使用場景。**
* **自治，自給自足，可以獨立安裝、升級和管理，確保組合的靈活性。**
* **可編排，模版和模版可以拼裝出新模版，具備無限拼裝能力。**
* **可發現，透過內部服務和外部服務兩種方式體現，可供業務和技術、開發者和其他應用訪問。**

**透過應用模版實現可複用模組和能力的打包。** 應用的架構充分解耦後，業務元件和擴充套件外掛理論上可以複製到其他應用中，但直接複製程式碼或映象非常低效，而且還有很多執行環境相關的配置需要考慮，將業務元件和擴充套件外掛打包成應用模版，並將應用模版釋出到應用市場供其他人使用，可以最大程度實現模組和能力的複用，減少重複造輪子。

**透過應用模版實現SaaS、私有化和離線環境的自動化交付，和個性化場景模組拼裝。** 應用模板中包含應用執行態所需的全部資源，對接到客戶執行環境，就可以實現一鍵安裝和執行，遮蔽了客戶環境差異，一套產品模版可以交付所有型別客戶，對於離線環境，應用模版以檔案的形式匯出，到客戶離線環境再匯入執行即可。對於功能需要個性化的場景，利用應用模版對業務模版打包的能力，先拼裝已經模組化的能力，然後再定製化開發，新開發的功能，如果可複用還可以繼續釋出成應用模版，供後續複用。

## 不懂 Kubernetes 實現雲原生的體驗

基於以上的設計思路，讓開發者專注於業務本身，回到使用者效果和價值體現的原點上，不用關心底層複雜的技術和不相關的概念，全面實現應用自動化。

開發應用的體驗：

1. **程式碼無需改動，就能變成雲原生應用。** 對於新業務或已有業務，程式碼不需要改動就能將其容器化。不需要懂 docker 、Kubernetes 等技術，就能將應用部署起來，具備雲原生應用的全部特性。
2. **業務積木式拼裝編排。** 可複用的業務模組積累到應用市場，當由新業務需要開發，基於應用市場已經業務模組，透過“拖拉拽”的方式拼裝，然後再開發沒有的業務能力，當積累的業務模組越多，開發新業務的速度越快。
3. **開箱即用的Service Mesh微服務架構，並可一鍵更換Service Mesh框架。** 不用學習微服務框架的SDK，透過無侵入的方式實現Service Mesh微服務架構，主流的Service Mesh框架以外掛的形式存在，需要時開啟，如果覺得不好還可以隨時更換。

使用應用的體驗：

1. **像安裝手機 App 一樣安裝雲原生應用。**  雲原生應用以應用模版的形式存放到應用市場，當對接各種基礎設施或雲資源，實現應用即點即用或一鍵安裝/升級。
2. **普通開發者不需要學習就能實現應用運維。**  透過應用級抽象，普通開發者瞭解應用級屬性就能實現應用運維，並透過外掛擴充套件監控、效能分析、日誌、安全等運維能力，應用運維不再需要專用的SRE。
3. **複雜應用一鍵交付客戶環境。** 複雜應用釋出成應用模版，當客戶環境可以聯網，對接客戶環境一鍵安裝執行，當客戶環境不能聯網，匯出離線應用模版，到客戶環境匯入並一鍵安裝執行。

## 實現方案

基於上面的設計思路，我們在Kubernetes基礎上實現了[Rainbond](https://www.rainbond.com/)，並將它[開源](https://github.com/goodrain/rainbond)。Rainbond提供開箱即用的體驗，使用簡單，不需要懂容器和Kubernetes，支援管理多種Kubernetes叢集，提供企業級應用的全生命週期管理。主要功能包括應用開發環境、應用市場、微服務架構、應用交付、應用運維、應用級多雲管理等。

不懂 Kubernetes 實現雲原生是什麼體驗？

相關文章