Skip to content

如何对接DevOps运维平台实施流量管控

Jump to bottom
Neptune edited this page Oct 21, 2022 · 45 revisions

目录

本文档只适用于Discovery 6.16.3及以上版本的集成方式

对接DevOps运维平台架构方案

对接DevOps运维平台架构

① 控制台需要连接注册中心和配置中心

② 控制台建议实现高可用架构，控制台前面部署API网关和运维平台对接

对接DevOps运维平台方案

① 运维平台调用控制台的Open API，控制台进行链路智能编排

② 控制台把最终蓝绿灰度规则策略推送到配置中心

对接DevOps运维平台环境搭建

① 下载代码，Git clone https://github.com/Nepxion/DiscoveryGuide.git，分支为6.x.x-simple。代码很简洁，建议复制出来形成独立工程进行部署

② 运行discovery-guide-console下面的DiscoveryGuideConsole.java

③ 控制台需要实现高可用，做集群部署，可以前置API网关或者Nginx

对接DevOps运维平台最佳实践

最佳实践采用举例说明，使用者需要依据实际情况来确认版本号、业务参数名和值等

生产环境上，全链路调用路径，如下

API网关 -> 服务A -> 服务B

2021年6月1日，运维平台已经上线了服务A和服务B各1个实例，进行如下染色

① 它们的组通过流量染色步骤，都赋予为nepxion（如果整个企业只有一个网关，可以不设置组，缺省为default）

② 它们的版本号通过流量染色步骤，都赋予为20210601-0001

启动故障转移（可选）

在新版本服务上线之前，通过故障转移步骤实施，启动故障转移功能

可以通过运维平台实施故障转移的管控

启动蓝绿灰度兜底策略

在API网关上，通过蓝绿灰度发布的创建版本蓝绿灰度发布步骤，创建兜底规则策略，避免流量进入新服务实例

Yaml格式

service:
  - a
  - b

Json格式

{
  "service": ["a", "b"]
}

以Nacos和Apollo配置中心为例，举例配置方式。下同

① Nacos配置中心Group为nepxion或者default，Data Id为API网关的服务名

② Apollo配置中心Key为API网关的服务名-nepxion或者API网关的服务名-default

上线新服务

2021年7月1日，运维平台上线新的服务A和服务B各1个实例，进行如下染色，两个新服务实例都启动成功

① 它们的组通过流量染色步骤，都赋予为nepxion（如果整个企业只有一个网关，可以不设置组，缺省为default）

② 它们的版本号通过流量染色步骤，都赋予为20210701-0001

启动蓝绿灰度发布

在API网关上，通过蓝绿灰度发布的创建版本蓝绿灰度发布步骤，创建蓝绿灰度发布规则策略

通过在调用API网关的URL上增加基于Header/Parameter/Cookie的业务参数xyz

① 蓝绿发布

  • xyz为1，切换到蓝路由（旧版本链路）
  • xyz为2，切换到绿路由（新版本链路）
  • xyz缺失，切换到兜底路由（旧版本链路）

Yaml格式

service:
  - a
  - b
blueGreen:
  - expression: "#H['xyz'] == '1'"
    route: green
  - expression: "#H['xyz'] == '2'"
    route: blue

Json格式

{
  "service": ["a", "b"],
  "blueGreen": [
    {
      "expression": "#H['xyz'] == '1'",
      "route": "green"
    }, 
    {
      "expression": "#H['xyz'] == '2'",
      "route": "blue"
    }
  ]
}

② 灰度发布

  • xyz为3，稳定路由（旧版本链路）和灰度路由（新版本链路）的流量配比是90:10
  • xyz为4，稳定路由（旧版本链路）和灰度路由（新版本链路）的流量配比是70:30
  • xyz缺失，稳定路由（旧版本链路）和灰度路由（新版本链路）的流量配比是100:0，即流量不会进行新版本服务的链路

Yaml格式

service:
  - a
  - b
gray:
  - expression: "#H['xyz'] == '3'"
    weight:
      - 90
      - 10
  - expression: "#H['xyz'] == '4'"
    weight:
      - 70
      - 30
  - weight:
      - 100
      - 0

Json格式

{
  "service": ["a", "b"],
  "gray": [
    {
      "expression": "#H['xyz'] == '3'",
      "weight": [90, 10]
    },
    {
      "expression": "#H['xyz'] == '4'",
      "weight": [70, 30]
    },
    {
      "weight": [100, 0]
    }
  ]
}

蓝绿灰度执行结果处理

  • 蓝绿灰度发布成功，新版本实例测试通过，流量全部切到新版本实例，下线老版本服务实例
  • 蓝绿灰度发布失败，新版本实例测试失败，流量全部切到旧版本实例，下线新版本服务实例，待问题解决后重新上线新服务

启动无损下线（可选）

在旧版本服务实例下线之前，在API网关上，执行无损下线的添加下线的服务实例到黑名单步骤，保证流量不会进入要下线的老版本实例

下线旧服务

运维平台停止旧版本的服务实例

停止无损下线（可选）

等待一段时间后，待旧服务实例彻底下线，在API网关上，执行无损下线的从黑名单清除所有过期的服务实例步骤

停止蓝绿灰度发布

在API网关上，通过蓝绿灰度发布的清除蓝绿灰度发布步骤，清除蓝绿灰度发布规则策略

整个流程过程，示意如下，故障转移和无损下线步骤可以省略

对接DevOps运维平台步骤详解

流量染色

运维平台通过命令行java -jar启动应用，加入启动参数-Dmetadata.group=xxx和-Dmetadata.version=yyy，表示给服务实例进行组维度和版本维度的流量染色，即

java -jar -Dmetadata.group=xxx -Dmetadata.version=yyy abc.jar

基于时间戳格式的全局唯一版本号流量染色，有如下两种最佳实践，使用者根据企业现状，选择一种

① Git插件创建版本号（把版本号创建权力下放给基础架构）

服务通过集成插件git-commit-id-plugin产生git信息文件的方式，获取git.commit.time（最后一次代码提交日期）加{git.total.commit.count}（总提交次数）来自动创建版本号，例如，20210601-567。运维平台不再需要加入启动参数-Dmetadata.version=yyy

  • 增加Git编译插件
<plugin>
    <groupId>pl.project13.maven</groupId>
    <artifactId>git-commit-id-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>revision</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <!-- 必须配置，并指定为true -->
        <generateGitPropertiesFile>true</generateGitPropertiesFile>
        <!-- 指定日期格式 -->
        <dateFormat>yyyyMMdd</dateFormat>
        <!-- <dateFormat>yyyy-MM-dd-HH:mm:ss</dateFormat> -->
    </configuration>
</plugin>
  • 开启Git插件产生版本号的开关
# 开启和关闭使用Git信息中的字段单个或者多个组合来作为服务版本号。缺失则默认为false
spring.application.git.generator.enabled=true

② 运维平台创建版本号（把版本号创建权力下放给运维平台）

运维平台决定版本号可以采用日期戳-序号的格式

  • 日期戳表示当天的日期
  • 序号表示当天的发布次数，一般定义为四位，即从0001-9999。序号由运维平台来维护，当天每发布一个版本，序号自加1

这种表示方式具有很强的可读性意义，例如，20210601-0003，表示某一组服务实例蓝绿灰度的版本为2021年6月1日发布的第三个版本

故障转移

在网关和服务上开启如下开关

# 启动和关闭版本故障转移。缺失则默认为false
spring.application.strategy.version.failover.enabled=true

运维平台对接控制台，在网关上实施故障转移

① 创建故障转移

网关和服务上有默认故障转移方式，如果通过运维平台来实施管控，则默认故障转移方式失效

② 清除故障转移

运维平台取消实施故障转移方式的管控

具体用法，请参考

蓝绿灰度发布

运维平台对接控制台，通过链路在后台智能编排的方式，在网关上实施蓝绿灰度发布

① 创建版本蓝绿灰度发布

运维平台通过创建兜底、蓝绿、灰度、混合蓝绿灰度等四种方式实施流量管控

② 清除蓝绿灰度发布

运维平台完成蓝绿灰度发布

③ 校验版本蓝绿灰度发布

运维平台预验证蓝绿灰度对象是否合法，链路智能编排结果是否正确

④ 校验条件表达式

运维平台预验证条件表达式是否正确

⑤ 获取蓝绿灰度发布

运维平台调用配置接口的获取规则配置对象步骤，获取其中的蓝绿灰度发布规则策略

具体用法，请参考

无损下线

运维平台对接控制台，在服务实例下线之前，在网关上实施服务实例的黑名单屏蔽，在服务实例下线一段时间后，再解除黑名单屏蔽

① 添加下线的服务实例到黑名单

运维平台下线服务实例之前，通过IP地址和端口添加入黑名单（转化成UUId存储）进行单个屏蔽，返回全局唯一的该服务实例的UUId，即可实现实时无损下线

② 通配添加下线的服务实例到黑名单

运维平台下线服务实例之前，通过UUId前缀的日期或者时间（标识服务实例上线的时间戳）以通配符方式加入黑名单进行批量屏蔽，即可实现实时无损下线

例如：

  • A服务有两个实例，实例1的UUId为20220920-113301-033-4289-533-056，实例2的UUId为20220920-113259-190-5762-550-884，代表它们同一天2022年09月20日上线
  • 通过20220920*通配符的方式，表示屏蔽2022年09月20日上线的A服务的所有实例，如果希望更精确，20220920-11*，表示屏蔽2022年09月20日11点上线的A服务的所有实例

③ 从黑名单清除所有过期的服务实例

运维平台下线服务实例一段时间之后（大于负载均衡3个时钟周期，推荐5分钟），从黑名单清除所有过期的服务实例

注意事项

UUId全局唯一，同样的服务实例重启注册后，UUId会重新产生，不会重复。添加过多的UUId，虽然不会影响功能，但UUId堆积过多，使规则配置文本变得臃肿，可能会影响配置订阅的响应效率

④ 获取下线的服务实例的黑名单

运维平台调用配置接口的获取规则配置对象步骤，获取其中的黑名单规则策略

具体用法，请参考

对接DevOps运维平台半自动化发布

① 第一次蓝绿灰度发布

通过创建版本蓝绿灰度发布，手工输入条件表达式，后端链路智能编排。Open API支持Yaml和Json格式两种，任选一个

http://localhost:6001/strategy/create-version-release-yaml/{group}/{serviceId}
http://localhost:6001/strategy/create-version-release-json/{group}/{serviceId}

接口传输内容示例

service:
  - service-a
  - service-b
blueGreen:
  - expression: "#H['xyz'] == '1'"
     route: green
  - expression: "#H['xyz'] == '2'"
     route: blue

② 第二次以及未来N次蓝绿灰度发布

通过重新创建版本蓝绿灰度发布，把需要重新执行蓝绿灰度发布的服务列表加入，重用上次的保留条件表达式，进行蓝绿灰度发布。Open API支持Yaml和Json格式两种，任选一个

http://localhost:6001/strategy/recreate-version-release-yaml/{group}/{serviceId}
http://localhost:6001/strategy/recreate-version-release-json/{group}/{serviceId}

接口传输内容示例

service:
  - service-a
  - service-b
condition: true

③ 停止蓝绿灰度发布

通过重置蓝绿灰度发布，保留条件表达式，清除链路路由，以便下一次蓝绿灰度发布不再输入条件表达式。Open API如下

http://localhost:6001/strategy/reset-release/{group}/{serviceId}

④ 定时更新灰度发布

DevOps运维平台每隔一段时间，调整灰度权重比例（减少旧版本流量，增加新版本流量），平稳达到流量从旧版本到新版本的迁移

⑤ 半自动化蓝绿灰度发布模拟流程测试

框架通过自动化测试方式提供一个半自动化蓝绿灰度发布的模拟流程，请参考半自动化蓝绿灰度发布模拟器指南示例，分支为6.x.x-simulator

采用全链路智能编排 + 流量侦测相结合的做法，支持网关和服务为侦测入口两种方式，用于测试环境或者开发环境通过自动化测试手段验证全链路蓝绿灰度方式的准确性

注意事项

禁止在生产环境使用

application.properties配置文件

  • “spring.application.test.console.url”替换成部署在测试环境控制台的地址
  • “testcase.group”和“testcase.service”替换成相应的订阅的组名和服务名
  • 网关侦测入口或者服务侦测入口任选一种，把“testcase.inspect.url”替换成相应的网关地址或者服务地址。当选择网关作为侦测入口时候，“testcase.inspect.context.service”替换成网关后第一跳的服务名，当选择服务作为侦测入口时候，“testcase.inspect.context.service”不能配置
  • 其它参数可以按照默认的来设置，不需要改动
# 自动化测试框架内置配置
# 测试用例类的扫描路径
spring.application.test.scan.packages=com.nepxion.discovery.simulator
# 测试用例的配置内容推送后，等待生效的时间。推送远程配置中心后，再通知各服务更新自身的配置缓存，需要一定的时间，缺失则默认为3000
spring.application.test.config.operation.await.time=5000
# 测试用例的配置内容推送的控制台地址。控制台是连接服务注册发现中心、远程配置中心和服务的纽带
spring.application.test.console.url=http://localhost:6001/

# 业务测试配置
# 订阅的组名
testcase.group=discovery-guide-group
# 订阅的服务名
testcase.service=discovery-guide-gateway
# testcase.service=discovery-guide-service-a

# 网关侦测入口地址
testcase.inspect.url=http://localhost:5001/discovery-guide-service-a/inspector/inspect
# 网关侦测入口转发服务
testcase.inspect.context.service=discovery-guide-service-a

# 服务侦测入口地址
# testcase.inspect.url=http://localhost:3001/inspector/inspect

# 每个测试用例执行循环次数
testcase.loop.times=1

# 测试用例的灰度权重采样总数。采样总数越大，灰度权重准确率越高，但耗费时间越长
testcase.bluegreen.sample.count=100

# 测试用例的灰度权重采样总数。采样总数越大，灰度权重准确率越高，但耗费时间越长
testcase.gray.sample.count=500
# 测试用例的灰度权重准确率偏离值。采样总数越大，灰度权重准确率偏离值越小
testcase.gray.weight.offset=5

规则策略文件

在如下四个文件

  • discovery-first-version-basic-release.yaml
  • discovery-first-version-bluegreen-gray-release.yaml
  • discovery-second-version-basic-release.yaml
  • discovery-second-version-bluegreen-gray-release.yaml

如下服务列表替换成测试环境要模拟蓝绿灰度发布的服务列表

service:
  - discovery-guide-service-a
  - discovery-guide-service-b

模拟流程部分结果

【模拟场景3】蓝绿策略，测试全链路调用，Header xyz缺失...
抽样次数 : 100
调用结果 : [email protected]命中次数=0
调用结果 : [email protected]命中次数=100
调用结果 : [email protected]命中次数=0
调用结果 : [email protected]命中次数=100
测试结果 : 通过
【模拟场景3】蓝绿策略，测试全链路调用，Header xyz等于1...
抽样次数 : 100
调用结果 : [email protected]命中次数=0
调用结果 : [email protected]命中次数=100
调用结果 : [email protected]命中次数=0
调用结果 : [email protected]命中次数=100
测试结果 : 通过
【模拟场景3】蓝绿策略，测试全链路调用，Header xyz等于2...
抽样次数 : 100
调用结果 : [email protected]命中次数=100
调用结果 : [email protected]命中次数=0
调用结果 : [email protected]命中次数=100
调用结果 : [email protected]命中次数=0
测试结果 : 通过
【模拟场景3】灰度策略，测试全链路调用，Header xyz缺失...
抽样次数 : 500
抽样进度 : 第100次...
抽样进度 : 第200次...
抽样进度 : 第300次...
抽样进度 : 第400次...
抽样进度 : 第500次...
调用结果 : [email protected]命中次数=0
调用结果 : [email protected]命中次数=500
调用结果 : [email protected]命中次数=0
调用结果 : [email protected]命中次数=500
权重结果偏差值=5%
期望结果 : 旧版本路由权重=100%, 新版本路由权重=0%
最终结果 : 旧版本路由权重=100.0%, 新版本路由权重=0.0%
测试结果 : 通过
【模拟场景3】灰度策略，测试全链路调用，Header xyz等于3...
抽样次数 : 500
抽样进度 : 第100次...
抽样进度 : 第200次...
抽样进度 : 第300次...
抽样进度 : 第400次...
抽样进度 : 第500次...
调用结果 : [email protected]命中次数=52
调用结果 : [email protected]命中次数=448
调用结果 : [email protected]命中次数=52
调用结果 : [email protected]命中次数=448
权重结果偏差值=5%
期望结果 : 旧版本路由权重=90%, 新版本路由权重=10%
最终结果 : 旧版本路由权重=89.6%, 新版本路由权重=10.4%
测试结果 : 通过
【模拟场景3】灰度策略，测试全链路调用，Header xyz等于4...
抽样次数 : 500
抽样进度 : 第100次...
抽样进度 : 第200次...
抽样进度 : 第300次...
抽样进度 : 第400次...
抽样进度 : 第500次...
调用结果 : [email protected]命中次数=147
调用结果 : [email protected]命中次数=353
调用结果 : [email protected]命中次数=147
调用结果 : [email protected]命中次数=353
权重结果偏差值=5%
期望结果 : 旧版本路由权重=70%, 新版本路由权重=30%
最终结果 : 旧版本路由权重=70.6%, 新版本路由权重=29.4%
测试结果 : 通过
【模拟场景3】* 测试通过...

上面提到的步骤，请参考

对接DevOps运维平台公共接口




2017-2050 ©Nepxion Studio Apache License

           

Total visits

讲义篇

集成篇

概念篇

实践篇

功能篇

配置篇

扩展篇

测试篇

升级篇

贡献篇

Clone this wiki locally