Skip to content

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

Jump to bottom
Neptune edited this page Aug 26, 2024 · 45 revisions

目录

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

对接DevOps运维平台架构方案

对接DevOps运维平台架构

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

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

对接DevOps运维平台方案

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

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

对接DevOps运维平台环境搭建

① 控制台执行过程，有两种方式

② 控制台需要实现高可用，做集群部署，可以前置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}（日期 + Git提交次数）或者{git.build.version}（对应到Maven工程的版本）来自动创建版本号。运维平台不再需要加入启动参数-Dmetadata.version

  • 增加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

有两种格式

# 日期 + Git提交次数的版本号格式
spring.application.git.version.key={git.commit.time}-{git.total.commit.count}
# POM版本号格式
# spring.application.git.version.key={git.build.version}

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

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

  • 日期戳表示当天的日期
  • 序号表示当天的发布次数，一般定义为四位，即从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运维平台公共接口




2017-2050 ©Nepxion Studio Apache License

           

Total visits

讲义篇

集成篇

概念篇

实践篇

功能篇

配置篇

扩展篇

测试篇

升级篇

贡献篇

Clone this wiki locally