百亿交易、618日9亿：16年金融架构老兵的踩坑全记录

CSDN 技术博客 · 架构实战 | 16年金融系统经验 | 500人产研团队 | 百亿交易规模 | 618日交易9亿 | JEECG 5K Star

写在前面：这不是概念科普

CSDN 上讲微服务、讲架构演进的文章很多，但大部分有个共同问题——距离生产太远。讲概念的多，讲踩坑的少；讲"该怎么做"的多，讲"当时为什么这么决策"的少。

我在金融科技行当干了16年，从平安科技的寿险系统写起，经手过PICC再保系统，主导过某互金公司（500人产研团队）从单体到微服务到混合云的完整架构演进。这套系统最终支撑了年出借规模超百亿、618司庆日日交易额9亿元、千万级理财用户的业务体量。

这篇文章不聊"什么是微服务"——那种文章搜一搜一大把。我想聊的是：一个真实的百亿级金融交易系统，架构是怎么一步步演过来的，每个阶段踩了什么坑，做了什么决策，为什么这么决策。

适合谁看： 正在做或即将做微服务改造的架构师、技术负责人、3年以上后端开发。如果你正在纠结"要不要拆""怎么拆""拆完怎么管"，这篇文章至少能帮你少走半年弯路。

PHASE 01 · 2010-2014 | 单体时代：金融系统的"大泥球"起步

2010年我入行，在平安科技写寿险系统。那时候的金融系统架构，一句话概括：一个WAR包打天下。

所有功能模块——承保、理赔、保全、收付费——全部塞在一个工程里，部署到几台Tomcat上，前面挂个Nginx做负载均衡，后面连一个Oracle数据库。典型的单体三层架构：表现层（JSP/Struts）→ 业务层（Service）→ 数据访问层（DAO）。

后来在东软带团队做PICC再保系统、车商航保系统，架构形态也差不多。再保系统涉及分保、分批、分摊、超赔临分、账务结算等复杂业务逻辑，但所有代码还是在一个工程里。

单体阶段的痛点

单体不是原罪。在业务早期，它开发快、部署简、测试容易。但当业务量上来后，问题开始集中爆发：

• 全量部署风险高： 改一个理赔模块的Bug，整个系统重新打包部署，重启期间所有业务中断
• 牵一发动全身： 模块间耦合严重，改一处代码，不确定会影响哪些功能，回归测试成本巨大
• 无法独立扩容： 承保模块流量大想加机器，但不可能只部署承保模块，必须整个应用一起扩
• 团队协作瓶颈： 几十个人改同一个代码库，合并冲突、发布协调、代码所有权争夺
• 技术栈锁定： 整个应用绑死在某个技术栈上，想引入新框架/新语言，牵扯太大

教训： 单体可以做，但一定要做好分层和模块边界。我当时做PICC系统基础架构设计时就学到了——分层不是为了好看，是为了以后能拆。 如果单体阶段没有清晰的模块边界，后面拆服务时就像拆墙发现钢筋、水管、电线全缠在一起。

PHASE 02 · 2014-2016 | 基础平台建设：低代码启蒙与ESB时代

2014年底，我加入一家互金公司（以下简称"公司"），负责技术架构。当时公司业务是信贷+理财，日交易量在快速增长，单体架构已经开始扛不住。

第一件事不是拆微服务——而是先把基础平台搭起来。没有基础平台，微服务拆了也是一盘散沙。

// 低代码平台核心模块
UM管理 / 权限管理（Shiro）
统一用户认证（CAS SSO）
流程管理（JBPM 4.4）
数据权限管理
任务管理 / 多线程任务调度
日志管理（Flume + ZooKeeper + RocketMQ + ES）
影像资料管理（FastDFS）
缓存管理（Redis）
代码生成器
REST接口服务管理
IM消息管理
ESB企业服务总线（Mule）

这套平台解决了一个核心问题：各业务系统不再重复造轮子。以前每个系统自己搞权限、搞流程引擎、搞日志收集，现在统一由基础平台提供，业务系统只关注业务逻辑。

ESB时代的尝试与局限

当时用了Mule ESB做服务编排。各业务系统对外暴露REST接口，ESB负责路由、协议转换、编排。这算是SOA的实践——还没有到微服务的粒度，但已经开始服务化。

ESB的好处是统一了入口，但问题也很明显：ESB本身成了单点瓶颈和性能天花板。所有服务调用都经过ESB，一旦ESB出问题，全链路瘫痪。而且ESB的编排逻辑越来越重，维护成本急剧上升。

反思： ESB不是错的，但在高并发金融场景下，中心化的服务编排注定走不远。这为后面下决心做微服务去中心化埋下了伏笔。

图1 · 架构演进四阶段时间轴

2010-2014单体时代平安 · 东软PICC系统Struts/Oracle/Tomcat

2014-2016基础平台低代码 · ESBJBPM/Shiro/CAS

2016-2019微服务化盘古架构体系SpringCloud/Nacos

2019-2021云原生混合云 · 双活K8s/Rancher百亿交易 · 618日9亿架构演进四阶段时间轴

PHASE 03 · 2016-2019 | 微服务化：盘古架构体系的诞生

2016年下半年，业务量迎来爆发式增长。线上获客流量快速攀升，信贷、理财、催收、风控等业务系统的复杂度和并发量都在飙升。单体+ESB的模式已经明显扛不住了。

我向公司提议做微服务改造，组建了架构部，从零规划了一套微服务基础架构体系——内部代号"盘古"。名字取"开天辟地"之意，因为这是公司技术架构从零到一的分水岭。

盘古架构全景

盘古不是一个服务，是一整套微服务基础设施。我把它分成五层：

图2 · 盘古微服务架构体系全景

关键技术决策

1. 为什么选SpringCloud而不是Dubbo？

2016年这个时间点，Dubbo和SpringCloud都在用。我们选SpringCloud的核心原因是：SpringCloud生态更完整，Nacos做注册发现和配置中心一站式搞定，加上SpringBoot的开发体验更好。Dubbo当时还没有完善的治理生态（Sentinel那时还不成熟），而我们金融系统对熔断、限流、降级的要求极高。事实证明这个选择是对的——后面接Sentinel做熔断降级时非常顺滑。

2. 天网监控平台：为什么自己建？

市面上有Pinpoint、CAT、SkyWalking等APM工具，但金融系统对监控的要求不只是"看链路"。我们需要：一分钟发现问题、五分钟定位问题、十分钟解决问题。这要求监控覆盖从基础设施到业务指标的完整链路。天网平台整合了日志（ELK）、指标（Prometheus）、链路追踪、业务大屏、告警链路，是一个一站式监控中枢。

架构决策原则： 能用开源的不自己造，但开源覆盖不了的业务监控需求，一定要自己补。监控是金融系统的生命线，不能有盲区。

3. 微服务拆分的边界怎么定？

这是被问最多的问题。我们的经验：按业务域拆，不按技术层拆。 展业、风控、账务、催收、理财、资产保全——每个业务域一个或几个服务。不按"controller一个服务、service一个服务、dao一个服务"那样拆——那是假微服务，只是把分层变成了远程调用，增加网络开销却没有获得独立部署的好处。

拆分粒度的判断标准：能否独立部署、独立扩容、独立故障隔离。 如果拆出来的服务改一个还得连着改另一个，说明拆错了——边界没切在业务域的正确位置。

HASE 04 · 2019-2021 | 云原生与混合云：百亿交易的底座

微服务化解决了"拆"的问题，但带来了新问题：几十个微服务怎么部署、怎么运维、怎么弹性伸缩？

2019年我们启动了云原生改造，核心做了三件事：

1. 容器化 + K8s编排

所有微服务Docker化，用Rancher管理K8s集群。容器化的核心收益不是"部署快了一点"，而是环境一致性和弹性伸缩能力。

以前裸机部署，开发环境和生产环境不一致的问题能把人逼疯——"在我机器上能跑"这种事在金融系统里是不可接受的。容器化后，开发、测试、生产环境严格一致，消除了90%的环境问题。

更关键的是弹性伸缩。金融交易有明显的时间波动——白天交易高峰要扩容，夜间低谷要缩容。K8s的HPA（Horizontal Pod Autoscaler）配合自定义指标，实现了IT资源10分钟内快速弹性伸缩。这直接降低了30%以上的服务器成本。

2. 两地多中心混合云

金融系统最大的恐惧是数据丢失和服务中断。我们建设了两地多中心的集团金融混合云架构：

• 等保三级合规： 满足金融监管要求的等级保护标准
• 业务系统双活： 不是主备，是真双活——两个数据中心同时承载流量，任一中心故障，另一个秒级接管
• 长城网关： 混合云部署架构下的统一管控、审计、安全出口

双活的核心难点不在基础设施，而在数据一致性。两个数据中心同时写数据库，怎么做数据同步？我们采用的是同步+异步混合方案：核心交易数据双写同步保证强一致，非核心数据异步同步保证性能。

3. DevOps全流程标准化

微服务+容器化后，几十个服务的发布管理是个大工程。我们做了完整的CI/CD流水线：

// DevOps发布流水线
Git提交 → Jenkins自动构建 → Sonar代码质量检查
→ Docker镜像构建 → Harbor镜像仓库
→ K8s滚动发布 → 健康检查 → 流量切换 → 完成

// 关键指标
每周 2次 大版本发布
每次超 10个 系统平滑升级
发布窗口从 4小时 缩短至 30分钟

关键战役：618司庆日9亿交易额的极限挑战

说了这么多架构演进，到底扛不扛得住？讲一个最硬的验证场景。

公司618司庆活动，是全年流量最大的日子。当天千万理财用户涌入，日交易额峰值达到9亿元。这个量级对系统的考验是全方位的——从接入层限流到数据库写入，从消息队列积压到缓存击穿，每一个环节都可能成为雪崩的起点。

618扛住的关键设计

第一道防线：接入层限流。 长城网关在入口做多层限流——IP维度、用户维度、接口维度。超阈值的请求直接拒绝，不让压力传导到后端。

第二道防线：服务降级与熔断。 非核心功能（如推荐、消息推送、数据统计）在高峰期自动降级，把资源让给核心交易链路。Sentinel的熔断规则按RT和异常比例双维度配置，一旦某服务响应变慢或异常率升高，自动熔断隔离。

第三道防线：异步化削峰。 交易请求不是同步处理完所有逻辑，而是核心链路同步（下单→扣款→确认），非核心链路异步（通知→统计→日志）。RocketMQ做消息队列，峰值积压不影响核心交易RT。

第四道防线：数据库分库分表 + 读写分离。 核心交易表按用户ID分库分表，读操作走从库，写操作走主库。配合连接池优化，单库压力降了一个数量级。

618复盘最核心的一条： 限流不是"流量太大限一限"那么简单。限流策略必须在业务可控的前提下设计——哪些用户限、限到什么程度、被限的用户怎么处理（排队vs直接拒绝vs降级提示），每个决策都直接影响业务收入和用户体验。这不是技术问题，是业务+技术的联合决策。

架构演进复盘：四阶段对比

回头看这四个阶段，每个阶段解决的核心问题不同，引入的新问题也不同。架构演进从来不是"越新越好"，而是"当前阶段最痛的问题优先解决"。

关键性能指标变化

这几个数字背后是大量的优化工作：90%的接口性能提升至2秒以内——这不是一两个优化点能做到的，是数据库索引优化、缓存策略调整、SQL重写、连接池配置、JVM调优、服务间调用优化等几十项措施的叠加效果。

超200个日终任务缩短至2小时——原来跑日终批处理要大半夜甚至跨天，优化后2小时内跑完。这直接影响了业务部门看报表的时间窗口和运维的夜间值班压力。

踩过的坑：比成功经验更值钱

坑1：分布式事务的幻觉

微服务拆分后第一个大坑：跨服务的数据一致性。很多人觉得引入Seata/TCC就解决问题了，但实际生产中，强一致性的代价在金融场景下不可接受——TCC的性能损耗在高并发场景下是致命的。

我们最终采用的是最终一致性 + 业务补偿的方案。核心交易走同步调用保证数据落库，非核心走异步消息，跨服务的最终一致性通过对账机制兜底。金融系统不能没有对账——它是最后一道防线。

坑2：过早拆分

不是所有系统都该一上来就拆微服务。我见过一个团队3个人拆了8个微服务——每个服务只有几百行代码，但8个服务的部署、监控、联调成本远大于一个单体应用。

拆分的前提是：业务边界清晰、团队规模够、基础设施到位。 这三个条件差一个，微服务就从"解药"变成"毒药"。

坑3：监控后置

很多团队先拆服务，等出问题了再补监控——这是最常见也最致命的错误。微服务拆完后链路复杂度指数级上升，没有全链路监控，出问题就是黑盒，定位时间从分钟变小时。

天网监控平台是和微服务拆分同步建设的。甚至可以说，先有监控、再拆服务——因为拆完第一天就需要用监控验证拆分效果和健康度。

写在最后：架构师该有的判断

16年走过来，我最大的体会是：架构师的价值不在于选什么技术，而在于在约束条件下做正确的权衡。

每一个架构决策都是trade-off：

• 拆微服务获得独立性，但付出分布式复杂度代价
• 选容器化获得弹性，但付出运维体系建设的代价
• 做双活获得高可用，但付出数据一致性复杂度的代价
• 引入缓存获得性能，但付出缓存一致性问题的代价

没有银弹。架构师的核心能力是：看清当前阶段最痛的问题是什么，选一个代价可承受的方案先解决，把代价留给下一阶段去消化。

这就是"架构演进"的本质——不是一步到位的完美设计，是一系列在正确时间做正确决策的累积。百亿交易系统不是一天建成的，是踩着无数坑一步步演过来的。

如果你正在做架构改造，记住一句话：先把单体做好，再谈拆分；先把监控建好，再谈微服务；先把CI/CD跑通，再谈容器化。顺序错了，每一步都是债。