作者 | 王銀利(芸峥)
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/hcl5.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-sdk5.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。
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-catalog5.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-alibaba5.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.md5.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：用于運作使用者函數的特定語言環境。
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 項目。
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/tektoncd5.5 叢集管理
5.5.1 Federation
Kubernetes Federation（以下簡稱KubeFed）允許您通過托管叢集中的一組 API 來協調多個 Kubernetes 叢集的配置。 KubeFed 的目的是提供一種機制，用于表達應管理哪些叢集及其配置以及應該如何配置的叢集。KubeFed 提供的機制是有意的底層機制，旨在為更複雜的多叢集用例（例如部署多地理位置應用程式和災難恢複）奠定基礎。
https://github.com/kubernetes-sigs/kubefed5.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 解決方案。
5.7.2 Fluid
Fluid 是一款開源的雲原生基礎架構項目。在計算和存儲分離的大背景驅動下，Fluid 的目标是為 AI 與大資料雲原生應用提供一層高效便捷的資料抽象，将資料從存儲抽象出來，以便達到以下目的：
通過資料親和性排程和分布式緩存引擎加速，實作資料和計算之間的融合，進而加速計算對資料的通路；
将資料獨立于存儲進行管理，并且通過 Kubernetes 的命名空間進行資源隔離，實作資料的安全隔離；
将來自不同存儲的資料聯合起來進行運算，進而有機會打破不同存儲的差異性帶來的資料孤島效應。
https://github.com/fluid-cloudnative/fluid5.7.3 KubeTEE
KubeTEE 是一個雲原生大規模叢集化機密計算架構，旨在解決在雲原生環境中 TEE 可信執行環境技術特有的從開發、部署到運維整體流程中的相關問題。KubeTEE 是雲原生場景下如何使用 TEE 技術的一套整體解決方案，包括多個架構、工具和微服務的集合。
https://github.com/SOFAEnclave/KubeTEE6 . 雲原生存在的問題
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、函數計算等現代化架構演進，形成充分的産品技術競争力，成為雲原生時代的引領者。