今日咱们来聊一下微服务项目中的版别号要怎样规划。

小伙伴们平常看到的项目版别号，基本上都是分为了三部分 X.Y.Z，版别晋级的时分版别号都会变，那么版别号怎样变，这可不是拍脑门决议的，今日咱们就一起来探讨一下这个话题。

1. 语义化版别操控标准

版别号该怎么操控？其实是有一个标准标准的，标准地址：

  • semver.org/lang/zh-CN/

这个标准十分友爱的提供了中文版的内容。

语义化的版别操控标准要求版别号由三部分构成：

  • MAJOR（X）：这个是主版别号，一般是涉及到不兼容的 API 更改时，这个会改动。
  • MINOR（Y）：这个是次版别号，当咱们对 API 进行向后兼容的增强时，这个版别号会改动，换句话说，也便是有新增的功用时，这儿会改动。
  • PATCH（Z）：这个是修订号，当咱们进行一些 BUG 的修复，然后要发版的时分，这儿会发生改动。

语义化的版别操控标准首要做了如下一些要求：

  1. 运用语义化版别操控的软件有必要（MUST）界说公共 API。该 API 能够在代码中被界说或出现于谨慎的文档内。不管何种方式都应该力求精确且完整。
  2. 标准的版别号有必要（MUST）选用 X.Y.Z 的格局，其间 X、Y 和 Z 为非负的整数，且制止（MUST NOT）在数字前方补零。X 是主版别号、Y 是次版别号、而 Z 为修订号。每个元素有必要（MUST）以数值来递加。例如：1.9.1 -> 1.10.0 -> 1.11.0。
  3. 标记版别号的软件发行后，制止（MUST NOT）改动该版别软件的内容。任何修正都有必要（MUST）以新版别发行。有的小伙伴或许会说咱们的项目处于快速开发阶段，API 不稳定，天天变，要是依照这个要求来得发多少个版别才够用呀！其实，一般 API 快速改动首要有两种状况，一种是项目刚立项的时分，此时主版别号为 0，那么这个时分的 API 就不能算是稳定的 API；别的一种状况则是下个主版别处于快速开发中，但是这种状况一般会有一个新的分支用来办理下个版别的代码，所以和这儿的要求实践上并不冲突（具体参见第 4、5 条）。
  4. 主版别号为零（0.y.z）的软件处于开发初始阶段，一切都或许随时被改动。这样的公共 API 不该该被视为稳定版。
  5. 1.0.0 的版别号用于界定公共 API 的形成。这一版别之后一切的版别号更新都基于公共 API 及其修正内容。那么有的小伙伴或许会纠结什么时分版别号从 0.Y.Z 变为 1.Y.Z 呢？一般来说，当你的项目现已上了出产环境或许说有稳定的 API 提供给别人运用的时分，基本上就能够算是 1.Y.Z 了。
  6. 修订号 Z（x.y.Z | x > 0）有必要（MUST）在只做了向下兼容的修正时才递加。这儿的修正指的是针对不正确结果而进行的内部修正。
  7. 次版别号 Y（x.Y.z | x > 0）有必要（MUST）在有向下兼容的新功用出现时递加。在任何公共 API 的功用被标记为弃用时也有必要（MUST）递加。也能够（MAY）在内部程序有大量新功用或改善被参加时递加，其间能够（MAY）包含修订等级的改动。每逢次版别号递加时，修订号有必要（MUST）归零。
  8. 主版别号 X（X.y.z | X > 0）有必要（MUST）在有任何不兼容的修正被参加公共 API 时递加。其间能够（MAY）包含次版别号及修订等级的改动。每逢主版别号递加时，次版别号和修订号有必要（MUST）归零。
  9. 先行版别号能够（MAY）被标示在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符来润饰。标识符有必要（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且制止（MUST NOT）留白。数字型的标识符制止（MUST NOT）在前方补零。先行版的优先级低于相关联的标准版别。被标上先行版别号则表明这个版别并非稳定而且或许无法满足预期的兼容性需求。典范：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
  10. 版别编译信息能够（MAY）被标示在修订版或先行版别号之后，先加上一个加号再加上一连串以句点分隔的标识符来润饰。标识符有必要（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且制止（MUST NOT）留白。当判别版别的优先层级时，版别编译信息可（SHOULD）被疏忽。因此当两个版别只要在版别编译信息有不一起，归于相同的优先层级。典范：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。
  11. 版别的优先层级指的是不同版别在排序时怎么比较。
    1. 判别优先层级时，有必要（MUST）把版别依序拆分为主版别号、次版别号、修订号及先行版别号后进行比较（版别编译信息不在这份比较的列表中）。
    2. 由左到右依序比较每个标识符，第一个差异值用来决议优先层级：主版别号、次版别号及修订号以数值比较。例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。
    3. 当主版别号、次版别号及修订号都相一起，改以优先层级比较低的先行版别号决议。例如：1.0.0-alpha < 1.0.0。
    4. 有相同主版别号、次版别号及修订号的两个先行版别号，其优先层级有必要（MUST）透过由左到右的每个被句点分隔的标识符来比较，直到找到一个差异值后决议：
      1. 只要数字的标识符以数值凹凸比较。
      2. 有字母或连接号时则逐字以 ASCII 的排序来比较。
      3. 数字的标识符比非数字的标识符优先层级低。
      4. 若最初的标识符都相一起，栏位比较多的先行版别号优先层级比较高。 例如：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。

2. 微服务中的版别号

那么在微服务中，咱们的版别号该怎样规划呢？

首先，整体上的思路，便是依照上文所说的语义化版别操控标准来。

其次，上面尽管给出了很多条条框框，然而咱们实践开发中，一般只需要从以下几个方面简略考虑即可，每次发版的时分都去翻这个标准显然也不现实：

  1. 理想状况下，咱们应该只进行向后兼容的更新。

咱们要为项目增加新功用、新特性，咱们有必要要考虑到项目的兼容性。例如接口中新加了一个参数，那么为了老版别的客户端能够顺利拜访这个接口，服务端应该考虑为老版别客户端缺少的恳求参数提供一个默认值。咱们也或许为呼应增加新的特点，或许提供了一些新的接口，当然这些一般都不影响老客户端。

  1. 有必要进行不兼容的晋级。

有时分咱们有必要进行一些不兼容的晋级，对 API 做一些首要的修正，考虑到微服务之间的松耦合性，咱们无法强迫客户端进行立马晋级，此时或许会考虑在某一个时间段内，两个版别的 API 共存。

多个 API 共存的时分，一个比较简略的办法是在 API 规划的时分，加上版别号，例如 /v1/xxx 或许 /v2/xxx，不过这种写法有一个小小的缺陷，便是途径中加了版别号之后，这个途径看起来就不是一个完美的 REST 途径了。

所以这块还有一个方案，便是把恳求的 API 的版别号写到恳求头中。

具体的实现思路是这样：

首先，在微服务中，咱们一切的恳求一般来说都会经过网关，咱们能够在网关中提取出恳求头的 Accept 参数，然后依据 Accept 中的恳求版别号，做不同的恳求转发，假如版别号是 1.0，就转发到 1.0 的服务上去；假如版别号是 2.0，则转发到 2.0 的服务上去。基本上便是这个姿态。

以现在微服务中主流的网关 Spring Cloud Gateway 为例，咱们能够做如下装备：

spring:
  application:
    name: gateway
  cloud:
    nacos:
      discovery:
        password: nacos
        username: nacos
        server-addr: a.b.c.d:8848
        namespace: public
    gateway:
      discovery:
        locator:
#          enabled: true
          lower-case-service-id: true
      routes:
        - id: v1_provider
          uri: lb://provider
          predicates:
            - Path=/p/**
            - Header=Accept,.*;?version=1\.0(|;.*)
          filters:
            - StripPrefix=1
server:
  port: 8082

咱们看一下这个装备：

  1. 首先记住封闭服务自动发现，不然经过默认的服务名进行代理就不会经过咱们装备的过滤器了。
  2. 然后咱们手动装备服务转发，上面的装备基本上都是常规装备，跟版别号相关的装备是 Header=Accept,.*;?version=1\.0(|;.*)，这个装备便是对恳求头提出要求，首先前面的 Accept 表明这儿是要判别恳求头中的 Accept 字段，然后后边紧跟着的是 value（两者之间用 , 隔开），这个 value 是一个正则表达式 .*;?version=1\.0(|;.*)，意思便是在 version=1.0 之前和之后能够有任意字符串，只要 value 中包含 version=1.0 就算匹配上了。只要匹配上了，才会进行恳求转发，不然不会进行恳求转发。
  3. 最终，咱们在发送恳求的时分，设置如下恳求头即可：
    微服务的版本号要怎么设计？
    假如版别号是 version=2.0，则会报一个 404 错误：
    微服务的版本号要怎么设计？

好啦，一个小小的版别号话题，感兴趣的小伙伴能够试试最终这段代码哦～