前言
在前幾天的工作對接中，發現有的同學對服務的版本管理意識有點模糊，這裏結合前公司的版本管理規範簡單談一下微服務的版本管理應該怎麼做，權當拋磚引玉。
一、背景
在服務提供期間，我們常常會對服務有一些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定義中，結構體字段順序不能隨意變更；
- 枚舉字段可新增但不可被移除；
三、大版本遞增規則
大版本的遞增沒有太大的約束，但需要注意：在新版本爲大版本遞增的情況下，老版本的客戶端是無法調達新版本服務端的。若需求無法再滿足支持老版本客戶端，需注意通知老版本客戶使用方進行包依賴升級。
四、總結
接口定義是一種契約，作爲服務的提供者，我們應該多從用戶的角度出發切身處地爲用戶考慮，重視服務的版本管理。
