Nepxion/Discovery灰度发布组件的使用教程(二)、基于REST请求调用灰度路由策略的使用

策略是通过REST或者RPC调用传递Header或者参数，达到用户自定义和编程灰度路由的目的。使用者可以实现跟业务有关的路由策略，根据业务参数的不同，负载均衡到不同的服务器，其核心代码参考discovery-plugin-strategy以及它的扩展。

可以简单的理解，灰度策略是在程序运行期间，动态的通过改变header或者参数来实现调用链路的动态变更，简单的说实现原理，就是从注册中心获取到的干个版本标记的服务列表中，过滤并找到只符合配置路由策略的这条路由线路上的服务进行请求调用，不符合路由策略的服务将被避开。

除了之前讲到的要引入相关的依赖包，更重要的是要是先灰度策略，配置参数的准确性非常重要

如果你的注册中心是基于eureka

# Eureka config for discovery
eureka.instance.metadataMap.group=xxx-service-group
eureka.instance.metadataMap.version=1.0
eureka.instance.metadataMap.region=dev

eureka:
  instance:
    metadata-map:
      # Eureka config for discovery
      group: xxx-service-group # 服务分组
      version: 1.0 # 服务版本
      # region: tianjin # 区域如果没有使用可以不填写

如果你的注册中心是基于nacos

# Nacos config for discovery
spring.cloud.nacos.discovery.metadata.group=example-service-group
spring.cloud.nacos.discovery.metadata.version=1.0
spring.cloud.nacos.discovery.metadata.region=dev

spring:
  cloud:
    nacos:
      discovery:
        metadata:
          # Nacos config for discovery
          group: xxx-service-group
          version: 1.0
          region: tianjin

作用就是首先要在metadata里标识服务自身的版本，A服务的1实例版本1.0，如果A服务升级调整变为版本2.0，则注册到注册中心的A服务实例包含2个版本 1.0和2.0

同时还有一个很重要的参数需要开启

开启(true)和关闭(false)用户自定义和编程灰度路由策略的时候，对REST方式的调用拦截。缺失则默认为false
spring.application.strategy.rest.intercept.enabled=true

spring:
  application:
    # ----- 开启(true)和关闭(false)用户自定义和编程灰度路由策略的时候，对REST方式的调用拦截。缺失则默认为false
    strategy:
      rest:
        intercept:
          enabled: true

这样所有的服务都具备了版本属性

然后在使用请求的时候，请求的Header中传入 n-d-version来进行路由规划，配置方式有2种：

第一种方式是直接填写版本号，例如 n-d-version: 1.0 或者 n-d-version: 2.0  则整个调用链路，都会使用1.0或者使用2.0来进行

如果服务间存在调用关系，使用的Feign调用，则A服务1.0调用B服务1.0 或者 A服务的2.0调用B服务的2.0

第二种方式是填写版本调用关系，例如n-d-version:{"example-server-a":"1.0","example-server-a":"2.0"}，这样的一个JSON串标识的含义是 A服务的1.0调用B服务的2.0。n-d-version:{"example-server-a":"1.0","example-server-a":"1.0;2.0"}，代表A服务1.0调用B服务的1.0或者2.0，B服务是轮训负载调用，此时如果B服务的2.0下线，则A服务会每次调用B服务的1.0，只是要注意一个现象，如果没有完全下线完毕，注册中心还有而服务不可用，则负载到B服务的2.0时候会有超时，但是过后还是会调用到1.0服务上返回结果，因为注册中心很快会下线，这种情况一般来说比较短暂。

以上这种场景比较适合小程序的前端发布，例如微信小程序一般会有一个发布上线审核的过程，审核期间可以发布对应的新版本服务用于微信官方审核，待审核发布通过后，老版本服务下线。最终实现基于灰度策略的路由。