Serverles是什麼？
在講Knative之前，我們先說一下Serverless。
如同許多新的概念一樣，Serverless目前還沒有一個普遍公認的權威的定義。最新的一個定義是這樣描述的：“無伺服器架構是基於網際網路的系統，其中應用開發不使用常規的服務程式。相反，它們僅依賴於第三方服務（例如AWS Lambda服務），客戶端邏輯和服務託管遠端過程呼叫的組合。”
最開始，“無伺服器”架構試圖幫助開發者擺脫執行後端應用程式所需的伺服器裝置的設定和管理工作。這項技術的目標並不是為了實現真正意義上的“無伺服器”，而是指由第三方雲端計算供應商負責後端基礎結構的維護，以服務的方式為開發者提供所需功能，例如資料庫、訊息，以及身份驗證等。簡單地說，這個架構的就是要讓開發人員關注程式碼的執行而不需要管理任何的基礎設施。程式程式碼被部署在諸如AWS Lambda這樣的平臺之上，透過事件驅動的方法去觸發對函式的呼叫。很明顯，這是一種完全針對程式設計師的架構技術。其技術特點包括了事件驅動的呼叫方式，以及有一定限制的程式執行方式，例如AWS Lambda的函式的執行時間預設為3秒到5分鐘。從這種架構技術出現的兩年多時間來看，這個技術已經有了非常廣泛的應用，例如移動應用的後端和物聯網應用等。簡而言之，無伺服器架構的出現不是為了取代傳統的應用。然而，從具有高度靈活性的使用模式及事件驅動的特點出發，開發人員／架構師應該重視這個新的計算範例，它可以幫助我們達到減少部署、提高擴充套件性並減少程式碼後面的基礎設施的維護負擔。
傳統的 Serverless 解決方案卻一直叫好不叫座，這與其自身的問題是分不開的。目前Serverless存在以下問題：
- 缺乏統一標準。呈現碎片化，各家都有各自的實現。
- 廠商鎖定。比如使用 AWS Lambda 就必須配套使用 AWS 的 DB, S3 等產品，這樣使用者就被該廠商繫結，不能進行隨意的遷移或者遷移成本非常高。
此時Knative出現了。
Knative
Knative 是谷歌牽頭髮起的 Serverless 專案，其定位為基於 Kubernetes 的 Serverless 解決方案，旨在標準化 Serverless，簡化其學習成本。Knative 是以 Kubernetes 的一組自定義資源型別（CRD）的方式來安裝的，因此只需使用幾個 YAML 檔案就可以輕鬆地開始使用 Knative 了。這也意味著，在本地或者託管雲服務上，任何可以執行 Kubernetes 的地方都可以執行 Knative 和你的程式碼。
Knative 將重點放在兩個關鍵元件上：為其提供流量serving（服務），以及確保應用程式能夠輕鬆地生產和消費event（事件）。
Serving（服務）
基於負載自動伸縮，包括在沒有負載時縮減到零。允許你為多個修訂版本（revision）應用建立流量策略，從而能夠透過 URL 輕鬆路由到目標應用程式。
Event（事件）
使得生產和消費事件變得容易。抽象出事件源，並允許操作人員使用自己選擇的訊息傳遞層。
關於Serving和Event詳細介紹，我們會在後續的文章中一一解讀。
knative的優勢：
- 便利性：Knative 以 Kubernetes 作為其底層框架，因此無論是線上還是線下，任何 Kubernetes 叢集，無論是雲上 Kubernetes 服務還是自建 Kubernetes 叢集，都能透過安裝 knative 外掛快速的搭建 serverless 平臺。
- 標準化：Knative 聯合 CNCF，把所有事件標準化，統一為 CloudEvent，提供事件的跨平臺，同時讓函式和具體的呼叫方能夠解耦。
- 服務間解耦：使用 Knative 使得應用不在與底層依賴服務強繫結，可以跨雲實現業務互通
- 成熟的生態：Knative 基於 Kubernetes 體系構建，與 kubernetes 生態結合更緊密；
- 自動伸縮：監控應用的請求，並自動擴縮容, 藉助於istio(ambassador,gloo等)天生支援藍綠髮布、回滾功能，方便應用釋出流程。
- 應用監控：支援日誌的收集、查詢和分析，並支援 VAmetrics 資料展示、呼叫關係 tracing
結論
Knative 解決了現在Serverless 的諸多問題，如果kubernetes是容器編排的事實上的標準，那麼Knative也許就是未來serverless的事實上的標準。