本篇文章不做深入的技術討論，僅從Knative的基本概念及誕生背景入手，讓讀者對Knative的產生初步瞭解。
Knative是什麼？
2018年7月，Google在Google Cloud Next 2018上發佈了Knative，將其定位爲基於Kubernetes的Serverless解決方案，旨在標準化Serverless，簡化其學習成本。自開源以來，Knative項目備受關注，在github上已經獲得1000+的start， Pivotal、IBM、Red Hat等公司也紛紛成爲其重要的合作伙伴。
傳統Serverless之殤
既然Knative的定位是Serverless解決方案，那我們不不妨看看Knative之前的Serverless解決方案是什麼樣子。
提到Serverless，開發者往往可以想到一張經典的圖片，它描述了傳統互聯應用架構與Serverless架構的不同點，Serverless架構讓開發者在構建應用的過程中無需關心計算資源的獲取和運維，由服務提供商按需分配計算資源並保證應用執行的SLA，商業策略上也不同於傳統資源的計費模式，按照調用次數進行計費，避免了資源冗餘造成的浪費，有效節省應用成本。
Serverless大體上可以分爲兩種類型：“Backend as a Service” 和 “Functions as a Service”。
BaaS(Backend as a Service) 後端即服務，服務商爲客戶(開發者)提供整合雲後端的服務，如提供文件存儲、數據存儲、推送服務、身份驗證服務等功能，以幫助開發者快速開發應用。
FaaS(Function as a Service) 函數即服務，服務商提供一個平臺，允許客戶開發、運行和管理應用程序功能，而無需構建和維護基礎架構。按照此模型構建應用程序是實現“無服務器”體系結構的一種方式，通常在構建微服務應用程序時使用。
傳統的互聯網APP主要採用B/S架構，服務器端需長期維持業務進程來處理客戶端請求，並調用代碼邏輯完成請求響應流程。而在Serverless架構中，應用的業務邏輯將基於FAAS架構拆分成多個相互獨立的功能組件，並以API的形式向外提供服務；同時，不同功能組件間的代碼將存儲在雲服務廠商的函數服務（Function Service）上，如：Amazon Lambda，Azure Function，Google Cloud Functions等，業務代碼僅在被調用時運行，在響應結束時釋放資源。
然而，傳統的Serverless解決方案卻一直叫好不叫座，這與其自身的問題是分不開的:
- 廠商綁定
Serverless只提供了應用本身部署和運行的便利性，但應用依賴的其它服務，比如API網關、數據庫、消息、緩存管理組件等，會因爲選用了某個廠商的Serverless平臺，而必須使用該廠商提供的配套服務，比如使用AWS Lambda就必須配套使用AWS的DB, S3等產品，這樣用戶就被該廠商綁定，不能進行隨意的遷移或者遷移成本非常高。在Baas行業內，一個比較典型的事件是：2016年1月19日，Facebook關閉曾經花鉅額資金收購的Parse，造成用戶不得不遷移在這個平臺中產生一年多的數據，無疑需要花費比較大的人力和時間成本。
- 沒有行業標準
因爲對Serverless缺乏統一認知以及相應的標準，Serverless應用無法適應所有的雲平臺，只適合簡單的應用開發，無法推動形成大型成功案例。
Knative：Serverless大規模商業化實施的基石
Knative提供了一組標準中間件，專注於在雲原生平臺上構建和運行應用的通用任務，比如源碼到容器的構建、將服務綁定到事件生態系統（通過事件觸發工作負載的執行）、管理部署期間的路由和流量以及工作負載的自動擴展。該框架爲用戶提供了“部署任何負載都需要的熟悉的、慣用的語言支持以及標準化的模式，這些負載包括傳統的應用，也包括函數或容器應用”。
相對於傳統的Serverless解決方案，Knative的優良性得到開發者和企業認可，這也是其短時間內得到業內各大廠商追捧的主要原因。
細數一下Knative的優勢，包括：
- 便利性：Knative以Kubernetes和istio作爲其底層框架，因此無論是線上還是線下，任何Kubernetes集羣，無論是雲上Kubernetes服務還是自建Kubernetes集羣，都能通過安裝istio和knative插件快速的搭建serverless平臺。
- 標準化：Knative聯合 CNCF，把所有事件標準化，統一爲CloudEvent，提供事件的跨平臺，同時讓函數和具體的調用方能夠解耦。
- 服務間解耦：使用Knative使得應用不在與底層依賴服務強綁定，可以跨雲實現業務互通
- 成熟的生態：Knative基於Kubernetes 體系構建，與kubernetes 生態結合更緊密；
- 自動伸縮：監控應用的請求，並自動擴縮容,得益於Istio能力加持，天生支持藍綠髮布、回滾功能，方便應用發佈流程。
- 應用監控：支持日誌的收集、查找和分析，並支持VAmetrics數據展示、調用關係tracing
目前，Knative已經發布到0.5版本，每一次更新都離客戶的最終訴求近了一步，加上Google, IBM ，Pivotal，Redhat這樣的豪華社區陣營支持，Knative的未來必定是一片坦途，相信在很短的時間內，我們就能看到基於Knative的成功商業化案例。
下一篇文章開始，我們將對Knative的核心組件：Build、Serving、Event進行深入解讀，並結合我們在日常工作中的案例，讓大家對Knative從技術到應用有一個全方位的瞭解。