几年前，我们的系统是一个标准的单体应用：一个Spring Boot打成的war包，扔进Tomcat，连着一个MySQL，部署在几台虚拟机上。简单、直接、高效。但业务量涨了十倍，团队从5人扩到30人后，这个“大泥球”开始让人窒息——改一行代码要全量回归，发一次版要停服半小时，数据库连接池天天爆满。
于是，我们踏上了微服务拆分的“不归路”。今天就把这次演进的技术栈变化和踩过的坑，完整复盘一遍。
单体时代的甜蜜与烦恼
单体架构的甜，在于开发简单、调用直接、事务好管。但甜头很快被痛苦淹没：代码库膨胀到几十万行，模块间循环依赖，新人上手要三个月；每次上线像拆炸弹，一个模块的bug能拖垮整个系统；更致命的是，我们无法针对高并发模块单独扩容，只能整体加机器，成本飙升。
微服务拆分：从“大泥球”到“分布式”
我们按业务域拆出了用户、订单、商品、支付、库存等八个服务。每个服务独立开发、独立部署、独立数据库。技术栈也随之全面升级：
服务框架：从Spring Boot单体，过渡到Spring Cloud Alibaba。Nacos做服务注册发现和配置中心，替代了原来的Eureka+Config。
网关：引入Spring Cloud Gateway，统一鉴权、限流、路由，前端不再直接调用后端服务。
服务调用：OpenFeign声明式调用，配合Sentinel做熔断降级，防止雪崩。
数据库：每个服务独立MySQL实例，通过ShardingSphere分库分表。跨服务查询改用API组合，不再用JOIN。
消息队列：引入RocketMQ处理异步解耦，比如订单创建后发消息通知库存扣减和积分增加。
链路追踪：Sleuth + Zipkin，后来换成SkyWalking，终于能看清一个请求跨了哪些服务、耗时多少。
容器化：Docker打包，K8s编排，配合Jenkins Pipeline实现滚动发布。
复盘：踩过的坑与反思
坑一：拆分粒度过细。一开始追求“小”，把用户拆成注册、登录、信息三个服务，结果一个查询要跨三次调用，延迟翻倍。后来合并为“用户服务”，边界围绕业务能力而非技术分层。
坑二：分布式事务想得太简单。订单扣库存，用Saga补偿，结果补偿逻辑比正向还复杂，消息重复消费导致库存扣两次。最后改成“本地消息表+定时对账”，牺牲强一致换可用性。
坑三：运维复杂度指数级上升。服务从1个变8个，日志散落各处，排查问题像大海捞针。直到上了ELK和SkyWalking，才把可观测性补齐。但K8s的学习曲线，让运维团队脱了一层皮。
坑四：团队组织没跟上。服务拆了，但人还是一个大组，改一个接口要协调三个服务。后来按服务划分小组，每个组6-8人，全生命周期负责，才算真正落地康威定律。
总结：没有银弹，只有取舍
微服务不是目的，而是应对“大规模团队协作”和“独立部署”的手段。它带来了弹性、可扩展性和技术异构性，但也引入了分布式复杂性、数据一致性和运维成本。
如果让我重新选一次，我会在业务真正需要时才拆，先做好模块化，再考虑服务化。技术栈的演进不是越新越好，而是越匹配团队能力越好。从单体到微服务，我们得到的不仅是架构升级，更是对“权衡”二字的深刻理解。
