云原生體系下的技海浮沉與理論探索

作者 | 王銀利(蕓崢)

1 . 概述

攻技者，短之；理論者，長之；踐行者，勝之，可以這么說，一座城市的良心就體現在下水道上，不論這座城市有多少高樓大廈，建設得有多么宏偉，只要是下雨天，雨水就變成了城市良心的檢驗者，如果由城市建設來類比云原生體系的建設，那么云原生的良心又應該是什么？誰是云原生的暴風雨？誰又是云原生良心的檢驗者？

云原生帶來的業務價值非常多，主要有如下幾條：
1）快速迭代：天下武功，唯快不破，我們想要在殘酷的市場競爭中爭得一席之地，就必須先發制人，云原生的本質就是幫助業務快速迭代，核心要素就是持續交付，
2）安全可靠：云原生通過可觀測機制，可以快速讓我們從錯誤中恢復，同時通過邏輯多租和物理多租等多種隔離方式，限制非法使用，
3）彈性擴展：通過將傳統的應用改造為云原生應用，做到彈性擴縮容，能夠更好地應對流量峰值和低谷，并且達到降本提效的目的，
4）開源共建：云原生通過技術開源能夠更好地幫助云廠商打開云的市場，并且吸引更多的開發者共建生態，從一開始就選擇了一條“飛輪進化”式的道路，通過技術的易用性和開放性實作快速增長的正向回圈，又通過不斷壯大的應用實體來推動了企業業務全面上云和自身技術版圖的不斷完善，

接下來，本文將由淺入深，從云原生的方方面面進行分析，包括基礎的概念、常用的技術、一個完整的平臺建設體系，讓大家對云原生有個初步的了解，

2 . 什么是云原生

2.1 云原生的定義

云原生的定義一直在發生變化，不同的組織也有不同的理解，比較出名的有 CNCF 和 Pivotal ，下面是 CNCF 的最新定義：

云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用，云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API，

這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統，結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更，

云原生計算基金會（CNCF）致力于培育和維護一個廠商中立的開源生態系統，來推廣云原生技術，通過將最前沿的模式民主化，讓這些創新為大眾所用，

另外，作為云計算領導者，Heroku 的創始人 Adam Wiggins 整理了著名的云原生十二要素（The Twelve-Factor App：https://12factor.net/zh_cn/)，之后，同樣作為云計算領導者，Pivotal (已被VMWare收購）的 Kevin Hoffman 出版了 Beyond the 12 factor App 一書，基于原十二要素新增了三個新要素，即云原生十五要素 ，

十五要素綜合了他們關于 SaaS 應用幾乎所有的經驗和智慧，是開發此類應用的理想實踐標準，十五要素適用于任何語言開發的后端應用服務，將流程自動化和標準化，降低新員工的學習成本；并且劃清了與底層作業系統間的界限，以保證最大的可移植性，

下圖可概覽云原生所有的定義和特征：

2.2 云原生本質

從字面意思上來看，云原生可以分成云和原生兩個部分，

云是和本地相對的，傳統的應用必須跑在本地服務器上，現在流行的應用都跑在云端，云包含了 IaaS、PaaS 和 SaaS ，

原生就是土生土長的意思，我們在開始設計應用的時候就考慮到應用將來是運行在云環境上，要充分利用云資源的優點，比如?云服務的彈性和分布式優勢，

云原生既包含技術（微服務、敏捷基礎設施），也包含管理（DevOps、持續交付、康威定律、重組等），云原生也可以說是一系列云技術、企業管理方法的集合，

一、云原生不是業務本身

好幾個人問我云原生是什么，我會反問他們，如果你想自己的業務快速迭代，你希望云原生是什么，云原生一定不是一個具體的東西，而是代表了如何追求問題的本質，它本來是什么，就是什么，它是一套方法論，

云原生的本質是幫助業務快速迭代，不是業務本身，不是技術堆疊，不是生搬硬套，我們不應該看我們有什么，而要看客戶本來要的是什么，

那么云原生其實就是代表了科技的進步，我們不光要提高新業務的迭代效率，還要打破舊業務的迭換效率，一個好的架構一般會兼容人類的愚蠢，所以這里的舊業務可能是歷史包袱，可能是知識瓶頸帶來的偏見，

我們無時無刻都在變成舊，無時無刻都在創造新，人要敢于質疑自己，質疑過去，質疑權威，才有創建新的動力和洞見，

二、云原生不是云計算

云計算（Cloud Computing）和云原生（Cloud Native）有很大區別，主要體現在以下六個方面：

起源
云原生應用程式源于云原生，如前所述，它們構建并部署在云中，真正地訪問了云基礎設施的強大功能，云計算應用程式通常是在內部使用傳統基礎設施開發的，并且經過調整后可以在云中遠程訪問，

設計

云原生應用程式被設計為多租戶實體托管（微服務架構），云計算應用程式在內部服務器上運行，因此它們沒有任何多租戶實體，

便捷性

云原生應用程式是高度可擴展性，可以對單個模塊進行實時更改，而不會對整個應用程式造成干擾，云計算應用程式需要手動升級，從而會導致應用程式中斷和關閉，

價格

云原生應用程式不需要任何硬體或軟體上的投資，因為它們是在云上進行的，通常可以在被許可方獲得，因此使用起來相對便宜，云計算應用程式通常比較昂貴，因為它們需要進行基礎升級以適應不斷變化的需求，

實作

由于不需要進行硬體或軟體配置，云原生應用程式很容易快速實作，云計算應用程式需要定制特定的安裝環境，

三、云原生本身是復雜的

云原生改變的不止是技術，最終去改變的是業務，云原生既然會幫助業務快速迭代，那么業務代碼和專案流程必然會發生根本性變化，典型的就是業務越來越輕，底座越來越厚，資料處理越來越自動化，非人用戶越來越多，

接下來，我們可以從尤瓦爾赫拉利的三部簡史來窺探下云原生的本質，

21 世紀隨著人工智能的發展，人類社會將由人文主義逐漸過渡到資料主義，人類社會如果是一個比較大的資料網路，包括人類的情感都只是進化論選擇下的生物演算法，那么每一個人只是其中的一個資料處理器，可以是智人，可以是虛擬人，也可以是未來的超人類，我們可以拿共產主義和資本主義的區別來舉例，共產主義是集中式演算法，通過國家的資料網路計算每一個人的需求再進行分配；資本主義是分布式演算法，少數的資本家掌控大部分的社會資源，

可以說以前的資料是一個孤島，部署在幾個物理機上，管好自己就可以，不會影響別人，而今天不一樣，所有的應用都在線化，逐漸變成一個有生命力的資產后，應用的約束也會越來越嚴格和復雜，所有的資料流向及依賴完全是你人為難以預期的，光鋪人已經解決不了了，

云原生其實很復雜，本質是連接資料，將資料從雜亂無序處理為資訊、知識、智慧，云原生的復雜來源于它想容納更多復雜的事務和結構，但某一方面來說，云原生其實又很簡單，因為它給終端用戶帶來無窮無盡的便利和豐富功能，但又無需他們感知，復雜和簡單是相對的，底層越復雜，上層越簡單，

3 . 什么是云原生應用

什么是云原生應用呢？和云原生的關系又是什么？云原生應用的定義基本如下：

云原生應用，是指原生為在云平臺上部署運行而設計開發的應用，云原生應用不只是將應用打包成 Docker 鏡像，而且需要將鏡像部署到到 Kubernetes 容器云上運行，公平的說，大多數傳統的應用，不做任何改動，都是可以在云平臺運行起來的，只不過這種運行模式，不能夠真正享受云的紅利，我們也叫做云托管（Cloud Hosting）應用，

另外，云原生應用有各種不同的分類方式，根據業務場景，主要可以按照狀態和職能進行分類，

3.1 按狀態分類

云原生應用主要分為無狀態應用（stateless）和有狀態應用（stateful）兩類，是否有無狀態，主要體現為是否需要感知應用實體的狀態，在 Kubernetes 中，應用實體即 Pod ，有狀態應用本質上依賴于 Pod 的狀態，

3.1.1 無狀態應用

無狀態應用就是不依賴本地運行環境的應用，實體間互相不依賴，可以自由伸縮，

無狀態應用的特征：
無狀態應用的實體可類比為牲畜，無名、可丟棄；
運行的實體不會在本地存盤需要持久化的資料；
停止的實體所有資訊（除日志和監控資料外）都將丟失，

3.1.2 有狀態應用

有狀態應用就是依賴本地運行環境的應用，實體之間有依賴和啟動先后關系，需要做資料持久化，不能隨意伸縮，

有狀態應用的特征：
有狀態應用的實體可類比為寵物、有名、不可丟棄；
實體升級和灰度對啟停順序的要求，如分布式選主；
依賴實體資訊，如 ID、Name、IP、MAC、SN 等資訊；
需要做資料持久化，依賴本地檔案和配置，

3.1.3 無狀態和有狀態相互轉化

有狀態應用和無狀態應用是可以相互轉化的，大部分的中間件應用都是有狀態應用，例如 ZooKeeper、RocketMQ、etcd、MySQL 等，大部分的業務應用都是無狀態應用，例如 Web 類應用、查詢類應用等，

一、無狀態到有狀態

比如一個比較簡單的云產品，在公有云部署時，可以依賴公有云的基礎設施，所以是無狀態；但在專有云部署時，卻需要自己解決環境和對其他BaaS的依賴，所以是有狀態，這就是基礎設施和運維方式不同造成的差距，

一般情況下，我們不提倡應用之間的依賴過于復雜，尤其在專有云場景下，復雜的依賴帶來的環境問題相當多，拔蘿卜帶泥幾乎要把整個公有云搬到專有云，無論對我們還是對客戶，都是比較大的心智負擔，

二、有狀態到無狀態

業務應用本質上都應該是有狀態的，不過它可以借助中間件、運維 API、BaaS、Serverless 的能力，把有狀態轉嫁到了中間件上，而能夠被轉嫁成無狀態應用的有狀態應用又叫做“偽有狀態應用”，

通過中間件改造為無狀態

大部分業務應用可以使用公有云上的中間件產品來實作計算、存盤、網路的能力，例如 Web 應用，可以使用 RDS 等資料庫產品，通過BaaS能力開通和依賴RDS實體，只實作核心的業務邏輯即可，

通過運維 API 改造為無狀態

有特殊運維邏輯的應用可以呼叫運維 API 轉嫁運維的復雜性，例如 MetaQ 需要主備切換，這時候利用 Kubernetes 上的 etcd 提供的選主 API 給 MetaQ 實體進行打標， MetaQ 開發者就可以像無狀態應用一樣運維 MetaQ 了，

通過 Serverless 改造為無狀態

對于業務邏輯非常簡單的應用，不一定需要打包鏡像，可直接通過各種 Serverless 平臺進行開發，交給平臺來進行運維，

為了更好的識別偽有狀態，我們應該從應用的本質而非狀態去定義是否有無狀態，而對于 ZooKeeper、etcd、MySQL 這種完全依賴自身應用代碼進行運維的中間件，就算是比較徹底的有狀態應用了，很難進行改造，

那么有狀態到無狀態的轉化，有狀態是消失了嗎？有狀態其實是本質存在的，其實面向終態，不是說不去做一些運維操作，而是根據狀態變化把這些運維操作，交給平臺來處理，以期達到的期望狀態，這個程序就是生命周期的運維了，不是有狀態減少了，而是有狀態不給用戶暴露而已， Kubernetes 其實幫大家解決了 Pod 的有狀態，而對于有狀態應用，我們需要關注 Pod 的生命周期，把業務的 Operator 變成平臺的 Operator ，就是有狀態改造為無狀態的主要作業量了，

在云原生體系下，我們要盡量試著把有狀態應用轉為無狀態應用，這樣可以盡最大能力地使用云原生的福利，把可觀測和高可用都交給云平臺去保障，而開發同學只需關心離客戶最近的業務，

隨著技術的進步，有狀態應用會不斷變成無狀態應用，只有少數快取、訊息、存盤相關的中間件需要進行有狀態運維，并且慢慢下沉到底層，后面一般人根本不需要了解二者的區別，

3.2 按職能分類

云原生中的應用如果按職能來區分，可以包含業務應用和運維應用兩種，

3.2.1 業務應用

業務應用就是業務開發工程師通過 Java、Go、Python 等語言來開發業務代碼，然后打包為鏡像后部署的應用，業務應用主要用來解決業務問題，實作特定的業務功能，業務應用的交付物主要是鏡像，

在 Serverless 平臺中，業務應用也可以是一些函式代碼，可以打鏡像；也可以不打鏡像，直接部署到多語言運行環境中，

3.2.2 運維應用

由于云原生重點需要解決應用運維自動化的問題，而業務應用無法解決自身運維的問題，即自己無法管理自己，所以需要運維應用來管理業務應用，

運維應用就是運維開發工程師用 YAML、Helm 等開發的運維代碼，然后下發到 Kubernetes 上部署的應用，運維應用主要用來解決運維問題，實作特殊的運維邏輯，運維應用的交付物主要是 YAML ，

4. 云原生的理論探索

4.1 一切皆資料

其實從 DevOps 到 AIOps 之間，還有個 DataOps，Kubernetes 的面向終態就像是一個黑盒，讓人不知道運行狀態如何，就像同樣能跑到終點，你跑得快還是我跑得快沒人知道，所以相對于面向終態又出現了可觀測，用來衡量達到終態的程序是否完善，是否健康，

因此，我們在平時的設計中必須具有資料思維，進行更多的資料建模，否則可觀測也是無米之炊，我們來看看云原生的各個環節中，都有哪些資料？

我們需要編輯資源的配置，并通過 GitOps 或者 K8s 命令進行下發，也叫資料驅動，即一切皆配置資料；
資源的各種邏輯都需要執行一系列動作，執行動作可以有多種觸發方式，即一切皆執行資料；
資源內部的生命周期需要編排，資源之間的依賴關系也需要編排，本質是編排執行動作，即一切皆編排資料；
K8s 是基于事件驅動的架構，K8s 上各種資源狀態的變化，都會產生事件，即一切皆事件資料；
事件流即日志，業務記錄即日志，動作變化即日志，結構化的日志是可觀測的根本，即一切皆日志；
無論是配置指令、還是依賴編排，亦或者是事件，都是圍繞資源進行的，所有的 API 都是以資源這個主體進行呼叫，即一切皆資源資料，

4.2 多維業務組合論

經常有人跟我說，云原生的技術搞得如此火熱，整天讓我們上云，除了節省成本外，為啥我沒看出來對業務的快速交付有什么明顯幫助呢？我認為可能是你還沒找到一套特別適合云原生時代的業務架構，

有人說漢語是世界上最優秀的表意語言，因為漢語是二維語言，基礎詞匯 2000 多個，其他觸類旁通，千變萬化，形神俱佳，思維面廣闊，而英語只是一維語言，出現一個新事物，就得創造一個新單詞，沒有聲調，同類事物的單詞也看不出關聯，但在表達非海量資訊的領域比較擅長，比如編程、數理化運算式等，從這里可以類比得出結論，底層的技術用機器語言 0-1 比較便捷，而上層的業務就需要一個多維的業務模型，

可以這么說，云原生帶來的是不僅技術的發展，更是業務的深刻變革，那么我們現今有沒有一套業務模型能指導云原生時代的復雜業務呢？

典型的如微服務架構，事件驅動架構、中臺架構，但貌似都無法解決問題，筆者也進行了一些探索，發明出一套多維業務組合論，并以縱橫圖的方式來表征，

各個圖形的含義：

縱橫圖：以縱橫交錯的線條和面積塊來細分各個領域；

點：業務功能，業務組裝的最小單位；
橫向線：微平臺，PaaS，服務主體單一；
縱向線：業務軟體，SaaS；
圓柱體：業務領域或者技術領域；
面積塊：解決方案或一站式作業臺，可按租戶、產品、服務控制權限，

我們可以從圖中看出每個領域的隔離區域和拓展范圍，縱橫層會變得越來越多，領域也會分割地越來越細，

舉個例子，有一個交易系統的應用，需要依賴訊息佇列和資料庫，并且想部署到公有云的 Kubernetes 中，假設今天沒有這些分層，那么負責這個交易系統的同學，需要自己買公有云的機器，然后部署 Kubernetes ，再然后部署中間件，接著再部署交易系統，并且需要解決各種網路和穩定性問題，結果可想而知，

另外，我們還可以從技術的發展來看縱橫圖的價值，技術發展得越快，業務同學感覺事情并沒有以前那么簡單了，因為業務的復雜度在增加，同時對迭代速度要求更高，微服務、容器、中臺很多概念都是為了加速創新，解耦是為了更好的組合，那如何來把控粒度呢？這其實可以從物理學的發展看出一二，理論上人類文明進化得越高，微觀會更微，宏觀會更宏，例如量子力學和相對論，所以粒度的大小是跟當今社會的創新能力相匹配的，

未來我們要打技術生態，對于技術點的組合編排創新必然成為主旋律，可以這么說，單點技術很難發揮價值和沉淀下來，也極易被替換，靠做單點被集成去獲得生態，這條路很難長久，一個好的平臺，其中的任何一個技術點在都是可替換的，技術編排的時代到來了，云原生的最終目標是解交付，而非成本，為了更快創新，

4.3 面向終態論

面向終態論，有點類似資料驅動論，讓軟體系統更加接近人類指令的終極理論，K8s中的面向終態，回應式編程中的資料驅動，讓事件交給系統來管理，我們只需要知道自己想要什么，而不用關心如何實作，

可以說，在整個 Kubernetes 設計理念中，面向終態是其核心理念，是運維自動化的關鍵，比如我的應用需要 10 個實體，這機器故障時，幫我自動跟換一臺等，這些需求，通過宣告后提交給系統，系統會自動化的完成這些用戶期望的事情，而這種方式，就是一種面向終態的設計，面向終態設計的核心手段就是使用“宣告式API”，

下面主要以 Deployment 為例，核心邏輯是把自定義 CR（MyApp）當做終態，把 Deployment 當做運行態，通過比對屬性的不一致，撰寫相關的 Reconcile 邏輯，

一張圖解釋各種資源和 Controller 的關系：

從圖中可以得出如下結論：

replicas在My-App CR和Deployment之間的流程是單向的；

My-App驅動Deployment，Deployment驅動Pod；
Pod的狀態反饋到Deployment，Deployment的狀態反饋到My-App，然后App的狀態達到Running，

但是 Kubernetes 中的面向終態設計還不夠完整，它并沒有設計各類資源整個生命周期的終態定義，例如如何定義資源狀態機，如何依賴 BaaS 和 Config ，如何插入鉤子，如何訂閱事件并處理，如何設計完成度和健康度，

運維的本質是面向程序的，所以程序也需要定義，如同人的一生的終態是走向死亡，終態真的是我們向往的嗎？我們需要去拓寬生命的寬度，尋找幸福的意義，云原生中的運維也是類似的，所有資源都有生命周期，有生命周期就有程序，有程序就有狀態，有狀態就有狀態機，

4.4 中心管理論

云原生的本質在于連接業務或者資料，比如為了不被云廠商鎖定，就需要跨云；為了異地多活，就需要跨 Region ；邊緣計算中為了簡化管理或者組成邏輯集群，就需要跨 Kubernetes 集群，在這些場景下，中心化就是必然需要解決的問題，

可以這么說，大到一個國家，小到一個 ZooKeeper 選主，所謂的跨 XXX ，就必然有一個中心化的管理組織，一般來說，我們的物理隔離主要隔離的是資料中心，資料分為很多種，我們主要關心用于調度的資料，調度的資料都是比較簡單表征用戶的指令，我們把它叫做配置，所以云原生中的中心化管理需要一個全域的調度中心，全域配置中心，在復雜的場景下，可以在每一個物理集群中加一個可接收和決議到指令的客戶端 Agent 即可，例如 Prometheus 監控的設計就是如此，我們需要在每一個 node 節點加一個監控的 Agent 進行系統監控并搜集資料上報，

4.5 編排上移論

自己無法編排和管理自己，自身一定是自倍訓的，所以總有更上一層的物件編排自己，例如所有的集群調度系統的架構都是無法橫向擴展的，如果需要管理更多的服務器，唯一的辦法就是創建多個集群；還有容器無法編排自己，所以出現了 Kubernetes ；再有就是在分布式選主中，master 只能有一個，如果有兩個 master ，就不知道用哪個實體管理了；又比如在同一個團隊只能有一個主管，要是有兩個主管，必然這兩個主管上面還必須出現一個主管做最終的裁定，

另外，每一層的位置不是一成不變的，業務堆疊在逐漸上移，今天我們認為復雜的事，未來會全部自動化掉，

解耦的關鍵在于自倍訓，組合的關鍵在于編排，自動化的關鍵在于調度和調協，

在云原生中還有一個現象，就是很多功能都能參考到資源編排上去，例如云服務申請叫資源編排，運維調度叫資源編排，應用部署也叫資源編排，資源很大，編排也很大，資源+編排就是大上加大， Kubernetes 里一切皆資源，機器是資源，存盤和計算是資源，服務也是資源；一切組合都是編排，有依賴就有編排，連說人是非，也能說在編排誰誰？所以我們在講編排時，一定要加上一個限定詞，否則會出現定位不清的問題，

另外，編排和調度、調協也有本質區別，舉個例子，在容器平臺中，雖然調度與編排同屬一部分，但它們負責的內容并不相同，調度是將分布式系統中的閑置資源合理分配給需要運行的行程并采用容器進行封裝的程序，編排則是對系統中的容器進行健康檢查、自動擴縮容、自動重啟、滾動發布等的程序，還有我們在達到面向終態的程序中，需要設計控制器對于資源的狀態進行控制，這個程序就叫調協，更形象地說，在應用生命周期管理中，作業負載產生 Pod 是調度，掛載 Hook 是編排，消費 Event 是調協，

4.6 永不失敗論

又叫依賴相對論，唯一永遠不會失敗的系統是那些讓你活著的系統，你處在系統呼叫鏈的某個環節，相信你依賴的系統的穩定性，由它為你兜底，

下面拿業務應用的環境分層模型來舉例，我們將業務應用的環境分為測驗環境、預發環境、生產環境，業務應用依賴中間件，中間件需要運行在 Kubernetes 上，一般情況下，業務應用依賴的底層基礎設施環境一般都具有很高的可靠性，否則出大事了，所以你在測驗自己的業務應用時，主要是測驗自己的核心功能，需要相信自己的上游是穩定的，不然測驗系統的設計將極其復雜，當然在監控鏈路中，需要監控與自己業務系統相關的上游系統問題，一旦出現報警，能夠找上游系統的同學來兜底，

4.7 生命周期論

軟體的架構就是為了滿足不斷增長的業務需求，對原有的生命周期進行拆分，形成新的核心生命周期（主體不變）和非核心生命周期（主體變化），而非核心生命周期可以交由他人來完成，最后合并各子生命周期并發執行的結果，完成總的生命周期，

從技術的發展可以看出來，應用的粒度是越拆越小，更多技術上的代碼都下沉到底層基礎設施上去了，

可以毫不客氣的說，在云原生應用平臺上運維業務，主要包括 Pod 、配置、BaaS 應用、產品、解決方案等資源的運維，實作自動化的關鍵就是定義好每個資源的生命周期，并編排每個階段的鉤子和訂閱事件進行消費，

4.8 降維打擊論

近兩年有個詞很火，叫“降維打擊”，“消滅你，與你無關”，出自科幻小說《三體》，大概意思是說，用高級生物去打低級世界的生物，一打一個準，用更通俗的語言表達，就是利用錯位競爭的方式讓你永遠領先對手，在云原生中，無論是技識訓是業務，如果充滿反叛精神，敢于創新，均可產生降維打擊，降維打擊的實作有三種路徑：

量變到質變：從小到大，聚沙成塔，創新是隨時隨地可發生的，到一定程度后，云原生對業務的影響是根本性的，是可見的；

跨維空降：從左到右，彎道超車，從一個行業轉向另一個關聯的行業，比如一個做容器平臺的團隊，很容易轉向做 APaaS ；
入口壟斷：從上到下，隱藏底層實作，比如一個做技術平臺的團隊，原來用一個收費的組件，但發展起來后，很有可能自研該組件，這個收費的組件就會受到很大的影響，

另外，我們還可以根據不同的業務場景，選擇不同的研發模式：

自底而上：先從底層開始，用 MVP 最小可用原則來開發業務系統，從小的技術點開始創新，到大的組合創新，最終符合云原生的終極目標，提高交付效率 ，縮短創新迭代的周期，

自頂而下：從業務視角逐漸下推技術架構，這樣設計的系統不會偏離業務本身，重構的可能性也較小，
原生模式：本來是什么就應該用什么思路開發，舉個例子，PaaS 的開發路徑有 SaaS->PaaS、IaaS->PaaS、原生 PaaS 三種，那么哪個會搞得更好？相信大多數人會選擇原生 PaaS ，拿造車來說，不能造個輪子就投入市場吧，而必須先有一輛能跑的車，

4.9 鴻溝理論

早在 1991 年 Jeffery Moore 針對高科技行業和高科技企業生命周期的特點，提出了著名的“鴻溝理論”，這個理論基于“創新傳播學”，將創新性技術和產品的生命周期分為五個階段：創新者（Innovator）、早期使用者（Early adopters）、早期大眾（Early majority）、晚期大眾（Late majority）、落后者（Laggard），

Kubernetes 在 2017 年底成為容器編排事實標準，之后以其為核心的云原生生態持續爆發，在傳播周期上可以說已經跨過鴻溝了，進入 Early majority 早期大眾階段，開始占領潛力巨大的主流市場，

4.10 飛輪理論

飛輪效應指為了使靜止的飛輪轉動起來，一開始你必須使很大的力氣，一圈一圈反復地推，每轉一圈都很費力，但是每一圈的努力都不會白費，飛輪會轉動得越來越快，達到某一臨界點后，飛輪的重力和沖力會成為推動力的一部分，這時，你無須再費更大的力氣，飛輪依舊會快速轉動，而且不停地轉動，

飛輪效應其實也是復利效應，下面以 AWS 的崛起舉個例子， AWS 的三大支柱業務就是讓飛輪效應啟動的關鍵：
超值的 prime 會員服務，每年只要 99 美金，就能享受很多增值服務；
Markerplace 第三方賣家平臺，除了亞馬遜自己售賣的商品，其他賣家也可以進駐亞馬遜直接售賣自己的商品；
AWS 云服務，它的主要功能是向大大小小的企業提供云服務，無論你是大公司還是小企業，都可以把自己的整套 IT 系統建立在亞馬遜云服務上，性能穩定，

5 . 云原生的核心技術

云原生的技術發展十分之快，自從云原生理念提出以后，每年都有層出不窮的新技術范訓，本章節主要介紹云原生的各種常用的開源技術，

5.1 運維技術

從模板技術到配置技術，再到編程技術，運維的靈活性逐次增強，模板技術過于死板，無法抽象成現實世界的物件；編程技術雖然很靈活，但是復雜度十分高，增加了很多不可控因素，運維成本十分高，所以，從我的角度上理解，動態配置技術未來會逐漸代替模板技術，成為主流，

所以有著嚴格約束的語言好呢，還是靈活萬能的語言好呢？我認為跟它的使用場景有關，一味的統一只是抹殺了業務的豐富多彩，踐行“通用就是無用”的理論，

5.1.1 模板技術

5.1.1.1 YAML

YAML 是一個可讀性高，用來表達資料序列化的格式，在 Kubernetes 中，面向終態、資料驅動和宣告式 API ，均是通過 YAML 來體現的，

但是 YAML 無法體現面向物件的設計思想，我們很難將各種扁平的 YAML 碎片關聯起來，也無法清晰地推測事務的發展軌跡，而且在 YAML 中嵌入 JSON 和其他腳本的方式，也在把該語言變成一個蹩腳的萬能語言，為了解決 YAML 的一系列問題，社區逐漸發展出了各種增強 YAML 的技術，例如動態配置和運維框架等，如果 Kubernetes 是未來的作業系統，那么 YAML 就是未來的匯編語言，

官網：https://yaml.org/

5.1.1.2 Helm

Helm 是 Kubernetes 的軟體包管理工具，但顯然，它并不只想成為一個包管理工具，同時它還包含模板渲染、簡單的依賴配置，

Helm 依舊延續了 YAML 的缺點，只是簡單的把 YAML 堆在了一起，同時復雜的模板語法除錯成本極高，例如各種流程控制結構結合空格縮進問題，對于眼神不好的人簡直是個災難，

官網：https://helm.sh/

5.1.1.3 KUDO

Kubernetes Universal Declarative Operator，提供了一種通過宣告式構建產品級Kubernetes Operator，針對 Kubernetes 對作業負載做了一些簡單的自動化增強之外，還需要一些更復雜的場景需要手動解決，而 KUDO 就是用于來幫助開發人員全面自動化的方式，

KUDO 的包結構和 Helm 比較類似，但是在 Helm 的基礎上增加了資源的執行計劃編排，編排的動作相對于 Helm 只有 Apply ，還增加了 Delete、Toggle 等，

官網：https://kudo.dev/

5.1.1.4 MetaController

Metacontroller 是一個封裝了自定義控制器所需的大部分基礎功能的針對 Kubernetes 的擴展服務，當你通過 Metacontroller 的 API 去創建一個自定義的控制器時，你僅需要在你的控制器中提供一個你所需要的業務邏輯函式，這些業務邏輯函式會通過 webhooks 的方式被觸發，

MetaController 看起來配置簡潔，但是卻想借技術手段解決業務問題，且解決的有限，目前主要包括兩種手段：

一是為一組物件構建復合物件的控制器；二是為已經存在的物件添加新的行為，

官網：https://metacontroller.app/

5.2.2 配置技術

5.2.2.1 CUE

CUE，發音為 Q ，是一種通用且基于約束的強型別語言，旨在簡化涉及定義和使用資料的任務，CUE受到多種語言的影響，例如 BCL、GCL、LKB、Go、JSON、Swift、Typescript、Javascript、Prolog、Jsonnet、HCL、Flabbergast、Nix、JSONPath、Haskell、Objective-C 和 Python 等，

CUE 設計時考慮了云配置和相關系統，但不限于此域，它從關系編程語言中衍生出其形式主義，同時 CUE 延續了 JSON 超集的思路，在技術方面的關鍵創新在于基于集合論實作了型別設計，可以說是 BCL 思路的一種開源版實作，目前 CUE 的生態還不是很強大，沒有配套的開發工具，但是好在阿里的多個團隊正在積極研發它，

官網：https://cuelang.org/

5.2.2.2 Jsonnet

Jsonnet 是 Google 開源的一門配置語言，用于彌補 JSON 所暴露的短板，它完全兼容 JSON ，并加入了 JSON 所沒有的一些特性，包括注釋、參考、算數運算、條件運算子、陣列和物件深入、引入函式、區域變數、繼承等，Jsonnet 程式被編譯為兼容 JSON 的資料格式，簡單來說 Jsonnet 就是增強版 JSON ，

Jsonnet 的生態比較完善，無論 Jsonnet 檔案還是 Libsonnet 都有開發工具，并且還有開源的 UI 組件，目前 Promethus 和 Kubeless 都使用了該動態配置語言，

官網：https://jsonnet.org/

5.2.2.3 HCL

HCL 是 HashiCorp 構建的配置語言，HCL 的目標是構建一種人機友好的結構化配置語言，以與命令列工具一起使用，但專門針對 DevOps 工具，服務器等，HCL 也完全兼容 JSON ，也就是說 JSON 可以用作期望使用 HCL 的系統的完全有效輸入，這有助于使系統與其他系統互操作，

官網：https://github.com/hashicorp/hcl

5.2.2.4 Kusion

Kusion 主要是基于云原生基礎設施的高級專用語言及工具鏈，在不可變業務鏡像外提供 "Compile to Cloud" 的完整技術堆疊支持，Kusion 由 KCL 語言及工具鏈，KusionCtl 工具，Kusion-Models SDK 及 OCMP 實踐定義四部分組成，

KCL 是一種專用于配置定義、校驗的動態強型別配置語言，重點服務于 configuration & policy programing 場景，以服務云原生配置系統為設計目標，但作為一種配置語言不限于云原生領域，KCL 吸收了宣告式、OOP 編程范式的理念設計，針對云原生配置場景進行了大量優化和功能增強，

Kusion 由阿里內部研發，目前尚未開源，

5.1.3 編程技術

5.1.3.1 Operator

Operator 是 CoreOS 推出的旨在簡化復雜有狀態應用管理的框架，它是一個感知應用狀態的控制器，通過擴展 Kubernetes API 來自動創建、管理和配置應用實體，

一個 Operator 工程一般必須包含 CRD 和 Controller，Webhook 是可選的，如果說 Kubernetes 是 "作業系統" 的話，Operator 是 Kubernetes 的第一層應用，使用 Kubernetes "擴展資源" 介面的方式向更上層用戶提供服務，Operator 的實作方式主要包括 OperatorSDK 和 KubeBuilder ，目前 KubeBuilder 在阿里使用的比較多，

KubeBuilder：https://github.com/kubernetes-sigs/kubebuilder
OperatorSDK：https://github.com/operator-framework/operator-sdk

5.1.3.2 OperatorPlatform

希望通過設計一個通用化的 Operator 平臺來解決原生Operator的各種問題，這個平臺的核心目標包括：
簡化、標準化 Operator 撰寫（多語言、簡化框架、降低用戶門檻）；
下沉 Operator 核心能力、統一管控（中心管控所有用戶 Operator）；
提升用戶 Operator 性能（水平擴展、多集群、精簡快取）；
控制 Operator 灰度及運行時的風險（完善監控、灰度回滾能力、控制爆炸半徑、權限控制，訪問限制），

OperatorPlatform 由阿里內部研發，目前尚未開源，

5.1.3.3 Pulumi

Pulumi 是一個架構即代碼的開源專案，可在任何云上創建和部署使用容器，無服務器功能，托管服務和基礎架構的云軟體的最簡單方法，Pulumi 采用了基礎設施即代碼以及不可變基礎設施的概念，并可讓您從您最喜歡的語言（而不是 YAML 或 DSL）中獲得自動化和可重復性優勢，

Pulumi 的中心是一個云物件模型，與運行時相結合以了解如何以任何語言撰寫程式，理解執行它們所需的云資源，然后以強大的方式規劃和管理您的云資源，這種云運行時和物件模型本質上是與語言、云中立的，這就是為什么我們能夠支持如此多的語言和云平臺，

官網：https://www.pulumi.com/

5.1.3.4 Ballerina

Ballerina 是一款開源的編譯式的強型別語言，Ballerina是一種開放源代碼編程語言和平臺，供云時代的應用程式程式員輕松撰寫可以正常運行的軟體，Ballerina 是語言和平臺的組合設計，敏捷且易于集成，旨在簡化集成和微服務編程，

Ballerina 是一種旨在集成簡化的語言，基于順序圖的互動，Ballerina 內置了對通用集成模式和連接器的支持，包括分布式事務、補償和斷路器，憑借對 JSON 和 XML 的一流支持，Ballerina 能夠簡單有效地構建跨網路終端的強大集成，

官網：https://ballerina.io/

5.1.3.5 CDK8S

CDK8S 是 AWS Labs 發布的一個使用 TypeScript 撰寫的新框架，它允許我們使用一些面向物件的編程語言來定義 Kubernetes 的資源清單，CDK8S最終也是生成原生的 Kubernetes YAML 檔案，所以我們可以在任何地方使用CDK8S來定義運行的 Kubernetes 應用資源，

官網：https://cdk8s.io/

5.1.3.6 Terraform

Terraform 是一個構建、變更、和安全有效的版本化管理基礎設施的工具，Terraform 可以管理已存在和流行的服務提供商以及定制的內部解決方案，Terraform 的特性包括：架構就是代碼、執行計劃、資源圖、變更自動化等，

官網：https://www.terraform.io/

5.1.4 應用技術

5.1.4.1 OAM

以應用程式為中心的標準，用于構建云原生應用程式平臺，OAM 綜合考慮了在公有云、私有云以及邊緣云上應用交付的解決方案，提出了通用的模型，讓各平臺可以在統一的高層抽象上透出應用部署和運維能力，解決跨平臺的應用交付問題，

OAM 的核心理念如下：
第一個核心理念是組成應用程式的組件（Component），它可能包含微服務集合、資料庫和云負載均衡器；
第二個核心理念是描述應用程式運維特征（Trait）的集合，例如，彈性伸縮和 Ingress 等功能，它們對應用程式的運行至關重要，但在不同環境中其實作方式各不相同；
最后，為了將這些描述轉化為具體的應用程式，運維人員使用應用配置（Application Configuration）來組合組件和相應的特征，以構建應部署的應用程式的具體實體

官網：https://oam.dev/

5.1.4.2 KubeVela

KubeVela 是一個簡單易用且高度可擴展的應用管理平臺與核心引擎，KubeVela 是基于 Kubernetes 與 OAM 技術構建的，對于應用開發人員來講，KubeVela 是一個非常低心智負擔的云原生應用管理平臺，核心功能是讓開發人員方便快捷地在 Kubernetes 上定義與交付現代微服務應用，無需了解任何 Kubernetes 本身相關的細節，在這一點上，KubeVela 可以被認為是云原生社區的 Heroku，

官網：https://oam.dev/

5.1.4.3 OpenKruise

OpenKruise 是 Kubernetes 的一個標準擴展，它可以配合原生 Kubernetes 使用，并為管理應用容器、Sidecar、鏡像分發等方面提供更加強大和高效的能力，OpenKruise包括以下資源：

CloneSet：提供更加高效、確定可控的應用管理和部署能力，支持優雅原地升級、指定洗掉、發布順序可配置、并行/灰度發布等豐富的策略，
Advanced StatefulSet：基于原生 StatefulSet 之上的增強版本，默認行為與原生完全一致，在此之外提供了原地升級、并行發布（最大不可用）、發布暫停等功能，
SidecarSet：對 Sidecar 容器做統一管理，在滿足 Selector 條件的 Pod 中注入指定的 Sidecar 容器，
UnitedDeployment：通過多個 Subset Workload 將應用部署到多個可用區，
BroadcastJob：配置一個 Job，在集群中所有滿足條件的 Node 上都跑一個 Pod 任務，
Advanced DaemonSet：基于原生 DaemonSet 之上的增強版本，默認行為與原生一致，在此之外提供了灰度分批、按 Node label 選擇、暫停、熱升級等發布策略，

官網：https://openkruise.io/

5.2 微服務

5.2.1 BaaS

BaaS 即指業務應用依賴的后臺服務，它需要有一個服務目錄，供用戶選擇需要使用的中間件，然后通過 BaaS Plan 選擇規則，再創建完服務實體后，再通過 BaaS Connector 和 BaaS 的 Endpoint 系結，更多原理可以參看云原生應用平臺的服務中心章節，

5.2.1.1 Service Catalog

服務目錄是 Kubernetes 社區的范訓專案 Kubernetes Service Catalog 專案，旨在接入和管理第三方提供的 Service Broker ，使 kubernetes 上托管的應用可以使用 Service Broker 所代理的外部服務，

官網：https://github.com/kubernetes-sigs/service-catalog

5.2.1.2 Open Service Broker

Open Service Broker API 專案使獨立軟體供應商，SaaS 提供者和開發人員可以輕松地為運行在 Cloud Foundry 和 Kubernetes 等云原生平臺上的作業負載提供支持服務，該規范已被許多平臺和數千個服務提供商采用，它描述了一組簡單的API端點，可用于提供，獲取和管理服務產品，該專案的參與者來自 Google，IBM，Pivotal，Red Hat，SAP 和許多其他領先的云公司，

官網：https://www.openservicebrokerapi.org/

5.2.1.3 Spring Cloud Connector

Spring Cloud Connector 為在云平臺上運行的基于 JVM 的應用程式提供了一個簡單的抽象，可以在運行時發現系結的服務和部署資訊，并且支持將發現的服務注冊為 Spring Bean ，它基于插件模型，以便相同的編譯應用程式可以在本地或任何多個云平臺上進行部署，并通過 Java 服務提供程式介面（SPI）支持定制服務定義，

官網：https://cloud.spring.io/spring-cloud-connectors/

5.2.2 Service Mesh

Service Mesh 直譯過來是服務網格，目的是解決系統架構微服務化后的服務間通信和治理問題，服務網格由 Sidecar 節點組成，

5.2.2.1 Istio

Istio 提供一種簡單的方式來為已部署的服務建立網路，該網路具有負載均衡、服務間認證、監控等功能，而不需要對服務的代碼做任何改動，Istio的能力如下：
Istio 適用于容器或虛擬機環境（特別是 K8s），兼容異構架構，
Istio 使用 Sidecar（邊車模式）代理服務的網路，不需要對業務代碼本身做任何的改動，
HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡，
Istio 通過豐富的路由規則、重試、故障轉移和故障注入，可以對流量行為進行細粒度控制；支持訪問控制、速率限制和配額，
Istio 對出入集群入口和出口中所有流量的自動度量指標、日志記錄和跟蹤，

目前 AliMesh 和 ASM 都使用的是 Istio 方案，

官網：https://istio.io/

5.2.2.2 linkerd

linkerd 是一個透明的服務網格，旨在通過透明地將服務發現、負載均衡、故障處理，插樁和路由添加到所有的服務間通信中，使現代應用程式安全可靠，而無需侵入應用內部本身的實作，

linkerd 作為一個透明的 HTTP/gRPC/thrift/ 等代理，通常可以以最少的配置被加入到現有的應用程式中，不管這些應用程式采用什么語言撰寫，linkerd 能與許多通用協議和服務發現后端運行，包括 Mesos 和 Kubernetes 等預定好的環境，

官網：https://linkerd.io/

5.2.3 Micro Service Framework

5.2.3.1 Dapr

Dapr 是微軟開發的開源的、可移植的、事件驅動的應用運行時，它使開發人員可以輕松地構建彈性的、微服務的無狀態和有狀態的應用，這些應用運行在云端和邊緣之上，Dapr 作為 Sidecar 更像微服務的運行時，為程式提供本來不具備的功能，Dapr 的主要功能如下：
服務呼叫：彈性服務與服務之間（service-to-service）呼叫可以在遠程服務上啟用方法呼叫，包括重試，無論遠程服務在受支持的托管環境中運行在何處，
狀態管理：通過對鍵 / 值對的狀態管理，可以很容易撰寫長時間運行、高可用性的有狀態服務，以及同一個應用中的無狀態服務，
在服務之間發布和訂閱訊息：使事件驅動的架構能夠簡化水平可擴展性，并使其具備故障恢復能力，
事件驅動的資源系結：資源系結和觸發器在事件驅動的架構上進一步構建，通過從任何外部資源（如資料庫、佇列、檔案系統、blob 存盤、webhooks 等）接收和發送事件，從而實作可擴展性和彈性，
虛擬角色：無狀態和有狀態物件的模式，通過方法和狀態封裝使并發變得簡單，Dapr 在其虛擬角色（Virtual Actors）運行時提供了許多功能，包括并發、狀態、角色激活 / 停用的生命周期管理以及用于喚醒角色的計時器和提醒，
服務之間的分布式跟蹤：使用 W3C 跟蹤背景關系（W3C Trace Context）標準，輕松診斷和觀察生產中的服務間呼叫，并將事件推送到跟蹤和監視系統，

官網：https://dapr.io/

5.2.3.2 Dubbo

Dubbo 是阿里巴巴開源的基于 Java 的高性能 RPC（一種遠程呼叫） 分布式服務框架（SOA），致力于提供高性能和透明化的 RPC 遠程服務呼叫方案，以及 SOA 服務治理方案，目前阿里內部使用的 HSF 也將逐漸被 Dubbo代替，

官網：http://dubbo.apache.org/

5.2.3.3 Spring Cloud

Spring Cloud 為開發者提供了在分布式系統（如配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性 Token、全域鎖、決策競選、分布式會話和集群狀態）操作的開發工具，使用 Spring Cloud 開發者可以快速實作上述這些模式，

目前阿里基于原生 Spring Cloud 框架再加上阿里中間件做了一版增強，叫做 Spring Cloud Alibaba ，
Spring Cloud：https://spring.io/projects/spring-cloud
Spring Cloud Alibaba：https://spring.io/projects/spring-cloud-alibaba

5.3 Serverless

Serverless 本質上是不需要別人感知服務器，可以根據不同的無服務器場景分為Kubernetes Serverless、App Serverless、BaaS Serverless、FaaS Serverless、Data Serverless 等，

Serverless 在非容器時代，在大資料和人工智能領域，已經得到一定程度的發展，例如阿里內部的 ODPS、TPP 等平臺；但是容器時代的到來，更是大大加速了 Serverless 的發展，

還有，Serverless 在前端領域發展的十分風騷，出現了各種各樣易用性非常好的Serverless 平臺，

5.3.1 Cloud Events

CloudEvents 是一種規范，用于以通用格式描述事件資料，以提供跨服務、平臺和系統的互動能力，

事件格式指定了如何使用某些編碼格式來序列化 CloudEvent，支持這些編碼的兼容 CloudEvents 實作必須遵循在相應的事件格式中指定的編碼規則，所有實作都必須支持 JSON 格式，

官網：https://cloudevents.io/

5.3.2 Serverless Framework

Serverless Framework 是業界非常受歡迎的無服務器應用框架，開發者無需關心底層資源即可部署完整可用的 Serverless 應用架構，Serverless Framework 具有資源編排、自動伸縮、事件驅動等能力，覆寫編碼-除錯-測驗-部署等全生命周期，幫助開發者通過聯動云資源，迅速構建 Serverless 應用，

官網：https://github.com/serverless/components/blob/master/README.cn.md

5.3.3 FaaS Serverless

5.3.3.1 Kubeless

Kubeless 是一個基于 Kubernetes 的 Serverless 框架，允許您部署少量代碼，而無需擔心底層基礎架構管道，它利用 Kubernetes 資源提供自動擴展、API 路由、監控、故障排除等功能，Kubless 有三個核心概念：
Function：代表需要被執行的用戶代碼，同時包含運行時依賴、構建指令等資訊；
Trigger：代表和函式關聯的事件源，如果把事件源比作生產者，函式比作執行者，那么觸發器就是聯系兩者的橋梁；
Runtime：代表函式運行時所依賴的環境，

官網：https://kubeless.io/

5.3.3.2 Nuclio

Nuclio 是專注于資料，I/O 和計算密集型作業負載的高性能“無服務器”框架，它與 Jupyter 和 Kubeflow 等流行的資料科學工具很好地集成在一起；支持各種資料和流媒體源；并支持通過 CPU 和 GPU 執行，Nuclio 專案于 2017 年開始，并且一直在迅速發展，許多初創企業和企業現在都在生產中使用Nuclio，
Jupyter：https://jupyter.org/
Kubeflow：https://www.kubeflow.org/
官https://fission.io/網：https://nuclio.io/

5.3.3.3 Fission

Fission 是由私有云服務提供商 Platform9 領導開源的 serverless 產品，它借助 kubernetes 靈活強大的編排能力完成容器的管理調度作業，而將重心投入到 FaaS 功能的開發上，其發展目標是成為 AWS lambda 的開源替代品，Fission包含三個核心概念：
Function：代表用特定語言撰寫的需要被執行的代碼片段，
Trigger：用于關聯函式和事件源，如果把事件源比作生產者，函式比作執行者，那么觸發器就是聯系兩者的橋梁，
Environment：用于運行用戶函式的特定語言環境，

官網：https://fission.io/

5.3.3.4 OpenFaas

OpenFaas 是一個受歡迎且易用的無服務框架（雖然在上表中不及 OpenWhisk），但它不像 OpenWhisk 那么受歡迎，而且代碼的提交都是基于個人進行的，除了個人開發者在業余時間的貢獻外，VMWare 還聘請了一個團隊在全職維護 OpenFaas，

官網：https://www.openfaas.com/

5.3.3.5 OpenWhisk

OpenWhisk 是一個成熟的無服務框架，并且得到 Apache 基金會和 IBM 的支持，IBM 云函式服務也是基于 OpenWhisk 構建的，主要提交者都是 IBM 的員工，OpenWhisk 利用了 CouchDB、Kafka、Nginx、Redis 和 ZooKeeper，有很多底層的組件，所以增加了一定的復雜性，

官網：https://openwhisk.apache.org/

5.3.3.6 FnProject

Fn是可以運行在用戶側或者云端的容器原生的無服務器計算平臺，它需要使用 Docker 容器，該專案主要的貢獻者都來自于 Oracle，還有一個叫 Fn Flow 的新功能，它可以用來編排多函式，類似 OpenWhisk，

官網：https://fnproject.io/

5.3.3.7 Serverless Devs

Serverless Devs 是阿里巴巴首個開源的 Serverless 開發者平臺，也是業內首個支持主流 Serverless 服務/框架的云原生全生命周期管理的平臺，通過該平臺，開發者可以一鍵體驗多云 Serverless 產品，極速部署 Serverless 專案，

官網：https://www.serverless-devs.com/#/home

5.3.4 App Serverless

5.3.4.1 Knative

Knative 是谷歌開源的 Serverless 架構方案，旨在提供一套簡單易用的 Serverless 方案，把 Serverless 標準化，目前參與的公司主要是 Google、Pivotal、IBM、Red Hat，2018 年 7 月 24 日才剛剛對外發布，當前還處于快速發展的階段，Knative 是為了解決容器為核心的 Serverless 應用的構建、部署和運行的問題，此外，Knative原始的 Build 功能已經被廢棄，被 Tekton 代替，

官網：https://knative.dev/

5.4 CI/CD

5.4.1 GitOps

GitOps 是一種快速、安全的方法，可供開發或運維人員維護和更新運行在 Kubernetes 或其他宣告式編排框架中的復雜應用，GitOps 的四個原則如下：
以宣告的方式描述整個系統；
系統的目標狀態通過 Git 進行版本控制；
對目標狀態的變更批準后將自動應用到系統；
驅動收斂 & 上報偏離，

對于沒有管控系統，需要暫時用黑屏操作的同學來說，可以選擇 GitOps ；如果有管控系統，不建議使用 GitOps ，否則你需要保證管控的資料庫、Git 的檔案、Kubernetes的運行時檔案的狀態的一致性，中間多了一個環節，出錯幾率高，

5.4.2 Argo

Argo 是一個云原生的作業流/流水線引擎，Argo 作業流以CRD形式實作，Argo作業流的每個步驟，都是一個容器，多步驟的作業流建模為任務的序列，或者基于DAG來捕獲任務之間的依賴，Argo 主要包括以下功能：
Argo Workflows：宣告式的作業流引擎；
Argo CD：宣告式的 GitOps 持續交付；
Argo Events：基于事件的依賴管理；
Argo Rollouts：支持灰度、藍綠部署的 CR ，

由于 Argo 的每個步驟都是 Pod ，極其占用服務器資源，對于生產級業務系統，需要謹慎使用，

官網：https://argoproj.github.io/

5.4.3 Tekton

Tekton 是一個功能強大且靈活的 Kubernetes 原生框架，用于創建 CI/CD 系統，通過抽象出底層實作細節，允許開發者跨多云環境或本地系統進行構建、測驗與部署，Tekton 整體的架構抽象非常棒，基本能解決所有容器下的編排問題，

但同樣每個步驟都是 Pod ，跟 Argo 一樣極其占用資源，

官網：https://github.com/tektoncd

5.5 集群管理

5.5.1 Federation

Kubernetes Federation（以下簡稱KubeFed）允許您通過托管集群中的一組 API 來協調多個 Kubernetes 集群的配置， KubeFed 的目的是提供一種機制，用于表達應管理哪些集群及其配置以及應該如何配置的集群，KubeFed 提供的機制是有意的底層機制，旨在為更復雜的多集群用例（例如部署多地理位置應用程式和災難恢復）奠定基礎，

官網：https://github.com/kubernetes-sigs/kubefed

5.5.2 K3S

K3S 是一個輕量級Kubernetes，它易于安裝，二進制檔案包小于40MB，只需要512MB RAM 即可運行，它非常適用于 Edge、IoT、CI、ARM 等場景，K3S 是Rancher 出品的一個簡化、輕量的 K8s ，從名字上也能看出，K3s 比 K8s 少了些東西，

官網：https://k3s.io/

5.5.3 K9S

K9S 提供了一個終端 UI 與您的 Kubernetes 集群進行互動，該專案的目的是簡化瀏覽，觀察和管理應用程式的程序，K9S 持續監視 Kubernetes 的更改，并提供后續命令與您觀察到的資源進行互動， K9S 是 一款管理員們喜歡的 “單一螢屏” 實用程式，K9S提供了一個基于 curses 的全屏終端 UI ，可與您的 Kubernetes 集群進行互動，

官網：https://k9scli.io/

5.5.4 Minikube

Minikube 是一個易于在本地運行 Kubernetes 的工具，可在你的筆記本電腦上的虛擬機內輕松創建單機版 Kubernetes 集群，便于嘗試 Kubernetes 或使用 Kubernetes 日常開發，Minikube 相當于一個運行在本地的 Kubernetes 單節點，我們可以在里面創建 Pods 來創建對應的服務，

官網：https://minikube.sigs.k8s.io/

5.5.5 OpenYurt

OpenYurt 主打“云邊一體化”概念，依托 Kubernetes 強大的容器應用編排能力，滿足了云-邊一體化的應用分發、交付、和管控的訴求，OpenYurt 能幫用戶解決在海量邊、端資源上完成大規模應用交付、運維、管控的問題，并提供中心服務下沉通道，實作和邊緣計算應用的無縫對接，在設計 OpenYurt 之初，我們就非常強調保持用戶體驗的一致性，不增加用戶運維負擔，讓用戶真正方便地 “Extending your native kubernetes to edge”，

官網：https://openyurt.io/en-us/

5.6 PaaS

5.6.1 OpenShfit

OpenShift 是紅帽開發的云開發平臺即服務（PaaS），自由和開放原始碼的云計算平臺使開發人員能夠創建、測驗和運行他們的應用程式，并且可以把它們部署到云中， Openshift 廣泛支持多種編程語言和框架，如 Java，Ruby 和 PHP 等，另外它還提供了多種集成開發工具如 Eclipse integration，JBoss Developer Studio和 Jenkins等，OpenShift 只部署 Operator 應用，并提出了 Operator 成熟度，有自己的 Operator 應用定義模板，相對其他容器平臺來說，還是比較輕的，

官網：https://www.openshift.com/

5.6.2 CloudFoundry

Cloud Foundry 是 Pivotal 公司開發的業界第一個開源 PaaS 云平臺，它支持多種框架、語言、運行時環境、云平臺及應用服務，使開發人員能夠在幾秒鐘內進行應用程式的部署和擴展，無需擔心任何基礎架構的問題，

Cloud Foundry 和 Spring Cloud Connector 結合，對于 Spring 應用的服務依賴問題支持得非常好，但是 Cloud Foundry 相當重，在容器時代之前就存在了，運維難度很高，要謹慎使用，

官網：https://www.cloudfoundry.org/

5.6.3 KubeSphere

KubeSphere 是 QingCloud 開發的基于 Kubernetes 構建的分布式、多租戶、多集群、企業級開源容器平臺，具有強大且完善的網路與存盤能力，并通過極簡的人機互動提供完善的多集群管理、CI / CD 、微服務治理、應用管理等功能，幫助企業在云、虛擬化及物理機等異構基礎設施上快速構建、部署及運維容器架構，實作應用的敏捷開發與全生命周期管理，

KubeSphere 可謂是業屆的良心之作，互動體驗十分棒，功能也很完善，和 App Matrix 幾乎承擔了 QingCloud 的所有業務應用和云產品的運維，而目前的阿里云云產品基本都是垂直化的運維系統，

Demo（demo1 / Demo123）：https://demo.kubesphere.io/
官網：http://kubesphere.qingcloud.com/

5.6.4 Azure

Azure 是微軟開發的基于云計算的作業系統，原名“Windows Azure”，和 Azure Services Platform 一樣，是微軟“軟體和服務”技術的名稱，Microsoft Azure的主要目標是為開發者提供一個平臺，幫助開發可運行在云服務器、資料中心、Web 和 PC 上的應用程式，另外，通過 Azure 的 Service Fabric ，可輕松開發、打包、部署和管理可縮放且可靠的微服務（或者非微服務），

官網：https://azure.microsoft.com/zh-cn/

5.6.5 Anthos

Anthos 是 Google 開發的以 Kubernetes 為核心的混合云/多云管理平臺，主要作用是保護客戶的網路連接和應用程式，并以容器化的部署形式，提供云服務支撐能力，它的開發是因為客戶希望使用單一的編程模型，這使他們可以選擇并靈活地將作業負載轉移到 Google Cloud 和其他云平臺（如 Azure 和 AWS）而不做任何更改，

官網：https://www.anthos.org/

5.6.6 Heroku

Heroku 是 Salesforce 旗下云服務商，提供方便便捷的各種云服務，如服務器、資料庫、監控、計算等，并且它提供了免費版本，這使得我們這些平時想搞一些小東西的人提供了莫大的便捷，雖然它有時長和宕機的限制，但是對于個人小程式來說已經足夠了，

官網：https://www.heroku.com/

5.6.7 Crossplane

Crossplane 是 Upbond 公司開發的一個開源的多云平臺控制面板，用于跨環境、集群、區域和云，管理你的云原生應用程式和基礎設施，Crossplane 可以安裝到現有的 Kubernetes 集群中，以添加托管服務供應，或者作為多集群管理和作業負載調度的專用控制平面部署，

目前，OAM 和 Crossplane 社區共同致力于建設一個聚焦在標準化的應用和基礎設施上的開放社區，

官網：https://crossplane.io/

5.6.8 Rancher

Rancher 是供采用容器的團隊使用的完整軟體堆疊，它解決了在任何基礎架構上管理多個 Kubernetes 集群的運營和安全挑戰，同時為 DevOps 團隊提供了用于運行容器化作業負載的集成工具，

Rancher 的 Rio 是一種 MicroPaaS ，可以在任何標準 Kubernetes 集群之上進行分層，用戶可以輕松地將服務部署到Kubernetes并自動獲得持續交付，DNS，HTTPS，路由，監控，自動擴展，Canary 部署，Git 觸發構建等等，所有這一切只需要 Kubernetes 集群和 Rio CLI ，

官網：https://rancher.com/

5.7 大資料與AI

5.7.1 Kubeflow

Kubeflow 是谷歌發布的一個機器學習工具庫，Kubeflow 專案旨在使 Kubernetes 上的機器學習變的輕松、便捷、可擴展，其目標不是重建其他服務，而是提供一種簡便的方式找到最好的 OSS 解決方案，

官網：https://www.kubeflow.org/

5.7.2 Fluid

Fluid 是一款開源的云原生基礎架構專案，在計算和存盤分離的大背景驅動下，Fluid 的目標是為 AI 與大資料云原生應用提供一層高效便捷的資料抽象，將資料從存盤抽象出來，以便達到以下目的：
通過資料親和性調度和分布式快取引擎加速，實作資料和計算之間的融合，從而加速計算對資料的訪問；
將資料獨立于存盤進行管理，并且通過 Kubernetes 的命名空間進行資源隔離，實作資料的安全隔離；
將來自不同存盤的資料聯合起來進行運算，從而有機會打破不同存盤的差異性帶來的資料孤島效應，

官網：https://github.com/fluid-cloudnative/fluid

5.7.3 KubeTEE

KubeTEE 是一個云原生大規模集群化機密計算框架，旨在解決在云原生環境中 TEE 可信執行環境技術特有的從開發、部署到運維整體流程中的相關問題，KubeTEE 是云原生場景下如何使用 TEE 技術的一套整體解決方案，包括多個框架、工具和微服務的集合，

官網：https://github.com/SOFAEnclave/KubeTEE

6 . 云原生存在的問題

6.1 無狀態真的是萬能的嗎？

我們雖然倡導應用都應該改造成無狀態應用，例如 Kubernetes 中的 Deployment 就是專門針對于無狀態應用的，部分狀態機框架也推薦 Pipeline 也應該設計成無狀態的，還有 FaaS 中的 Function 也基本都是無狀態的，但是無狀態真的是萬能的嗎？例如一些需要查庫進行大量計算的高 QPS 的 Function，如果能把資料快取在本地，是否會更好些呢？

6.2 一處接入，處處運行是否真的可行？

可以說云原生的技術堆疊在不斷上移，越來越接近業務，例如應用運維，我們原來想創造一門技術，處處通吃，只要中間件接入一個應用平臺，隨著這個應用平臺就能輸出到各種公有云和專有云中，但是通過很長時間的實踐，我們發現不同的客戶要求不同，還有各種云基礎設施的差異，基本很難“一處接入，處處運行”，盲目地去搞大一統，只會陷入一個處處不行的大泥坑中，

6.3 中臺難在哪里？

中臺理論既然能提出，必然是符合當時的業務背景的，那么為啥后來的實踐卻不怎么理想呢？我粗淺地認為，主要問題在于根深蒂固的 To C基因，很難用一個大而全的業務理論去改變，我們還需要繼續探索，從業務和技術兩個方面去完善和改進中臺理論，

6.4 客戶想要的和說的不一樣？

你會發現，在客戶決定要買你的產品時，跟你聊得都是一些高大上的功能，例如異地多活、單元化、多租隔離、限量降級等；但在買回去后，發現用到的都是一些比較基礎的功能，這是因為決定買的客戶和使用的客戶不是同一批人，所以我們一定要深入挖掘使用產品的用戶到底想要的是什么，這才能建立長期合作的機制，

6.5 同一套應用模型真的能一統天下嗎？

每一個應用模型背后都需要相應的平臺配套，應用本就是很偏業務的一層，不僅有云原生的基礎應用，還有各種行業應用，不同的業務場景，對于應用的使用方式和交付流程都是不一樣，另外，基本每一個平臺都有自己的應用模型，所以應用模型本身是為某一個應用平臺服務的，例如 OpenShift、CloudFoundry、KubeSphere 都有自己基于原生 Kubernetes 概念抽象后的應用模型，所以，同一套應用模型，只能用在某一個垂直場景中，

7 . 云原生的未來展望

云原生技術的發展已經成為不可阻擋的趨勢，目前正是云原生技術大幅度運用到商業化產品的最好時機，在技術體系的變革后，必然會迎來業務模式的變革，我們都知道未來會變，如何抓住云原生這個貧訓，找到屬于時代的重要風口呢？

唯有打破舊的體系和認知才是唯一出路，

團隊介紹：阿里云云原生應用平臺以容器和 K8s 為突破口，以分布式、微服務、服務治理、服務網格、訊息、PaaS 為切入點布局產品技術，面向行業客戶承擔加速企業數字化轉型升級，幫助企業客戶和開發者全面擁抱云計算、享受云計算的紅利，面向未來定義研發、運維模式，推動 Serverless、函式計算等現代化架構演進，形成充分的產品技術競爭力，成為云原生時代的引領者，