1. 从“能用”到“扛住百亿”架构到底在解决什么问题先亮个底我做过一个互联网金融产品从零开始日交易量从几万涨到几千万笔累计交易额跨过百亿门槛。这段历程最深的体会是——架构不是设计出来的是被业务倒逼出来的。没有哪套方案是提前规划到三年后的所有看起来“高瞻远瞩”的架构本质上都是一次次线上事故和业务痛点推着往前走的。很多人一听到“互联网金融架构”第一反应是分布式、微服务、高并发这些时髦词。但真正经历过从0到1、再到百亿规模的人会告诉你这些只是表象。架构演进的核心其实是在回答三个问题数据怎么放才不丢、请求怎么扛才不挂、业务怎么拆才不乱。这三个问题在不同阶段有不同的答案而所谓“发展史”就是答案不断变化的过程。这篇内容适合三类人看一是正在做金融或类金融系统的技术负责人想了解规模化过程中真正的关键节点二是刚转架构方向、对分布式和微服务只有概念没有体感的后端开发三是想复盘自己系统瓶颈、准备做技术债清理的团队leader。我会按照典型的演进路径把每个阶段的决策逻辑、踩坑过程和实操经验都写出来不铺垫也不绕弯子。提示每个公司的业务形态不同演进路径不会完全一样但底层思路是通用的——先想清楚“这一阶段到底被什么卡住”再选对应的架构方案。2. 阶段一单体架构时代——从0到1的野蛮生长2.1 为什么起步一定是单体应用而不是一步到位几乎所有的金融类项目起步阶段都会选择单体架构这不是保守而是理性。我见过不止一个团队项目刚启动就规划了十几个微服务结果业务还没上线光是服务间联调就耗费了两个月。原因很简单微服务解决的是扩展性和独立部署问题但它在0到1阶段带来的复杂度远大于它解决的问题。单体架构的好处非常朴素开发简单、部署简单、调试简单。一个应用里包含controller、service、dao三层数据存在一个MySQL库里前端连后端后端连数据库整条链路清晰得像白纸。初期团队往往只有五六个人如果五六个人就要维护一套微服务治理体系每个人还要同时关注注册中心、配置中心、链路追踪、网关路由实际上没有人在专心写业务。当时我们选择的方案就是标准的Spring Boot单体应用一个工程、一个数据库、一台应用服务器先跑起来再说。这个阶段的技术选型也不需要复杂把基础件做扎实比什么都重要。MySQL选InnoDB引擎、主从同步配置好Redis做热点数据缓存MQ先不引入一切以“最快速度交付可用的业务”为目标。与其说这是技术决策不如说是生存决策——在业务还没有被验证之前任何过度设计都是在烧钱。2.2 单体架构被迫拆分的三个信号单体架构并非不能支撑一定规模的发展它的问题在于到达某个临界点后所有原本的小问题都会被放大。以我们的实际体感为例有三个非常清晰的信号第一个信号是数据库连接数不够用了。单体应用的所有请求都指向同一个数据库当应用实例从1台扩到3台后连接池的总大小直接决定数据库能扛住的并发量。MySQL默认的连接数上限是151即便调大也受限于服务器资源而且连接数是线性增长的应用一扩容数据库先撑不住。第二个信号是发布越来越痛苦。一个应用里塞进了用户、账户、交易、风控、活动、对账等十几个模块任何小改动都要全量回归测试。初期一次发布30分钟还能接受到后面合并代码要半天联调要一天发布窗口根本排不过来。某个模块出了bug全站跟着一起重启这谁受得了。第三个信号是某个模块的流量开始“绑架”整个系统。典型场景是营销活动——搞一次拉新活动运营发一堆优惠券秒杀流量瞬间打进来交易模块被冲垮用户连登录都登不上。单体架构里不同模块共享一个进程和同一批线程池一个模块的突发流量必然挤占其他模块的资源。这个时候你才意识到拆分不是技术洁癖是被流量活生生逼出来的。2.3 单体阶段必须做好的三件基本功即便后续一定会拆分单体阶段有几件事必须做扎实否则拆分会更加痛苦。第一是数据库设计的规范。字段命名、索引规范、表结构评审这些看似小事后续影响极大。我们在单体阶段维护了一套统一的字段规范如create_time、update_time所有表必须存在这为后续分库分表节省了大量改造时间。另外每个核心表的唯一索引和业务唯一键必须提前想好——金融系统最容易出问题的就是重复支付、重复入账这全靠唯一索引兜底。第二是接口文档和契约管理。单体阶段大家在一个代码库里接口调整影响范围还能通过IDE全局搜索来掌握但拆成服务后跨团队的接口变更就是一场灾难。我们提前养成了用Swagger/OpenAPI管理接口契约的习惯后续服务化改造时接口兼容性问题少了很多。第三是日志规范。从单体阶段就开始做统一的traceId在一次请求中贯穿始终的跟踪ID是整个链路追踪体系的雏形。当时只是为了排查问题时方便grep后来微服务化之后traceId成了全链路追踪的基石这个习惯让我们少走了很多弯路。如果单体阶段不做拆分后再补日志规范的改造成本是极高的。3. 阶段二分布式架构转型——从1到10的架构觉醒3.1 什么样的业务形态决定了什么样的拆分方式网上有很多拆分的“标准方法论”按领域划分、按DDD限界上下文划分等等。但实际做下来互联网金融项目的拆分维度首先必须服从业务风险隔离的需求。比如账户和交易是资金流转的核心链路要做最严格的隔离和冗余用户和营销模块则更偏向流量承接要考虑弹性扩缩容。两种模块的故障影响范围完全不同放在一起是互相伤害。我们当时的第一刀不是按业务域拆而是按“是否涉及资金”拆。所有涉及资金的核心链路开户、充值、交易、提现放到一个独立的“交易核心服务”里所有非资金链路营销、活动、消息通知、用户资料放到另一个应用里。这是最关键的一刀因为资金链路的稳定性和非资金链路的突发流量诉求是相反的——资金链路要的是稳非资金链路要的是快和灵活两者一旦分开各自的侧重点都可以极致地做。拆分后的第一个受益点是发布粒度。非核心服务可以一周发十次版本核心服务保持每周一次甚至两周一次的节奏二者的稳定性指标互不拖累。第二个受益点是故障隔离营销活动把非核心服务打挂了用户登录和交易完全不受影响这是单体时代想都不敢想的。3.2 分布式架构的必经之路服务发现与负载均衡应用拆分之后随之而来的问题是服务之间怎么找到对方单机时代直接配置IP地址就够了但服务多了以后每个服务有多个实例实例还会动态扩缩容这个“位置信息”必须有一个统一的注册中心来维护。主流方案是Nacos或Consul我们选择的是Nacos。原因很实际Nacos在服务发现之外还集成了配置管理一个组件同时解决服务注册和配置下发两个问题对团队规模和运维成本的友好度都更高。注册中心的核心机制是心跳续约——服务实例启动后向注册中心上报自己的IP和端口之后每隔一段时间发送心跳如果多个心跳周期没有收到心跳注册中心就把这个实例标记为不健康并摘除流量。这套机制保证了调用方永远只会把请求发给“活着”的实例。负载均衡策略我们用的是Spring Cloud LoadBalancer默认的ZoneAvoidanceRule在某些情况下会有风险——当某个可用区内所有实例都不可用它可能会把流量转发到另一个区这本身没问题但如果你没有做跨区容灾这个行为可能会掩盖故障。我们后来改成了WeightedResponseTimeRule基于响应时间的权重分配效果更贴近生产实际。3.3 分布式下最大的坑数据一致性该怎么保分布式架构里服务拆开了但数据还在同一个库里矛盾会在第一次跨服务事务出现时彻底暴露。比如用户发起提现交易服务要扣减账户余额通知服务要发送提现短信这两个操作如果分别在两个服务里做一旦扣款成功但短信发送失败用户就会以为没提现成功但钱已经扣了。当时我们面对的第一选择是分布式事务框架比如Seata。但深入了解后发现Seata的AT模式自动补偿事务模式虽然对业务代码侵入小却在性能上有明显代价——每个分支事务都要走全局锁和undolog高并发场景下锁竞争非常剧烈。最终我们定的原则是能避免分布式事务就避免实在避免不了才引入框架。怎么“避免”实际上是改变了业务设计。以提现为例我们把“扣款”和“发通知”从强一致的事务关系改成最终一致——扣款成功后在本地事务里写入一条“待通知”记录由MQ异步通知服务消费这条记录并发送短信如果发送失败就重试重试多次失败则进入人工处理队列。这条链路的核心思想是资金链路必须强一致非资金链路可以最终一致不同的一致性要求决定了你要不要用分布式事务。注意金融系统里资金类操作永远不要依赖“异步补偿”来保证正确性异步只能用于非关键路径。涉及到余额变动和账户流水写入的场景宁可使用数据库本地事务也不要引入跨服务的分布式事务除非万不得已。3.4 分库分表从什么时候开始以及怎么切数据量是分布式架构里最容易忽视的隐形炸弹。单体阶段一个用户表可能只有几十万条数据到业务增长后轻松突破千万、亿级。MySQL单表数据量超过2000万后索引深度增加、查询性能明显下滑这时候就要考虑分库分表了。我们当时用了ShardingSphere-JDBC做分库分表核心策略是按userId做哈希取模分片。2000万之前一张表能扛住到5000万时已经明显感觉到简单查询的延时从几十毫秒涨到了几百毫秒。切分的过程并没有想象的简单——首先是存量数据迁移我们用停机迁移的方式在凌晨低峰期把数据按新的分片规则重新分布其次是全局主键问题单库的auto_increment已经不够用必须换成分布式ID生成方案我们用的是雪花算法改造号段模式确保分片之间不会产生重复主键。分库分表真正考验人的不是技术实现而是查询路由的设计。分片键必须和最常见的查询条件匹配否则一次查询要广播到所有分片去扫描性能比不分片更差。我们业务里最常见的是查用户自己的交易记录所以分片键选了userId这个决策在早期看起来平平无奇却为后续所有按用户的查询提供了性能保障。如果选择订单中心的分片就必须有orderId旁路索引的能力这又是另一种复杂度。4. 阶段三微服务化——从10到100的基础设施重构4.1 微服务不该是“为了微而微”拆分的粒度怎么定很多人对微服务有一个误解以为服务拆得越细越好。实际上服务的粒度不是由代码量决定的而是由“故障爆炸半径”和“团队协作效率”共同决定的。我们拆到第二阶段后一些服务的粒度其实已经变得很不合理比如“用户服务”里既有用户基本信息、又有实名认证、还有用户分层权益三类功能变更频率和稳定性要求完全不同揉在一起谁也别想好好发版。第三阶段我们引入了微服务架构但拆分原则不再是单纯按业务域切而是按“变更频率”和“故障影响范围”切成不同的团队归属。例如实名认证这类涉及外部监管对接、变更频率极低的服务独立成一个服务由专门的合规组维护用户权益这类随运营活动频繁迭代的服务独立成服务由业务组维护。这样的拆分让团队的发布节奏和周报目标都各自清晰。另外也设置了拆分后的红线指标每个微服务必须独立部署、独立数据库或者独立Schema、独立限流指标。在这个阶段的基础设施选型上我建议优先完善以下核心组件服务注册与发现Nacos、API网关Spring Cloud Gateway、配置中心Nacos Config、链路追踪SkyWalking、熔断限流Sentinel、消息队列RocketMQ。这些组件的组装成本不低但每一件都是在业务流量增长过程中“不得不用”的早一点引入比晚一点引入更从容。4.2 API网关流量入口的统一收口微服务化之后所有外部请求不再直接打到业务服务而是统一经过API网关。网关的核心职责有三个路由转发、鉴权认证、流量控制。我们用的是Spring Cloud Gateway它基于WebFlux性能上比传统的Zuul 1.x好很多在高并发下的线程模型优势明显。网关层面有一个经常被忽略的点是协议转换。外部渠道接入方可能用HTTP、HTTPS、TCP长连接等不同协议网关需要统一转换成内部服务间的调用协议。我们遇到过的情况是某个银行渠道只支持XML报文而内部服务都是JSON如果不做网关协议转换每一个对接服务都要维护一套独立的协议解析逻辑这会导致接入成本剧增。在网关统一做了协议适配后新渠道接入从一周缩短到一天。网关的鉴权策略也需要精细化设计。JWT、Token、签名校验、时间戳防重放这些不能只做一层最好是网关做第一层粗粒度鉴权检查token是否有效、签名是否正确服务内部再做细粒度鉴权校验用户权限、商户权限。我们曾经在网关层只做了token校验结果某个内部接口被超权调用好在发现得早后面在服务层补齐了细粒度RBAC权限校验。4.3 配置中心与优雅上下线容易被忽略但极其重要微服务数量上来后配置管理就成了绕不过去的坎。改一个数据库连接地址如果靠人工登录每台服务器去改不仅效率低而且极易漏改或改错。Nacos Config帮我们解决了这个问题——所有配置统一在控制台上维护服务启动时从配置中心拉取同时支持配置变更的实时推送。这在日常变更和紧急降级时都产生了极大的价值。举例来说某个依赖的外部渠道接口出现故障我们需要快速把调用方流量切换到备用渠道这个路由开关如果硬编码在代码里至少要发一次版本才能生效放在配置中心里改一行配置几秒钟内全集群生效这个能力在故障处理时是救命的。另外一个细节是服务的优雅上下线。很多团队上线新版本的方式是直接kill旧进程、启动新进程这在微服务化之后会造成大量请求失败。正确做法是下线前先从注册中心摘除流量Nacos里有“下线”操作等已经转发到当前实例的请求执行完再停止进程启动时先健康检查通过再向注册中心注册自己开始接收流量。如果漏了摘流量这一步发布期间一定会有零星5xx告警而且很随机排查起来极其头疼。5. 阶段四面向百亿规模的高可用与容灾体系5.1 高可用不是“堆机器”而是“控制故障半径”到了百亿规模这个量级系统的高可用不再只是靠某几台机器不挂而是必须接受一个前提故障一定会发生关键是在故障发生时系统怎么表现。一台服务器宕机只是影响某几个实例一个机房断网就得看同城双活的能力一个数据库被误删就得考验备份恢复的速度。我们搭建的高可用体系分为三层。第一层是应用层每个服务至少部署两个实例分布在两个不同的可用区同城双机房当一个可用区故障时注册中心自动把流量切换到另一个可用区的健康实例。第二层是数据层数据库采用主从同步加半同步复制主库出现故障时从库在秒级内提升为新主库。第三层是容灾层定期做全量备份备份数据异地保存确保极端情况下能够在15分钟内恢复核心业务。有一个很容易被忽视的高可用细节是第三方依赖的故障隔离。互联网金融业务要接支付渠道、银行接口、征信服务等大量外部依赖任何一个第三方接口抖动都有可能引发业务线程池被占满进而拖垮整个服务。我们的经验是对所有外部调用强制设置超时时间一般是2-3秒并用线程池隔离或信号量隔离的方式限制某个第三方故障对整体吞吐的影响。5.2 缓存体系设计Redis不光是缓存还是抗流量的第一道防线高并发场景下缓存的作用不仅是加速更重要的是挡流量。如果所有请求都直接打数据库即便分库分表做了数据库的QPS上限依然在几千到几万之间而热点活动流量经常是几万甚至几十万QPS没有缓存根本扛不住。Redis的使用我们分了三层。第一层是本地缓存Caffeine适合读取量极大但变化不频繁的数据如用户基础信息、产品配置信息。第二层是分布式缓存Redis适合跨实例共享的数据如用户账户余额的热点副本、活动库存等。第三层才是数据库。这三层缓存的设计带来了一个明显的效果数据库的读QPS从高峰期的20万降到了3万以内数据库压力大幅缓解。这里要特别提醒一个缓存穿透的问题——用户查询一个不存在的ID每次都打到数据库这就是穿透。我们用了布隆过滤器做前置过滤把所有存在的用户ID加载到布隆过滤器里查不到的请求直接返回空结果不再放行到数据库。另一个是缓存雪崩大量缓存同时过期会导致数据库瞬时被打满所以过期时间一定要加随机因子比如基础过期时间0到300秒的随机值避免集中在同一秒失效。5.3 限流与降级保护系统不被流量冲垮的“最后一根稻草”限流不是限制用户使用而是在流量超出系统承载能力时优先保护核心支付链路。假设系统峰值能扛10万QPS活动流量瞬间到了30万QPS怎么办如果硬扛系统整体雪崩所有人都用不了如果限流至少保住80%的用户体验是正常的。限流算法的选择上我们用的是Sentinel默认支持滑动窗口和令牌桶算法生产环境建议用令牌桶——它允许突发流量但不会让突发无限放大。限流要分维度来设置全局限流总入口QPS、接口级限流某个核心接口的QPS、用户级限流单个用户每秒最多多少次请求、IP级限流防刷。我们曾经漏配了用户级限流结果某次活动被一个用户用脚本刷了几十万次接口导致给该用户推送的权益被重复领取多次损失了一笔不小的资金。降级策略方面需要提前梳理核心链路和非核心链路。比如积分明细查询、历史账单列表这类非关键查询在系统压力大时可以直接降级返回“系统繁忙请稍后重试”但余额查询、交易、提现这类资金操作绝对不允许降级。我们在网关层做了分级降级配置通过配置中心实时切换某个接口的降级策略可以在故障发生时60秒内完成全站保护动作。6. 阶段五可观测性与故障定位体系没有它百亿规模就是个黑盒6.1 全链路追踪从用户点击到数据库SQL的一条线串起来系统从单体变成几十个微服务后最痛苦的事情从“写代码”变成了“排查问题”。一个请求从前端进来经过网关、用户服务、交易服务、账务服务、消息服务最后写到数据库中间任何一个环节慢上几百毫秒整个接口就超时了。如果没有全链路追踪排查这样一个慢请求靠的是各服务各自的日志翻来翻去可能两个小时都找不到根因。我们接入的是SkyWalking核心思路是每个请求在入口生成一个全局唯一的traceId经过每个服务时都把这个traceId透传到调用链的下一环同时记录每一跳的开始时间、结束时间、耗时、状态。排查问题时只需要拿traceId在SkyWalking UI里查看整条链路一眼就能看出耗时在哪个服务、哪个SQL上。6.2 监控告警体系不要等用户投诉才知道系统挂了监控告警的建设我特别想强调两个原则一是告警必须收敛二是告警必须可响应。最开始的告警配置我们几乎给所有指标都加了告警结果告警数量一天上千条团队很快就麻木了真正重要的告警反而不被关心。后来收敛到三个核心维度错误率突增、P99延时超标、核心资源水位CPU、内存、连接数超限。告警渠道也做了分级P0级支付失败、资金异常直接电话值班人P1级发短信P2级只是IM群提醒。还有一个关于业务监控的点是很多人忽略的。技术指标一切正常不代表业务没问题——比如支付渠道成功率下降技术层面完全看不出异常但业务量在掉。我们额外建设了一套业务大盘实时监控订单量、支付成功率、提现成功率、余额变动频次等业务指标技术告警和业务告警分开处理。有一次支付渠道因为银行系统升级导致成功率明显下滑就是业务大盘最先发现异常的。注意金融系统的监控重点不是“基础设施多健康”而是“资金链路是否正常”。一周一次的“对账平账”和实时监控交易成功率是保命的两个关键动作缺一不可。6.3 容量压测与性能基线大战之前的必修课没有压测过的大促都是耍流氓。百亿规模不是一天达成的每次活动前我们都要做一次全链路压测确认系统的真实承载上限。压测不是简单地用JMeter发大量请求而是要在压测环境完整串联网关、服务、缓存、数据库、消息队列的全部链路并且标记好压测数据避免污染生产数据。压测中我们发现过非常经典的性能陷阱。比如某个账户查询接口正常流量下P99只有80ms压测到5倍流量时P99飙升到800ms。排查发现瓶颈在数据库的一个SQL——该SQL有一个字段没走索引平时数据量不大所以没暴露高并发时全表扫描的代价被放大了。这类问题只有压测能发现线上流量是不够的。压测后我们建立了一套性能基线每个核心接口标注P99耗时和最大QPS作为日常发布的性能护栏一旦新版本压测低于基线直接驳回上线。7. 常见问题排查技巧与经验总结7.1 线上问题排查的标准化动作多年的实操下来我把线上问题排查沉淀为四个标准动作先看监控大盘确认影响面再查全链路追踪定位瓶颈服务然后捞traceId关联日志看异常堆栈最后回滚或降级止血。这四个动作的顺序不能乱很多人一出问题就扎进日志里翻是在浪费大把时间。举一个排查慢SQL的例子。某天余额查询接口P99从100ms飙到500ms按照标准动作先在监控大盘里看到影响的是账户服务接着在SkyWalking链路里查到慢在某个数据库查询再拿traceId去数据库慢日志里找到那条SQL最后发现是某个大客户账户的交易流水表没有走索引的大范围扫描。处理方式是把查询SQL从join写法改成子查询并加上覆盖索引P99立刻回到100ms以内。整个过程用了不到30分钟靠的就是标准化流程如果直接去代码里碰运气大概率一小时起步。7.2 演进过程中必须做对的关键决策回头看这段从零到百亿的架构历程有几个决策一旦做错后果会是灾难性的我列成一张表方便对照参考决策点错误做法正确做法理由服务拆分时机业务刚起步就微服务化单体先行出现故障隔离或发布瓶颈后再拆分前期最重要的目标是快速验证业务分库分表分片键按订单号分片但业务查询大多按用户ID按userId分片分片键必须匹配最高频查询缓存过期时间统一固定时间加随机因子防止缓存雪崩分布式事务所有跨服务操作都上Seata按一致性要求区分资金操作本地事务非资金异步最终一致强一致事务性能代价太高第三方调用超时不设超时或超时过长强制2-3秒超时线程池隔离防止外部抖动拖垮自身服务告警配置宁多勿缺收敛分级P0电话P1短信P2群告警多了等于没有告警7.3 人力有限的小团队哪些基础设施值得优先投入如果你所在团队人力并不充裕但业务增长速度很快我建议按优先级投入以下方向第一优先级是数据库的监控和备份恢复金融系统数据不能丢第二优先级是服务注册中心和网关这是所有流量收口的基础第三优先级是全链路追踪没有这套系统微服务化之后你已经无法排查问题了第四优先级才是配置中心和高级的容量压测体系。这四个方向按顺序来每一层都在为上一层打基础跳级投入大概率会变成“工具很重业务很轻”。8. 写在最后架构演进的本质是认知升级我在这个项目里最大的心得是架构永远是为业务服务的不是为了好看的架构图存在的。从单体到分布式、从分布式到微服务、从微服务到高可用容灾体系每一步都是被真实的痛点推着走的。如果你现在正处在单体阶段不要焦虑自己没有微服务如果你正处在微服务化瓶颈期也不必觉得是自己的架构选错了所有百亿规模的系统都走过同样的路。另外分享一个小技巧每次架构调整都建议写一份“架构决策记录”把背景、方案选项、最终选择和原因写清楚。半年后回头再看这些记录你会发现那些当初争论不休的“重大决策”很多都是可以复盘出更优解的。这种记录不仅是对团队的经验沉淀也是下一代技术负责人最宝贵的学习材料。架构这条路没有终点百亿之后还有千亿千亿之后还有国际化、多活容灾、智能化运维。但核心的逻辑不会变把数据保护好、把流量承接住、让业务快速迭代。理解了这个本质无论架构怎么演进你都不会走在方向上。