共計 1804 個字符，預計需要花費 5 分鐘才能閱讀完成。
今天就跟大家聊聊有關如何理解 kubernetes 中的 api 多版本機制實現，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
在 web 開發中隨著版本的更新迭代, 通常要在系統中維護多個版本的 api, 多個版本的 api 在數據結構上往往也各不相同, 今天就來一起學習下 kubernetes 中的 Scheme 機制是如何解決這個問題的, 如何借助 HTTP 請求里面的數據進行反序列化操作
1. web 請求的處理流程 1.1 HTTP 請求處理流程
通常首先是 webServer 先進行 Http 協議的處理, 然后解析成基礎的 webServer 內部的一個 Http 請求對象, 通常該對象持有對應請求的請求頭和底層對應的字節序列 (從 socket 流中讀取) 接著首先會通常根據對應的編碼格式來進行反序列化，完成從字節序列到當前接口的業務模型的映射, 然后在交給業務邏輯處理，從而最終進行持久化存儲, 本文的重點也就在反序列化部分
2. 模型映射的實現 2.1 描述資源版本信息
/api/{version}/{resource}/{action}
上面是一個基礎的 web url 通常我們都會為每個版本注冊一個對應的 URL, 其中會包含很關鍵的兩個信息即 version 與 resource, 通過這兩個信息, 通常我們就可以知道這可能是某個資源的那個版本, 如果我們把后面的 action 也包裹進來, 我們通常就可以知道對應的資源的那個具體操作
2.2 Group 組信息
在微服務流行的今天我們通常會為按照業務功能來進行微服務的切分，本質上一個微服務可能就是實現某個具體業務場景的功能集合，比如用戶系統通常會包含用戶的所有相關操作，在 kubernetes 中也有類似的概念就是所謂的 Group
POST /apis/batch/v1beta1/namespaces/{namespace}/cronjobs
POST /apis/apps/v1/namespaces/{namespace}/daemonsets
我們來看一個實例這是一個創建 daemonsets 和 cronjobs 的 url, 如果按照 Group、resource、version 來進行拆分可以拆成如下：batch、v1beta1、cronjobs 和 apps、v1、daemonsets，也就是大家嘗試的 GroupVersionKind, 其中 kind 對應的就是 resource
2.3 模型映射的實現
我們通過 url 里面獲取到資源的 GroupVersionKind 信息，如何將其映射為一個具體的類型呢？這貌似就很簡單了結合反射和 map 來進行就可以了，我們通過 url 獲取到對應想的 GVK 信息，然后在通過我們的映射表，就知道對應的模型是哪個，接下來就只需要進行轉換就行了
gvkToType map[schema.GroupVersionKind]reflect.Type3. 反序列化實現 3.1 解碼機制
那如何將對應的 Http 里面的數據流反序列化成內部的一個對象呢，別忘記了是 Http 協議, 肯定就是 header 頭里面的信息了，我們通過 header 頭里面的序列化就可以知道對應的編碼格式，只需要調用對應格式的解碼就可以完成了
Content-Type: application/json
3.2 默認對象
如果要將 json 格式的字節數組進行解碼通常要進行如下操作，我們需要傳入一個目標對象的指針，然后由 json 將對應的字節數據解析到目標對象中，我們也需要這樣一個對象，用于存儲反序列化的結果
func Unmarshal(data []byte, v interface{}) error {}
那只要我再提供一個當前版本對應的對象構造函數是不是就可以呢？答案是的
func() Object{ return 目標對象},
4. 設計總結
首先在進行 url 注冊的時候，我們構造出對應 url 映射的資源的版本信息即 GroupVersionKind, 后續的很多操作我們可以通過對應的版本映射獲取對應的目標操作或者對象, 然后再通過 Header 里面的字段獲取對應的解碼器, 并將 Body 里面的字節序列進行解碼到目標對象，就可以實現多版本資源的映射和反序列化操作了。
看完上述內容，你們對如何理解 kubernetes 中的 api 多版本機制實現有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
