重新理解雲原生

雲原生的本質和最終效果

要明白什麼是雲原生，就要先弄明白雲計算是什麼，有什麼問題。雲計算將計算資源、網絡、存儲等基礎設施統一管理，通過資源規模化和自動化管理，實現降低資源的成本和提高資源的管理效率。

雲計算本質上解決的是資源的自動化管理問題，但數字化和信息化的關鍵在應用，雲計算沒有解決應用的管理問題，應用的管理和運維是難題，對人依賴度很高，雲原生的出現就是爲了解決應用的管理問題。

應用管理比資源管理複雜很多，涉及到應用開發、應用架構、應用交付和應用運維等應用層的管理，還要配合應用解決資源自動化管理問題，雲原生本質就是解決應用的自動化管理問題。

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

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

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

爲了實現應用管理自動化，還有很多雲原生相關的技術，像 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 周邊的很多概念和技術。

  2. 已有應用需要改造，開發習慣需要改變。已有的應用要運行在 Kubernetes 上，需要會寫 Dockerfile 和 YAML，如果要改造成微服務架構，還需要按照框架的 SDK 改造代碼，跟之前的開發習慣會有很大變化。

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

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

雲原生落地的難點在使用，如果能將雲原生底層複雜的技術包裝成開發者熟悉的應用層屬性和動作，開發者就不用學習新的概念和技術；如果能將業務跟運維能力解耦，跟微服務框架解耦，就能實現開發者按需擴展運維能力和切換微服務框架，實現對業務按需賦能；如果能實現根據不同客戶類型，自定義交付流程和自動化交付，就能大大降低交付成本，提升客戶滿意度。

當以上三點都能解決，就可以讓開發者聚焦在業務本身，業務之外的事情不用關心，有更多精力關注客戶價值輸出。

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

應用抽象模版核心設計在三方面：

  1. 應用級抽象

  2. 架構充分解耦

  3. 使用應用模版交付

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

應用級抽象是 “以應用爲核心” 的抽象模型，對用戶暴露應用級的概念、屬性和動作，底層 Kubernetes 和系統級的概念和技術，要麼完全實現自動化，要麼包裝成應用級的屬性和動作。

爲了實現靈活的應用編排和自動化調度，Kubernetes 定義了很多概念，提供豐富的擴展機制，並以 YAML 的方式跟它交互，Kubernetes 的這些可編程的體驗，對管理和擴展 Kubernetes 的人來說，是非常好的特性，但對於普通開發者，門檻太高，並且很多概念和技術跟自己開發的業務並沒有直接關係，所以對於普通開發者來說需要更加友好的操作體驗，不需要學習就能使用。

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

1IsSHj

應用級抽象並不是要將 Kubernetes 概念全部隱藏起來，而是對於不同的使用者，職責不同展現不同的交互界面。對普通開發者職責是開發業務，只需要關心應用級的概念，提供應用級的操作界面。

但對於雲原生平臺的管理人員，除了關心應用級的概念，還要關心 Kubernetes 的管理和維護，有能力的話還可以擴展平臺的能力，所以對於平臺管理人員，提供高級的暴露 Kubernetes 概念的操作界面，或者直接操作 Kubernetes 也可以管理平臺上的應用，通過這種方式也規避了，由於包裝概念產生的 “黑箱” 導致對平臺的可觀測性和可掌控性不足。

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

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

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

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

NJqu8e

按照 Pod 機制實現的插件只能擴展單個業務容器的能力，而要對應用擴展微服務架構能力，需要對每一個業務容器擴展服務治理的插件，這跟 Service Mesh 的實現機制一致。

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

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

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

應用模型以應用模版的形式具象化展現和存儲，應用由源碼、容器鏡像和插件拼裝而成，然後一鍵導出成應用模版，應用模版設計主要圍繞使用者，讓使用者能用起來，讓應用交付併產出價值，從而拉動應用的迭代和開發。

從使用體驗上，應用模版可以一鍵安裝和一鍵升級，通過 “拖拉拽” 的方式實現業務拼裝。應用模版有很強靈活性，應用模版支持不同顆粒度大小，模版和模版能拼裝出新的模版，新的模版還可以持續拼裝，顆粒的大小由使用者決定，由使用者賦予它意義。應用模版可以交付到兼容 Kubernetes API 的分支版本，實現一鍵安裝和升級，或將應用模版存放到應用市場，實現即點即用的效果。

應用模版需要具備四個特點：

通過應用模版實現可複用模塊和能力的打包。應用的架構充分解耦後，業務組件和擴展插件理論上可以複製到其他應用中，但直接複製代碼或鏡像非常低效，而且還有很多運行環境相關的配置需要考慮，將業務組件和擴展插件打包成應用模版，並將應用模版發佈到應用市場供其他人使用，可以最大程度實現模塊和能力的複用，減少重複造輪子。

通過應用模版實現 SaaS、私有化和離線環境的自動化交付，和個性化場景模塊拼裝。應用模板中包含應用運行態所需的全部資源，對接到客戶運行環境，就可以實現一鍵安裝和運行，屏蔽了客戶環境差異，一套產品模版可以交付所有類型客戶，對於離線環境，應用模版以文件的形式導出，到客戶離線環境再導入運行即可。

對於功能需要個性化的場景，利用應用模版對業務模版打包的能力，先拼裝已經模塊化的能力，然後再定製化開發，新開發的功能，如果可複用還可以繼續發佈成應用模版，供後續複用。

不懂 Kubernetes 實現雲原生的體驗

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

開發應用的體驗：

  1. 代碼無需改動，就能變成雲原生應用。對於新業務或已有業務，代碼不需要改動就能將其容器化。不需要懂 Docker 、Kubernetes 等技術，就能將應用部署起來，具備雲原生應用的全部特性。

  2. 業務積木式拼裝編排。可複用的業務模塊積累到應用市場，當由新業務需要開發，基於應用市場已經業務模塊，通過 “拖拉拽” 的方式拼裝，然後再開發沒有的業務能力，當積累的業務模塊越多，開發新業務的速度越快。

  3. 開箱即用的 Service Mesh 微服務架構，並可一鍵更換 Service Mesh 框架。不用學習微服務框架的 SDK，通過無侵入的方式實現 Service Mesh 微服務架構，主流的 Service Mesh 框架以插件的形式存在，需要時開啓，如果覺得不好還可以隨時更換。

使用應用的體驗：

  1. 像安裝手機 App 一樣安裝雲原生應用。雲原生應用以應用模版的形式存放到應用市場，當對接各種基礎設施或雲資源，實現應用即點即用或一鍵安裝 / 升級。

  2. 普通開發者不需要學習就能實現應用運維。通過應用級抽象，普通開發者瞭解應用級屬性就能實現應用運維，並通過插件擴展監控、性能分析、日誌、安全等運維能力，應用運維不再需要專用的 SRE。

  3. 複雜應用一鍵交付客戶環境。複雜應用發佈成應用模版，當客戶環境可以聯網，對接客戶環境一鍵安裝運行，當客戶環境不能聯網，導出離線應用模版，到客戶環境導入並一鍵安裝運行。

實現方案

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/9XEVZcA8jwAEeS0TIaQ3xw

猜你喜歡