从 AmEx 支付系统看 Cell-based Architecture真正的高可用不是无限重试而是控制失败边界TL;DR场景高可用支付系统的架构设计AmEx 2018 年起现代化核心支付生态结论高可用的核心不是让组件永不失败而是用 Cell GTR 把失败控制在边界内产出12 节工程实践 5 张配套图示 错误速查卡版本矩阵功能/特性状态说明Cell-based Architecture 用于核心支付✅ 已验证AmEx 2018 年起现代化核心支付生态每个核心支付生态实例即一个 Cell来源americanexpress.io每个 Cell 独立部署、拥有独立数据✅ 已验证来源AmEx 文章原文Cell 在交易关键路径上无同步跨 Cell 依赖✅ 已验证AmEx 关键设计DNS、数据库、微服务均在 Cell 边界内Global Transaction RouterGTR作为统一入口✅ 已验证GTR 强制所有跨 Cell 流量经其转发禁止 Cell 直连静态数据复制到 Cell动态数据走确定性路由✅ 已验证AmEx 数据本地性原则不可回头点 唯一交易 ID 幂等设计✅ 已验证用于安全重试与重新路由Cell 内观测本地优先、异步聚合到全局✅ 已验证避免中心化 Observability 平台成为同步依赖适用于所有业务一上来就照搬⚠️ 不建议适合高价值、高可用、高规模、强 SLA 系统流量小、模型未稳定时强上属于过度设计很多系统谈高可用最后都会落到几个熟悉的词上限流、熔断、降级、重试、监控、告警、自动扩容、多活、异地容灾。这些当然重要但它们更像是故障发生之后怎么办。AmEx 在《Cell-Based Architecture for Resilient Payment Systems》里讨论的重点更靠前一层系统一开始就要被设计成故障不会无限扩散的结构。这也是 Cell-based Architecture 的核心价值。在支付系统里这个问题尤其关键。一次支付请求不是普通的读写接口它可能同时牵涉商户、收单方、发卡方、风控、清结算、币种、国家市场、支付类型、协议格式和外部网络。支付链路对可用性、低延迟、确定性响应、数据一致性和重复交易控制都有很高要求。只靠服务挂了自动重启“接口超时就重试”“数据库主从自动切换”并不能解决最危险的问题。真正危险的不是某一个服务坏掉而是一个局部故障把整个支付网络拖下水。Cell 架构要解决的就是让系统坏得有边界。1. Cell 不是一个服务而是一套完整的小系统最简单的理解是一个 cell 是一套可以独立完成某类业务处理的系统单元。它不是一个微服务实例不是一个 Kubernetes namespace也不是一组部署标签。一个成熟的 cell 通常包含一组微服务、数据库、缓存、消息组件、配置、观测组件以及完成业务处理所需要的本地依赖。也就是说cell 是一个完整的小系统。传统架构经常是这样的入口网关后面是一组全局共享服务服务之间互相调用数据库集中部署缓存集中部署配置中心集中部署日志链路集中部署。看起来资源利用率高组件复用充分但问题也很明显任何一个共享组件出问题都可能影响整个平台。Cell 架构会把系统切成多个相对独立的处理单元。请求进入系统后先由路由层判断应该进入哪个 cell。进入 cell 之后尽量只访问本 cell 内的服务和数据。如果某个 cell 故障理论上只影响被路由到这个 cell 的那部分流量其他 cell 继续工作。所以cell 架构的第一原则不是复用而是隔离。2. Cell 架构和微服务不是同一件事很多人会把 cell 架构理解成更细的微服务拆分这个理解不准确。微服务解决的是业务职责拆分。订单服务、支付服务、用户服务、风控服务、账务服务每个服务负责不同能力。Cell 架构解决的是失败域隔离。它关心的是一组服务、数据和依赖能不能形成一个独立运行边界。所以一个系统可以是微服务架构但不是 cell 架构。比如你有 50 个微服务但所有服务共享同一套数据库、缓存、配置中心、消息集群和下游依赖。一旦共享数据库故障全系统仍然不可用。反过来一个 cell 里也可以包含多个微服务。AmEx 的支付处理平台就是微服务体系但它把一组微服务、数据库和支撑组件组织成独立 cell。每个 cell 都能独立处理支付请求并且在交易关键路径上没有同步跨 cell 依赖。可以这样理解微服务是把业务拆开。Cell 是把失败关住。3. AmEx 的关键设计每个核心支付生态实例都是一个 CellAmEx 在文章里提到他们从 2018 年开始现代化核心支付生态。这个平台处理实时卡支付交易是面向持卡人和合作伙伴的关键系统。在新平台里每个核心支付生态实例都被设计成一个 cell。它具备几个特征可以独立部署。拥有自己的微服务、数据库和支撑组件。是一个明确的失败域。可以从流量轮转中摘除用于维护或故障处理。在交易处理关键路径上没有同步跨 cell 依赖。最后一点最重要没有同步跨 cell 依赖。很多系统表面上拆了多个区域、多个集群、多个 Kubernetes 环境但服务之间仍然跨区域同步调用或者业务处理时要去中心库查数据。这种架构看起来多活实际上还是强耦合。一个远端依赖慢了本地 cell 也会慢一个共享数据源坏了所有 cell 都会坏。AmEx 的思路是交易进入 cell 后处理过程必须尽量本地完成。DNS、数据库、微服务和支撑服务都在 cell 边界内。跨 cell 交互被严格限制cell 不能退化成一个部署分组而要成为真正的故障边界。4. 数据本地性支付系统不能每次都去中心系统查支付处理离不开数据比如币种汇率、商户类别码、合作方规则、市场配置、支付类型规则、交易状态等。这里的难点是不同数据不应该用同一种方式处理。第一类是静态或半静态数据例如币种汇率、商户类别码、市场配置。它们变化频率不高可以提前复制到每个 cell。这样交易处理时就不需要临时访问中心系统也不会因为 cache miss 去远端查询。这背后的原则是复制可以慢一点但交易不能等。复制发生在交易路径之外。交易处理不等待复制完成也不依赖中心系统实时返回。这样既降低延迟也减少故障传播路径。第二类是动态数据例如会随交易变化的状态。这类数据不能简单靠广播复制解决因为复制延迟可能导致某个 cell 拿不到最新状态。AmEx 的做法不是让所有 cell 都做全局强一致而是用确定性路由把交易送到拥有正确数据的 cell。这点很重要。很多系统一遇到数据一致性问题就倾向于做全局同步、分布式事务、跨 region 强一致、集中状态服务。但这些方案如果放进支付关键路径延迟和可用性都会受到影响。更稳的做法是如果最新状态只在某个 cell 权威可用那路由层就应该知道如何把请求送到那个 cell而不是让任意 cell 接到请求后再跨 cell 找数据。不要在业务处理过程中补救路由错误要在入口处就把请求送对地方。5. GTR不是普通网关而是支付网络的交通控制层AmEx 架构里有一个核心组件Global Transaction Router简称 GTR。它不是普通意义上的 API Gateway。普通网关通常负责鉴权、限流、转发、协议转换和日志。GTR 更像支付网络里的交通控制层。它要理解足够少、但足够关键的支付协议字段从而做路由、故障转移、灰度、流量切换和 cell 边界控制。这里有一个重要分寸GTR 需要理解足够做路由的支付信息但不能承载复杂支付业务逻辑。如果 router 太薄它无法判断请求应该进入哪个 cell。如果 router 太厚它又会变成新的中心化业务系统成为更大的故障点和复杂性中心。所以 GTR 的定位可以概括为懂协议不做业务。它知道如何基于合作方、市场、支付类型、交易属性等信息做确定性路由。但真正的支付处理逻辑仍然在 cell 内部完成。GTR 还有一个更关键的作用强制所有跨 cell 流量经过它。如果一个 cell 不能处理某笔交易需要重新路由到另一个 cell也必须回到 GTR。cell 之间不能直接互相调用。这条规则看起来麻烦但它避免了一个非常常见的架构腐化过程一开始大家都说 cell 之间不要互调后来某个需求为了方便开了一个例外再后来另一个服务也跨 cell 查一下最后跨 cell 调用越来越多cell 边界名存实亡。AmEx 通过 GTR 把边界制度化。只有 GTR 能跨 cell 通信普通微服务不能绕过它。这才是架构约束而不是团队约定。6. 故障转移不是恢复半截交易而是安全重启支付系统里的故障转移有一个难题如果一笔交易在 cell A 里处理到一半cell A 出问题了能不能在 cell B 接着处理直觉上看接着处理似乎更高效。但 AmEx 的做法不是跨 cell 恢复部分处理状态而是在安全边界内用原始交易数据在另一个健康 cell 重新开始处理。原因很清楚跨 cell 恢复半截状态会引入共享状态、状态同步、部分提交、幂等冲突、重复请求、外部系统副作用等一系列问题。为了恢复一笔交易可能会破坏整个 cell 隔离模型。所以更合理的是 restart model如果交易还没有到达不可回头点失败后可以重新路由到另一个 cell从原始交易数据重新处理。如果交易已经发送到外部系统例如发卡方那就进入不可回头点不能再随意重新路由。因为外部系统可能已经收到请求重复发送可能造成重复授权或状态不一致。这对后端系统很有启发。真正可靠的系统不是到处保存中间状态然后试图精确恢复每一步而是把流程设计成在关键副作用发生前可以安全重试、重新路由、重新执行。在关键副作用发生后必须依赖幂等键、交易唯一标识、状态机和补偿机制控制重复影响。AmEx 对其他支付类型也使用唯一交易标识来管理幂等。交易在重试和重新路由中保持同一个唯一 ID下游系统用这个 ID 识别和抑制重复请求。所以 cell 架构不是单独成立的。它必须和幂等设计、状态机设计、外部副作用边界一起工作。7. 越靠近入口依赖越要少AmEx 文章里还有一个很实际的点越靠近入口依赖越要少。GTR 是支付网络入口一旦它阻塞或不可用会直接影响交易进入系统。所以它不能依赖太多外围系统尤其不能让日志、配置、监控这类非关键能力阻塞交易处理。比如日志系统不可用时交易不能因为写日志失败而失败。文章中提到的做法是使用异步日志和缓冲区截断策略。如果缓冲区满了就丢日志而不是阻塞支付请求。这在工程上很现实关键路径上宁可丢非关键观测数据也不能阻塞核心交易。配置也是类似。配置服务不可用时系统应该继续使用最后一次已知配置运行而不是立刻停摆。配置异步更新关键路径读取本地内存里的配置快照。这类设计背后的共同原则是关键路径只依赖必须依赖的东西。日志、指标、配置、控制面、管理面、全局看板都不应该成为交易处理的同步前置条件。很多系统的可用性问题并不是核心业务代码坏了而是被旁路依赖拖死。比如日志打不出去导致线程阻塞配置中心抖动导致服务拒绝请求监控 SDK 卡住导致接口延迟飙升。这些问题在普通业务里已经危险在支付入口层更不可接受。8. 观测也要本地优先很多人设计 cell 架构时会关注业务服务和数据库隔离但忽略观测系统。AmEx 的做法是每个 cell 先把日志、指标、trace 发布到 cell 本地的观测组件然后再异步聚合到全局平台用于统一看板、告警和分析。这样做的好处是如果某部分观测系统出问题只会降低对应 cell 的可见性而不是影响整个平台的交易处理也不会影响所有 cell 的观测采集。可以抽象成一句话观测要全局可见但采集不能全局强依赖。也就是说全局看板可以异步聚合但 cell 内部必须先能独立采集、独立判断、独立运行。不要让中心化 observability 平台成为所有 cell 的同步依赖。9. Cell 架构的收益不只是容灾Cell 架构最直观的收益是降低故障爆炸半径。如果一个系统有 10 个 cell每个 cell 承担一部分流量那么单个 cell 故障时理论影响范围会被限制在对应流量或对应分区内。其他 cell 继续处理请求。但它还有两个额外收益。第一是低延迟。交易进入 cell 后服务调用、数据库访问、支撑依赖都尽量本地完成减少跨区域、跨集群、跨共享服务的网络跳转。外部依赖越少延迟越可预测。第二是扩展性。传统系统扩展经常是把一个大系统变得更大数据库更大、缓存更大、集群更大、消息队列更大。问题是系统越大隐藏瓶颈越多压测越难故障影响面越大。Cell 架构更倾向于复制多个有上限的小系统。每个 cell 有明确容量上限压测可以围绕单 cell 进行。超过容量后不是无限扩一个 cell而是增加新的 cell。这是一种从 scale up 到 scale out 的思路变化。更重要的是单 cell 的极限更容易测试。一个巨大共享系统很难完整压到边界但一个固定规模 cell 可以被反复压测、故障注入、验证容量水位。系统增长时复制经过验证的 cell而不是不断放大未知复杂性。10. 代价资源、数据、路由和组织纪律Cell 架构不是免费的。第一个代价是资源和运维成本。每个 cell 都要有自己的服务、数据库和支撑组件。某些共享服务在传统架构里只要一套在 cell 架构里可能要复制多套。第二个代价是数据设计更复杂。哪些数据可以提前复制哪些数据必须路由到权威 cell哪些数据可以异步最终一致哪些数据不能跨 cell 共享这些都要非常清楚。第三个代价是路由层复杂度上升。router 必须知道用什么 partition key 或交易属性做路由。这个 key 必须稳定、可获得、可解释不能在关键路径上依赖复杂查询。第四个代价是组织纪律要求更高。cell 边界很容易被临时需求腐蚀。只要跨 cell 同步调用一多cell 架构就会退化成普通分布式系统而且复杂度更高。第五个代价是发布和运维策略要重做。不能所有 cell 同时发布否则坏版本会同时影响全局。更合理的方式是按 cell 分批发布、灰度、回滚、观察。所以 cell 架构适合高价值、高可用、高规模、强 SLA 的系统不适合所有业务一上来就照搬。对于普通后台系统如果流量不大、可用性要求不极端、数据模型还没稳定强行上 cell 架构只会过度设计。11. 普通业务系统怎么借鉴不要一开始就问我要不要上 cell 架构。更好的问题是我的系统里有没有必须被隔离的失败域一个租户故障能不能不影响其他租户一个地区故障能不能不影响其他地区一个客户的异常请求能不能不拖垮全站一个坏版本发布能不能只影响一小部分流量一个数据库分片故障能不能只影响对应业务分区如果这些问题的答案很重要才值得考虑 cell 化。一个可落地的演进路径通常是明确 partition key。可以是租户 ID、客户 ID、商户 ID、地区、业务线、支付类型、订单归属等。这个 key 必须在入口请求阶段就能确定。把路由层做薄。router 只负责路由、灰度、故障切换和流量控制不承载复杂业务逻辑。拆出本地数据边界。能提前复制的数据提前复制必须强一致的数据路由到权威 cell不能让业务服务在处理过程中到处跨 cell 查数据。禁止 cell 间随意互调。跨 cell 通信必须走统一控制点否则边界会失效。设计幂等和重启模型。请求失败后是重试、重放、补偿还是终止必须由状态机和副作用边界定义清楚。把发布、观测、容量和故障演练按 cell 组织。cell 不是部署标签而是运维单位、容量单位、发布单位和失败单位。12. 对 Java 后端和平台工程的启发对于 Java 后端系统cell 架构不是某个框架能直接提供的能力。Spring Cloud、Nacos、Gateway、Dubbo、Kubernetes、Istio、Envoy 都只是工具。真正重要的是系统边界设计。如果落到工程实现可以对应到这些方面网关层需要支持基于业务 key 的确定性路由而不只是简单负载均衡。注册发现需要区分 cell 内服务和跨 cell 入口避免服务发现直接暴露所有实例。数据库要按 cell 划分连接和权限服务只能访问本 cell 数据库。缓存、消息队列、配置、限流、熔断策略也要按 cell 维度设计不能所有 cell 强依赖同一套中心组件。发布系统要支持 cell-by-cell 灰度而不是全量滚动。监控告警要同时有 cell 内视角和全局视角。压测要先压单 cell 的容量边界再推导整体容量模型。故障演练要验证一个 cell 故障时流量是否能摘除、是否会跨 cell 传播、是否会产生重复处理。这比加几个熔断注解复杂得多但也更接近真正的高可用工程。13. 最核心的结论AmEx 这篇文章最值得记住的不是某个组件名字而是几个架构判断高可用不是让所有组件都不失败而是让失败被限制在可控边界内。Cell 不是部署单元而是完整业务处理单元和失败域。关键路径上不能有同步跨 cell 依赖。静态数据复制到 cell动态强一致数据通过确定性路由找到权威 cell。Router 要足够聪明以完成路由但不能变成业务大脑。故障转移不是恢复半截状态而是在安全边界内基于原始请求重新开始。幂等、唯一交易 ID、不可回头点是支付系统能安全重试和重新路由的前提。越靠近入口依赖越少非关键能力必须让位于核心交易处理。Cell 架构的本质不是多部署几套系统而是用架构纪律控制复杂系统的失败传播。真正成熟的支付系统不是没有故障而是故障发生时系统知道哪里可以坏、坏到什么范围、如何摘除、如何重试、如何恢复以及哪些边界绝对不能被突破。这就是 AmEx 这篇 cell-based architecture 实战最有参考价值的地方。参考资料American Express Technology, Cell-Based Architecture for Resilient Payment Systems, 2026-06: https://americanexpress.io/cell-based-architecture-for-resilient-payment-systems/错误速查卡症状根因定位修复单个 cell 故障导致全平台不可用“多活” 形似神不似服务仍有同步跨区域/跨 cell 调用或共享中心数据库追踪服务调用链与数据连接是否存在跨 cell 同步 RPC、中心库查询严格遵守 cell 边界关键路径上消除同步跨 cell 依赖动态强一致数据改走 GTR 确定性路由关键路径上日志/配置/监控抖动直接拖垮交易关键路径同步依赖了非关键旁路能力日志 SDK、配置中心、监控采集故障时刻的调用栈与依赖健康度看是否存在写日志/读配置/打点的同步阻塞点关键路径上日志改异步截断、配置改本地快照、监控改本地优先异步聚合故障转移后出现重复扣款/状态不一致跨 cell 直接恢复半截状态或重新路由时未保持唯一交易 ID核对失败交易在外部发卡方侧的请求记录与 cell 内状态机日志看是否多次触达不可回头点改为 restart model不可回头点前重路由重启不可回头点后依赖幂等键 唯一交易 IDcell 架构运行一段时间后边界失效临时需求开了跨 cell 直连的小口子跨 cell 同步调用逐步增多静态扫描服务间调用关系、看是否绕过 GTR 直连强制所有跨 cell 通信经 GTR把边界做成架构约束而不是团队约定普通业务系统强上 cell 架构后运维/资源成本爆炸流量规模与 SLA 与 cell 模式不匹配数据模型也未稳定评估 partition key 是否清晰、是否存在权威 cell、流量是否足够分摊多 cell 成本不直接上 cell先问是否存在必须隔离的失败域按 6 步演进路径逐步推进router 越来越重、变更越来越难router 越权承载业务逻辑从路由层退化为中心化业务系统看 router 内部是否出现业务规则编排、复杂计算、依赖业务库等代码把 router 拉回懂协议、不做业务的定位业务逻辑下沉到 cell 内部作者武子康的个人博客