![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/cf06cf144f424fcf99fde11fa900d3af.png)
作者 | 王銀利(芸崢)
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/TwYp4tfu4hZhnBZcVFYLfg)

# 概述

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

![1.png](https://ucc.alicdn.com/pic/developer-ecology/46052266a31f4e85bb085cfed9f7f142.png)

雲原生帶來的業務價值非常多，主要有如下幾條：

- **快速迭代**：天下武功，唯快不破。我們想要在殘酷的市場競爭中爭得一席之地，就必須先發制人。雲原生的本質就是幫助業務快速迭代，核心要素就是持續交付。

- **安全可靠**：雲原生透過可觀測機制，可以快速讓我們從錯誤中恢復，同時透過邏輯多租和物理多租等多種隔離方式，限制非法使用。

- **彈性擴充套件**：透過將傳統的應用改造為雲原生應用，做到彈性擴縮容，能夠更好地應對流量峰值和低谷，並且達到降本提效的目的。

- **開源共建**：雲原生透過技術開源能夠更好地幫助雲廠商開啟雲的市場，並且吸引更多的開發者共建生態，從一開始就選擇了一條“飛輪進化”式的道路，透過技術的易用性和開放性實現快速增長的正向迴圈，又透過不斷壯大的應用例項來推動了企業業務全面上雲和自身技術版圖的不斷完善。

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

# 什麼是雲原生？

## 1. 雲原生的定義

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

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

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

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

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

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

下圖可概覽雲原生所有的定義和特徵：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/c9c89dc444eb4776aa47a8a2394f8103.png)

## 2. 雲原生本質

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

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

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

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

### 1）雲原生不是業務本身

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

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

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

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

### 2）雲原生不是雲端計算

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

- 起源

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

- 設計

雲原生應用程式被設計為多租戶例項託管（微服務架構）。雲端計算應用程式在內部伺服器上執行，因此它們沒有任何多租戶例項。

- 便捷性

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

- 價格

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

- 實現

由於不需要進行硬體或軟體配置，雲原生應用程式很容易快速實現。雲端計算應用程式需要定製特定的安裝環境。

### 3）雲原生本身是複雜的

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

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

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

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

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

# 什麼是雲原生應用？

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

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

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

## 1. 按狀態分類

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

### 1）無狀態應用

無狀態應用就是不依賴本地執行環境的應用，例項間互相不依賴，可以自由伸縮。

無狀態應用的特徵：

- 無狀態應用的例項可類比為牲畜，無名、可丟棄；
- 執行的例項不會在本地儲存需要持久化的資料；
- 停止的例項所有資訊（除日誌和監控資料外）都將丟失。

### 2）有狀態應用

有狀態應用就是依賴本地執行環境的應用，例項之間有依賴和啟動先後關係，需要做資料持久化，不能隨意伸縮。

有狀態應用的特徵：

- 有狀態應用的例項可類比為寵物、有名、不可丟棄

- 例項升級和灰度對啟停順序的要求，如分散式選主

- 依賴例項資訊，如 ID、Name、IP、MAC、SN 等資訊

- 需要做資料持久化，依賴本地檔案和配置。

### 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 平臺進行開發，交給平臺來進行運維。

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/24ca257944c84c338c052e8912adc9d2.jpg)

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

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

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

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

## 2. 按職能分類

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

### 1）業務應用

業務應用就是業務開發工程師透過 Java、Go、Python 等語言來開發業務程式碼，然後打包為映象後部署的應用。業務應用主要用來解決業務問題，實現特定的業務功能。業務應用的交付物主要是映象。

在 Serverless 平臺中，業務應用也可以是一些函式程式碼，可以打映象；也可以不打映象，直接部署到多語言執行環境中。

### 2）運維應用

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

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

# 雲原生的理論探索

## 1. 一切皆資料

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

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

- 我們需要編輯資源的配置，並透過 GitOps 或者 K8s 命令進行下發，也叫資料驅動，即一切皆配置資料。

- 資源的各種邏輯都需要執行一系列動作，執行動作可以有多種觸發方式，即一切皆執行資料。

- 資源內部的生命週期需要編排，資源之間的依賴關係也需要編排，本質是編排執行動作，即一切皆編排資料。

- K8s 是基於事件驅動的架構，K8s 上各種資源狀態的變化，都會產生事件，即一切皆事件資料。

- 事件流即日誌，業務記錄即日誌，動作變化即日誌，結構化的日誌是可觀測的根本，即一切皆日誌。

- 無論是配置指令、還是依賴編排，亦或者是事件，都是圍繞資源進行的，所有的 API 都是以資源這個主體進行呼叫，即一切皆資源資料。

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/f4204bd689c84835a90f2a44666645c3.jpg)

## 2. 多維業務組合論

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

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

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

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

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/0bc641c1368d4e51a7f7074f18e0595c.jpg)

各個圖形的含義：

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

- 點：業務功能，業務組裝的最小單位

- 橫向線：微平臺，PaaS，服務主體單一

- 縱向線：業務軟體，SaaS

- 圓柱體：業務領域或者技術領域

- 面積塊：解決方案或一站式工作臺，可按租戶、產品、服務控制許可權。

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

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

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

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

## 3. 面向終態論

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

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

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

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

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/729970cb2e604fd3abdba4a08fdca94d.jpg)

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

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

- My-App 驅動 Deployment，Deployment 驅動 Pod。

- Pod 的狀態反饋到 Deployment，Deployment 的狀態反饋到 My-App，然後 App 的狀態達到 Running。

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

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

## 4. 中心管理論

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

可以這麼說，大到一個國家，小到一個 ZooKeeper 選主，所謂的跨 XXX ，就必然有一箇中心化的管理組織。一般來說，我們的物理隔離主要隔離的是資料中心，資料分為很多種，我們主要關心用於排程的資料，排程的資料都是比較簡單表徵使用者的指令，我們把它叫做配置，所以雲原生中的中心化管理需要一個全域性的排程中心，全域性配置中心，在複雜的場景下，可以在每一個物理叢集中加一個可接收和解析到指令的客戶端 Agent 即可。例如 Prometheus 監控的設計就是如此，我們需要在每一個 node 節點加一個監控的 Agent 進行系統監控並蒐集資料上報。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/561405edf9be480396c4eb9e6b7cc12e.png)

## 5. 編排上移論

自己無法編排和管理自己，自身一定是自閉環的，所以總有更上一層的物件編排自己。例如所有的叢集排程系統的架構都是無法橫向擴充套件的，如果需要管理更多的伺服器，唯一的辦法就是建立多個叢集；還有容器無法編排自己，所以出現了 Kubernetes ；再有就是在分散式選主中，master 只能有一個，如果有兩個 master，就不知道用哪個例項管理了；又比如在同一個團隊只能有一個主管，要是有兩個主管，必然這兩個主管上面還必須出現一個主管做最終的裁定。

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

解耦的關鍵在於自閉環，組合的關鍵在於編排，自動化的關鍵在於排程和調協。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/3987738c216a46f0b26b3857c30ca592.png)

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

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

## 6. 永不失敗論

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

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

![9.jpg](https://ucc.alicdn.com/pic/developer-ecology/b2a4b5fb5d174163b991d92874480697.jpg)

## 7. 生命週期論

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

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

![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/7f63aea8deb54615bdc2224afd767440.jpg)

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

![11.jpg](https://ucc.alicdn.com/pic/developer-ecology/5d3f474f9b5146cfb2565305dd2393e8.jpg)

## 8. 降維打擊論

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

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

- 跨維空降：從左到右，彎道超車，從一個行業轉向另一個關聯的行業，比如一個做容器平臺的團隊，很容易轉向做 APaaS 。

- 入口壟斷：從上到下，隱藏底層實現，比如一個做技術平臺的團隊，原來用一個收費的元件，但發展起來後，很有可能自研該元件，這個收費的元件就會受到很大的影響。

![12.jpg](https://ucc.alicdn.com/pic/developer-ecology/c064ac36de184dd2a33f026cf59e7c35.jpg)

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

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

- 自頂而下：從業務視角逐漸下推技術架構，這樣設計的系統不會偏離業務本身，重構的可能性也較小。

- 原生模式：本來是什麼就應該用什麼思路開發。舉個例子，PaaS 的開發路徑有 SaaS->PaaS、IaaS->PaaS、原生 PaaS 三種，那麼哪個會搞得更好？相信大多數人會選擇原生 PaaS 。拿造車來說，不能造個輪子就投入市場吧，而必須先有一輛能跑的車。

## 9. 鴻溝理論

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

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

![13.png](https://ucc.alicdn.com/pic/developer-ecology/cca2af4643ee4e698e56e8f8d81b9af1.png)

## 10. 飛輪理論

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

飛輪效應其實也是複利效應，下面以 AWS 的崛起舉個例子， AWS 的三大支柱業務就是讓飛輪效應啟動的關鍵：

- 超值的 prime 會員服務，每年只要 99 美金，就能享受很多增值服務。

- Markerplace 第三方賣家平臺，除了亞馬遜自己售賣的商品，其他賣家也可以進駐亞馬遜直接售賣自己的商品。

- AWS 雲服務，它的主要功能是向大大小小的企業提供雲服務，無論你是大公司還是小企業，都可以把自己的整套 IT 系統建立在亞馬遜雲服務上，效能穩定。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/3a34d64496174e84a3b576f75a813a19.png)

# 雲原生的核心技術

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

## 1. 運維技術

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

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

### 1）模板技術

#### [【YAML】](https://yaml.org/)

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

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

官網：[https://yaml.org/](https://yaml.org/)

#### [【Helm】](https://helm.sh/)

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

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

官網：[https://helm.sh/](https://helm.sh/)

#### [【KUDO】](https://kudo.dev/)

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

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

官網：[https://kudo.dev/](https://kudo.dev/)

#### [【MetaController】](https://metacontroller.app/)

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

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

一是為一組物件構建複合物件的控制器；二是為已經存在的物件新增新的行為。

官網：[https://metacontroller.app/](https://metacontroller.app/)

### 2）配置技術

#### [【CUE】](https://cuelang.org/)

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/](https://cuelang.org/)

#### [**【Jsonnet】**](https://jsonnet.org/)

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

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

官網：[https://jsonnet.org/](https://jsonnet.org/)

#### [**【HCL】**](https://github.com/hashicorp/hcl)

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

官網：[https://github.com/hashicorp/hcl](https://github.com/hashicorp/hcl)

#### 【Kusion】

Kusion 主要是基於雲原生基礎設施的高階專用語言及工具鏈，在不可變業務映象外提供 "Compile to Cloud" 的完整技術棧支援。Kusion 由 KCL 語言及工具鏈，KusionCtl 工具，Kusion-Models SDK 及 OCMP 實踐定義四部分組成。

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

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

### 3）程式設計技術

#### 【Operator】

Operator 是 CoreOS 推出的旨在簡化複雜有狀態應用管理的框架，它是一個感知應用狀態的控制器，透過擴充套件 Kubernetes API 來自動建立、管理和配置應用例項。

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

- KubeBuilder：[https://github.com/kubernetes-sigs/kubebuilder](https://github.com/kubernetes-sigs/kubebuilder)

- OperatorSDK：[https://github.com/operator-framework/operator-sdk](https://github.com/operator-framework/operator-sdk)

#### 【OperatorPlatform】

希望透過設計一個通用化的 Operator 平臺來解決原生 Operator 的各種問題，這個平臺的核心目標包括：

- 簡化、標準化 Operator 編寫（多語言、簡化框架、降低使用者門檻）。

- 下沉 Operator 核心能力、統一管控（中心管控所有使用者 Operator）。

- 提升使用者 Operator 效能（水平擴充套件、多叢集、精簡快取）。

- 控制 Operator 灰度及執行時的風險（完善監控、灰度回滾能力、控制爆炸半徑、許可權控制，訪問限制）。

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

#### [【Pulumi】](https://www.pulumi.com/)

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

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

官網：[https://www.pulumi.com/](https://www.pulumi.com/)

#### [【Ballerina】](https://ballerina.io/)

Ballerina 是一款開源的編譯式的強型別語言。Ballerina是一種開放原始碼程式語言和平臺，供雲時代的應用程式程式設計師輕鬆編寫可以正常執行的軟體。Ballerina 是語言和平臺的組合設計，敏捷且易於整合，旨在簡化整合和微服務程式設計。

Ballerina 是一種旨在整合簡化的語言。基於順序圖的互動，Ballerina 內建了對通用整合模式和聯結器的支援，包括分散式事務、補償和斷路器。憑藉對 JSON 和 XML 的一流支援，Ballerina 能夠簡單有效地構建跨網路終端的強大整合。

官網：[https://ballerina.io/](https://ballerina.io/)

#### [【CDK8S】](https://cdk8s.io/)

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

官網：[https://cdk8s.io/](https://cdk8s.io/)

#### [【Terraform】](https://www.terraform.io/)

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

官網：[https://www.terraform.io/](https://www.terraform.io/)

### 4）應用技術

#### [**【OAM】**](https://oam.dev/)

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

OAM 的核心理念如下：

- 第一個核心理念是組成應用程式的元件（Component），它可能包含微服務集合、資料庫和雲負載均衡器。

- 第二個核心理念是描述應用程式運維特徵（Trait）的集合，例如，彈性伸縮和 Ingress 等功能。它們對應用程式的執行至關重要，但在不同環境中其實現方式各不相同。

- 最後，為了將這些描述轉化為具體的應用程式，運維人員使用應用配置（Application Configuration）來組合元件和相應的特徵，以構建應部署的應用程式的具體例項

官網：[https://oam.dev/](https://oam.dev/)

#### [【KubeVela】](https://oam.dev/)

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

官網：[https://oam.dev/](https://oam.dev/)

#### [【OpenKruise】](https://openkruise.io/)

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/](https://openkruise.io/)

## 2. 微服務

### 1）BaaS

BaaS 即指業務應用依賴的後臺服務，它需要有一個服務目錄，供使用者選擇需要使用的中介軟體，然後透過 BaaS Plan 選擇規則，再建立完服務例項後，再透過 BaaS  Connector 和 BaaS 的 Endpoint 繫結。更多原理可以參看雲原生應用平臺的服務中心章節。

#### [**【Service Catalog】**](https://github.com/kubernetes-sigs/service-catalog)

服務目錄是 Kubernetes 社群的孵化專案 Kubernetes Service Catalog 專案，旨在接入和管理第三方提供的 Service Broker ，使 kubernetes 上託管的應用可以使用 Service Broker 所代理的外部服務。

官網：[https://github.com/kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog)

#### [**【Open Service Broker】**](https://www.openservicebrokerapi.org/)

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

官網：[https://www.openservicebrokerapi.org/](https://www.openservicebrokerapi.org/)

#### [**【Spring Cloud Connector】**](https://cloud.spring.io/spring-cloud-connectors/)

Spring Cloud Connector 為在雲平臺上執行的基於 JVM 的應用程式提供了一個簡單的抽象，可以在執行時發現繫結的服務和部署資訊，並且支援將發現的服務註冊為 Spring  Bean 。它基於外掛模型，以便相同的編譯應用程式可以在本地或任何多個雲平臺上進行部署，並透過 Java 服務提供程式介面（SPI）支援定製服務定義。

官網：[https://cloud.spring.io/spring-cloud-connectors/](https://cloud.spring.io/spring-cloud-connectors/)

### 2）Service Mesh

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

#### [**【Istio】**](https://istio.io/)

Istio 提供一種簡單的方式來為已部署的服務建立網路，該網路具有負載均衡、服務間認證、監控等功能，而不需要對服務的程式碼做任何改動。Istio 的能力如下：

- Istio 適用於容器或虛擬機器環境（特別是 K8s），相容異構架構。

- Istio 使用 Sidecar（邊車模式）代理服務的網路，不需要對業務程式碼本身做任何的改動。

- HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡。

- Istio 透過豐富的路由規則、重試、故障轉移和故障注入，可以對流量行為進行細粒度控制；支援訪問控制、速率限制和配額。

- Istio 對出入叢集入口和出口中所有流量的自動度量指標、日誌記錄和跟蹤。

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

官網：[https://istio.io/](https://istio.io/)

#### [**【linkerd】**](https://linkerd.io/)

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

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

官網：[https://linkerd.io/](https://linkerd.io/)

### 3）Micro Service Framework

#### [**【Dapr】**](https://dapr.io/)

Dapr 是微軟開發的開源的、可移植的、事件驅動的應用執行時，它使開發人員可以輕鬆地構建彈性的、微服務的無狀態和有狀態的應用，這些應用執行在雲端和邊緣之上。Dapr 作為 Sidecar 更像微服務的執行時，為程式提供本來不具備的功能。Dapr 的主要功能如下：

- 服務呼叫：彈性1服務與服務之間（service-to-service）呼叫可以在遠端服務上啟用方法呼叫，包括重試，無論遠端服務在受支援的託管環境中執行在何處。

- 狀態管理：透過對鍵 / 值對的狀態管理，可以很容易編寫長時間執行、高可用性的有狀態服務，以及同一個應用中的無狀態服務。

- 在服務之間釋出和訂閱訊息：使事件驅動的架構能夠簡化水平可擴充套件性，並使其具備故障恢復能力。

- 事件驅動的資源繫結：資源繫結和觸發器在事件驅動的架構上進一步構建，透過從任何外部資源（如資料庫、佇列、檔案系統、blob 儲存、webhooks 等）接收和傳送事件，從而實現可擴充套件性和彈性。

- 虛擬角色：無狀態和有狀態物件的模式，透過方法和狀態封裝使併發變得簡單。Dapr 在其虛擬角色（Virtual Actors）執行時提供了許多功能，包括併發、狀態、角色啟用 / 停用的生命週期管理以及用於喚醒角色的計時器和提醒。

- 服務之間的分散式跟蹤：使用 W3C 跟蹤上下文（W3C Trace Context）標準，輕鬆診斷和觀察生產中的服務間呼叫，並將事件推送到跟蹤和監視系統。

官網：[https://dapr.io/](https://dapr.io/)

#### [**【Dubbo】**](http://dubbo.apache.org/)

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

官網：[http://dubbo.apache.org/](http://dubbo.apache.org/)

#### **【Spring Cloud】**

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

目前阿里基於原生 Spring Cloud 框架再加上阿里中介軟體做了一版增強，叫做 Spring Cloud Alibaba 。

- Spring Cloud：[https://spring.io/projects/spring-cloud](https://spring.io/projects/spring-cloud)

- Spring Cloud Alibaba：[https://spring.io/projects/spring-cloud-alibaba](https://spring.io/projects/spring-cloud-alibaba)

## 3. Serverless

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

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

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

### 1）[Cloud Events](https://cloudevents.io/)

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

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

官網：[https://cloudevents.io/](https://cloudevents.io/)

### 2）[Serverless Framework](https://github.com/serverless/components/blob/master/README.cn.md)

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

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

### 3）FaaS Serverless

#### [【Kubeless】](https://kubeless.io/)

Kubeless 是一個基於 Kubernetes 的 Serverless 框架，允許您部署少量程式碼，而無需擔心底層基礎架構管道。它利用 Kubernetes 資源提供自動擴充套件、API 路由、監控、故障排除等功能。Kubless 有三個核心概念：

- Function：代表需要被執行的使用者程式碼，同時包含執行時依賴、構建指令等資訊。

- Trigger：代表和函式關聯的事件源。如果把事件源比作生產者，函式比作執行者，那麼觸發器就是聯絡兩者的橋樑。

- Runtime：代表函式執行時所依賴的環境。

官網：[https://kubeless.io/](https://kubeless.io/)

#### [【Nuclio】](https://nuclio.io/)

Nuclio 是專注於資料，I/O 和計算密集型工作負載的高效能“無伺服器”框架。它與 Jupyter 和 Kubeflow 等流行的資料科學工具很好地整合在一起；支援各種資料和流媒體源；並支援透過 CPU 和 GPU 執行。Nuclio 專案於 2017 年開始，並且一直在迅速發展。許多初創企業和企業現在都在生產中使用 Nuclio。

- Jupyter：[https://jupyter.org/](https://jupyter.org/)

- Kubeflow：[https://www.kubeflow.org/](https://www.kubeflow.org/)

- 官網：[https://nuclio.io/](https://nuclio.io/)

#### [**【Fission】**](https://fission.io/)

Fission 是由私有云服務提供商 Platform9 領導開源的 serverless 產品，它藉助 Kubernetes 靈活強大的編排能力完成容器的管理排程工作，而將重心投入到 FaaS 功能的開發上，其發展目標是成為 AWS lambda 的開源替代品。Fission 包含三個核心概念：

- Function：代表用特定語言編寫的需要被執行的程式碼片段。

- Trigger：用於關聯函式和事件源。如果把事件源比作生產者，函式比作執行者，那麼觸發器就是聯絡兩者的橋樑。

- Environment：用於執行使用者函式的特定語言環境。

官網：[https://fission.io/](https://fission.io/)

#### [**【OpenFaas】**](https://www.openfaas.com/)

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

官網：[https://www.openfaas.com/](https://www.openfaas.com/)

#### [**【OpenWhisk】**](https://openwhisk.apache.org/)

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

官網：[https://openwhisk.apache.org/](https://openwhisk.apache.org/)

#### [【FnProject】](https://fnproject.io/)

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

官網：[https://fnproject.io/](https://fnproject.io/)

#### [【Serverless Devs】](https://www.serverless-devs.com/#/home)

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

![15.png](https://ucc.alicdn.com/pic/developer-ecology/657f01be9c014bc7ad1a110c4994a539.png)

### 4）App Serverless

#### [**【Knative】**](https://knative.dev/)

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

官網：[https://knative.dev/](https://knative.dev/)

## 4. CI/CD

### 1）GitOps

GitOps 是一種快速、安全的方法，可供開發或運維人員維護和更新執行在 Kubernetes 或其他宣告式編排框架中的複雜應用。GitOps 的四個原則如下：

- 以宣告的方式描述整個系統

- 系統的目標狀態透過 Git 進行版本控制

- 對目標狀態的變更批准後將自動應用到系統

- 驅動收斂 & 上報偏離

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

### 2）[Argo](https://argoproj.github.io/)

Argo 是一個雲原生的工作流/流水線引擎，Argo 工作流以 CRD 形式實現。Argo 工作流的每個步驟，都是一個容器。多步驟的工作流建模為任務的序列，或者基於 DAG 來捕獲任務之間的依賴。Argo 主要包括以下功能：

- Argo Workflows：宣告式的工作流引擎

- Argo CD：宣告式的 GitOps 持續交付

- Argo Events：基於事件的依賴管理

- Argo Rollouts：支援灰度、藍綠部署的 CR 。

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

官網：[https://argoproj.github.io/](https://argoproj.github.io/)

### 3）[Tekton](https://github.com/tektoncd)

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

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

官網：[https://github.com/tektoncd](https://github.com/tektoncd)

## 5. 叢集管理

### 1）[Federation](https://github.com/kubernetes-sigs/kubefed)

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

官網：[https://github.com/kubernetes-sigs/kubefed](https://github.com/kubernetes-sigs/kubefed)

### 2）[K3s](https://k3s.io/)

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

官網：[https://k3s.io/](https://k3s.io/)

### 3）[K9s](https://k9scli.io/)

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

官網：[https://k9scli.io/](https://k9scli.io/)

### 4）[Minikube](https://minikube.sigs.k8s.io/)

Minikube 是一個易於在本地執行 Kubernetes 的工具，可在你的膝上型電腦上的虛擬機器內輕鬆建立單機版 Kubernetes 叢集。便於嘗試 Kubernetes 或使用 Kubernetes 日常開發。Minikube 相當於一個執行在本地的 Kubernetes 單節點，我們可以在裡面建立 Pods 來建立對應的服務。

官網：[https://minikube.sigs.k8s.io/](https://minikube.sigs.k8s.io/)

### 5）[OpenYurt](https://openyurt.io/en-us/)

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

官網：[https://openyurt.io/en-us/](https://openyurt.io/en-us/)

## 6. PaaS

### 1）[OpenShfit](https://www.openshift.com/)

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

官網：[https://www.openshift.com/](https://www.openshift.com/)

### 2）[CloudFoundry](https://www.cloudfoundry.org/)

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

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

官網：[https://www.cloudfoundry.org/](https://www.cloudfoundry.org/)

### 3）[KubeSphere](http://kubesphere.qingcloud.com/)

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

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

- Demo（demo1 / Demo123）：[https://demo.kubesphere.io/](https://demo.kubesphere.io/)
- 官網：[http://kubesphere.qingcloud.com/](http://kubesphere.qingcloud.com/)

### 4）[Azure](https://azure.microsoft.com/zh-cn/)

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

官網：[https://azure.microsoft.com/zh-cn/](https://azure.microsoft.com/zh-cn/)

### 5）[Anthos](https://www.anthos.org/)

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

官網：[https://www.anthos.org/](https://www.anthos.org/)

### 6）[Heroku](https://www.heroku.com/)

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

官網：[https://www.heroku.com/](https://www.heroku.com/)

### 7）[Crossplane](https://crossplane.io/)

Crossplane 是 Upbond 公司開發的一個開源的多雲平臺控制皮膚，用於跨環境、叢集、區域和雲，管理你的雲原生應用程式和基礎設施。Crossplane 可以安裝到現有的 Kubernetes 叢集中，以新增託管服務供應，或者作為多叢集管理和工作負載排程的專用控制平面部署。

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

相關文章