前言
在前几天的工作对接中，发现有的同学对服务的版本管理意识有点模糊，这里结合前公司的版本管理规范简单谈一下微服务的版本管理应该怎么做，权当抛砖引玉。
一、背景
在服务提供期间，我们常常会对服务有一些BugFix、或者是一些内部逻辑的更改、又或者是代码的优化。在于版本管理的角度来说，每当我们对已发布的代码进行更新以后，需要进行服务版本的升级。如SayHelloService v1.0.0服务进行了Bug的修复，下次升级的服务版本应该需要递增，如1.0.1或1.2.0等。
BugFix常有，那服务版本也会常常会有变化，这样已提供给接入方的客户端是否需要进行依赖包的升级？业界通用的做法是，服务小版本向下兼容。既1.0+可调达1.1+的服务端，如：v1.0.0 => v1.0.x => v1.x.x ≠> 2.x.x。
二、小版本递增规则
2.1 接口定义
在接口参数定义上，不可影响旧版本客户端的调用
- （RPC）入参顺序不应随意变更；
- 参数类型不应随意变更；
- 返回类型不可更改；
- （RPC）入参可在原参数结尾位置增加可选参数，但不能更改原有参数的顺序（REST接口参数无顺序，path variable除外）；
- 不可增加必选参数；
- 原必选入参不可被移除；
- （REST）不能更改操作资源的动词；
- （REST）不能更改响应的HTTP status；
2.2 结构体定义
- 结构体可随意增加可选类型字段，但不能重命名原有参数；如果是RPC接口TLV方式的IDL定义，则参数顺序也不可更改；
- 原必选字段不可被移除；
- RPC接口TLV方式的IDL定义中，结构体字段顺序不能随意变更；
- 枚举字段可新增但不可被移除；
三、大版本递增规则
大版本的递增没有太大的约束，但需要注意：在新版本为大版本递增的情况下，老版本的客户端是无法调达新版本服务端的。若需求无法再满足支持老版本客户端，需注意通知老版本客户使用方进行包依赖升级。
四、总结
接口定义是一种契约，作为服务的提供者，我们应该多从用户的角度出发切身处地为用户考虑，重视服务的版本管理。
