作者 | 王銀利(芸崢)
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/kubebuilderOperatorSDK：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-cloudSpring 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、函數計算等現代化架構演進，形成充分的產品技術競爭力，成為雲原生時代的引領者。