共計 3172 個字符，預計需要花費 8 分鐘才能閱讀完成。
今天給大家介紹一下如何分析 Knative 核心組件 Serving 基礎設計。文章的內容丸趣 TV 小編覺得不錯，現在給大家分享一下，覺得有需要的朋友可以了解一下，希望對大家有所幫助，下面跟著丸趣 TV 小編的思路一起來閱讀吧。
最近閑下來，打算把 Knative 的核心組件 Serving 給學習下，會繼續采用 k8s 源碼學習的方式，管中窺豹以小擊大，學習 serving 的主要目標: 可觀測性基礎設施、自動伸縮、流量管理等核心組件的設計與實現，今天先簡單臆測下，感興趣的同學，一起來學習吧
1. 基于云原生的單體應用構建
大多數公司的服務可能都已經經過單體、SOA 演進到了當下流行的微服務架構，微服務給我們帶來了獨立演進、擴容、協作、數據自治等便利的背景下，也帶來了諸如穩定性保障、維護、服務治理等實際的問題，我們今天來一起來回歸單體，比如我們要新開一個業務，新上一個小的模塊這個場景，在云原生的場景下，是如何玩的
1.1 云原生下的單體應用
云原生有很多大佬有很多的解釋，我就簡單理解成是基于云構建而來，可以使用云上所有已知的現有的服務，同時享受云所帶來的彈性、按需付費、高可用等方面的原生能力
一個基礎的單體應用通常會依賴如下幾部分：持久化數據存儲、高性能緩存、全文索引、消息隊列等常見組件，各家云廠商大多數會包含這些基礎的服務，我們只需要引入對應的類庫完成我們的應用邏輯即可, 然后程序就完成代碼的 coding 后, 下一步就是交付了
1.2 基于 k8s 的云原生交付
基于 k8s 的云原生已經成為一個事實上的標準，將代碼和應用的數據打包成 docker 鏡像，基于 Pod 的交付模式，讓我們并不需要關注我們是使用 IDC 里面的實體機，還是公有云的云服務，我們只需要打包成 docker 鏡像，然后設置好檔期環境的配置數據，我們的單體應用就可以運行了, 但是通常我們會有一些非業務需求, 比如監控、日志等, 下一節我們來解決這些問題
1.3 sidecar 模式
在應用開發的初期，我們可能并沒有考慮監控、日志這種可觀測性的需求，通常是在上線的時候才會考慮這些，而基于 k8s 的云原生的環境下，通常會使用一個 sidecar 來實現這種基礎功能的增強，通過嵌入一個 sidecar 容器完成這種基礎組件的復用，可以基于 sidecar 模式實現日志、監控、分布式跟蹤、Https 支持等基礎功能，而讓上層應用只關注業務邏輯的實現
1.4 服務即基礎設施
在公司中通常一個業務往往都會進行一些公司內部系統的接入，比如用戶、支付、運營等服務，如果公司的服務也可以與基礎設施同等對待，并且這些服務也可以通過 k8s 的形式進行交付，則我們就可以只關注單體應用自身的擴展 (小前臺)
通過上面的設想我們構建出了一個基礎的單體應用，應用程序只需要關注應用邏輯的編寫，全部的業務邏輯都耦合在一個應用內，其余的基礎設施、非業務需求全都由其他組件實現，接下來就該部署了，通常我們就需要分配個 XHXG 配置的 Pod，然后為了高可用可能還需要 N 個 replicaset，然后再來個 HPA 體驗下自動伸縮，跑了一段時間可能會發現，可能一天就兩個巴掌的訪問量，可是依舊占用著 N *XHXG 的資源，以這個角度我們來進入我們今天的主題 Knative
2.Knative
Knative 還在不斷變化中，一些設計文檔也并沒有對外開放，讀起來就相對 k8s 難一些，但整體代碼量相比較也少了一些，在后續的文章里面我們還是先管中窺豹，逐個組件進行代碼閱讀，但因為沒有相關的 Proposal, 主要是參考冬島大神的相關文章來進行代碼的閱讀，只是個人理解，如有不對，歡迎指教，接下來我們看看 knative 是如何完成上面提到的功能與實現按需分配關鍵組件, 我們從流量入口開始依次介紹各個組件
2.1 基于 Istio 實現南北向流量的管控
在 k8s 中南北向流量通常由 Ingress 來進行管控，而在 kantive 流量管控的實現，主要是依賴于 istio, Istio 是一個 ServiceMesh 框架，Knative 中與其集成主要是使用了 istio 的南北向流量管控的功能，其實就是利用 istio 對應的 ingress 的功能, 主要功能分為下面兩個部分
2.1.1 版本部署管理
Knative 里面支持藍綠、金絲雀等發布策略，其核心就是通過自己的 revision 版本管理和 istio 中的 ingress 的路由配置功能，即我們可以根據自己的需要設定對應的流量策略，從而進行版本的發布配置管理
2.1.2 自動伸縮 (至零)
Knative 自動伸縮有兩個特點：按需自動分配、縮容至零，按需分配時指的 knative 可以根據應用的并發能力，來自動計算實現自動擴容，而且整個基本上是秒級，不同于 HPA, 其次是就是縮容至零，即可以將對應的業務容器 Pod，全部干掉，但是新進入請求之后會立即進行分配，并不影響正常訪問 (可能初期延遲會相對高一些)
2.2 Queue sidecar
在上面到過可觀測性需求，在應用服務中通常可以分為三個部分：日志、監控、分布式跟蹤，為了實現這些功能 Knative 實現了 Queue 組件，其職責目前理解主要是分為兩個部分：完成觀測性數據收集、代理業務容器的訪問, Queue 組件通過代理的方式實現上面提到指標的統計, 并將對應的數據匯報給后端的日志 / 監控 / 分布式跟蹤服務, 同時還需要向 autoscaler 同步當前的并發監控, 以便實現自動伸縮功能, Queue 主要是代理應用容器, 而 Kantive 支持縮容至零的特性, 在縮容至零的時候, Knative 就會使用一個 Activator Pod 來替代 Queue 和應用容器，從而實現縮容至零
2.3 Activator
Activator 容器是縮容至零的關鍵，當業務容器沒有訪問的時候，Knative 就會將對應的 ingress 流量指向 Activator 組件，當縮容至零的時候，如果此時有業務請求，Activator 會立即通知 autoscaler 立刻拉起業務容器，并將流量轉發真正的業務容器，這樣既可以完成流量的無損轉發，又可以實現按需付費，再也不用為沒有訪問量的業務，一直啟動著 Pod 了, Activator 并不負責實際的伸縮決策，伸縮組件主要是通過 Autoscaler 來實現
2.4 Autoscaler
Autoscaler 是 Knative 中實現自動擴容的關鍵，其通過 Activator 和 Queue 兩個組件傳遞過來的監控數據并根據配置來計算，實時動態的調整業務容器的副本數量，從而實現自動伸縮
2.5 Controller
Controller 是 Knative 對應資源的控制器，其本身的功能跟 k8s 中其他的組件的實現類似，根據資源的當前狀態和期望狀態來進行一致性調整，從而實現最終一致性
2.6 webhook
Knative 是基于 k8s 的 CRD 實現的，其 webhook 主要包含對應資源數據的驗證和修改等 admission 相關
3. 總結
結合上面的組件功能猜想，大概猜想了核心的數據流的實現，如圖所示，我們可以分為五層來考慮：觀測層 (Queue 和 Activator)、決策層 (Autoscaler)、控制層 (Controller)、準入層 (Webhook)、路由層 (Istio INgress), 通過觀測層實時獲取用戶請求數據，發給決策層進行決策，并將決策結果寫入到 Apiserver, 控制層感知，負責進行對應資源的更新，最終由路由層感知，進行流量分配，這樣就實現了整體流量的感知、決策、路由等核心功能。
以上就是如何分析 Knative 核心組件 Serving 基礎設計的全部內容了，更多與如何分析 Knative 核心組件 Serving 基礎設計相關的內容可以搜索丸趣 TV 之前的文章或者瀏覽下面的文章進行學習哈！相信丸趣 TV 小編會給大家增添更多知識, 希望大家能夠支持一下丸趣 TV！
