1. 概述

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

雲原生帶來的業務價值很是多，主要有以下幾條：

快速迭代：天下武功，惟快不破 。咱們想要在殘酷的市場競爭中爭得一席之地，就必須先發制人。雲原生的本質就是幫助業務快速迭代，核心要素就是持續交付。
安全可靠： 雲原生經過可觀測機制，能夠快速讓咱們從錯誤中恢復，同時經過邏輯多租和物理多租等多種隔離方式，限制非法使用。
彈性擴展： 經過將傳統的應用改造爲雲原生應用，作到彈性擴縮容，可以更好地應對流量峯值和低谷，而且達到降本提效的目的。
開源共建： 雲原生經過技術開源可以更好地幫助雲廠商打開雲的市場，而且吸引更多的開發者共建生態，從一開始就選擇了一條「飛輪進化」式的道路，經過技術的易用性和開放性實現快速增加的正向循環，又經過不斷壯大的應用實例來推進了企業業務全面上雲和自身技術版圖的不斷完善。

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

2. 什麼是雲原生

2.1 雲原生的定義
node

雲原生的定義一直在發生變化，不一樣的組織也有不一樣的理解，比較出名的有 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、持續交付、康威定律、重組等）。雲原生也能夠說是一系列雲技術、企業管理方法的集合。

1、雲原生不是業務自己

好幾我的問我雲原生是什麼，我會反問他們，若是你想本身的業務快速迭代，你但願雲原生是什麼。雲原生必定不是一個具體的東西，而是表明瞭如何追求問題的本質，它原本是什麼，就是什麼，它是一套方法論。

雲原生的本質是幫助業務快速迭代，不是業務自己，不是技術堆疊，不是生搬硬套。咱們不該該看咱們有什麼，而要看客戶原本要的是什麼。

那麼雲原生其實就是表明了科技的進步，咱們不光要提升新業務的迭代效率，還要打破舊業務的迭換效率。一個好的架構通常會兼容人類的愚蠢，因此這裏的舊業務多是歷史包袱，多是知識瓶頸帶來的偏見。

咱們無時無刻都在變成舊，無時無刻都在創造新。人要勇於質疑本身，質疑過去，質疑權威，纔有建立新的動力和洞見。

2、雲原生不是雲計算

雲計算（Cloud Computing）和雲原生（Cloud Native）有很大區別，主要體如今如下六個方面：

起源git

雲原生應用程序源於雲原生。如前所述，它們構建並部署在雲中，真正地訪問了雲基礎設施的強大功能。雲計算應用程序一般是在內部使用傳統基礎設施開發的，而且通過調整後能夠在雲中遠程訪問。

設計

雲原生應用程序被設計爲多租戶實例託管（微服務架構）。雲計算應用程序在內部服務器上運行，所以它們沒有任何多租戶實例。

便捷性

雲原生應用程序是高度可擴展性，能夠對單個模塊進行實時更改，而不會對整個應用程序形成干擾。雲計算應用程序須要手動升級，從而會致使應用程序中斷和關閉。

價格

雲原生應用程序不須要任何硬件或軟件上的投資，由於它們是在雲上進行的，一般能夠在被許可方得到，所以使用起來相對便宜。雲計算應用程序一般比較昂貴，由於它們須要進行基礎升級以適應不斷變化的需求。

實現

因爲不須要進行硬件或軟件配置，雲原生應用程序很容易快速實現。雲計算應用程序須要定製特定的安裝環境。

3、雲原生自己是複雜的

雲原生改變的不止是技術，最終去改變的是業務。雲原生既然會幫助業務快速迭代，那麼業務代碼和項目流程必然會發生根本性變化。典型的就是業務愈來愈輕，底座愈來愈厚，數據處理愈來愈自動化，非人用戶愈來愈多。
程序員

接下來，咱們能夠從尤瓦爾赫拉利的三部簡史來窺探下雲原生的本質。

21 世紀隨着人工智能的發展，人類社會將由人文主義逐漸過渡到數據主義。人類社會若是是一個比較大的數據網絡，包括人類的情感都只是進化論選擇下的生物算法，那麼每個人只是其中的一個數據處理器，能夠是智人，能夠是虛擬人，也能夠是將來的超人類。咱們能夠拿共產主義和資本主義的區別來舉例。共產主義是集中式算法，經過國家的數據網絡計算每個人的需求再進行分配；資本主義是分佈式算法，少數的資本家掌控大部分的社會資源。

能夠說之前的數據是一個孤島，部署在幾個物理機上，管好本身就能夠，不會影響別人。而今天不同，全部的應用都在線化，逐漸變成一個有生命力的資產後，應用的約束也會愈來愈嚴格和複雜，全部的數據流向及依賴徹底是你人爲難以預期的。光鋪人已經解決不了了。

雲原生其實很複雜，本質是鏈接數據，將數據從雜亂無序處理爲信息、知識、智慧。雲原生的複雜來源於它想容納更多複雜的事務和結構，但某一方面來講，雲原生其實又很簡單，由於它給終端用戶帶來無窮無盡的便利和豐富功能，但又無需他們感知。複雜和簡單是相對的， 底層越複雜，上層越簡單。

3. 什麼是雲原生應用

什麼是雲原生應用呢？和雲原生的關係又是什麼？雲原生應用的定義基本以下：
github

雲原生應用，是指原生爲在雲平臺上部署運行而設計開發的應用。雲原生應用不僅是將應用打包成 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 類應用、查詢類應用等。

1、無狀態到有狀態

好比一個比較簡單的雲產品，在公有云部署時，能夠依賴公有云的基礎設施，因此是無狀態；但在專有云部署時，卻須要本身解決環境和對其餘BaaS的依賴，因此是有狀態，這就是基礎設施和運維方式不一樣形成的差距。

通常狀況下，咱們不提倡應用之間的依賴過於複雜，尤爲在專有云場景下，複雜的依賴帶來的環境問題至關多，拔蘿蔔帶泥幾乎要把整個公有云搬到專有云，不管對咱們仍是對客戶，都是比較大的心智負擔。

2、有狀態到無狀態

業務應用本質上都應該是有狀態的，不過它能夠藉助中間件、運維 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 一切皆數據
web

其實從 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 是阿里巴巴首個開源的 Server less 開發者平臺，也是業內首個支持主流 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. 雲原生存在的問題

1. 無狀態真的是萬能的嗎？spring

咱們雖然倡導應用都應該改形成無狀態應用，例如 Kubernetes 中的 Deployment 就是專門針對於無狀態應用的，部分狀態機框架也推薦 Pipeline 也應該設計成無狀態的，還有 FaaS 中的 Function 也基本都是無狀態的，可是無狀態真的是萬能的嗎？例如一些須要查庫進行大量計算的高 QPS 的 Function，若是能把數據緩存在本地，是否會更好些呢？數據庫

2. 一處接入，到處運行是否真的可行？apache

能夠說雲原生的技術堆棧在不斷上移，愈來愈接近業務。例如應用運維，咱們原來想創造一門技術，到處通吃，只要中間件接入一個應用平臺，隨着這個應用平臺就能輸出到各類公有云和專有云中。可是經過很長時間的實踐，咱們發現不一樣的客戶要求不一樣，還有各類雲基礎設施的差別，基本很難「一處接入，到處運行」。盲目地去搞大一統，只會陷入一個到處不行的大泥坑中。

3. 中臺難在哪裏？

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

4. 客戶想要的和說的不同？

你會發現，在客戶決定要買你的產品時，跟你聊得都是一些高大上的功能，例如異地多活、單元化、多租隔離、限量降級等；但在買回去後，發現用到的都是一些比較基礎的功能。這是由於決定買的客戶和使用的客戶不是同一批人，因此咱們必定要深刻挖掘使用產品的用戶到底想要的是什麼，這才能創建長期合做的機制。

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

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

7. 雲原生的將來展望

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

惟有打破舊的體系和認知纔是惟一出路。

本文分享自微信公衆號 - 雲服務圈（heidcloud）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。

雲原生|理論認識探索