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

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

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

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

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

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

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

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

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

2.Knative

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

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

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

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

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

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

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

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

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

3. 總結(jié)

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