1. 项目概述为什么印尼征信服务必须做同城双活ADVANCE.AI把旗下印尼征信服务CBI做成了同城双活架构可用性指标直接拉到99.95%。这事放在东南亚金融科技圈分量不小——因为“业内首家”这四个字意味着没有任何现成模板可以抄整个方案从架构选型到切换演练都得自己趟出一条路。先拆一下这个成色的含金量。99.95%的可用性换算成年停机时间是4.38小时单月停机不超过21.6分钟。听起来好像不多但征信服务有个特殊性它是风控链路的前置依赖下游信贷机构做一次放款审批要调它做一次贷后管理也要调它它每挂一分钟所有下游客户的业务都在裸奔。更关键的是印尼的国情——雅加达常年面临水灾、电力波动、光纤中断数据中心的物理环境谈不上多可靠。在这样的条件下做到4.38小时/年的停机等于把每个环节的冗余都榨干了。再说同城双活这个概念本身。很多人一听双活以为是两套机房平时各跑各的、出故障时切一下就行这是误解。真正的双活是任意一个机房挂掉另一个机房能无缝接管全部流量用户无感知业务不中断数据不丢。也就是说两套系统同时对外提供服务同时承载读写流量任何一边宕机另一边平滑顶上。这和传统的“主备模式”有本质区别主备模式还有个致命问题备机长期空转切换的时候往往发现配置不一致、数据不同步、脚本跑不通轻则切换失败重则数据损坏。征信业务对双活的要求比普通互联网应用更苛刻原因有二。第一征信查询是强一致性场景用户A查了某人的信用报告这一笔记录必须立刻生效下游机构基于这个结果做授信决策如果双活架构成异步复制导致数据滞后可能出现同一身份证号在不同机房查到不同结果这是业务事故。第二征信服务涉及敏感个人数据合规要求高数据在两个机房之间的流动必须满足当地监管对数据驻留和安全性的要求不能随便找个公网通道就复制数据。所以ADVANCE.AI做这件事的难度不只在技术本身还在于要在金融监管、数据合规、业务连续性和基础设施约束之间找到一个平衡点。这篇文章想聊的就是这套架构背后的设计思路、实施细节、以及那些只有真正扛过线上故障才能总结出来的经验和教训给同样在东南亚做金融基础设施的人一个参考。2. 方案选型与架构设计同城双活不是堆机器是设计取舍2.1 先搞清楚“同城双活”到底要解决什么问题在进入架构细节之前得先把账算清楚。同城双活的容灾目标不是“尽量少挂”而是“挂了也不影响业务”。围绕这个目标核心要解决三个问题数据怎么在两个机房之间保持一致并且切换时不丢数据、不产生脏数据流量怎么在两个机房之间分配并且切换时做到用户无感知故障发生时怎么快速判断、快速决策并且自动完成切换。这三个问题对应到架构上分别是存储层的高可用方案、接入层的流量调度方案、以及运维层的故障响应方案。很多人设计同城双活一上来就纠结数据库用什么复制技术其实接入层的流量调度和故障响应机制如果没想清楚数据库做得再好也白搭。ADVANCE.AI的CBI征信服务在印尼的部署有一个天然的优势条件——机房物理距离足够近。同城双活最怕的不是技术复杂而是两个机房之间的网络延迟太高。数据中心之间光缆的往返延迟如果超过5毫秒数据库同步就会面临很大的性能压力应用层做分布式事务也会变得非常吃力。所以在方案选型的第一个关口就是确认两个机房之间的物理距离和网络延迟是否在可接受范围内。从公开信息看这套方案选择了同城两个可用区AZ部署中间用高带宽低延迟的光纤互联。只有在网络延迟和带宽都达标的前提下后面的数据同步和流量调度方案才有生存空间。这是所有同城双活项目的第一步没这个基础谈什么都白搭。2.2 架构分层接入层、应用层、数据层各自怎么做这套同城双活架构从下到上可分为三层每层的设计侧重点完全不同接入层负责流量调度核心思考是“用户请求从哪个入口进来怎么分发到两个机房”。ADVANCE.AI的选择是部署全局负载均衡GSLB同时在两个机房的入口各部署一套本地负载均衡SLB。正常情况下两边的流量比例可以按需调配比如5:5或者6:4都行关键指标是“活性”——即每个机房都能实时感知到自己的健康状态一旦异常GSLB应在秒级内把流量切到健康机房。应用层负责业务逻辑处理核心思考是“应用实例部署在哪怎么做到无状态化”。无状态化是双活架构的基本功如果应用本地存了会话、存了临时文件一旦流量切换到另一个机房这些状态就丢了用户请求就会报错。ADVANCE.AI把会话统一放到分布式缓存里应用实例本身不保存业务状态任何机房的应用实例都能处理来自任何地方的请求。这一层听着简单实际改造中最耗时间因为很多存量代码里藏着各种静态变量、本地缓存、文件读写都得逐一清理干净才能谈双活。数据层负责数据读写核心思考是“数据在两个机房之间怎么同步怎么保证强一致”。这一层是整个双活架构中最复杂、风险最高、实施难度最大的部分。CBI征信服务的数据特性是读多写少但写入后的数据必须立即生效。ADVANCE.AI在这里采用了数据库同步 缓存双写的策略正常运行时两个机房同时承担读写流量关键业务数据在两个机房之间实时同步缓存层的数据也通过同步机制保持最终一致。切换时通过分布式锁和事务补偿机制保证数据不出问题。这个分层架构的逻辑我在实际项目中验证过很多次接入层解决的是“用户能不能进来”的问题应用层解决的是“进来之后能不能处理”的问题数据层解决的是“处理完数据对不对”的问题。三层各自闭环每一层都有自己的健康检查、故障切换和自愈机制这样才不会出现“机房都挂了监控还没发现”“监控发现了但不知道切哪边”的尴尬局面。2.3 为什么99.95%是“够用就好”不是“越高越好”99.95%的可用性意味着每年4.38小时的停机时间。很多人会问为什么不直接做到99.99%这样每年只有52分钟的停机时间不是更稳妥吗这里涉及一个关键的成本收益权衡。可用性从99.9%提升到99.95%需要多做的投入已经非常可观——比如两套独立的冗余链路、更高规格的监控告警系统、更频繁的故障演练等等。但如果要再往上冲99.99%光靠同城双活就不够了你得引入异地灾备甚至是三地多活的架构这涉及数据跨区域复制的延迟、监管合规对数据出境的限制、以及成倍增加的基础设施成本。对于征信服务来说4.38小时的年停机时间只要分布在业务低谷期对下游客户的实际影响是可控的。所以99.95%这个数字不是拍脑袋定的而是基于业务容忍度和成本曲线做的一个理性选择。另外一个细节是99.95%这个数字不是一个预测值而是一个设计目标。要达到它单机房本身的可用性必须在99.99%以上——因为双活的逻辑是单机房故障时另一个机房必须接管但如果单机房自己都不能保证高可用双活就只能兜个底每次切换都有失败风险。所以ADVANCE.AI在每个单机房内部也做了完整的冗余设计双电源、双上联、负载均衡集群、数据库主从所有关键组件都没有单点。这些底层的“隐性投入”才是99.95%的真正支撑。3. 核心实施细节与实操要点流量调度、数据同步、切换演练三板斧3.1 流量调度怎么设计才能让用户无感知流量调度是整个双活架构的门面。用户发起一次征信查询第一步走到哪里决定了后面所有的逻辑。ADVANCE.AI在接入层做了这么几个关键动作DNS层面的GSLB调度。征信服务的接口调用方大多是下游金融机构的服务器不是普通用户所以DNS解析的结果相对稳定。GSLB会根据两个机房的健康状态和负载情况动态返回不同的IP地址。正常情况下两边各承担一半流量如果某一边出现异常GSLB会在DNS的TTL存活时间范围之内把全部流量切到另一边。这里有一个容易被忽视的点TTL设太短DNS请求频率会很高增加解析压力和成本TTL设太长切换后客户端的解析缓存过期慢会有一段“流量还在往坏机房走”的窗口期。ADVANCE.AI的实践是把TTL压在30到60秒之间在成本和切换速度之间取平衡。机房内部的SLB健康检查。GSLB负责跨机房调度但单机房内部的流量分发由机房入口的SLB完成。SLB会对后端的应用实例做应用层健康检查不是简单的Ping而是发一个真实的业务探测请求比如查一次模拟数据。只有健康检查正常流量才会分到这个实例上。这个细节非常关键——如果只做TCP层的存活探测应用进程还活着但数据库连接池已经耗尽的情况就探测不到流量照样进来用户看到的还是超时。会话保持策略。征信查询请求通常是短连接一个请求进来、返回结果、连接关闭。但下游机构的安全策略可能需要上传一些上下文信息比如用户身份凭证、设备指纹等。如果这些信息存在某个机房的本地会话里切换时就全丢了。ADVANCE.AI的解法是把会话统一收口到分布式缓存集群两个机房共享访问同时把缓存的Key设计成包含用户标识保证同一用户的所有请求都能命中同一份缓存数据。这样即使连接从A机房切换到B机房用户的上下文信息还在。这里分享一个实操中的坑会话数据放到共享缓存之后一定要注意缓存的序列化兼容性。我们曾经在升级缓存客户端版本时没有注意新旧版本的序列化格式差异导致线上部分用户的会话数据读出来是乱码排查了很久才发现是新老版本不兼容。从这之后我养成了一个习惯缓存数据结构变更和客户端升级必须先做向后兼容测试新旧版本同时线上跑一段时间再逐步淘汰老版本。3.2 数据同步征信服务的强一致性和容灾的平衡数据同步是双活架构里最复杂、最容易出事的一环。征信服务的数据特征是强一致要求高、读多写少、单笔数据体量小、峰值QPS集中在工作日的白天时段。为了满足这些特征ADVANCE.AI在数据层做了这样几个设计数据库层采用同步复制机制。在两个机房的核心数据库之间建立同步复制关系主营业务数据的写入请求要同时提交到两个机房才算成功任何一边写失败整个事务回滚。这样设计的好处是任何一个机房发生故障另一个机房的数据已经是完整且一致的不需要再做数据补齐或回放切换时几乎没有数据丢失的风险。代价是两次写入的延迟叠加事务耗时比单机房模式多了约一倍。为了缓解这个延迟应用层做了批量提交和异步化改造把一些不要求实时一致的操作比如日志记录、非核心维度信息的更新剥离出主事务只保证主数据的强一致。缓存层采用双写加对比校验。征信查询的路径上大量的读请求是走缓存的用来降低数据库压力。双活模式下缓存写操作需要同步到两个机房否则会出现“用户在A机房写了缓存切到B机房后缓存没命中穿透到数据库”的问题。穿透本身不影响正确性但高峰期大量穿透会把数据库打爆。ADVANCE.AI的缓存同步策略是写操作同时写入两个机房的缓存集群如果某一侧的写入失败记录下来做异步补偿同时触发一次数据库兜底查询确保用户请求不报错。同时定期对两个机房的缓存数据做抽样对比发现差异立即修复。幂等设计是不可或缺的前提。这是数据同步中最容易被低估的一环。在双活架构下同一个请求可能因为网络重试、SDK超时重发、或者切换瞬间的双写操作在系统里被处理多次。如果下游系统没有做幂等处理就会出现重复扣款、重复授信、重复写入征信记录这类严重事故。ADVANCE.AI的处理方式是所有关键写操作都带一个全局唯一的请求ID服务端根据这个ID做去重同一个ID只处理一次重复请求直接返回第一次处理的结果。这个看似简单的设计实际是整个数据一致性的最后一道保险。健康检查除了应用层的业务探测数据库同步链路本身也要有独立的健康检查机制。ADVANCE.AI的做法是建立一条旁路监控每秒钟向主数据库写入一条心跳记录通过同步链路复制到备机房然后在备机房里检查这条记录的到达时间。延迟超过阈值就报警持续超过一定时间就自动触发切换流程。这个心跳记录不只是检测链路用的还顺手把时间戳写进去用来精确计算同步延迟。3.3 切换演练把“敢不敢切”变成“会不会切”绝大多数双活项目翻车不是死在技术实现上而是死在“平时不演练真到故障时不敢切、不会切、切了又切不回来”。ADVANCE.AI在CBI双活项目上线后建立了一套常态化的切换演练机制具体做法大概有三条定期进行计划内切换。每季度至少做一次真实的机房切换演练把全量流量从A机房切到B机房运行一段时间再切回来。演练不只是验证技术链路还要验证人的流程——值班工程师是否清楚切换步骤是否能在规定时间内完成操作切换后是否符合预期。刚开始演练的时候肯定会有各种各样的问题暴露出来比如某个下游机构的防火墙还没放行B机房的IP段、某个老客户端的证书只信任A机房的域名等。这些坑在演练中发现总比在真实故障中踩雷好。制造计划外故障。计划内切换是“全须全尾”地切计划外故障演练是“无预警地搞破坏”比如直接拔掉一个机房的电源、把光纤交换机断电、杀掉数据库主进程等。这种演练的目的是检验监控告警是否真的能第一时间发现、自动切换机制是否真的能兜底、人的应急响应是否真的能跟上。ADVANCE.AI最早做这类演练时出现过告警发了但值班人员没有及时响应、自动切换脚本由于某个参数没更新执行失败等状况后来逐一修复才有了现在的切换成功率。演练结果做量化评估。每次演练都记录关键指标从故障发生到发现的时间、从发现到切换完成的时间、切换期间请求失败率、切换后数据一致性校验结果等。这些数据用来看趋势——如果某个指标连续两次演练都在变差就要警惕了。切换演练这块我想多说几句踩坑经验。第一次做真实切换演练时我们的预期是“数据同步没问题切换应该很顺利”结果是切换完成后发现大量请求超时排查了半天发现是SLB的健康检查只探测了应用层但应用实例启动后数据库连接池还没建立好健康检查就返回正常SLB开始放流量前端请求打到这些“半活”实例上自然全线超时。从那以后我们的健康检查里多了一道“依赖就绪检查”只有数据库连接池、缓存连接、消息队列连接全部就绪之后应用才会向健康检查返回正常状态。这个教训之后每次切换演练都会先跑一遍“依赖就绪”检查清单。4. 高可用系统的韧性和工程落地从技术方案到组织能力4.1 高可用不只是技术问题还是组织能力问题99.95% 的可用性是一个技术指标但做到这个指标光靠技术方案是不够的。ADVANCE.AI 在落地双活的过程中同步建设了两样不太起眼、但至关重要的东西监控体系和应急流程。两者分别对应“能发现问题”和“能解决问题”。监控体系的设计逻辑我总结为三条分层、可量化、能预警。分层是指监控从基础设施机房、网络、电源、平台层负载均衡、数据库、缓存、应用层接口QPS、延迟、错误率到业务层征信查询成功率、响应时间分布都有覆盖。可量化是指每个监控项都有明确的阈值和告警等级。能预警是指监控不只是事后发现而是能根据历史数据预测风险——比如数据库连接池的使用率持续升高预测多久会耗尽提前告警。应急流程的成败通常只取决于两个因素响应速度和操作准确性。ADVANCE.AI在双活项目上线时就制定了一套完整的三级响应机制明确每种故障等级由谁负责决策、谁负责执行、谁负责对外沟通。同时他们把切换动作脚本化、自动化把原来需要手工执行的几十个步骤收敛成几个一键操作——但一键操作并不是让值班人员直接点按钮而是每一步都有二次确认、每一步都有回滚预案、每一步都有日志记录。这里分享一个高可用系统建设的核心心法高可用是靠“故意破坏”练出来的。每一次演练都是一次制造的故障系统在一次次故障注入中暴露弱点团队在一次次应急响应中积累经验架构在一次次问题修复后变得更加健壮。不演练的高可用系统只是个“看起来可用”的纸面架构。4.2 回切比切换更难双活最容易翻车的环节做了多年稳定性工作我自己的体会是同城双活最难的环节不是故障时的切换而是故障后的回切。切换是从一个“不健康”的机房切到“健康”的机房目标明确回切是要把流量从“健康”机房再切回“已修复”的机房这个操作有几个天然的难点第一故障机房的修复质量需要充分验证。只验证进程起来了不算修复完成还要验证数据同步是否赶上、缓存是否预热、与下游系统的连接是否恢复、容量是否足以承载流量。第二回切过程中数据一致性的风险更高。切换期间所有业务都在B机房运行A机房可能积累了大量的增量数据回切前必须确保这些增量数据已经全部同步到A机房否则回切后用户会看到陈旧数据。ADVANCE.AI在CBI双活项目中专门设计了一个“数据回放”工具在回切前自动对比两个机房的数据快照跑出差异报告只有确认差异为零或者可接受的范围内才允许执行回切动作。第三回切后的流量验证不能只看指标还要走真实的用户请求。ADVANCE.AI的策略是“灰度回切”先放5%的流量到已修复机房跑一段时间确认新机房状态没有问题再把流量逐步放大到预期比例。我见过不少团队在回切阶段翻车就是因为这个问题——本来想着故障处理完可以松一口气了结果一放松警惕回切操作被当成简单的反向操作来执行草草验证一下就把流量全部打过去结果把刚修好的机房又打挂了。4.3 核心踩坑清单给同样在搞高可用的人一份参考做了那么多年稳定性相关的工作我把高可用系统工程落地过程中反复踩过的坑整理成一份清单供参考用了同步复制忘了评估事务延迟。同步复制模式下数据库事务耗时是单机房的两倍如果应用层有几条链路是串行的、依赖数据库写完成后才能走下一步整个接口的P99延迟会被拉长。解决办法是重新梳理关键链路的依赖关系把串行改并行把非关键步骤异步化。双活切换成功但下游子系统没适配。征信服务不是孤岛它自己还要依赖其他子系统比如身份验证、反欺诈、人工审核等。如果只做了主链路双活但依赖的子系统的调用域名还指向单机房切换后照样会因为跨机房调用延迟增高而失败。所以双活改造必须完整梳理所有依赖关系从入口到出口全链路适配一个都不能漏。只关注了主数据库忽略了从库和缓存。切换后发现主库没问题但从库数据滞后了几秒缓存还是旧数据下游机构查询到了不一致的结果。双活的改造对象是所有数据组件不只是主数据库。监控告警有了但没有告警联动。告警发到群里人没看、没反应等于没有告警。要建立告警升级机制超过一定时长没人响应自动升级到更高一级的负责人。演练成功了一次就认为万事大吉。系统和环境一直在变这个月成功不代表下个月成功。演练必须是常态化机制还要定期引入新的故障场景。5. 写在最后99.95%不是终点是起点CBI同城双活上线后ADVANCE.AI的征信服务可用性达标但在我看来这个项目的真正意义不在于架构本身而是在于它证明了东南亚金融科技基础设施的技术水平可以做到和全球主流云厂商同等的容灾能力。在基础设施条件不那么理想的地区把可用性做到99.95%这个经验本身就有很强的参考价值和复制可能性。就我个人而言经历过多次线上故障和演练之后最深的体会有两点第一高可用系统的建设越早做越好上线后再补成本至少翻三倍第二高可用不是运维一个团队的事而是从架构设计到开发编码、从测试验证到线上运维整个链条共同承担的责任。业务架构师在设计方案时要有双活思维开发人员在写代码时要有状态分离意识测试人员在设计用例时要有故障注入视角运维人员在值班前要能独立完成切换与回切。如果你正在规划类似的双活项目我的建议是先别急着买设备、搭环境先把你的业务核心链路画出来找到那些“断了一环就全线崩溃”的节点再对照文章里的分层思路逐项设计。架构方案有了、关键环节的风险点摸清了、切换与回切流程在演练中验证过了然后再去动工实现一步一个脚印事情自然能成。