从整体责任边界出发，说明请求如何安全进入一个合格地域，以及各类组件各自负责什么。
4. 总体架构
下图只表达逻辑责任边界和边界之间交付的内容，不展开组件、缓存或部署拓扑。六个中性节点可以由多个组件共同实现，也可以分散部署；名称中的“中心”表示统一规则与责任归属，不表示请求必须同步调用一个集中式服务。
逻辑边界总览
%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 34, "rankSpacing": 44, "htmlLabels": true}}}%%
flowchart TB
subgraph CONTROL["策略与配置"]
direction LR
CONFIG["配置发布与运营中心<br/>管理变更 · 版本发布 · 紧急只拒绝"] -->|"路由策略快照"| ROUTING["流量路由策略中心<br/>一份策略 · 两个执行点"]
end
subgraph REQUEST["商户请求路径"]
direction LR
MERCHANT["商户系统"] --> INGRESS["统一接入层<br/>入口选择 · 边缘防护 · 可信来源"]
INGRESS --> ACCESS["访问控制中心<br/>身份验证 · Key-IP · Scope"]
ACCESS --> GOVERN["请求治理与执行层<br/>流量策略 · 安全门禁 · 后端调用"]
GOVERN --> PLATFORM["支付平台服务<br/>WebPay Inbox · BPS · Zero Confirmation"]
end
ROUTING -.->|"入口地域策略"| INGRESS
ROUTING -.->|"后端候选与故障转移门禁"| GOVERN
CONFIG -->|"Key · IP · Scope 快照"| ACCESS
CONFIG -->|"路由治理快照"| GOVERN
GOVERN -.->|"数据面运行与决策事件"| OBSERVE["可观测性与审计中心<br/>关联查询 · 告警 · SLO · 合规证据"]
CONFIG -.->|"变更事件与事务内审计"| OBSERVE
classDef external fill:#F7F9FC,stroke:#8A9AAF,color:#18212F,stroke-width:1.5px
classDef entry fill:#EAF2FF,stroke:#1264D6,color:#12345B,stroke-width:2px
classDef runtime fill:#FFFFFF,stroke:#4F79A7,color:#18212F,stroke-width:1.5px
classDef policy fill:#EDF8F3,stroke:#16835E,color:#124D3B,stroke-width:1.5px
classDef control fill:#F2F0FF,stroke:#6657C7,color:#292057,stroke-width:1.5px
class MERCHANT,PLATFORM external
class INGRESS entry
class ACCESS,GOVERN runtime
class ROUTING,OBSERVE policy
class CONFIG control
style CONTROL fill:#FAF9FF,stroke:#C9C0F1,stroke-width:2px
style REQUEST fill:#F8FBFF,stroke:#B8CDEA,stroke-width:2px
总览中的实线是请求或版本化快照的交付关系，虚线是策略影响或事件汇聚关系。流量路由策略中心不是请求热路径上的集中式同步服务：入口执行点选择入口地域，认证后的治理执行点选择后端并应用故障转移门禁。可观测性与审计中心不替代控制面的事务内审计写入，只负责安全汇聚、关联查询、告警与证据输出。总览不单列缓存；本地域快照是访问控制和请求治理的内部实现，来源始终是配置发布链路。
| 抽象节点 | 单一职责 | 展开位置 |
|---|---|---|
| 统一接入层 | 把外部连接安全地送入一个合格地域，并产生可信来源上下文 | 第 4.1 节 |
| 流量路由策略中心 | 用一份版本化策略约束入口地域和认证后后端选择 | 第 7.1.1 节 |
| 访问控制中心 | 完成身份、Key-IP 与路由 Scope 判定，输出稳定的允许或拒绝语义 | 第 5.6 节 |
| 请求治理与执行层 | 对已授权请求应用流量、安全与调用策略，并调用一个明确后端 | 第 6.1 节 |
| 配置发布与运营中心 | 校验管理变更、单写持久化、发布快照并提供独立紧急拒绝通道 | 第 10.1 节 |
| 可观测性与审计中心 | 汇聚脱敏事件，形成关联查询、告警、SLO 和合规证据 | 第 12.1 节 |
4.1 统一接入层
统一接入层包含全局流量产品、边缘防护、TLS 终止点或透传路径、地域入口和负载均衡。它只建立可信连接与来源上下文，不认证 API Key，也不授予平台权限。认证前的商户或平台提示只能缩小入口候选集。
%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 34, "rankSpacing": 38, "htmlLabels": true}}}%%
flowchart TB
MERCHANT["商户 TLS 请求"] --> EDGE["全局边缘保护<br/>L3/L4 DDoS · 连接与速率边界"]
HINT["未认证路由提示<br/>只缩小候选集 · 不授予权限"] --> SELECT["执行点 1 · 入口地域选择<br/>allowed_regions · 合规 · 地域健康"]
POLICY["路由策略中心<br/>入口地域策略版本"] -.-> SELECT
EDGE --> SELECT
SELECT -->|"存在合格地域"| REGION["地域入口"]
SELECT -->|"无合格地域"| FAIL["停止解析或返回 503<br/>由全局流量产品能力决定"]
subgraph REGIONAL["合格地域内的接入处理"]
direction LR
REGION --> TLS["TLS 终止或透传<br/>mTLS 在实际终止点完成握手"]
TLS --> WAF["L7 WAF 与协议边界<br/>方法 · Header · 路径 · 报文大小"]
WAF --> SOURCE["可信来源 IP<br/>覆盖外部转发头 · 校验受信代理链"]
SOURCE --> BALANCE["地域内负载均衡<br/>仅选择健康网关实例"]
BALANCE --> OUTPUT["输出<br/>规范请求 + 可信来源 IP<br/>mTLS 证书上下文"]
end
classDef external fill:#F7F9FC,stroke:#8A9AAF,color:#18212F,stroke-width:1.5px
classDef input fill:#F4F7FB,stroke:#72849A,color:#253954,stroke-width:1.5px
classDef entry fill:#EAF2FF,stroke:#1264D6,color:#12345B,stroke-width:1.5px
classDef reject fill:#FFF2EC,stroke:#C7582B,color:#6B2812,stroke-width:1.5px
class MERCHANT external
class HINT,POLICY input
class EDGE,SELECT,REGION,TLS,WAF,SOURCE,BALANCE,OUTPUT entry
class FAIL reject
style REGIONAL fill:#F8FBFF,stroke:#B8CDEA,stroke-width:2px
输出中的 mTLS 证书上下文只是握手结果，证书与 API Key 的显式绑定要在身份认证成功后校验。外部 TLS 在 WAF 终止还是透传到网关仍是待选型事项，但无论终止位置在哪里，都必须执行凭据脱敏、证书保护和可信代理链校验。
4.2 数据面组件
- 流量路由策略中心（逻辑能力）：统一定义入口地域和地域内后端路由策略，通过版本化快照发布到两个执行点本地评估，不引入跨地域同步数据库依赖。
- 全局入口、WAF 与负载均衡：入口执行点根据已发布策略和地域健康选择入口地域；WAF 与负载均衡承担 DDoS 防护、TLS 终止或透传、基础协议校验和地域内实例分发。
- API Gateway：完成请求规范化、认证调用、权限执行、限流、路由、超时、熔断、请求标识和响应规范化。
- API Key 验证服务（每个地域部署）：验证 Secret 摘要、Key 状态、入口环境和 Key-IP 绑定，向网关返回已验证身份与 Scope 集合；它不决定商户能否访问某条路由。
- 本地域配置快照与限流缓存：保存已签名或带版本号的 Key、IP、Scope、吊销和路由快照，以及分布式限流状态。支付写入 Nonce 使用独立安全缓存，只在已允许写入故障转移的地域间同步。
- 服务路由层：作为认证后的第二执行点，维护地域内后端端点、健康状态、重试边界，并执行策略中心发布的跨地域故障转移门禁。
4.3 控制面组件
- Gateway Admin API：提供机器可调用的 Key 生命周期、Scope、IP 绑定和路由管理接口。
- 内部身份与审批：管理员必须通过公司身份系统登录；高风险操作采用双人审批。
- 统一控制面：验证配置不变量，持有单写租约，写入 PostgreSQL，并通过事务 Outbox 发布版本化变更事件。
- PostgreSQL：作为商户、Key、权限、绑定和路由配置的唯一事实源，采用跨地域主动与备用复制和写入围栏。
- 备用控制面：正常情况下不接受写入，只有旧主完成围栏并取得新 epoch 后才能接管。
- 消息总线：把变更推送到各地域，支持重放、消费位点和幂等消费。
- break-glass 只拒绝入口：控制面不可用时向各地域的 API Key 验证服务追加紧急拒绝项，永远不能扩大权限。
- 审计存储：记录谁在何时因何原因进行了何种变更，以及变更前后的非敏感差异。
4.4 推荐技术基线
在缺少既有技术栈约束的情况下，建议先采用以下基线进行原型验证：
- 数据面代理：Envoy Gateway 或等价的成熟 L7 代理。
- API Key 验证：独立的外部验证服务处理凭据摘要、Key 状态、环境与 Key-IP 绑定；网关策略执行路由可见性和 required scope，避免把验证逻辑硬编码在代理配置中。
- 配置主库：PostgreSQL。
- 本地域配置快照与限流：Redis 兼容集群。
- 配置分发：Kafka 兼容消息总线与 PostgreSQL 事务 Outbox。
- 部署平台：Kubernetes，多可用区部署并使用 Pod 反亲和规则。
- 密钥保护：云 KMS 或等价硬件保护的密钥管理服务。
该技术基线需要在平台团队提供现有基础设施清单后做一次选型确认。逻辑架构不依赖特定厂商产品。