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

1. 基于云原生的單體應(yīng)用構(gòu)建

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

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

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

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

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

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

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

2.Knative

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

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

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

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

在上面到過可觀測性需求，在應(yīng)用服務(wù)中通?？梢苑譃槿齻€部分：日志、監(jiān)控、分布式跟蹤，為了實現(xiàn)這些功能Knative實現(xiàn)了Queue組件，其職責(zé)目前理解主要是分為兩個部分：完成觀測性數(shù)據(jù)收集、代理業(yè)務(wù)容器的訪問, Queue組件通過代理的方式實現(xiàn)上面提到指標(biāo)的統(tǒng)計, 并將對應(yīng)的數(shù)據(jù)匯報給后端的日志/監(jiān)控/分布式跟蹤服務(wù), 同時還需要向autoscaler同步當(dāng)前的并發(fā)監(jiān)控, 以便實現(xiàn)自動伸縮功能, Queue主要是代理應(yīng)用容器, 而Kantive支持縮容至零的特性, 在縮容至零的時候, Knative就會使用一個Activator Pod來替代Queue和應(yīng)用容器，從而實現(xiàn)縮容至零

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

Autoscaler是Knative中實現(xiàn)自動擴容的關(guān)鍵，其通過Activator和Queue兩個組件傳遞過來的監(jiān)控數(shù)據(jù)并根據(jù)配置來計算，實時動態(tài)的調(diào)整業(yè)務(wù)容器的副本數(shù)量，從而實現(xiàn)自動伸縮

Controller是Knative對應(yīng)資源的控制器，其本身的功能跟k8s中其他的組件的實現(xiàn)類似，根據(jù)資源的當(dāng)前狀態(tài)和期望狀態(tài)來進行一致性調(diào)整，從而實現(xiàn)最終一致性

Knative是基于k8s的CRD實現(xiàn)的，其webhook主要包含對應(yīng)資源數(shù)據(jù)的驗證和修改等admission相關(guān)

3. 總結(jié)

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