服务版本与服务发布

服务版本与服务发布

1、服务概述

服务和人一样，需要不断成长，而导致服务成长的因素很多，比如业务的发展、功能变更、线上Bug等。人在不同的阶段会有不同的年龄，而服务在不同的阶段会有不同的版本。服务的多版本管理是分布式服务框架的重要特性。服务提供者和服务消费者都属于服务多版本管理的范围。服务提供者发布服务时，需要支持指定服务的版本号。服务消费者消费服务时，需要支持指定引用服务的版本号。

2、服务版本
 2.1　服务版本概述
服务版本号一般由“主版本（Major）＋副版本（Minor）＋微版本（Micro）”构成，比如正式版：1.0.1、1.2.6等。服务的版本号必须是有序的，在服务名相同的情况下，两个相同服务名的不同服务版本的版本号可以比较大小。当两个服务的服务名、版本号全部相同时，两个服务才是同一个服务，否则以第一个出现差异的版本号的大小决定服务版本的大小。

1）主版本：
    全盘重构时增加。
    重大功能或方向改变时增加。
    大范围不兼容之前的接口时增加，例如1.1.1 → 2.1.1。
2）副版本：增加新的业务功能时增加版本号，比如1.1.1 → 1.2.1。
3）微版本：
      增加新的接口时增加。

     在接口不变的情况下，增加接口的非必填属性时增加。

     增强和扩展接口功能时增加。
      修复接口的Bug时增加，例如1.1.1 → 1.1.2。

2.2　Snapshot和Release
在开发过程中，服务有Release正式版和Snapshot快照版。
Snapshot版本：代表不稳定、尚处于开发中的版本，即快照版本。
Release版本：代表功能趋于稳定、当前更新停止、可以用于发布的正式版本。

这两个概念用于描述JAR包，JAR包提供给其他服务作为依赖。服务版本升级路线如图12-1所示。

这里需要特别注意几点：
（1）Release版本一经发布，不得修改其内容，任何修改必须在新版本发布。

（2）不要轻易修改API，尤其是对API进行不兼容的升级或弃用。如果需要弃用API，就要提前在一个或几个版本中加入弃用标示或注解，在文档中建议用户更换为其他可替换的API，然后在下个版本号升级时再真正丢掉弃用的API。
（3）在接口还没有确定下来的时候，应该先使用Snapshot版本。