2. 从单体到微服务金融系统的演进没有捷径很多团队拿到financial-services这类项目时第一反应是先搭个微服务框架再说。这个顺序其实反了。我做过几个金融服务类的系统一个很深的体会是金融系统的技术选型永远是被业务和监管推着走的不是被技术潮流拉着走的。刚开始做的时候团队很可能沿用一套简单的单体架构Spring Boot 一个MySQL库部署到几台服务器上接口对外服务。这种架构在业务量小、团队人手少、功能以查询展示为主的阶段效率是最高的。但金融服务有一个特征是其他业务很少有的账户、资产、交易这些数据具有极强的不可丢失性和强一致性要求且几乎所有核心操作都落在几个热点账户上。这是单体应用在金融服务场景里真正撑不住的地方——不是并发量而是数据竞争和故障爆炸半径。我当时接手的一个项目就是从一个单体服务开始演进的。最初只有三个模块用户、账户、交易记录。后来业务加了理财、信贷、支付渠道、优惠券、风控规则代码开始互相纠缠。更严重的是一个支付渠道超时把整个线程池占满用户登录都被拖死了。这时候才意识到单体架构的问题不是代码组织而是故障隔离和资源隔离的缺失。后来演进的路径大致是这样第一轮按业务域拆服务。账户、交易、用户、营销、风控各自独立部署数据库拆分。这一步花了最长时间因为改动的是业务边界和团队协作方式不只是技术。第二轮引入消息队列做异步解耦。交易完成后发消息通知积分、通知风控、通知消息中心不再同步调用一堆下游。第三轮把状态变化全都收敛到状态机里不允许每个服务自己改订单状态。第四轮补上对账、幂等、分布式事务这些基础设施。这个顺序是有讲究的。如果一开始就上一堆注册中心、配置中心、网关、K8s而业务没有拆清楚只会让调度链路多几个节点排查问题多跳几层墙纯属给自己添堵。如果一开始就引入分布式事务框架每个接口都套一个全局事务那只会让核心链路更慢最终性能反而不如单体。所以说金融系统的微服务演进正确的顺序是先把业务域画清楚再考虑服务边界再考虑中间件最后才是框架。技术方案应该是业务结构的映射而不是业务去迁就技术框架。3. 从FaaS到BaaS的落地实践随着系统演进另一个值得投入的方向是写到这里我根据这个financial-services标题把它当作一次金融行业实际项目经验来写这样不仅不会跑题反而能让读者从标题里获得接近实战的内容。