最近閑下來，打算把Knative的核心組件Serving給學習下，會繼續采用k8s源碼學習的方式，管中窺豹以小擊大，學習serving的主要目標: 可觀測性基礎設施、自動伸縮、流量管理等核心組件的設計與實現，今天先簡單臆測下，感興趣的同學， 一起來學習吧

1. 基于云原生的單體應用構建

大多數公司的服務可能都已經經過單體、SOA演進到了當下流行的微服務架構，微服務給我們帶來了獨立演進、擴容、協作、數據自治等便利的背景下，也帶來了諸如穩定性保障、維護、服務治理等實際的問題，我們今天來一起來回歸單體，比如我們要新開一個業務，新上一個小的模塊這個場景，在云原生的場景下，是如何玩的

云原生有很多大佬有很多的解釋，我就簡單理解成是基于云構建而來，可以使用云上所有已知的現有的服務，同時享受云所帶來的彈性、按需付費、高可用等方面的原生能力

一個基礎的單體應用通常會依賴如下幾部分：持久化數據存儲、高性能緩存、全文索引、消息隊列等常見組件， 各家云廠商大多數會包含這些基礎的服務，我們只需要引入對應的類庫完成我們的應用邏輯即可, 然后程序就完成代碼的coding后,下一步就是交付了

基于k8s的云原生已經成為一個事實上的標準，將代碼和應用的數據打包成docker鏡像，基于Pod的交付模式，讓我們并不需要關注我們是使用IDC里面的實體機，還是公有云的云服務，我們只需要打包成docker鏡像，然后設置好檔期環境的配置數據，我們的單體應用就可以運行了, 但是通常我們會有一些非業務需求, 比如監控、日志等, 下一節我們來解決這些問題

在應用開發的初期，我們可能并沒有考慮監控、日志這種可觀測性的需求，通常是在上線的時候才會考慮這些，而基于k8s的云原生的環境下，通常會使用一個sidecar來實現這種基礎功能的增強，通過嵌入一個sidecar容器完成這種基礎組件的復用，可以基于sidecar模式實現日志、監控、分布式跟蹤、Https支持等基礎功能，而讓上層應用只關注業務邏輯的實現

在公司中通常一個業務往往都會進行一些公司內部系統的接入，比如用戶、支付、運營等服務，如果公司的服務也可以與基礎設施同等對待，并且這些服務也可以通過k8s的形式進行交付，則我們就可以只關注單體應用自身的擴展(小前臺)

通過上面的設想我們構建出了一個基礎的單體應用，應用程序只需要關注應用邏輯的編寫，全部的業務邏輯都耦合在一個應用內，其余的基礎設施、非業務需求全都由其他組件實現，接下來就該部署了，通常我們就需要分配個XHXG配置的Pod，然后為了高可用可能還需要N個replicaset，然后再來個HPA體驗下自動伸縮，跑了一段時間可能會發現，可能一天就兩個巴掌的訪問量，可是依舊占用著N*XHXG的資源，以這個角度我們來進入我們今天的主題Knative

2.Knative

Knative還在不斷變化中，一些設計文檔也并沒有對外開放，讀起來就相對k8s難一些，但整體代碼量相比較也少了一些，在后續的文章里面我們還是先管中窺豹，逐個組件進行代碼閱讀，但因為沒有相關的Proposal, 主要是參考冬島大神的相關文章來進行代碼的閱讀，只是個人理解，如有不對，歡迎指教，接下來我們看看knative是如何完成上面提到的功能與實現按需分配關鍵組件, 我們從流量入口開始依次介紹各個組件

在k8s中南北向流量通常由Ingress來進行管控，而在kantive流量管控的實現，主要是依賴于istio, Istio是一個ServiceMesh框架，Knative中與其集成主要是使用了istio的南北向流量管控的功能，其實就是利用istio對應的ingress的功能, 主要功能分為下面兩個部分

Knative里面支持藍綠、金絲雀等發布策略，其核心就是通過自己的revision版本管理和istio中的ingress的路由配置功能，即我們可以根據自己的需要設定對應的流量策略，從而進行版本的發布配置管理

Knative自動伸縮有兩個特點：按需自動分配、縮容至零，按需分配時指的knative可以根據應用的并發能力，來自動計算實現自動擴容，而且整個基本上是秒級，不同于HPA, 其次是就是縮容至零，即可以將對應的業務容器Pod，全部干掉，但是新進入請求之后會立即進行分配，并不影響正常訪問(可能初期延遲會相對高一些)

在上面到過可觀測性需求，在應用服務中通常可以分為三個部分：日志、監控、分布式跟蹤，為了實現這些功能Knative實現了Queue組件，其職責目前理解主要是分為兩個部分：完成觀測性數據收集、代理業務容器的訪問, Queue組件通過代理的方式實現上面提到指標的統計, 并將對應的數據匯報給后端的日志/監控/分布式跟蹤服務, 同時還需要向autoscaler同步當前的并發監控, 以便實現自動伸縮功能, Queue主要是代理應用容器, 而Kantive支持縮容至零的特性, 在縮容至零的時候, Knative就會使用一個Activator Pod來替代Queue和應用容器，從而實現縮容至零

Activator容器是縮容至零的關鍵，當業務容器沒有訪問的時候，Knative就會將對應的ingress流量指向Activator組件，當縮容至零的時候，如果此時有業務請求，Activator會立即通知autoscaler立刻拉起業務容器，并將流量轉發真正的業務容器，這樣既可以完成流量的無損轉發，又可以實現按需付費，再也不用為沒有訪問量的業務，一直啟動著Pod了, Activator并不負責實際的伸縮決策，伸縮組件主要是通過Autoscaler來實現

Autoscaler是Knative中實現自動擴容的關鍵，其通過Activator和Queue兩個組件傳遞過來的監控數據并根據配置來計算，實時動態的調整業務容器的副本數量，從而實現自動伸縮

Controller是Knative對應資源的控制器，其本身的功能跟k8s中其他的組件的實現類似，根據資源的當前狀態和期望狀態來進行一致性調整，從而實現最終一致性

Knative是基于k8s的CRD實現的，其webhook主要包含對應資源數據的驗證和修改等admission相關

3. 總結

結合上面的組件功能猜想，大概猜想了核心的數據流的實現，如圖所示，我們可以分為五層來考慮：觀測層(Queue和Activator)、決策層(Autoscaler)、控制層(Controller)、準入層(Webhook)、路由層(Istio INgress), 通過觀測層實時獲取用戶請求數據，發給決策層進行決策，并將決策結果寫入到Apiserver, 控制層感知，負責進行對應資源的更新，最終由路由層感知，進行流量分配，這樣就實現了整體流量的感知、決策、路由等核心功能。