说明策略如何由配置发布链路提供，并分别指导入口地域与认证后后端的选择。
7. 路由与多地域设计
7.1 路由模型
每条路由配置至少包含以下信息：
- 唯一路由标识。
- 平台和服务标识。
- 运行环境。
- 允许的 HTTP 方法和规范化路径规则。
- required scope。
- 读取或写入类型。
- 超时、重试、请求体上限和限流策略。
- 首选地域、允许的故障转移地域、后端服务标识和服务能力声明。
- 配置版本、生效时间和回滚版本。
路由发布前必须通过静态校验：路由无冲突、required scope 存在、目标服务已注册、写请求明确声明幂等策略、超时有上限。
7.1.1 流量路由策略中心决策逻辑
流量路由策略中心维护一份版本化策略，但在两个位置执行。第一执行点位于全局入口，只负责选择入口地域；第二执行点位于地域网关，在 API Key 验证和路由匹配完成后选择后端。入口阶段使用的商户或平台提示未经认证，只能缩小入口候选集，不能授予权限；进入地域后必须以已验证身份复核，不一致时重新选择合格后端或拒绝请求。
会议只确认了多地域冗余和路由能力，没有确定具体算法。固定首选与主备模式是当前设计基线；权重或就近多活属于建议选项，默认关闭，只能在商户显式允许的地域集合内用于无状态读取。执行点 1 在认证前无法可靠判断请求类型；如果写请求被送到非 writer 地域，执行点 2 仍必须选择当前 writer 或返回 503，不得产生跨地域盲写。全局流量产品、TLS 终止点和认证前路由提示机制尚未确定，因此入口失败行为与可用输入需要在选型后确认。图中的 reason_code 只写入内部决策日志与审计，不对外披露；对外错误遵循第 6.2 节。
7.2 商户地域归属
为每个商户维护显式的首选地域和可用地域列表。流量路由策略中心把策略发布到两个执行点：全局入口优先把商户请求送到首选地域，地域内网关在认证后根据商户路由分区、服务能力和请求类型选择后端。
商户地域归属不能只依赖 DNS 解析地理位置，因为商户出口、专线接入点和业务数据所在地可能不同。地域策略必须由控制面配置并审计。
7.3 区域故障转移
- 网关数据面按多可用区部署，单实例或单可用区故障由区域负载均衡自动摘除。
- 流量路由策略中心的入口执行点确认地域不可用后，只把允许故障转移的商户切换到已配置且合格的备用地域。
- 每个平台接入时必须声明读取一致性等级、最大允许复制延迟、复制状态信号的采集方式和信号最大有效期。读取请求只有在备用地域上报的复制延迟不超过该路由的最大允许值，且状态信号未过期时才允许自动故障转移。
- 支付写请求只有在后端平台提供全局幂等键、唯一约束和明确的写入主地域切换机制时才能跨地域重试。
- 后端未满足跨地域写入前提时，网关返回可追踪的
503，禁止同时向两个地域写入。 - 区域恢复后采用受控回切，先验证授权配置版本和后端复制状态，再逐步恢复流量。
7.4 后端多数据库边界
会议提到 Zero Confirmation 可能使用三个数据库，BPS 未来也可能采用相似模式。网关只保存“商户或分区应路由到哪个后端服务”的元数据，不直接持有业务分库连接，也不拆分业务 SQL。
每个平台必须自行保证：
- 分区映射和业务数据库拓扑的一致性。
- 交易写入的唯一约束和幂等语义。
- 跨地域复制、恢复点和恢复时间。
- 数据库切换完成后向网关发布新的可用服务端点或路由版本。
7.5 控制面容灾
统一控制面采用跨地域主动与备用模式，任何时刻只允许一个控制面地域写入：
- PostgreSQL 在主地域内同步复制，在备用地域异步复制 WAL；备用地域复制延迟目标不超过 60 秒。
- 控制面版本使用
(epoch, sequence)二段版本并按字典序比较。正常提交只递增sequence，主地域切换时先递增epoch再从新的sequence开始，禁止两个地域产生可比较但分叉的版本。 - 主地域提升或备用地域接管前，必须通过托管数据库围栏或共识租约确认旧主节点已失去写权限；无法完成围栏时禁止接管。
- 控制面实例只有持有有效单写租约时才能接受管理写入，租约过期立即失败关闭。
- 备用地域 WAL 应用延迟超过 60 秒时停止接受普通配置写入并告警；紧急只拒绝操作改走第 10.3 节的 break-glass 通道。
- 接管后先恢复未发布 Outbox 事件，再以新
epoch发布完整配置快照；各地域拒绝旧epoch的任何事件。 - 控制面建议恢复时间目标为 30 分钟，配置恢复点目标为 1 分钟；这两个目标必须通过季度恢复演练验证。
控制面故障不应中断已加载配置的数据面请求，但会暂停普通 Key 创建、轮换、Scope 变更、IP 变更和路由发布。