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

一、背景

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

如果基本服务的同事不愿意支持，我们应该自己开发。考虑到基于dubo-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收集到机器信息，调用dubo-admin数据写入接口到mysql表（数据写入接口需要在dubo-admin中开发）

3.用户使用连续部署平台发布应用程序，然后使用dubo-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 "dubo端口"，    `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=“发布信息表”;

上表中的一些字段用于生存检查和健康检查。当拉出新旧版本的机器时，主动进行检测。如果机器已经离线，请删除它

在Dubo-admin应用管理模块注册应用信息，需要自行开发，收集健康检查和生存检查信息

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

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

将发布机的信息写入mysqll中

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

方法二:应用级别——application.添加依赖性的yml

dubbo：

consumer：

tag: currTag

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

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

发布应用程序，检查新旧版本的机器，实现灰度发布（本文需要自行开发）

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

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

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

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

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

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

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