this is a micro service gray sdk.
一、需求产生背景
1、微服务化之后，在dev环境下，会有如下场景：

1）、多人开发同一微服务，调试时，各个开发的微服务都注册在eureka上，这时，各个开发使用dev环境的服务调用方，无法准确的将请求路由到需要调试的微服务上。

2）、开发人员在本地调试某一微服务（不稳定版本）时，会注册到eureka上，这时，dev环境的服务依赖方，会有部分流量访问到这个本地服务，造成dev环境中的服务依赖方可能不稳定。

2、在qa环境下，会有如下场景：

测试人员需要测试的功能部署在特定的服务器上，必须指定路由访问。

3、在线上，可能会有这样的场景：

针对某些重大功能的发布，需要首先尝试小部分的发布，发布后能够达到预期效果，之后全量推广。

二、总体方案


三、灰度策略
用户特征：

1、按照用户请求的ip划分（例如：ip段为172网段的）

2、按照用户名区分（例如：手机尾号为1的用户）

3、header中设置tag标记（例如：alpha版本的app调用的header均打入alpha标记）

服务器特征：

以环境变量的形式提供：

podenv：缺省为no，在dev部署环境下，此环境变量设置为dev

gray_tag：缺省为no，可以通过环境变量，或者jvm参数-Dgray_tag=xxxx 来设置

gray_name：缺省为no，可以通过环境变量，或者jvm参数-Dgray_name=xxxx 来设置

gray_ip：缺省为no，可以通过环境变量，或者jvm参数-Dgray_ip=xxxx 来设置

服务的路由策略：

自动策略类型：（如果使用白名单，应当把相关的自动策略放在白名单的末尾）

1、A_IP_，自动策略1：某ip发起的调用，如果发现调用链上有相同ip的服务器，则选择该服务器。

2、A_DEV_，自动策略2：不满足自动策略1的基础上，优先选择dev环境稳定版本，如果发现服务的环境变量podenv为qa、sim、res，则优先选择对应的服务器

3、DEF，随机策略：任意在可用的服务中选择一个

服务器定义策略类型：

3、S_REGIP_，ip正则特征策略：某服务的apollo配置项gray_ip需要在运行时设置符合标准的ip特征，采取正则表达式方式（策略名：server_ip的缩写）

    举例说明：172段ip的地址      jvm参数-Dgray_ip=^172\.\d{1,3}\.\d{1,3}\.\d{1,3}$

4、S_REGNA_，用户名特征策略：（目前暂时不可用）某服务的apollo配置项gray_name需要在运行时设置符合标准的用户名特征，采取正则表达式方式（策略名：server_username的缩写）

    举例说明：用户名末尾为0的用户      jvm参数-Dgray_name=^*0$

5、S_TAG_，HEADER TAG策略：根据header中的tag来选择路由服务器，某服务的apollo配置项gray_tag需要在运行时设置符合标准的tag特征，采取正则表达式方式

     举例说明：某服务器的启动参数中设置了-Dgray_tag=tag1:EDU521,tag2:EDU522 ，那么凡是在请求header中拥有huohua-tag1=EDU521 或者huohua-tag2=EDU522的请求，都会命中此服务器

HEADER定义策略类型：

6、H_SVIP_，指定路由策略：完全根据header中的路由表(huohua-svips=SVNAME1:IP1,SVNAME2:IP2,)来选择服务路由（策略名：header_server-ip的缩写）

7、H_IPS_，优先服务器IP路由策略：根据header中的IP列表(huohua-ips=IP1,IP2,IP3)来优先选择服务路由（策略名：header_iplist的缩写）

策略选择：

1、多策略场景下，用户可以自主选择策略类型，方式：

在header中，策略白名单（仅白名单的策略起作用）：graywl={策略名,策略名,}

在header中，策略黑名单（仅黑名单的策略起作用）：graybl={策略名,策略名,}

2、如果用户不选择策略，则按照所有策略的顺序依次过滤

//策略排序
int SORT_H_IPS = 1;
int SORT_H_SVIP = 2;
int SORT_S_TAG = 3;
int SORT_S_IP = 4;
int SORT_S_NA = 5;
int SORT_A_IP = 6;
int SORT_A_DEV = 7;
注意：如果用户的请求头中使用了策略白名单，则严格按照白名单中的顺序应用策略，上述策略排序无效

四、启用灰度SDK
1、在pom中添加：

<!--灰度 -->
<dependency>
 <groupId>com.peppa.common</groupId>
 <artifactId>peppa-service-gray</artifactId>
 <version>1.0-SNAPSHOT</version>
</dependency>
<!--灰度 end-->
2、在application上添加注解：
scanBasePackages = {"com.peppa.xxx","com.peppa.common.handler","com.peppa.common.grayconfig"}
特别注意："com.peppa.xxx"代表你项目的主包目录，必须填写正确

3、如果有需求，可以在服务器的启动参数中加入策略参数

4、如果有需求，可以自定义header的请求头，通过chrome插件 header editor

五、header插件使用方法
header插件.zip

插件使用方法：

1、下载后解压缩到本地文件夹

2、打开Chrome浏览器→ 左上角偏好设置→ 扩展程序→ 开发者模式打开→ 加载解压缩扩展程序→ 选择解压缩后的4.07目录进入



3、点击右上角的插件图标，进入管理



4、点击导入导出→ 导入→ 选择解压缩文件夹内的strategy.json→ 然后选择保存

5、进入规则列表点击未分组后面的下拉，可以看到规则





六、应用场景DEMO
1、场景一：在开发环境里，我想调试我本地的微服务，但是请求入口是从dev或qa环境的manage开始的，我只想我的请求访问到我自己本地的服务。

    操作：无需特殊设置，仅需要启用SDK。（A_IP_，自动策略1生效）

2、场景二：在dev/qa/sim/res环境里，某个环境的服务，希望路由链路仅限制在相同环境的微服务中。

   操作：无需特殊设置，仅需要启用SDK。（A_DEV_，自动策略2生效）

3、场景三：我是一名测试，我需要测试一个功能，这个功能涉及到3个服务，目前部署在IP1,IP2,IP3这三台服务器上（H_SVIP_，指定路由策略生效）

   操作：在chrome浏览器上，打开header editor插件，启用【H_SVIP_策略，填写服务器名-ip列表】，添加header信息：

        头名称：huohua-svips

        头内容：SERVER1:IP1,SERVER2:IP2,SERVER3:IP3

4、场景四：我们是一个开发团队，我们希望我们的服务能够一起调试，能够优先互相调用（S_TAG_，HEADER TAG策略生效）

   操作：

    1、在chrome浏览器上，打开header editor插件，启用【S_TAG_策略，自定义tag规则，只要包含此tag的服务器就会选中】，添加header信息：

        头名称：huohua-tagcrm

        头内容：CRM

    2、在小组所有的开发机的IDEA上，配置启动vmoption：-Dgray_tag=tagcrm:CRM

5、场景五：线上环境，我希望测试一个新功能，需要少量的流量引入，比如需要所有172网段的ip请求都走新功能服务（S_REGIP_，ip正则特征策略生效）

    操作：在具备新功能的服务器上，jvm启动参数中加入-Dgray_ip=^172\.\d{1,3}\.\d{1,3}\.\d{1,3}$

6、场景六：我想关闭某个服务的灰度控制功能

    所有服务器操作：在apollo的application中，加入peppa.gray=false

  个别服务器操作：在指定服务器上，jvm启动参数中加入-Dpeppa.gray=false
7、场景七：我有一个请求，只想使用S_TAG_策略和S_REGIP_策略，并且要有顺序

    操作：在chrome浏览器上，打开header editor插件，启用【使用策略白名单】，添加header信息：

        头名称：huohua-graywl

        头内容：S_TAG_,S_REGIP_

8、场景八：我的微服务调用方是cronjob，我怎么能让cronjob肯定调用我本机的微服务？

解决方案：通过cronjob服务的启动参数设置-DforceHeader，强制为feignclient的请求添加header，也就是把Chrome浏览器header editor添加内容添加到启动参数中，完成调用请求的header定制。

    操作：可以通过添加cronjob的jvm启动参数-DforceHeader=x-forwarded-for:本机ip，来优先调用本机的微服务