導讀：Serverless 無疑是當前最熱的雲原生話題，那麼作為業務的開發人員或者運維人員我們們應該怎麼看待這個事情？雲原生和 Serverless 到底有什麼關係？透過本次分享我們們將逐一揭開這些神秘的面紗。

透過本文您將瞭解到：

Knative 是如何讓普通的應用具備 Serverless 能力的？
為什麼說 Knative 是雲原生的應用 Serverless 編排引擎？
Knative 為什麼是由 Tekton 、Eventing 和 Serving 三個模組組成，以及這三個模組的協作方式。

本文共有四部分內容：首先我們們一起來看一下雲的核心驅動力是什麼，接著從這個核心驅動力出發看一下雲原生應用是什麼樣子。然後我們們再一起來看看 Knative 到底給應用的雲原生化帶來了什麼價值，最後我們們透過一個 Demo 親身感受一下 Knative 帶來的這些能力。

雲的核心驅動力

在討論雲原生之前我們先來思考一下：為什麼企業要上雲、為什麼技術人員要學習面向雲的程式設計思維以及我們們應該怎麼看待雲這件事兒。

我們們先來剖析一下發生這些事情的核心驅動力，然後透過這個核心驅動力出發看看整個雲原生技術棧是什麼樣子。

社會分工

我們先從一頓火鍋談起，一頓火鍋雖然很簡單，但會涉及到非常多的東西，比如各種蔬菜、牛羊肉等。細想一下，所有的這些東西我們都經常食用，但是其中有哪些東西是我們自己親手種植或養殖的呢？事實上都沒有，我們每天都是坐在辦公室，下班的路上到市場或超市買到這些東西，不知道也並不關心這些東西的具體生產過程。

我小時候在內蒙的農村長大，大家都知道，內蒙很大。村裡每戶人家都有一個大園子，夏天的時候家家戶戶都會在園子裡種植各種蔬菜，如蕃茄、黃瓜、茄子、辣椒等；但到了冬天，由於天氣很冷，根本見不到新鮮的蔬菜，大家吃的都是鹹菜、酸菜，或者是秋天晾曬的一些乾菜。我們可以發現：一個地域非常容易受到季節的影響，雖然夏天可以種植各種蔬菜，但是到了冬天就什麼都沒有了。但是現在就不同了，全國各地隨處都能非常容易地買到新鮮蔬菜，這其實是社會分工的結果、是不同地域、不同角間透過市場相互協作的成果。

現在因為有專業的人在做這些事情，所以我們大多數人都無需勞心蔬菜是怎麼種植的。而我們工程師所做的和計算機打交道的事情也能透過其他的渠道反過來幫助那些種菜的人。

分工提高效率，這是現代經濟學之父亞當斯密 200 多年前在他的經典著作《國富論》中的開篇觀點。其實現代社會的執行機制也印證了該理論；我認為它也是企業擁抱雲端計算的根本原因。因為大家需要把一些非業務核心的部分“承包”給專業的人士去完成，那些和自己的業務強相關的部分才是企業的核心競爭力。

應用上雲

接著我們們再來看看一個應用都是由哪些部分構成的。

應用要提供服務首先要有計算、儲存和網路資源才能把程式跑起來。當然這些也僅僅是把程式跑起來，如果要承接具體的業務還需要依賴資料庫等服務；如果要做分散式架構還需要做微服務拆分，這時候就需要快取、註冊中心、訊息各種中介軟體的服務。

以上的情況都是程式已經存在，如何把程式跑起來承接業務的部分。還有一部分是如何把程式碼變成可啟動的程式，這就是 CICD 部分了。從程式碼到應用啟動再到應用依賴的周邊系統支撐都說完了，還有一部分就是日常運維相關的：

比如日誌收集、分析
比如監控和告警

雖然我們本來只是想要寫一個應用，來為業務提供服務。但是應用周邊的這些支撐系統比這個應用自身的消耗還要高上很多。這其實不是我們期望的結果，讓業務團隊更多的聚焦在業務邏輯本身，而不是周邊的這些系統上，這才是我們希望看到的。

實際上有一定規模的公司，內部的組織架構基本也都是由一個基礎平臺團隊和多個業務團隊構成的，基礎平臺團隊負責提供這些應用需要的公共能力支撐，業務團隊更聚焦在業務上，直接使用基礎平臺團隊的能力即可。這其實就是社會分工在 IT 組織中的體現，專業的人做專業的事兒，分工提升效率。

現在我們再回顧一下剛才吃火鍋的例子。

如果時間倒退 20 年，回到北方的冬天，我們想要吃一頓有肉、有蔬菜、還有金針菇的火鍋，根本就不可能，但是現在，我們可以隨時隨地買到這些東西，而所有這些都是專業的人士生產的，我們無法自給自足這麼豐富的資源。

那麼對於一家企業而言，也是一樣的。雖然每個企業都有自己的基礎平臺團隊，但是由於規模或者資金投入等原因，不可能提供像雲這麼豐富的平臺支撐。如果有，那一定也是一個雲廠商。所以對於業務來說，把所有和應用相關的周邊系統都使用雲的初始設施搭建，把這些周邊系統承包給雲廠商才是高效率的做法。我理解為這就是雲原生出現的背景。

分工提高效率這是大家使用雲的根本動力。雲原生理念是在各大企業上雲的過程中逐漸形成和完善的。這套理念是協調所有參與方對服務上雲逐漸形成的統一標準，這個統一的標準可以很好地幫助企業上雲、幫助雲廠商釋放雲的能力。從雲的客戶角度來講，這個統一標準就是避免雲廠商鎖定。比如 Kubernetes 就是一個非常好的統一共識，因為所有云平臺都支援 Kubernetes。

那麼這個標準的價值是什麼呢？為什麼雲廠商和上雲的企業都積極參與這個標準的“制定”呢？這其實是一個互利互惠的結果。在具體談論這個標準的作用之前，我們先來聊聊兩種資源分配模式的差別。

排隊（先到先得）

這部分我們們以就醫為例進行說明。

去醫院看病需要提前掛號，醫生的號源這是一種先到先得的資源分式。特別是在北上廣這些大城市，好醫生的號源更是一號難求。如果想保證一定要拿到某個醫生的就診號，就要保證比別人都更早地到醫院排隊，提前排隊可以優先拿到就診號。我們現在來分析一下，提前排隊的人所付出的努力都有什麼價值。

對於排隊的當事人：當事人付出的努力對於自己是有意義的，自己拿到了就診號，得到了回報；
對於其他的排隊者而言，是沒有任何好處的。早來的人拿到了就診號，這就給別的競爭號源的人發出了一個訊號——來的越早就越有可能得到號源。這有可能引發更多人更早的前來排隊，這是一個惡性迴圈；
對於醫生來說，沒有任何意義，誰來看病都是一樣，誰得到這個號對醫生來說差別不大。很多時候甚至患者要求加號，但醫生其實是不願意的，因為每增加一個號源就意味著醫生要付出一點兒休息的時間。對於醫生而言，多付出的休息時間是不能換來更多報酬的，因為這是一個先到先得的排隊秩序規則，每一個號源的價格都是一樣的。

有沒有發現在排隊的過程中所做出的付出只對排隊的當事人是有意義的，對於醫生以及其他排隊者都沒有任何意義，甚至會帶來惡性競爭，造成社會資源的巨大浪費。在排隊的過程中，大量的資源都白白地流失，沒有給社會帶來任何價值。

市場經濟

這部分我們以購買雲伺服器 ECS 為例進行說明。

假設目前阿里雲的 ECS 是價效比最高的，大家上雲都優先選擇使用阿里雲的 ECS，那麼如果出現供不應求的情況就可能會導致 ECS 價格上漲，而價格上漲就會導致更多的雲廠商供應 ECS ，最終導致價格又回落下來。我們分析一下在這個過程中購買 ECS 的人和提供 ECS 的雲廠商之間的關係：

我們發現大量客戶選購 ECS 這件事情本身對於上雲的客戶是有益無害的，因為大量的需求會導致雲廠商做更多的供應，價格不可能持續高攀。所以 ECS 需求的競爭者之間其實不是零和博弈，而是一個相互合作的關係。大家一起把餅做大，就讓整個供應鏈更穩定、便宜。就好比我買蘋果手機，你也買蘋果手機，但是我們倆不是競爭關係，而且買的人越多，蘋果手機的質量就會越來越好；
大量的 ECS 需求會促使 ECS 技術的成熟。對於 ECS 的提供者雲廠商而言，越多的人購買自己的服務就越好，所有的客戶和雲廠商之間都是相互促進的關係。

市場經濟這種基於價格的自由交易能夠非常高效地促進大家的合作，任何一方的努力對於其他的參與者而言都是有價值的。和醫院排隊中先到的人付出的努力只對自己產生價值相比較，市場經濟的自由交易方式中，每一方的付出都讓整個系統得到了最佳化，這是社會資源合理利用、合理分配的一種非常好的方式。

是不是感覺扯遠了，這和雲端計算有什麼關係？我們繼續來剖析一下市場經濟，就可以看到和雲端計算的密切關係了。

我們先來看一下這個場景：如果雲廠商 A 提供的服務價效比很高，但是有一天雲廠商 B 提供了價效比更高的服務，客戶會不會立即把服務遷移到雲廠商 B 上去？答案是客戶想要遷移，但是比較難遷移。因為每一個雲廠商提供的服務標準都不太一樣，服務遷移的過程需要適配大量差異化的底層基礎設施，這給遷移帶來了巨大的成本，甚至抵消了雲廠商 B 提供的高價效比，所以平常比較少見到這種遷移。

前面我們們分析了市場經濟的資源分式是非常有利於社會各方面資源進行最優配置的，可是如果雲客戶不能在雲廠商之間低成本的流動，其實就很難選擇價效比高的雲廠商。所以從有效配置社會資源這個角度來分析，現在迫切需要一個能夠讓客戶在不同雲廠商之間低成本“流動”的體系，而這就是雲原生的意義所在。

如果把客戶要在雲上託管的應用比喻成水的話，那麼雲服務的價格就是海拔的高度。哪裡海拔低，水就很自然的流到哪裡去。無限降低遷移的成本，對於客戶和雲廠商來說都是非常有價值的一件事情。雲原生旨在以標準化雲服務的提供方式銜接雲廠商和客戶。這種方式對於客戶而言降低了上雲和跨雲遷移的成本，讓客戶始終保有和雲廠商議價的能力；對雲廠商而言，因為客戶跨雲遷移的成本低，所以只要能提供價效比更高的雲服務，就能很容易的聚集大量使用者。

雲原生是在不斷促進整個系統的良性迴圈：既能讓客戶始終保有選擇的能力，又能讓優秀的雲廠商快速服務更多的客戶。如果客戶的業務服務能像水一樣低成本在不同雲廠商之間流通，那麼雲廠商提供的服務就能像貨幣一樣在客戶之間流通。這是一個多贏的局面。

雲原生應用

說完雲原生這個理念，我們來看一下雲原生應用，以及在雲原生的這個大背景下，如何看待傳統的應用架構？

雲上基礎設施

無論是雲上的應用，還是雲下的應用，其實依賴的核心要素都沒有變，只是這些核心要素的提供形式發生了變化。

如上圖所示，共有 7 個核心要素。這 7 個要素中日常運維這一塊其實不是強依賴的，雖然它對業務的穩定性影響極大，但是這並不是業務跑起來的核心鏈路，沒有這些業務也能跑，而其它的幾塊都是核心鏈路。那麼我們就來看一下在雲原生架構下，這些核心鏈路的要素都處於什麼位置？然後剖析一下雲原生應用的基本正規化。

雲原生技術棧

我們先來看看最右邊的中介軟體這一塊，裡面有資料庫、Redis 以及訊息中介軟體元件。而這一塊其實是應用程式碼裡面直接呼叫的，並且這裡包含的所有能力都有標準的協議，比如無論是使用 SQL Server 還是使用 MySQL，我們程式裡都可以使用 SQL 規範進行操作。這部分其實早就被標準化了。

如圖所示，計算、儲存和網路這三個核心要素已經被 Kubernetes 層統一了。很多雲服務已經實現了計算、儲存和網路資源的無伺服器化，比如阿里雲的 ECI 和 ASK(Aliyun Serverless Kubernetes)。那麼還有兩塊 CICD 和應用託管沒有標準化，這就是應用編排這一層需要標準化的事情。Serverless 其實不單單是無伺服器，還包括應用本身的編排，這也是應用編排這一層的價值所在。

雲原生應用 Serverless 編排

Serverless Kubernetes 已經提供了 Pod 的無伺服器支援，而應用層想要用好這個能力其實還有很多事情需要處理。

彈性：

縮容到零
突發流量

灰度釋出

如何實現灰度釋出
灰度釋出和彈性的關係

流量管理

灰度釋出的時候如何在 v1 和 v2 之間動態調整流量比例
流量管理和彈性是怎樣一個關係
當有突發流量的時候如何和彈性配合，做到突發請求不丟失

我們發現雖然基礎資源可以動態申請，但是應用如果要做到實時彈性、按需分配和按量付費的能力還是需要有一層編排系統來完成應用和 Kubernetes 的適配。這個適配不單單要負責彈性，還要有能力同時管理流量和灰度釋出。

Knative 應運而生

上文中的內容就是 Knative 要解決的問題，這也是 Knative 出現的背景。接下來我們們來看看 Knative 。

Knative 是什麼

我們先看看官方給出的定義：“基於 Kubernetes 平臺，用於構建、部署和管理現代 Serverless 工作負載”。Knative 就是基於 Kubernetes 的應用 Serverless 編排系統。實際上 Knative 包含的不單單是 Workload，它還有 Kubernetes 原生的流程編排引擎和完備的事件系統。

前面提到 Kubernetes 實現了計算、儲存和網路的標準化，而 Knative 目標基於 Kubernetes 提供了應用 Serverless 工作負載編排的標準化。

Knative 核心模組

Knative 由三個核心模組構成：Tekton、Eventing 和 Serving。

Tekton 是 Kubernetes 原生的流程編排框架，主要用於構建 CICD 系統；
Eventing 主要負責事件處理功能，可以接入外部系統的事件，事件接入以後進行一系列的流程處理以及觸發 Serving 消費事件；
Serving 是應用執行工作負載的核心管理模組，主要負責流量排程、彈性以及灰度釋出等職責。

Tekton

Tekton 是一套 Kubernetes 原生的流程編排框架，主要用於構建 CICD 系統。比如從原始碼編譯成映象，以及對映象裡的服務進行測試、把映象釋出成應用等一系列的操作都可以基於 Tekton 完成。

Tekton 裡面基本的執行單元是 Task。>

Task 裡面可以包含多個順序執行的 Step。一個 Task 最終就是一個 Pod，裡面的每一個 Step 最終執行的時候就是一個 Container 。每提交一個 TaskRun CRD 到 Kubernetes 就會觸發一次 Task 的執行；
Pipeline 可以編排多個 Task，Pipeline 中的 Task 是可以設定依賴關係。Pipeline 會根據依賴關係生成一個有向無環圖，然後生成的根據有向無環圖併發或者序列執行一系列的 Task。每提交一個 PipelineRun CRD 就會觸發 Pipeline 的一次執行；
PipelineResource 代表 Pipeline 使用或者生成的資源，比如：github 程式碼倉庫、依賴或者使用的映象等等；
Tekton 是 Kubernetes 原生的實現，所以資源鑑權的秘鑰等資訊都可以透過 Kubernetes 的 Secret 進行管理。

Eventing

Eventing 模組基於 CloudEvent 標準實現了一系列的事件處理機制。Eventing 模組的核心能力分成四大塊。

外部事件接入

Eventing 有很強的擴充套件機制，可以接入任何外部事件源的事件，比如 github 裡面的 commit、pull request 等事件；Kubernetes 裡面的事件；訊息系統裡面的訊息；以及 OSS、表格儲存、Redis 等系統的事件。

CloudEvent 標準

Eventing 接入外部事件以後會轉換成 CloudEvent 格式，事件在內部的流轉都是透過 CloudEvent 事件標準完成的。

事件在內部的處理

Eventing 模組引入的 Broker 、Trigger 模型，不僅將事件複雜的處理實現給使用者遮蔽起來，更提供了豐富的事件訂閱、過濾機制。

事件處理事務管理

Eventing 基於可靠的訊息系統，可以對事件進行事務管理。如果事件消費失敗可以進行重試或者重新分發等操作。

Serving

Serving 核心的 CRD 就是 Service，Knative Controller 透過 Service 的配置自動操作 Kubernetes 的 Ingress、K8s Service 和 Deployment 從而實現簡化應用管理的目標。

Knative Service 對應一個叫做 Configuration 的資源，每次 Service 變化如果需要建立新的 Workload 就更新 Configuration，然後每次 Configuration 更新都會建立一個唯一的 Revision，Revision 可以認為是 Configuration 的版本管理機制。理論上 Revision 建立完以後是不會修改的，不同的 Revision 一般用於灰度釋出。

Route 是 Knative 管理流量的核心邏輯，Knative 是建立在 Istio 之後的，Knative Route Controller 透過 Route 的配置自動生成 Istio 的 VirtualService 資源，從而實現了流量的管理。

Knative Serving 對應用 Workload 的 Serverless 編排是從流量開始的。

流量首先達到 Knative 的 Gateway，Gateway 根據 Route 的配置自動把流量根據百分比拆分到不同的 Revision 上，然後每一個 Revision 都有一個自己獨立的彈性策略。當過來的流量請求變多的時候當前 Revision 就開始自動擴容。每一個 Revision 的擴容策略都是獨立的，相互不影響。

基於流量百分比對不同的 Revision 進行灰度，每一個 Revision 都有一個自己獨立的彈性策略。Knative Serving 透過對流量的控制實現了流量管理、彈性和灰度三者的完美結合。

Knative 的雲原生特性

Kubernetes 是業界公認的雲原生作業系統，作為雲原生的 Serverless 編排引擎 Knative 當然是相容 Kubernetes API 的。

Knative 本身就是開源的，你可以在任何 Kubernetes 叢集上面部署一套 Knative 。同樣，你在任何 Knative 叢集裡面的服務都可以無縫遷移到另外一個 Knative 叢集。如果你的服務是搭建在 Knative 之上，那麼你的服務就可以像水一樣在各個雲廠商流通，任何一個雲廠商的 Kubernetes 搭建好 Knative 就能輕鬆地把你的服務部署起來。我們們透過下面這個支援列表可以看到 Knative 已經被大量的廠商或平臺支援：

Google 的 CloudRun 是基於 Knative 的
IBM 公有云已經支援 Knative
阿里雲已經支援 Knative
Pivotal 的 Riff 是建立在 Knative 之上的 FaaS 系統
OpenShift 的 Knative 支援
Rancher RIO 是基於 Knative 的
kubeflow 社群基於 Knative 的 KFServing，正在用 Knative 做 AI 相關的框架

雲原生的力量就在於此，開放的標準得到了廣泛的支援。作為使用雲的客戶，基於這種開放的標準其實就是始終保有和服務商議價的權利，哪裡的服務好就到哪裡去，否則就有可能會被一家鎖定。對於雲廠商而言，透過開放的標準可以接入更多的客戶，而這個標準之下的具體實現，每家都會根據自身特點進行支援，這也是雲廠商的核心競爭力。

Knative 的典型應用場景

介紹了這麼多，接下來我們們就捋一捋 Knative 都適合在哪些場景中使用。

應用 Serverless 編排場景

Knative Serving 從流量入手對應用進行 Serverless 編排。

首先 Knative 基於 Istio Gateway 來接管服務的流量，可以做到按百分比對流量進行切分。切分的流量可以直接用於灰度釋出，比如把按百分比切分的流量直接轉給一個 Revision，精準地控制每一個 Revision 承接的流量百分比，從而達到精準控制灰度版本對線上服務應用的範圍。

Knative 的彈性策略是作用在每一個 Revision 之上的，不同的 Revision 根據“自己的節奏”獨自伸縮，實現了從流量到灰度灰度再到彈性這三者的完美結合，所有應用彈性託管訴求都可以透過 Knative 來實現。下面這些場景非常適合使用 Knative 來解決：

比如託管微服務應用
比如託管 Web 服務
比如託管 gRPC 服務

事件驅動

Knative 的 Eventing 提供了完整的事件模型，可以很容易地接入各個外部系統的事件。事件接入以後透過 CloudEvent 標準在內部流轉，Broker/Trigger 機制給事件處理提供了非常好的方式。

這套完備的事件系統可以比較容易的實現事件驅動的服務，比如：

IOT 場景
比如和各種雲產品的事件對接，從而實現雲產品狀態更新自動觸發一個服務等

基於 Tekton 的 Pipeline

基於 Tekton 構建 CICD 系統等，比如：

當 gihub 有程式碼提交以後自動觸發映象構建、服務釋出流程
當 docker 映象倉庫有映象提交的時候，自動對映象進行測試以及釋出成服務等

MicroPaaS

基於 Knative Servering 部署服務，你就無需手動操作 Kubernetes 資源，這樣可以大大降低使用 Kubernetes 的門檻。所以如果不是維護 Kubernetes 系統、或者要基於 Kubernetes 做複雜的開發，就可以使用 Knative 來管理自己的服務，非常便捷。

客戶案例

阿里雲 Knative 現在都有哪些典型的客戶案例？

Web 服務託管

Web 託管服務其實就是前面介紹的 MicroPaaS 型別的場景，客戶使用 Knative 是為了簡化使用 Kubernetes 的複雜度。即便不使用 Knative 的彈性也可以帶來應用託管效率的提升。

應用 Serverless 編排

微服務託管場景
web 應用託管和彈性
小程式、公眾號後臺
電商服務後臺

AI 服務託管

基於任務佇列的彈性伸縮
使用 ECI 做彈性，有效降低長期保有資源的成本

SaaS 服務託管

SaaS 使用者提交程式碼之後自動給使用者構建映象
SaaS 使用者自己推送了一個映象之後自動幫助使用者釋出服務
CMS 系統 SaaS 提供商可以透過 Helm Chart 非常方便地給使用者部署一套全新的服務

SpringCloud 微服務託管

把 Knative Service 的地址註冊到註冊中心，透過 Knative 的能力實現微服務的流量切分、灰度釋出和彈性。這樣 Knative 就給普通的微服務應用賦予了 Serverless 能力。

構建 CICD 系統

基於 git 程式碼倉庫的自動構建、服務釋出的 CICD 系統
當 docker 映象倉庫有新映象的時候自動執行測試或者服務釋出

OSS 事件

當 OSS 中新增一個檔案自動觸發機器學習任務的執行，對圖片進行分析、識別等
當 OSS 中新增一個影片檔案，自動觸發一個任務處理影片，比如影片內容識別等

TableStore 事件

Feed 流系統設計
社交資訊傳送通知等

Demo 演示

Demo 執行的命令如下：

https://help.aliyun.com/document_detail/126413.html 

縮容到零的場景  

registry.cn-hangzhou.aliyuncs.com/knative-sample/weather-detail:limit-v1 
hey -z 60s -c 30  
helm install ./chart --name live-weather --namespace live
helm delete live-weather --purge

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。

Knative Serverless 之道：如何 0 運維、低成本實現應用託管？