這是我的個人資料，有興趣的同學可以關注的我的個人技術部落格** skyao.io。
這次演講的內容將會有這些，首先給大家介紹一下knative是什麼，然後是knative的主要元件，讓大家對knative有乙個基本的了解。之後我會簡單的對knative做一些分析和**，以及介紹一下knative後續的發展。希望本次的內容讓大家能夠對knative有乙個基本的認知。
knative是google牽頭發起的 serverless 專案。
這是knative的專案定義，注意這句話裡面幾個關鍵字：kubernetes，serverless，workload。
這是最近幾年 google 做大型專案的常態：產品剛出來，陣營就已經很強大了，所謂先聲奪人。
這是目前knative專案的進展，可以看到這是乙個非常新的專案，剛剛起步。
備註：這是截至2018-11-24演講當天的情況，到2023年12月底，knative已經發布了v0.2.2和v0.2.3兩個bugfix版本。但也還只是 0.2 ......
我們來看一下，在knative出來前， serverless 領域已有的實現，包括雲端提供的產品和各種開源專案。
這幅摘自the new stack的乙個serverless 調查，我們忽略調查內容，僅僅看看這裡列出來的serverless產品的數量——感受是什麼？好多serverless專案，好多選擇！
那問題來了：到底該怎麼選？
這就是目前 serverless 的問題：由於缺乏標準，市場呈現碎片化。不同廠商，不同專案，各不相同，因此無論怎麼選擇，都面臨乙個風險：**商繫結！
這段話來自 knative 的官方介紹，google 推出 knative 的理由和動機。其中第一條和第二條針對的是當前 serverless 市場碎片的現狀。而第四條多雲戰略，則是針對**商繫結的風險。
google描述knative的動機之一，是將雲原生中三個領域的最佳實踐結合起來。
小結：當前 serverless 市場產品眾多導致碎片化嚴重，存在廠商繫結風險，而 google 推出 knative ，希望能提供一套簡單易用的 serverless 方案，實現 serverless 的標準化和規範化。
第二部分，來介紹一下knative的主要元件。
前面提到，google 推出 knative ，試圖將雲原生中三個領域的最佳實踐結合起來。反應到 knative 產品中，就是這三大主要元件：build，serving，eventing。
knative build 元件，實現從**到容器的目標。為什麼不直接使用 dockfile 來完成這個事情？
knative build 在實現時，是表現為 kubernetes 的 crd，通過 yaml 檔案來定義構建過程。這裡引入了很多概念如：build，builder，step，template，source等。另外支援用 service account 做身份驗證。
knative serving元件的職責是執行應用以對外提供服務，即提供服務、函式的執行時支撐。
注意定義中的三個關鍵：
kubernetes-based：基於k8s，也僅支援k8s，好處是可以充分利用k8s平台的能力
scale-to-zero：serverless 最重要的賣點之一，當然要強調
request-driven compute：請求驅動的計算
值得注意的是，除了k8s之外，還有另外乙個重要基礎：istio！後面會詳細聊這個。
knative serving專案同樣也提供了自己的中介軟體原語，以支援如圖所示的幾個重要特性。
knative中有大量的概念抽象，而在這之後的背景，說起來有些意思：knative 覺得 kubernetes 和 istio 本身的概念非常多，多到難於理解和管理，因此 knative 決定要自己提供更高一層的抽象。至於這個做法，會是釜底抽薪解決問題，還是雪上加霜讓問題更麻煩......
knative的這些抽象都是基於 kubernetes 的 crd 來實現，具體抽象概念有：service、route、configuration 和 revision。特別提醒的是，右邊圖中的 service 是 knative 中的 service 概念，service.serving.knative.dev，而不是大家通常最熟悉的 k8s 的 service。
對於knative serving 元件，最重要的特性就是自動伸縮的能力。目前伸縮邊界支援從0到無限，容許通過配置設定。
knative 目前是自己實現的 autoscaler ，原來比較簡單：revision 對應的pod由 k8s deployment 管理，pod上的工作負載上報 metrics，彙總到 autoscaler 分析判斷做決策，在需要時修改 replicas 數量來實現自動伸縮（後面會再講這塊存在的問題）。
當收縮到0，或者從0擴充套件到1時，情況會特別一些。knative在這裡提供了名為 activator 的設計，如圖所示：
istio route 控制流量走向，正常情況下規則設定為將流量切到工作負載所在的pod
當沒有流量，需要收縮到0時，規則修改為將流量切到 activator ，如果一直沒有流量，則什麼都不發生。此時autoscaler 通過 deployment 將 replicas 設定為0。
當新的流量到來時，流量被 activator 接收，activator 隨即拉起 pod，在 pod 和工作負載準備好之後，再將流量**過去
knative eventing 元件負責事件繫結和傳送，同樣提供多個抽象概念：flow，source，bus，以幫助開發人員擺脫概念太多的負擔（關於這一點，我保留意見）。
bus 是對訊息匯流排的抽象。
source 是事件資料來源的抽象。
knative 在事件定義方面遵循了 cloudevents 規範。
小結：簡單介紹了一下 knative 中的三大元件，讓大家對 knative 的大體架構和功能有個基本的認知。這次就不再繼續深入 knative 的實現細節，以後有機會再展開。
在第三部分，我們來分析**一下 knative 的產品定位，順便也聊一下為什麼我們會看好 knative。
首先，最重要的一點是：knative不是乙個 serverless 實現，而是乙個 serviceless 平台。
也就是說，knative 不是在現有市場上的20多個 serverless 產品和開源專案的基礎上簡單再增加乙個新的競爭者，而是通過建立乙個標準而規範的 serverless 平台，容許其他 serverless 產品在 knative 上執行。
knative 在產品規劃和設計理念上也帶來了新的東西，和傳統 serverless 不同。工作負載和平台支撐是 knative 最吸引我們的地方。
要不要istio？這是 knative 一出來就被人詬病和挑戰的點：因為 istio 的確是複雜度有點高。而 k8s 的複雜度，還有 knative 自身的複雜度都不低，再加上 istio......
關於這一點，個人的建議是：
而 kubernetes + servicemesh + serverless 的組合，我們非常看好。
當然，knative 體系的複雜度問題是無法迴避的：kubernetes，istio，knative 三者都是複雜度很高的產品， 加在一起整體複雜度就非常可觀了，挑戰非常大。
第四個部分，我們來展望一下 knative 的後續發展，包括如何解決一些現有問題。
第乙個問題就是效能問題。
queue proxy也是乙個現存的需要替換的模組。
前面講過 knative 的 autoscaler 是自行實現的，而 k8s 目前已經有比較健全原生能力： hpa 和 custom metrics。目前 knative 已經有計畫要轉而使用 k8s 的原生能力。這也符合 cloud native 的玩法：將基礎能力下沉到 k8s 這樣的基礎設施，上層減負。
除了下沉到 k8s 之外，autoscaler還有很多細節需要在後續版本中完善。
對事件源和訊息系統的支援也遠不夠完善，當然考慮到目前才 0.2.0 版本，可以理解。
目前 knative 還沒有規劃 workflow 類的產品。
在網路路由能力方面也有很多欠缺，上面是 knative 在文件中列出來的需求列表。
最後聊聊 knative 的可拔插設計，這是 knative 在架構設計上的乙個基本原則：頂層松耦合，底層可拔插。
最頂層是 build / serving / eventing 三大元件，中間是各種能力，通過 k8s 的 crd 方式來進行宣告，然後底層是各種實現，按照 crd 的要求進行具體的實現。
在這個體系中，使用者接觸的是 build / serving / eventing 通用元件，通過通過標準的 crd 進行行為控制，而和底層具體的實現解耦。理論上，之後在實現層做適配，knative 就可以執行在不同的底層 serverless 實現上。從而實現 knative 的戰略目標：提供 serverless 的通用平台，實現 serverless 的標準化和規範化。
最後，我們對 knative 做乙個簡單總結。
先談一下 knative 的優勢，首先是 knative 自身的幾點：
然後，再次強調：kubernetes + service mesh + serverless 的組合，在用好的前提下，應該威力不凡。
此外，knative 在負載的支撐上，不拘泥於傳統的faas，可以支援 baas 和傳統應用，在落地時適用性會更好，使用場景會更廣泛。（備註：在這裡我個人有個猜測，knative 名字中 native 可能指的是 native workload，即在 k8s 和 cloud native 語義下的原生工作負載，如果是這樣，那麼 google 和 knative 的這盤棋就下的有點大了。）
最後，考慮到目前 serverless 的市場現狀，對 serverless 做標準化和規範化，出現乙個 serverless 平台，似乎也是乙個不錯的選擇。再考慮到 google 拉攏大佬和社群一起幹的一貫風格，攜 k8s 和 cloud native 的大勢很有可能實現這個目標。
當然，knative 目前存在的問題也很明顯，細節不說，整體上個人感覺有：
最後，對 knative 的總結，就一句話：前途不可限量，但是成長需要時間。讓我們拭目以待。
重新定義QLabel的clicked事件
在qlabel中有mousepressevent事件，只需要重新實現這個事件即可。新建乙個class繼承qlabel，在建構函式中installeventfilter this 安裝事件過濾器，並實現實現一下 void mousepressevent qmouseevent ev return qw...
重新定義了左側邊欄
其實還是在 公告 裡寫script的方法。然後向id為leftmenu的div裡新增dom元素，一開始總是出現以後立馬消失，百思不得其解。後來分析了源 才發現，這個版式很特別，左側邊欄的內容原本都新增在頁面下方乙個id為lefttemp的div中 display自然為none 最後再動用js將其新增...
重新定義了左側邊欄
其實還是在 公告 裡寫script的方法。然後向id為leftmenu的div裡新增dom元素，一開始總是出現以後立馬消失，百思不得其解。後來分析了源 才發現，這個版式很特別，左側邊欄的內容原本都新增在頁面下方乙個id為lefttemp的div中 display自然為none 最後再動用js將其新增...