利用标签路由实现Dubbo灰度发布

一、背景

公司云平台提供的灰度发布功能，是通过Nginx对http服务做流量转发实现的。对于基于TCP的RPC服务，如Duboo，则并不支持。

基础服务的同事不愿意支持，那就我们研发自己搞定。考虑基于dubbo-admin二次开发支持灰度发布功能，这里可以使用标签路由或者修改权重值来实现。本次使用标签路由实现

dubbo-admin安装部署

二、标签路由

标签路由是一套严格隔离的流量体系，对于同一个应用而言，一旦打了标签则这部分地址子集就被隔离出来，只有带有对应标签的请求流量可以访问这个地址子集，这部分地址不再接收没有标签或者具有不同标签的流量。举个例子，如果我们将一个应用进行打标，打标后划分为 tag-a、tag-b、无 tag 三个地址子集，则访问这个应用的流量，要么路由到 tag-a (当请求上下文 dubbo.tag=tag-a)，要么路由到 tag-b (dubbo.tag=tag-b)，或者路由到无 tag 的地址子集 (dubbo.tag 未设置)，不会出现混调的情况。

https://blog.51cto.com/u_13222507/6127992

三、架构图

cousumer永远消费tag1的流量，provider新发布的版本指定为tag2，这时候tag2是不会被消费到的，之后手动修改配置，把tag2的机器放到tag1中，逐步完成整个替换过程。

但是这个过程，需要我们知道机器的ip，手动完成配置修改，有配置错误的风险，因此，衍生出下面的版本

1.编写数据上报SDK，用于收集应用发布的机器信息，包含ip，发布时间，批次号等，用于区分新老版本

2.各应用集成数据上报SDK，应用发布时，数据上报SDK采集到机器信息，调用dubbo-admin数据写入接口写到mysql表(数据写入接口需要在dubbo-admin自行开发)

3.用户使用持续部署平台发布应用，之后使用dubbo-admin的灰度发布功能读取到新老版本机器信息，选择机器，后台自动修改配置

4.consumer调用，有部分流量打到刚选择的机器上，功能验证完成，再用所有新版本机器替换老版本机器

四、库表设计

CREATE TABLE `dubbo_app_info` (
    `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
    `app_code` varchar(100) NOT NULL DEFAULT '' COMMENT '应用代码',
    `dubbo_port` varchar(20) NOT NULL DEFAULT '' COMMENT 'dubbo端口',
    `http_port` varchar(20) NOT NULL DEFAULT '' COMMENT 'http端口',
    `liveness_check` varchar(20) NOT NULL DEFAULT '' COMMENT '存活检查',
    `readiness_check` varchar(20) NOT NULL DEFAULT '' COMMENT '就绪检查',
    `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='应用信息表';

CREATE TABLE `dubbo_publish_info` (
    `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
    `app_code` varchar(100) NOT NULL DEFAULT '' COMMENT '应用代码',
    `publish_batch` varchar(20) NOT NULL DEFAULT '' COMMENT '发布批次号',
    `ip` varchar(20) NOT NULL DEFAULT '' COMMENT '发布机器地址',
    `publish_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '发布时间',
    `live_status` tinyint(1) unsigned NOT NULL DEFAULT '1' COMMENT '0下线|1存活',
    `batch_status` tinyint(1) unsigned NOT NULL DEFAULT '1' COMMENT '批次状态 0废弃|1使用中',
    `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='发布信息表';

上表中部分字段用于做存活检查和健康检查，当拉取新老版本机器时，主动去做一次探测，如果机器已下线则剔除掉

五、运行流程

5.1 注册应用信息

在Dubbo-admin应用管理模块注册应用信息，这块需要自行开发，用于收集健康检查，存活检查信息

5.2 provider接入数据上报SDK

5.2.1 添加依赖

<dependency>
     <groupId>com.gray.demo</groupId>
    <artifactId>startplus</artifactId>
    <version>1.1.0-SNAPSHOT</version>
</dependency>

5.2.2 启动类添加注解@EnableStartPlus

5.2.3 application.yml中添加配置

startplus:
  http:
    url: https://csp-dubbo-admin.com/dubbo/publishInfo/add

用于把发布机器信息写入mysql

5.3 consumer指定消费tag

方式一：方法级别（推荐使用）

方式二：应用级别——application.yml添加依赖

5.4 provider指定tag

第一次上线指定启动参数–dubbo.provider.tag=currTag，或者不指定去Dubbo-admin添加标签路由配置

之后每次上线启动参数添加–dubbo.provider.tag=newTag

5.5 执行灰度发布

发布应用，勾选新老版本机器，实现灰度发布(这块需自行开发)

六、功能演示

csp-tag-provider为服务提供方，csp-tag-consumer为服务调用方

/dubbo/gray接口是csp-tag-consumer循环调用100次csp-tag-provider，并把机器ip和调用次数返回

6.1 初始阶段

csp-tag-provider初始两台机器在线，csp-tag-consumer调用能收到两台机器的响应

6.2 发布新版本

csp-tag-provider开始发布两台机器，csp-tag-consumer调用此时仍然只能收到两台机器的响应

6.3 灰度切一台机器

使用dubbo灰度发布功能，切一台机器，可以看到csp-tag-consumer调用能收到3台机器的响应

6.4 灰度切最后一台

继续切最后一台，可以看到csp-tag-consumer调用能收到4台机器的响应

6.5 灰度完成

最后点击完成，会下掉原始两台机器10.18.68.12和10.18.72.154的流量，只路由到新的两台机器