3. 平台门户架构概览：开发者门户、运维门户、API网关与Mesh的集成点

在构建回滚护栏之前，必须先理解平台门户的整体架构。平台门户并非单一系统，而是由开发者门户、运维门户、API网关与Service Mesh控制面四个核心子系统组成的有机整体。每个子系统承担不同的职责，并通过明确的集成点协同工作，为回滚护栏提供数据、策略和执行能力。

3.1 四层架构总览

平台门户采用分层架构设计，从上至下依次为：用户交互层、策略编排层、流量接入层和数据平面层。每一层都对应特定的门户或组件，并通过标准化的API进行通信。

3.2 开发者门户：回滚的发起端

开发者门户是开发人员与平台交互的唯一入口。在回滚场景中，开发者门户承担以下职责：

• 版本发布申请： 开发者提交新版本部署请求，附带版本号、变更描述、回滚策略（如自动回滚阈值）。
• 回滚审批与执行： 当监控指标异常时，开发者可通过门户一键发起回滚申请，或由系统自动触发回滚流程。
• 金丝雀配置： 定义灰度发布的流量比例、版本权重，这些配置最终转化为Service Mesh的路由规则。
• 回滚历史查询： 查看每次回滚的原因、影响范围、执行时长，为后续决策提供数据支持。

3.3 运维门户：回滚策略的管控中心

运维门户是SRE和平台工程师的核心工作台，负责定义和管理回滚护栏的全局策略。它与开发者门户的“声明式”不同，更侧重于“管控式”。

3.4 API网关：回滚策略的流量入口执行者

API网关位于流量入口，是回滚策略的第一道执行关卡。它主要负责：

• 路由规则注入： 根据运维门户下发的策略，动态调整路由规则，将特定流量导向稳定版本或金丝雀版本。
• Header标记： 在请求中注入回滚相关的Header（如 x-rollback-version: v1.2.3），供下游服务识别。
• 限流与降级： 在回滚期间，对异常版本的服务进行限流，防止故障扩散。
• 灰度分流： 根据用户ID、地域等标签，将流量按比例分发到不同版本。

# API网关路由规则示例（Kong Gateway）
{
  "name": "rollback-canary-route",
  "methods": ["GET", "POST"],
  "hosts": ["api.example.com"],
  "paths": ["/v1/orders"],
  "service": {
    "name": "order-service-v2.0.0",
    "weight": 10
  },
  "plugins": [
    {
      "name": "header-injection",
      "config": {
        "headers": {"x-rollback-version": "v2.0.0"}
      }
    }
  ]
}

3.5 Service Mesh：回滚执行的最后一公里

Service Mesh（以Istio为例）是回滚策略在数据平面的最终执行者。它通过控制面（Istiod）将运维门户下发的策略转化为Envoy的xDS配置，实现精细化的流量管理。

3.6 集成点总结

四个子系统通过明确的API和协议进行集成，形成回滚护栏的完整链路：