圖解kubernetes中的api多版本機制實現

在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、v1beta一、cronjobs和apps、v一、daemonsets，也就是你們嘗試的GroupVersionKind,其中kind對應的就是resource

2.3 模型映射的實現

咱們經過url裏面獲取到資源的GroupVersionKind信息，如何將其映射爲一個具體的類型呢？ 這貌似就很簡單告終合反射和map來進行就能夠了，咱們經過url獲取到對應想的GVK信息，而後在經過咱們的映射表，就知道對應的模型是哪一個，接下來就只須要進行轉換就好了

gvkToType map[schema.GroupVersionKind]reflect.Type

3.反序列化實現

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學習筆記地址: https://www.yuque.com/baxiaoshi/tyado3

> 微信號：baxiaoshi2020 > 關注公告號閱讀更多源碼分析文章 > 更多文章關注 www.sreguide.com > 本文由博客一文多發平臺 OpenWrite 發佈