做金融科技这些年我碰过的所有系统里最让人不敢松气的一条链路就是联机交易。它是用户按下支付按钮、柜员敲下回车键、App 里扫完码的那一瞬间系统必须在几百毫秒内完成的整套动作。跟批次任务不一样联机交易没有“等会儿再算”的余地每一笔都在实时发生每一笔都牵扯账户、余额、风控、清算、审计任何一个环节慢半拍或者出错用户感知到的就是“钱付了没到账”或者“卡死转圈中”。这篇文章我想把我这些年做金融联机交易系统的架构设计心得和核心实践系统性地讲一遍。内容会覆盖联机与批次两条主线的协同、分层架构怎么拆、幂等怎么设计、分布式事务到底该怎么选型、高可用和容灾怎么做、以及我踩过的那些坑和排查思路。如果你是正在设计支付、信贷、存管、账户这类核心系统的工程师或者准备往 Fintech 架构方向深入这篇文章应该能帮你省不少摸索的时间。我不写空泛的概念尽量全是实操层面的东西配合真实场景来说。1. 联机交易与批次的定位差异1.1 联机交易到底在解决什么问题2015 年我做支付核心的时候第一次被拉去听架构师讲联机系统他开口第一句就是“我们做的不是 CRUD是钱的实时通道。”当时觉得这句话有点装后来自己真正扛过线上故障才发现这句话一点没夸张。联机交易的本质是前端发起一个请求后台必须在极短时间内完成校验、记账、返回结果整个过程通常以“笔”为单位请求到了就处理处理完就响应没有批量攒单的机会。这种请求-响应的模式跟传统的批次加工是完全不同的思维。联机交易关心的是单笔延迟、吞吐量、成功率而批次关心的是全量数据能否在某个时间窗口内处理完。你在联机交易里写的是“每一笔都要对”在批次里写的是“全量跑完我要对得上”。这个差异贯穿了从建表、写代码到部署架构的每一个决策。典型的联机交易场景包括余额查询、转账汇款、扫码支付、账户开户、贷款放款、还款扣款、签约解约。这些场景的共同点是请求量高、路径长、状态多而且每一个动作都带着真金白银的责任。所以联机系统在设计之初就要回答清楚三个问题多快算快、多稳算稳、坏了怎么收场。1.2 联机与批次白天与黑夜的配合很多人做联机系统时会忽略批次但金融系统里联机和批次从来不是孤立的。白天跑联机晚上跑批次这是绝大多数金融机构的基本节奏。批次干什么日终结算、利息计提、贷款批量扣款、批量开户、报表生成、总分核对、数据归档。这些任务不能跟联机抢资源因为它们一跑就是几十分钟甚至几小时如果白天硬挤进去联机延迟会受不了。但批次和联机不是简单的“错峰”关系它们之间有非常强的数据依赖。批次需要联机当天产生的交易流水联机则需要批次昨晚算好的额度和账户状态。比如你早上查信用卡账单上面显示的应还金额是昨晚批次计提完利息之后的今天你消费一笔实时余额又是联机系统现算的。这就逼着架构上必须把两条链路的数据边界定义清楚谁写什么表、谁读什么表写坏了就是灾难。我见过最典型的坑是这样的某系统为了报表方便让联机交易直接去更新日终汇总表结果白天对账累加和跑批的逻辑冲突日终数据怎么都对不上。后来我们干脆把联机和批次的数据模型彻底分开联机只写流水和余额批次只读流水生成汇总谁也不要碰谁的写路径问题直接消失。这个经验我后面在第四节还会展开讲。1.3 联机交易的核心需求画像给联机交易画需求画像五条主线逃不掉高并发、低时延、强一致、可审计、高可用。高并发意味着要支撑每天几千万甚至上亿的请求峰值低时延意味着大部分交易要在 300 毫秒到 1 秒内完成强一致意味着账户余额不能出现一毛钱的偏差可审计意味着每一笔交易从请求进入系统到最终落库全程有痕迹、可追溯高可用意味着 99.99% 甚至更高的可用性一年停机时间只能按分钟算。这五条放在一起天然是矛盾的。高并发要求异步、分片、最终一致强一致要求同步锁、串行化低时延又要求把同步开销压到最小。做架构设计就是在这些矛盾里找平衡点。我的经验是不要试图用一套方案解决所有问题而是要按交易类型分层治理。比如账户查询类交易可以走缓存、走异步复制但资金类交易必须走强一致路径营销活动这种高并发非核心场景可以熔断降级但账务核心任何时候都不能降。在架构上一开始就把这些边界划清楚后面才不会天天救火。2. 整体架构设计分域解耦2.1 接入层全渠道统一入口联机系统的第一层是接入层也叫接入网关或前置系统。它的职责不是业务逻辑而是把外部渠道的各种请求转成内部统一的报文格式再把内部的响应转回去。为什么需要这一层因为金融系统的渠道实在太多了手机 App、POS 机、柜面、网银、第三方支付机构、银联、网联每种渠道的协议、加密方式、字段定义都不一样。如果每一条业务链路都直接对接每一种渠道系统复杂度会爆炸。接入层通常做四件事协议适配、报文转换、安全认证、路由分发。协议适配负责处理不同渠道的通信方式比如 HTTP、TCP 长连接、MQ 异步消息安全认证负责验签、解密、令牌校验路由分发根据交易代码、渠道类型、租户信息把请求分发到不同的业务服务。这一层要做到无业务状态也就是说它不该保存任何跟某笔交易强相关的业务数据所有的上下文都应该往后端传递这样才能保证接入层可以水平扩展挂掉任意一台都不影响整体。2.2 服务编排层状态机与交易模板过了接入层请求会进入服务编排层这是整个联机系统的技术核心。在国内的金融核心系统里这一层的设计逻辑通常是把各种交易抽象成“模板状态机”。模板定义一笔交易要经过哪些步骤状态机定义每个步骤的状态流转。以一笔消费支付为例它的状态可能是初始化、风控校验中、账户扣款中、商户结算中、成功、失败、未知。每一个动作对应一个服务节点编排引擎负责按顺序调用并在异常时决定是回滚、重试还是转人工。为什么要用状态机而不是直接写业务代码因为在生产环境里交易的执行路径不可能一帆风顺。网络抖动、数据库超时、下游服务异常都可能让一笔交易卡在中间状态。如果没有状态机这笔交易就丢了或者只能靠人肉补单。有了状态机以后每一笔交易处于哪个状态、下一步该执行什么、哪些状态下允许重试都是可枚举、可控制的。配合一张交易状态表管理员随时可以查到所有“悬而未决”的交易还能通过管理台手工推动状态流转这在金融系统里是刚需。2.3 数据层内存数据库与持久化存储的组合数据层是联机系统最敏感的地方因为钱在这里。我的核心经验是把数据分成两层来看待。第一层是持久化的账务和流水数据必须保证绝对准确、绝不丢失这些数据放在关系型数据库里按客户维度做分库分表第二层是用于加速查询的热点数据比如账户余额、可用额度、客户等级、风控标签这些数据放在 Redis 这类内存数据库中用来减少对数据库的直接访问。分库分表的维度我最推荐的是按客户 ID 哈希或按客户号取模。因为金融业务中绝大多数交易都是围绕“客户-账户”展开的按客户维度分片可以把一个客户的所有账户数据放在同一个分片内这样单个账户的交易不需要跨库操作事务边界最小。要注意的是分片键选错是最危险的事。我之前见过一个系统按商户号分片结果客户查自己名下多个商户的交易流水时被迫跨库查询性能直接崩了。后来改造按客户维度路由查询效率立刻上来了。内存数据库在这里的作用要克制它只能用来缓存那些可以容忍短暂不一致的数据。比如余额的展示值、积分数、优惠券状态可以走缓存但真正的入账操作永远要落到数据库并且以数据库的余额为准。缓存的更新策略我建议用“先更新数据库再删除缓存”而不是先更新缓存。原因在于缓存永远可能被并发重建先更新数据库再删缓存即使删缓存失败最多是读到旧值下次再删反过来先更新缓存数据库一旦回滚缓存和库就永久对不上了。2.4 技术底座与部署形态再往下就是技术底座。联机系统通常跑在应用集群上前面挂负载均衡后面接数据库主从集群和应用层微服务。在部署形态上生产环境最少要有两套异地或同城灾备环境同城双活是当前金融机房的主流方案。应用层要无状态化会话信息不能存在本地内存里要么透传要么存到分布式缓存里这样任何一台机器挂掉流量可以被其他机器无缝承接。配套的基础设施还少不了一套注册中心负责服务的自动发现与下线配置中心负责动态调整参数比如限流阈值、超时时间、降级开关消息队列负责削峰和异步解耦分布式链路追踪系统负责把每一笔交易的完整路径串联起来。这里我特别想强调配置中心的重要性。以前我们用静态配置文件每次调超时时间都要发版重启一套联机系统几十个节点改一个参数要折腾一小时线上问题早就发酵了。后来上了配置中心所有动态参数全部走配置下发秒级生效对排查线上故障帮助巨大。3. 核心链路的技术实践3.1 线程模型与异步化改造联机系统的性能瓶颈相当一部分出在线程模型上。传统的同步阻塞模型里一个线程从头到尾串起一笔交易从接请求到查库、调下游、写结果全部同步。这种模型实现简单但并发能力非常有限线程多了上下文切换开销大线程少了请求排长队。我记得某个早期系统用的是 Tomcat 默认线程池压测到 200 TPS 就开始大量超时后来分析发现线程全部阻塞在外部接口调用上等响应的时间比真正计算的时间还长。改造方向有两个一是把跨系统调用改成异步化查询类操作并行发出去等待结果时线程可以干别的二是对写操作链路做削峰把非核心的、可延迟的步骤丢到消息队列里异步处理。举一个实际例子一笔代发工资交易核心步骤是校验付款账户余额、扣减付款方余额、增加收款方余额这三步必须同步完成。但发短信通知、更新统计报表、推送 App 模板消息这些动作完全可以在交易成功后异步执行。把这三步挪到消息队列之后单笔交易的耗时从 800 毫秒降到了 300 毫秒TPS 也跟着上了一个台阶。异步化有一个必须注意的前提核心状态的变更必须同步完成异步任务只能做“锦上添花”的事。如果你把记账本身也异步化用户付款后余额没立刻扣掉风控和账务都会出问题。所以我在设计异步链路的时候第一件事就是列清单哪些事可以异步、哪些绝对不行写进设计文档评审的时候逐一确认。这个清单在后期排障时还会帮你快速缩小问题范围。3.2 幂等设计与并发控制联机系统里怎么强调幂等都不为过。什么是幂等同一个请求重复发多次系统的结果跟发一次一样。为什么必须做幂等因为金融系统的网络环境不是绝对可靠的一个超时可能让客户端重试一个消息队列投递也可能重复。如果重复请求导致重复扣款那是绝对的生产事故。幂等的核心是幂等键。幂等键必须有全局唯一性通常由交易流水号、渠道代码、请求日期时间等字段拼接再经过哈希或标准化处理得到。框架层收到请求后先查幂等表如果存在相同键且处理中直接拒绝或等待如果已成功直接返回上次结果如果没有则插入一条处理中的记录再进入业务逻辑。这个幂等表本身要建唯一索引靠数据库的唯一约束来兜底并发下的重复插入。并发控制则是另一个层面。两个请求同时操作同一账户如果都读到余额 1000各扣 500最后余额变成 500那就错了正确结果应该是 0。解决办法有两个方向数据库层面的乐观锁通过 UPDATE account SET balance balance - 500 WHERE balance 500 这样的原子 SQL让数据库自己判断余额够不够或者应用层面的分布式锁对某个账户 ID 加锁串行化处理。我的建议是涉及余额变动的场景优先用数据库原子的条件更新因为它性能高、实现简单、不用考虑锁超时释放的问题分布式锁更适合处理“跨账户、跨服务”的复杂事务场景。3.3 分布式事务方案从两阶段到最终一致跨服务的事务一致性问题是联机架构里最让人头疼的部分。早期很多金融系统用的是两阶段提交或者基于传统应用服务器的全局事务管理器。但放到高并发、微服务化的架构里两阶段提交的同步阻塞和单点协调者问题会非常致命协调者一挂所有参与者全卡住。我个人的看法是除非是极其低频、路由极简单的内部系统否则不要在联机主链路上用两阶段提交。更务实的路线是最终一致性。主流的套路有三种本地消息表、事务消息、以及定时补偿对账。本地消息表适合团队不想额外依赖中间件的场景主流程在本地事务里同时写入业务数据和一条待发送消息然后由独立线程把消息发给下游下游消费成功后回执主流程再更新消息状态。事务消息则把这个过程搬到了消息中间件内部主流程发送半消息业务执行成功后再提交确认。两种方案本质上都是靠“本地事务 消息可靠投递”来保证不丢消息。最终一致性方案里我最想提醒的是设计上一定要预留“对账”兜底。也就是除了消息驱动之外每天要有定时任务扫描两边数据把漏掉的消息或失败的任务捞回来。我遇到过消息中间件集群抖动几千条账务消息没发出去靠本地消息表重推全部补上最终对账一分不差。如果当时没有对账机制这些交易就会变成“用户已扣款对方没收到”的呆账处理起来非常痛苦。3.4 超时、重试与防抖联机系统必须对超时和重试做精细化管理。超时时间不是拍脑袋定的而是根据链路里的每一跳来估算的。比如网关到服务编排层设 3 秒编排层到账务核心设 1 秒到风控设 500 毫秒整体对外承诺的响应时间要小于所有下游超时之和并且留出缓冲。某个系统曾经把整体超时设为 5 秒但内部某段调用也要 5 秒一压测整个链路全被拖垮了。后来我们把每个下游的超时时间都单独配置并且从下往上递减才解决了这个问题。重试更是一门学问。我的原则是只有“幂等安全的读操作”可以立即重试涉及资金变更的操作第一次超时之后不要盲目在本线程里重试而是走“挂起转人工”或“异步查询结果”的路径。为什么要这样因为一个扣款请求可能已经在数据库里执行成功了只是响应丢失如果立刻重试就重复扣款了。此时正确做法是主动查询这笔交易的状态根据状态决定是否补发。这个设计需要在报文设计时预留查询交易状态的接口别等到出了问题再补。4. 联机与批次的协同设计4.1 日切机制与跑批窗口金融系统里的“日切”指的是业务日期的切换。不是说每天凌晨 0 点 00 分 00 秒就自动切而是要等到当天最后一份联机交易落库、账务核对无误后才能切换。很多系统把日切时间定在凌晨 1 点到 2 点之间留出半小时到一小时的“静默窗口”在这个窗口里系统不接收联机交易专门做日终处理和日切。日切机制在系统层面靠的是账务日期参数。每个请求进入系统时会从配置中心读取当前账务日期所有交易都带上这个日期数据库按“账务日期 流水号”区分不同日期的数据。到了日切时间管理员先检查联机交易是否已全部处理完然后切换账务日期参数再启动批次任务。这里的关键是日切本身必须是一个可回退、可人工干预的操作。自动化脚本只能做常规切换异常情况下比如还有未处理完的交易一定要允许打断和人工确认。我们生产环境的日切脚本里加了一个前置检查任务扫描近 5 分钟的流水表如果还有状态为“处理中”的记录就自动挂起并报警等人工确认再往下走。4.2 保护联机体验的批量策略跑批任务对联机系统的冲击是架构设计里非常容易忽略又非常致命的问题。批次任务往往要全表扫描、批量更新如果跟联机共用数据库锁冲突、IO 争抢在所难免。我的设计原则是能隔离开的必须隔离。数据库层面批次的读操作走备库联机的写操作走主库应用层面批次服务独立部署限流设置得比联机低得多避免批次任务突发占满 CPU 或连接池。如果资源实在隔离不了批次任务就得分批执行、控制并发。比如批量扣款把 100 万笔拆成每批 1000 笔的小任务由定时器逐批提交每批之间间隔几秒给联机请求留出空隙。同时要监控数据库的锁等待时间一旦超过阈值就自动暂停批次任务等联机高峰过去再恢复。这套机制的核心原则是联机是爷爷批次要让路。一个批次任务晚跑 20 分钟最多是报表晚出但联机卡了 20 分钟那是直接的生产事故。4.3 批后校验与日终对账批次跑完不代表万事大吉更关键的是校验。日终对账分几个层面总分核对、明细核对、账实核对。总分核对是最基础的检查“当天联机流水笔数和金额之和”是否等于“批次入账的账务流水笔数和金额之和”明细核对是把每一笔联机流水与账户流水、清算流水逐笔匹配账实核对则是拿系统记录跟真实资金变动比对比如通过银行存管账户、人行清算记录来验证。这部分的设计思路是宁可多查不可漏查。每一个对账核对任务都要有独立的告警和独立的补偿入口发现差异后差异明细要导出成可读的清单让运营和开发能直接定位到具体交易。我见过一个团队把对账做成一个定时任务脚本跑完只输出“有差异”但差异在哪一笔、什么原因完全没有排障全靠 DBA 手工查库效率极低。后来我们改了方案对账结果按差异类型分类归档付款方无记录、收款方无记录、金额不符、状态不一致每一类都可以直接下钻到交易详情排障时间从小时级降到了分钟级。5. 高可用与容灾设计5.1 同城双活的应用与数据方案金融核心系统的高可用最低标准是同城双活。很多非金融行业的人听到“双活”会觉得就是多部署几台机器但金融系统的双活远没有那么简单。真正的的同城双活是两个机房同时在处理流量任何一个机房挂掉另一个机房能在分钟级内接管全部业务而且不丢一笔交易。这对网络、数据同步、路由切换的要求都是极高的。应用层面的双活做起来相对容易把无状态应用部署到两个机房前面用全局负载均衡分发流量任何一个机房的应用出问题流量自动切换。真正的难点在数据层。数据库层面的双活方案里金融系统一般用基于同步复制的主备模式加上仲裁节点来解决“脑裂”问题。这里的关键参数是同步复制必须保证主库提交成功之前备库已经收到日志并且落盘这样主库一旦宕机备库数据是完整的保证零丢失。但同步复制带来一个副作用就是主备之间网络延时越高写入延迟越高。所以两个机房的距离不能太远光纤延时必须控制在几毫秒以内机房距离超过 50 公里就要重新评估方案可行性了。5.2 优雅降级与熔断策略高可用设计的另一半是处理峰值和故障的柔性能力。联机系统在双十一、开门红等大促节点流量可能比平时高出好几倍如果所有系统都硬扛扛不住。我坚持的设计原则是核心链路必须做熔断和降级预案而且降级维度要提前定义清楚。比如营销活动、短信通知、App 推送这类非核心服务在流量高峰时可以直接降级用户感知不到核心功能受影响风控引擎如果是外部服务并且延迟升高可以降级到本地规则引擎牺牲部分风控精度保交易成功率首页轮播广告这种内容服务更是可以随时熔断的。降级的实施需要两个前提一是开关必须能动态下发不能靠重启应用二是降级动作要有监控记录事后能追溯哪些用户、哪些交易走了降级路径。我们曾经做过一次大促压测发现风控服务超时率飙升直接把风控降级成放行交易成功率立刻回升然后让风控团队在低峰期排查故障这就是一个典型的“先保通、再优化”的运维思路。别觉得降级是丢人的事在金融系统里所有旁路服务都可以降级唯独资金账务不能把保护资源用在最核心的路径上才是务实的架构。5.3 灰度发布与快速回滚联机系统一次发版影响的可能是几百万用户的资金操作不能像普通业务系统一样直接全量上。灰度发布是必须的。我们的实践是先挑选一个低流量渠道比如内部测试渠道切流量跑一段时间观察监控指标确认稳定后扩大到某个区域的全部用户最后再全量。整个过程由路由规则控制配置中心里放一个“灰度比例”参数从 0 到 100 平滑调整不需要重启。快速回滚比灰度发布更要紧。每次发布前除了代码库的 Tag 之外还必须准备好数据库的回滚脚本。联机系统最怕的是发布后跑了一阵子才发现问题这时候数据库已经被新逻辑改了回滚代码容易回滚数据极难。所以上线前我会强制要求凡是涉及数据结构变更的必须把变更脚本拆分成“升级脚本”和“回滚脚本”两部分回滚脚本要能把数据恢复到升级前状态。这个要求写进了团队的发布规范执行了几年帮我们避免了好几次“代码回滚了数据回不去”的灾难现场。6. 性能优化与问题排查实录6.1 性能指标设定与压测方法联机系统做性能评估我最看重的指标有三个TPS每秒处理交易数、响应时间的 P99 分位数、以及成功率。TPS 代表吞吐能力P99 代表绝大多数用户体验成功率代表系统的稳定性。这里特别要提醒不要只看平均响应时间。平均时间被少数极快请求拉低掩盖了大量慢请求的问题。比如一个系统平均响应时间 200 毫秒看起来不错但 P99 是 800 毫秒P999 是 3 秒意味着每 1000 个用户里就有一个用户等了 3 秒。所以性能目标一定要同时约束 P99 和成功率比如“P99 小于 500 毫秒成功率大于 99.95%”。压测方法上全链路压测是金融系统的主流做法。它不只是用一个工具对单个接口打流量而是在预发或专门的压测环境里把整条链路接入层、服务层、数据库、消息队列、下游外部系统都纳入进来模拟真实交易比例和生产数据量。压测前必须把测试流量的标识跟正常流量分开防止脏数据混入生产环境。我们做全链路压测时会先跑一遍 Scenic 脚本模拟正常用户的渐进式操作确认系统稳定再从低并发逐步加压同时监控每个节点的 CPU、内存、数据库连接数、线程池活跃数找到第一个瓶颈点解决掉继续加压再找下一个瓶颈。这个过程能暴露出大量平时根本看不出来的问题。6.2 常见问题速查表联机系统线上排查的问题是高度重复的我把这几年遇到的高频故障整理成一个速查表每次排障都按这个顺序过一遍效率高很多。症状常见根因排查思路避坑提示交易超时增多数据库连接池耗尽查数据库活跃连接数、应用连接池使用率不要盲目加连接数先看慢 SQL 是否把连接占死了响应变慢但 CPU 不高数据库锁等待查锁等待事件找到阻塞和被阻塞的 SQL批量任务和联机共用表时最容易出这类问题应用节点 CPU 飙高线程池被打满或死循环抓线程 dump看线程状态分布线程 dump 要多抓几次对比单次看不出增长趋势部分交易重复扣款幂等键生成规则不严谨审查幂等键拼接逻辑查重复流水幂等键必须包含全局唯一业务编号不能只靠时间戳缓存穿透导致数据库压力大热点 key 过期且大量请求同时回源加互斥锁或空值缓存热点数据做逻辑过期不要对每个 key 都设置同一过期时间要加随机偏移消息堆积导致下游延迟消费者处理能力不足或阻塞查消费者日志、线程阻塞点消息堆积期间先加消费实例再定位阻塞原因批次任务拖垮联机跑批 SQL 和联机抢共享资源查数据库 IO、锁等待、批次任务运行时段批次任务必须限速、分批、错峰不能一把梭外部渠道回调丢失网络抖动、回调方不重试主动轮询外部渠道获取交易结果核心外部交易必须有“定时主动查询”兜底不能只等回调6.3 几个值得坚持的优化习惯最后分享几个我个人觉得值得长期坚持的工程习惯。第一个是链路追踪必须全覆盖。每一笔联机交易从接入层进入时就生成一个全局唯一的 TraceId然后通过日志框架自动注入到所有下游日志和 MQ 消息里。排查问题的时候输入一个交易流水号就能把这一笔请求在网关、服务层、数据库、外部系统的完整路径全部拉出来。早年间我们用 grep 日志靠时间戳和关键词匹配慢不说还经常找错请求自从上了链路追踪系统排障效率提升了不是一个量级。第二个是监控面板要有“从宏观到微观”的层级。顶层是业务健康度比如交易成功率、交易量、平均响应时间中间层是系统资源比如各应用节点的 CPU、内存、GC、线程池底层是依赖项的健康度比如数据库延迟、消息队列积压、外部系统响应码。任何一个层级出问题都要能逐层下钻直到定位到具体的日志和 SQL。这个层级化的监控面板是我每到一个新团队第一件事就要搭起来的东西。第三个是每次故障都要有复盘和整改。复盘不是为了追责而是为了把故障变成系统演进的需求。我们团队有一条不成文的规定每次线上故障解决后48 小时内必须产出一份故障报告内容包括故障时间线、根因分析、影响范围、修复措施、后续预防计划。并且预防计划里必须至少有一条是“通过架构或基础能力改进而非靠人肉止损”的措施。坚持做下来你会发现同类故障会越来越少系统的韧性是这么一点一点磨出来的。做了这么多年联机交易我最大的体会是这个系统的复杂度不在某一段代码里而在整个链路的相互牵制里。接入层、服务编排、数据存储、批次任务、容灾切换每一块单独拎出来都不算难难的是让它们在几百万 QPS 的冲击下还能像一台精密钟表一样协同运转。文里写的每一个方案、每一组参数都是真金白银的线上事故换回来的。如果你正在搭或者正在优化联机系统我建议你先从幂等和超时管理入手这两个是最不起眼、却最容易出大问题的地方等把基础链路夯实了再逐步推进异步化、弹性伸缩和容灾建设路会稳很多。