几年前我们的系统是一个标准的单体应用一个Spring Boot打成的war包扔进Tomcat连着一个MySQL部署在几台虚拟机上。简单、直接、高效。但业务量涨了十倍团队从5人扩到30人后这个“大泥球”开始让人窒息——改一行代码要全量回归发一次版要停服半小时数据库连接池天天爆满。于是我们踏上了微服务拆分的“不归路”。今天就把这次演进的技术栈变化和踩过的坑完整复盘一遍。单体时代的甜蜜与烦恼单体架构的甜在于开发简单、调用直接、事务好管。但甜头很快被痛苦淹没代码库膨胀到几十万行模块间循环依赖新人上手要三个月每次上线像拆炸弹一个模块的bug能拖垮整个系统更致命的是我们无法针对高并发模块单独扩容只能整体加机器成本飙升。微服务拆分从“大泥球”到“分布式”我们按业务域拆出了用户、订单、商品、支付、库存等八个服务。每个服务独立开发、独立部署、独立数据库。技术栈也随之全面升级服务框架从Spring Boot单体过渡到Spring Cloud Alibaba。Nacos做服务注册发现和配置中心替代了原来的EurekaConfig。网关引入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人全生命周期负责才算真正落地康威定律。总结没有银弹只有取舍微服务不是目的而是应对“大规模团队协作”和“独立部署”的手段。它带来了弹性、可扩展性和技术异构性但也引入了分布式复杂性、数据一致性和运维成本。如果让我重新选一次我会在业务真正需要时才拆先做好模块化再考虑服务化。技术栈的演进不是越新越好而是越匹配团队能力越好。从单体到微服务我们得到的不仅是架构升级更是对“权衡”二字的深刻理解。