3. 分层架构介绍：基础设施层、平台层、应用层

说实话，分层架构这个事儿，很多团队都在画，但真正能把灰度回滚做利索的，不多。为什么？说白了就是每层该管什么、回滚时该看什么，没理清楚。

我个人习惯把灰度回滚的支撑架构拆成三层：基础设施层、平台层和应用层。每层的职责不同，灰度回滚的关注点也各有侧重。你想想看，网络策略的问题能靠应用层代码解决吗？配置中心挂了能靠重启业务实例恢复吗？都不行。所以分层的核心目的就一个：隔离风险，精准回滚。

下面这张图是我自己总结的分层架构全景，你一眼就能看明白各层的位置和它们灰度回滚的关键点。

3.1 基础设施层：灰度回滚的"地基"

这一层说白了就是所有服务的"家"——物理机、虚拟机、网络、存储、负载均衡、DNS 这些。它们不直接跑业务代码，但哪一块出问题，上面两层全得跟着遭殃。

我在项目中遇到过这样一个案例：某次灰度发布后需要回滚，结果网络策略没做好隔离，回滚流量把还在线上的旧版本实例冲垮了。原因是什么？基础设施层没有做资源隔离，新老版本的网络段混在了一起。

所以基础设施层灰度回滚要盯死三个点：

• 资源隔离—— 新老版本的资源池必须物理或逻辑隔离，回滚时互不干扰。
• 网络策略—— 防火墙规则、路由表、VIP 调度策略要支持秒级切换。
• 容量规划—— 回滚后流量瞬间涌入旧集群，扛得住吗？提前做好压测和 buffer。

3.2 平台层：灰度回滚的"枢纽"

平台层是连接基础和应用的关键地带。K8s 集群、Istio 服务网格、Apollo 配置中心、Prometheus 监控……这些组件共同构成了灰度发布的"控制面板"。回滚时，它们既是执行者，也是风险点。

我个人最关注的是配置回滚。你想想看，灰度发布时往往要调整很多运行时配置——流量比例、超时时间、熔断阈值等等。一旦需要回滚，配置的版本管理就至关重要。

平台层灰度回滚的三个核心关注点：

• 配置回滚 —— 配置中心必须支持按版本一键回退，而且回退后要能自动通知到所有订阅实例。
• 规则回退 —— 服务网格中的路由规则、重试规则、熔断规则要能原子化回滚，不能出现"回滚了一半"的状态。
• 流量调度 —— 灰度标签、权重分配、header 路由规则，回滚时要把流量从新版本集群平滑地切回旧版本集群。

3.3 应用层：灰度回滚的"前线"

应用层是直接面向业务的地方，也是灰度回滚最"敏感"的一层。微服务实例、API 网关、业务模块都在这里。这一层的回滚，影响最直接、用户感知最强烈。

我记得有一次做电商大促的灰度发布，新版本的价格计算模块有 bug，需要紧急回滚。结果回滚后数据库的 schema 不兼容，导致旧版本启动直接报错。这个教训太深刻了——数据兼容性是应用层回滚的命门。

应用层灰度回滚的核心关注点：

• 版本回退 —— 代码和依赖包要能快速切回上一版本，包括 jar 包、npm 包、镜像 tag 等。
• 数据兼容 —— 数据库字段变更、缓存结构变更、消息队列 schema 变更，必须保证前后兼容。
• 业务一致性 —— 回滚后业务状态不能"飘"，比如订单状态、用户积分等要保证最终一致。

3.4 三层协作：回滚不是单打独斗

好了，三层都介绍完了。但实际回滚的时候，它们不是各自为战的。我总结了一个协作原则：从底向上，逐层确认。

什么意思？就是回滚时先确认基础设施层是否稳定（网络通、资源够），再确认平台层是否就绪（配置对、规则准），最后才操作应用层回滚。反过来也一样，发布时从底向上建，回滚时从底向上查。

下面这个表格把三层的职责和回滚策略做了个对比，方便你快速对照：