海外版外卖平台多城并行时，云上最怕一次发布打到所有城：第二城改半径，首城骑手范围跟着变；或回滚时两城一起回。隔离发布不是「多买几台机器」，而是配置、发布、观察按城切开。
本文从云原生部署视角谈多城配置怎么隔离。支付与税务各国不同，支持按需定制对接，且应与运力发布解耦。
一、隔离单元：按城分配置命名空间
建议以 city_id 为边界：
- 运力参数、开放开关、回调相关配置分城存放
- 密钥与支付通道参数也可分城（具体国家通道按需定制对接）
- 默认配置只作模板，落城时复制再改，避免所有城指向同一可变对象
逻辑隔离优先于物理拆库：早期可以同集群，但查询与导出必须带城标识。配置中心或挂载配置按城分 key，例如 capacity/city_ops_b/version。
config/
city_ops_a/capacity.yaml
city_ops_b/capacity.yaml
secrets/
city_ops_a/payment.env
city_ops_b/payment.env
二、发布流水线：本城灰度
第二城变更走独立变更单：谁改、改什么、回滚点是什么。先灰度少量流量或内部账号，再全量。
首城观察指标保持平稳，就不触发首城滚动。禁止「所有城共用一个最新标签」的发布习惯。容器镜像可以共用，但配置版本必须按城；很多人把两者混为一谈，才会出现「为了改一城半径，全网滚动」。
# 教学示意
release:
target_city: city_ops_b
config_version: 12
gray_percent: 10
rollback_to: 11
image: app:stable # 可不变
三、数据、导出与观察
订单、骑手在岗、异常单都带 city_id。导出按城过滤，财务才不会把两城糊成一张说不清的表。状态库可以同实例，但备份恢复演练要能按城核验样本。
观察面板按城看：接单时长、取消率、空跑率、配置版本分布。灰度阶段若第二城取消率异常，只停第二城，不牵连首城。
四、回滚只回本城
回滚优先回本城配置版本；只有确认是镜像缺陷时，才滚动镜像，并评估是否影响其它城。进行中订单应绑定接单时配置快照，避免回滚瞬间半路改规则。
语言包与支付适配发布同样建议可按城或按市场切开：改提示不必重测整城运力；换支付通道不必重发运力配置。商务结算规则由客户确定；系统侧不抽成客户平台订单。
五、和路由分层怎么配合
云上隔离解决「发错范围」；路由快照解决「改配时进行中订单漂移」。两者缺一不可。只做配置分城、路由仍读「全局最新」，进行中订单仍会抖；只做快照、发布仍全局滚动，首城仍会被误伤。
六、落地检查清单
- 配置 key 是否按城分开，是否禁止写全局可变 latest
- 灰度与回滚是否声明目标城
- 导出与监控是否强制城维度
- 支付密钥是否可分城轮换
- 镜像滚动与配置滚动是否可独立进行
配置发布的工程细节
配置变更与镜像变更拆开流水线。配置产物是「城 + 版本」；镜像产物是「应用版本」。两边审批单分开，回滚命令也分开。
灰度可用流量百分比或内部账号白名单。白名单更适合运力试规则，单量可控。观察面板至少包含：配置版本分布、取消率、接单时长、派单失败原因。
密钥分城后，轮换也不要全局一起换。先换第二城支付密钥并验证回调，再计划其它市场。回调地址与签名校验按城配置，避免串城验签失败被误判成通道故障。禁用无变更单的生产热改；导出任务读取城标识过滤。
灰度失败时的标准动作：切回本城上一配置版本、保留现场日志、按城看取消率是否恢复。不要先全局回滚镜像。支付密钥与运力配置分仓管理，权限分开。
谁能改配置，失败怎么收
城配置变更绑定角色：城市运营改本城运力，不能改其它城；平台运维可回滚但要留变更单；支付密钥轮换走安全角色。配置中心变更通知推给本城负责人，含版本号与回滚点。
灰度失败标准动作：切回本城上一配置版本、保留现场日志、按城看取消率是否恢复。不要先全局回滚镜像。支付密钥与运力配置分仓管理。配置流水线与镜像流水线拆开，是云上隔离发布的底盘。
镜像共用、配置不共用
强调一次：多城可以共用同一应用镜像，但配置版本绝不能共用一个可变最新标签。镜像升级也按城灰度，先观察一城再铺开。这条做不到，前面所有命名空间都白做。发布单上分列镜像版本与配置版本两栏。
对象存储与配置快照归档
每次本城配置全量发布，除在线配置中心保留版本外，建议把当时快照 JSON 另存对象存储，路径含城标识与版本号。在线系统故障时，仍能取回「当时到底发布了什么」。归档只追加，不覆盖；回滚是发布新版本指向旧内容，不是改历史文件。财务或运营争议派单规则时，这份归档比聊天记录管用。
七、总结
海外版外卖平台在云上扩城，关键不是机器数量，而是发布单元按城切开。配置可灰可回，观察按城，支付与运力分线，试水成本才会下降。
把上述做法写进下一次变更复查：只认证据，不认感觉。复查记录与配置版本号、发布单号交叉引用，方便半年后追溯。若人手不足，先保住可回滚与可审计，再追求体验细节。
对外沟通时用同一套术语：进度码、配置版本、审计流水、导出抽查。术语统一后，研发、运营、财务才不会各说各话。本篇清单可以作为术语对照的附件一起存档。
配置回滚演练每月一次：选一城改到新版本再改回，确认进行中订单未漂移、新单已吃回滚版本。演练记录与版本号进运维月报。支付沙箱切换不放进这次演练，保持变量单一。
把本段做法与前文验收清单交叉引用，形成可执行闭环：改完必验，验完留证，证与版本号同存。对外说明时强调：系统提供核对与权限能力，商务规则由客户确定；海外相关篇目中支付税务支持按需定制对接。
灰度名单与流量百分比可以并用：先名单验证规则语义，再放百分比看指标。两阶段都通过才全量。发布单勾选当前处于哪一阶段，避免有人以为已经全量。
