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年底我加入一家互金公司以下简称公司负责技术架构。当时公司业务是信贷理财日交易量在快速增长单体架构已经开始扛不住。第一件事不是拆微服务——而是先把基础平台搭起来。没有基础平台微服务拆了也是一盘散沙。这套平台解决了一个核心问题各业务系统不再重复造轮子。以前每个系统自己搞权限、搞流程引擎、搞日志收集现在统一由基础平台提供业务系统只关注业务逻辑。ESB时代的尝试与局限当时用了Mule ESB做服务编排。各业务系统对外暴露REST接口ESB负责路由、协议转换、编排。这算是SOA的实践——还没有到微服务的粒度但已经开始服务化。ESB的好处是统一了入口但问题也很明显ESB本身成了单点瓶颈和性能天花板。所有服务调用都经过ESB一旦ESB出问题全链路瘫痪。而且ESB的编排逻辑越来越重维护成本急剧上升。反思ESB不是错的但在高并发金融场景下中心化的服务编排注定走不远。这为后面下决心做微服务去中心化埋下了伏笔。图1 · 架构演进四阶段时间轴2010-2014单体时代平安 · 东软PICC系统Struts/Oracle/Tomcat2014-2016基础平台低代码 · ESBJBPM/Shiro/CAS2016-2019微服务化盘古架构体系SpringCloud/Nacos2019-2021云原生混合云 · 双活K8s/Rancher百亿交易 · 618日9亿架构演进四阶段时间轴PHASE 03 · 2016-2019 | 微服务化盘古架构体系的诞生2016年下半年业务量迎来爆发式增长。线上获客流量快速攀升信贷、理财、催收、风控等业务系统的复杂度和并发量都在飙升。单体ESB的模式已经明显扛不住了。我向公司提议做微服务改造组建了架构部从零规划了一套微服务基础架构体系——内部代号盘古。名字取开天辟地之意因为这是公司技术架构从零到一的分水岭。盘古架构全景盘古不是一个服务是一整套微服务基础设施。我把它分成五层图2 · 盘古微服务架构体系全景关键技术决策1. 为什么选SpringCloud而不是Dubbo2016年这个时间点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的HPAHorizontal Pod Autoscaler配合自定义指标实现了IT资源10分钟内快速弹性伸缩。这直接降低了30%以上的服务器成本。2. 两地多中心混合云金融系统最大的恐惧是数据丢失和服务中断。我们建设了两地多中心的集团金融混合云架构等保三级合规满足金融监管要求的等级保护标准业务系统双活不是主备是真双活——两个数据中心同时承载流量任一中心故障另一个秒级接管长城网关混合云部署架构下的统一管控、审计、安全出口双活的核心难点不在基础设施而在数据一致性。两个数据中心同时写数据库怎么做数据同步我们采用的是同步异步混合方案核心交易数据双写同步保证强一致非核心数据异步同步保证性能。3. DevOps全流程标准化微服务容器化后几十个服务的发布管理是个大工程。我们做了完整的CI/CD流水线关键指标每周 2次 大版本发布每次超 10个 系统平滑升级发布窗口从 4小时 缩短至 30分钟关键战役618司庆日9亿交易额的极限挑战说了这么多架构演进到底扛不扛得住讲一个最硬的验证场景。公司618司庆活动是全年流量最大的日子。当天千万理财用户涌入日交易额峰值达到9亿元。这个量级对系统的考验是全方位的——从接入层限流到数据库写入从消息队列积压到缓存击穿每一个环节都可能成为雪崩的起点。指标数值618日交易额峰值9亿理财用户规模1000万年出借规模百亿618扛住的关键设计第一道防线接入层限流。长城网关在入口做多层限流——IP维度、用户维度、接口维度。超阈值的请求直接拒绝不让压力传导到后端。第二道防线服务降级与熔断。非核心功能如推荐、消息推送、数据统计在高峰期自动降级把资源让给核心交易链路。Sentinel的熔断规则按RT和异常比例双维度配置一旦某服务响应变慢或异常率升高自动熔断隔离。第三道防线异步化削峰。交易请求不是同步处理完所有逻辑而是核心链路同步下单→扣款→确认非核心链路异步通知→统计→日志。RocketMQ做消息队列峰值积压不影响核心交易RT。第四道防线数据库分库分表 读写分离。核心交易表按用户ID分库分表读操作走从库写操作走主库。配合连接池优化单库压力降了一个数量级。618复盘最核心的一条限流不是流量太大限一限那么简单。限流策略必须在业务可控的前提下设计——哪些用户限、限到什么程度、被限的用户怎么处理排队vs直接拒绝vs降级提示每个决策都直接影响业务收入和用户体验。这不是技术问题是业务技术的联合决策。架构演进复盘四阶段对比回头看这四个阶段每个阶段解决的核心问题不同引入的新问题也不同。架构演进从来不是越新越好而是当前阶段最痛的问题优先解决。维度单体阶段基础平台微服务化云原生时间2010-20142014-20162016-20192019-2021核心痛点全量部署·耦合严重重复造轮·ESB瓶颈服务治理·运维复杂弹性伸缩·双活容灾技术栈Struts·Oracle·TomcatJBPM·Shiro·CAS·Mule ESBSpringCloud·Nacos·RocketMQDocker·K8s·Rancher·混合云部署粒度整体WAR包多WAR ESB独立微服务容器化Pod扩展方式垂直复制整体按层拆分按服务独立扩展HPA自动弹性伸缩数据所有权共享数据库共享数据库逐步独立每服务一库·双写故障隔离全局级联部分隔离服务级隔离熔断容器级隔离双活发布频率月/周周按服务独立每周2次·10系统监控能力基础日志FlumeES日志天网全链路天网容器指标双活关键性能指标变化指标数值90%接口响应时间2秒200日终任务完成2小时IT资源弹性伸缩10分钟这几个数字背后是大量的优化工作90%的接口性能提升至2秒以内——这不是一两个优化点能做到的是数据库索引优化、缓存策略调整、SQL重写、连接池配置、JVM调优、服务间调用优化等几十项措施的叠加效果。超200个日终任务缩短至2小时——原来跑日终批处理要大半夜甚至跨天优化后2小时内跑完。这直接影响了业务部门看报表的时间窗口和运维的夜间值班压力。踩过的坑比成功经验更值钱坑1分布式事务的幻觉微服务拆分后第一个大坑跨服务的数据一致性。很多人觉得引入Seata/TCC就解决问题了但实际生产中强一致性的代价在金融场景下不可接受——TCC的性能损耗在高并发场景下是致命的。我们最终采用的是最终一致性 业务补偿的方案。核心交易走同步调用保证数据落库非核心走异步消息跨服务的最终一致性通过对账机制兜底。金融系统不能没有对账——它是最后一道防线。坑2过早拆分不是所有系统都该一上来就拆微服务。我见过一个团队3个人拆了8个微服务——每个服务只有几百行代码但8个服务的部署、监控、联调成本远大于一个单体应用。拆分的前提是业务边界清晰、团队规模够、基础设施到位。这三个条件差一个微服务就从解药变成毒药。坑3监控后置很多团队先拆服务等出问题了再补监控——这是最常见也最致命的错误。微服务拆完后链路复杂度指数级上升没有全链路监控出问题就是黑盒定位时间从分钟变小时。天网监控平台是和微服务拆分同步建设的。甚至可以说先有监控、再拆服务——因为拆完第一天就需要用监控验证拆分效果和健康度。写在最后架构师该有的判断16年走过来我最大的体会是架构师的价值不在于选什么技术而在于在约束条件下做正确的权衡。每一个架构决策都是trade-off拆微服务获得独立性但付出分布式复杂度代价选容器化获得弹性但付出运维体系建设的代价做双活获得高可用但付出数据一致性复杂度的代价引入缓存获得性能但付出缓存一致性问题的代价没有银弹。架构师的核心能力是看清当前阶段最痛的问题是什么选一个代价可承受的方案先解决把代价留给下一阶段去消化。这就是架构演进的本质——不是一步到位的完美设计是一系列在正确时间做正确决策的累积。百亿交易系统不是一天建成的是踩着无数坑一步步演过来的。如果你正在做架构改造记住一句话先把单体做好再谈拆分先把监控建好再谈微服务先把CI/CD跑通再谈容器化。顺序错了每一步都是债。