共计 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 行业资讯频道，感谢大家的支持。
