Serverless 開源架構方案

2014 年 11 月，AWS 釋出了新產品 Lambda，開啟了全新的 Serverless 時代。按照當時的描述，Lambda 是一種計算服務，它按需執行使用者的程式碼，使用者無須關注底層的計算資源。繼 AWS Lambda 之後，很多公有云提供商都推出了自己的 Serverless 支援。2016 年 Google、Microsoft Azure 相繼推出自己的 Cloud Function 服務，2017 年國內公有云提供商阿里雲和騰訊雲也分別推出了各自的 Serverless 產品。

整體來說，Serverless 當前還處於發展初期，正在快速地迭代，並且各個雲廠商均推出一套自己的 Serverless 標準，所以這些 Serverless 是無法互通的，從而導致一旦選定了某個雲廠商，就會被這個雲廠商的技術體系綁住，無法自如地遷移。面對 Serverless 領域當前的無序和混亂，Google 聯合 IBM、Pivotal、Redhat 和 SAP，一起推出了 Knative，目的是實現 Serverless 標準化。

Knative 是一個以 Kubernetes 和 Istio 為基礎的 Serverless 開源架構方案，目的是解決 Kubernetes 環境下 Serverless 應用的構建、部署和執行。Knative 和以往 Serverless 解決方案最大的不同是，Knative 不僅管理函式，它的定位是管理所有的工作負載，除了 Serverless 關注的函式外，還包括普通的微服務，因此 Knative 強調的是通過相應的機制，使用者不用再關注應用的伸縮和運維。

此外，Knative 不是實現一個具體的 Serverless，而是構建一個能夠執行標準化 Serverless 的平臺，Knative 提供大量的擴充套件性支援，允許其他 Serverless 產品在其上執行。

架構上， Knative 由 Build、Serving 和 Eventing 3 個核心元件組成 。其中 Build 負責構建工作，把使用者定義的函式和應用構建成容器映象；Serving 負責計算工作，具體包含 Serverless 例項的路由和訪問，以及 Serverless 例項的按需伸縮；Eventing 負責事件工作，自動完成事件的繫結和觸發執行。

Serving 系統基於 Kubernetes 和 Istio 進行開發，利用 Kubernetes 強大的容器排程和生命週期管理能力以及 Istio 的通訊和通訊鏈路治理能力。另外，為了遮蔽 Kubernetes 和 Istio 的複雜度，Knative Serving 自身有更高一層的抽象能力，提供一組用來對應用和通訊進行管理的抽象概念（可使用 Kubernetes CRD 對這些抽象概念進行管理）。Knative Serving 的主要概念如下。

1）Route：工作負載的路由規則，對應 Istio 的 VirtualService。

2）Configuration：應用的最新配置，對應 Kubernetes 的 Deployment。

3）Revison：每次對工作負載進行修改的快照，對應 Istio 的 Subset。

4）Service：對工作負載的整個生命週期進行管理。

Knative 的 Serving 系統做的事情和 Kubernetes、Istio 大體相同，但通過提供更高的抽象，遮蔽了 Kubernetes、Istio 的細節，自動幫應用管理好 Deployment、VirtualService 以及 auto scaling 之間的關係。

auto scaling 是 Knative Serving 實現工作負載自動伸縮的關鍵元件，當前還處於發展早期，有不少效能問題，很不成熟，Knative 後續計劃將 auto scaling 下沉，直接複用 Kubernetes 原生的 auto scaling 能力。

基於 Kubernetes 的 Serverless 產品和解決方案市場上已經有不少，比如 Fission、Funktion、Kubeless 等，但同時依賴 Kubernetes 和 Istio 這兩個重量級的專案，Knative 還是第一個。Kubernetes 和 Istio 的複雜度都很高，同時基於 Kubernetes 和 Istio，再加上 Serverless 自身的複雜度，會導致整個 Serverless 解決方案的複雜度非常高，學習曲線上也非常陡峭，因此很多人都有如下疑問和質疑：Knative 中為什麼採用 Kubernetes 和 Istio 這麼重的通訊解決方案？

從架構和通訊功能實現來看，確實沒有必要，為了對上層使用者遮蔽底層 Kubernetes 和 Istio 的實現細節，Knative 又引入了一層抽象概念，對 Kubernetes 的容器和通訊功能進行封裝。如果通訊直接放在 Knative 層面上做，只聚焦 Kubernetes 平臺對 Serverless 的通訊支援，不需要平臺擴充套件性和場景擴充套件性支援，架構設計上會特別簡單，同時靈活性也會比現在好。

從短期和靜態的角度看，Knative 引入 Istio，確實沒有那麼大的必要，因為增加了複雜度，減少了靈活性。但從雲端計算基礎設施的大趨勢來看，Kubernetes 已經成為容器排程和生命週期管理的事實標準，可以看成雲原生時代的 Linux 作業系統；Istio 雖然產生時間不長，但已經顯現出強大的發展勢頭，當前在 Service Mesh 和 Kubernetes 生態中的地位已經不可撼動，可以看成雲原生時代的 TCP/IP 協議。

因此，如果從雲端計算的發展趨勢上看，通訊功能會被 Istio 完全接管，並下沉為基礎設施的一部分。在通訊層面，Istio 肯定更聚焦、更專業，Knative 從大趨勢出發，直接複用 Istio 的通訊層功能，避免後續架構上的修改和返工，可以將自身聚焦到 Serverless 層面的功能和生態打造上。從架構的角度看，這也是 Unix 設計哲學的體現—— 整個系統採用模組化設計，每個模組只聚焦一件事情，並且做好做到極致 。