从效率视角，如何构建轻量级应用发布平台：以微服务全链路灰度为例

应用发布平台是企业用于实现一站式应用投产发布的基础设施，可对应用发布进行统一管理、自动化执行，包括单体/微服务应用发布、分布式/容器化发布、应用全生命周期管理和蓝绿/金丝雀发布等。

下图展示了一个典型的场景：

随着分布式系统的不断推广，企业的应用数量越来越多，应用发布频率也越来越高，构建一套功能齐全、灵活的发布工具已经成为企业实现自动化的最紧急、重要的需求。根据 Gartner 预测，到 2026 年，80% 的软件企业将建立平台团队，为内部的工程师提供可复用的服务、组件以及工具来帮助应用交付。

但在企业实际 IT 环境中，建设应用发布平台往往是一套系统性工程，会给研发团队带来海量挑战：

• 接入成本高：业务线内部平台服务/工具种类繁多，技术语言、框架、运行环境等存在异构情况。因此，通过统一应用发布平台串联研发流程的成本较高，周期也较长；

• 接入灵活性差：常规的应用发布平台和工具绑定关系较为单一，研发流程编排调用工具灵活性较差。这导致在实际使用中，用户往往需要进行大量的自定义配置和代码修改，以满足特定的业务需求。这种情况不仅增加了开发的复杂性和工作量，还可能导致系统的不稳定性和兼容性问题。此外，由于应用发布平台和工具的绑定关系较为紧密，一旦用户需要更换工具或平台，就需要重新进行配置和集成，这也会增加开发的成本和风险；

• 研发使用门槛较高：业务开发人员需理解周边系统的实现、最佳实践才能很好地使用平台。例如为了实现应用的高可用，开发人员需要学习 Kubernetes 基础知识；为了实现灰度发布，开发人员又需要了解微服务治理相关的能力。

在字节跳动内部，云原生基础设施 TCE 如今支撑着超过 80% 的业务，日变更数超过 3 万，这一平台背后是研发团队长达数年的投入——从 2016 年起，随着今日头条月活跃人数超 1.3 亿，研发团队开始建设基于 Kubernetes 的应用发布平台 TCE 作为内部研发设施的主要入口。TCE 从服务角度进行抽象，打通周边设施，提供服务创建、更新、扩缩容和运维治理等功能，使用户无需感知 Kubernetes 底层即可完成应用发布（滚动/灰度）。

为了更好地服务客户，帮助客户建设更轻量级的平台以优化开发者体验并加快产品团队为客户创造价值的速度，构建更灵活的基础设施以应对某些高度复杂、定制化的需求，火山引擎云原生团队基于字节跳动内部实践，成功抽象了一套构建强大、易用应用发布平台的轻量级解决方案，即通过丰富的原子能力和便捷的流水线来构建应用发布平台，实现灵活性和易用性间的平衡：

强大的流程引擎：使用强大的流程引擎解决接入成本高和灵活性差的问题，流程引擎提供 DAG 编排、多种触发机制方便新基础设施的快捷接入。

丰富的原子服务：专为 DevOps 领域设计的原子服务开放中心，易于接入和串联。如我们基于 OAM 理念提供对接 Kubernetes 和云原生网关的原子服务，开发者无需学习 Kubernetes 、网关、微服务等知识，只需在界面上填写少量参数即可将应用以高可用的方式发布到 Kubernetes 中，并完成与微服务、网关的对接，实现全链路灰度发布的能力。

丰富的流水线模版市场：支持通过流水线模版自定义项目研发流程，统一团队研发流程和规范。对于大部分后端生产服务部署，其实都可以抽象出如下流水线部署模板：部署灰度版本 → 人工审核→ 部署生产版本→ 人工审核→ 回收灰度版本。

在业务发布变更过程中，为最大限度降低对在线用户影响，保障版本发布质量，通常采用灰度发布的方式将少量的实际生产流量导入至更新版本，达到预期结果及充分测试验证后，将流量渐进式切流至更新版本随即完成基线版本服务下线。

在字节跳动内部，抖音、电商等多个业务域也已将全链路灰度发布作为在线服务发布的标准规范，有效提升了版本发布成功率，同时也帮助业务团队提前发现变更业务异常，降低发布变更失败业务损失。

假设我们现在有一个应用，它的架构由 API 网关以及后端的微服务架构（Spring Cloud）组成，后端调用服务有 3 个：svc1 、svc2、svc3，可以通过客户端或者 HTTP 请求来访问后端服务，这些服务之间通过 Nacos 注册中心实现服务发现。

客户 HTTP 请求流量从 APIG 网关进来，然后调用到 Ingress，Ingress 调用 svc1，svc1 再调用 svc2，svc2 调用下游服务 svc3，整体调用链路为 HTTP > APIG > Ingress > svc1 > svc2 > svc3。

通过 APIG 和 MSE 微服务治理提供的，我们可以构建从网关到多个后端服务的全链路灰度，控制具有一定特征的灰度流量始终路由到应用对应的灰度环境，满足同时灰度验证多个服务的诉求。此外，在应用无目标灰度版本时，自动 fallback 到基线环境中。如下图所示：

• 创建 VKE 集群

• MSE 开启微服务治理

• APIG 创建网关实例并开启路由同步

登录持续交付 CP（Code Pipeline）控制台：https://console.volcengine.com/cp/v2/overview，点击【创建工作区】。

mse-service-nacos

对应后端服务 svc1、svc2、svc3。

1. 应用交付-应用管理-创建应用，选择 OAM 应用

2. 应用编排-添加组件，选择组件模板-预置 MSE 泳道的 Deployment 服务模板，分别添加 service1、service2、service3，调用链路为 service1→ service2→ service3。

Ingress-nacos

1. 应用交付-应用管理-创建应用，选择 OAM 应用

2. 应用编排-添加组件，选择组件模板-预置 MSE 服务和 APIGIngress 网关路由（基于请求头）模板，MSE 命名空间同上，填写 ingress 相关配置参数，环境变量指定 NextServiceName=service1，使全链路调用为 ingressService→ service1→ service2→ service3。

1. 流水线-创建流水线，选择预置模板-应用部署灰度发布。

2. 流水线流程编排，点击灰度环境发布，应用类型选择 OAM 应用，应用下拉选择 ingress-nacos，环境下拉选择 gray，制品填写应用的镜像地址，点击基准环境发布类似，环境选择 base。

3. 流水线编排，在灰度环境发布节点下新增任务节点-应用部署-灰度，部署灰度环境版本的 mse-service-nacos，然后在基准环境发布节点下新增任务节点-应用部署，部署基线环境的 mse-service-nacos。

部署灰度版本的 Ingress&应用服务：

流水线-流水线详情，点击运行流水线，先会部署灰度版本的 Ingress 和应用服务，Ingress 部署成功后会自动将路由同步到 APIG 的灰度路由信息。

部署基线版本的 Ingress&应用服务：

人工卡点审批确认后，会开始部署基线版本的 Ingress&应用服务，Ingress 部署成功后会自动将路由同步到 APIG 的基线路由信息。

1. APIG 网关路由同步完成

路由管理-服务列表-服务详情，查看自动同步到 APIG 网关的路由信息，与 Ingress 配置保持一致。

2. 测试基线版本&灰度版本流量

# 基线版本流量while true;do curl -w 'n' -H "host:mse.demo.net" 10.56.229.222:32012/getnext;sleep 1;done# 灰度版本流量while true;do curl -w 'n' -H "host:mse.demo.net" -H "h1:v1" 10.56.229.222:32012/getnext;sleep 1;done

以上就是通过火山引擎持续交付 CP 快速构建微服务全链路灰度流水线的全流程。

火山引擎持续交付 CP 始终致力于提供开发者友好的云原生应用交付平台和灵活易用的一站式流水线，帮助企业打通研发运维工程的各个环节，高质量、高效率完成业务的持续集成、持续验证和持续发布，打造极致敏捷的数字化转型底座。

欢迎感兴趣的用户扫码咨询、使用！