从单体到微服务：一场架构进化的实战之旅
背景介绍：为何我们要拆分单体应用？
我第一次接触微服务，是在两年前负责一个电商后台系统的重构工作。当时，我们的系统是一个典型的 Spring Boot 单体应用，前后台分离，部署在一台服务器上。随着业务增长，系统出现了明显的瓶颈：
- 系统响应越来越慢，尤其是促销期间经常出现超时或崩溃
- 功能迭代变得缓慢，每次上线都提心吊胆，小改动容易引发大问题
- 难以横向扩展，数据库连接数和线程数撑不住高并发场景
- 不同团队开发同一个项目，代码冲突频繁，沟通成本越来越高
我们意识到，必须进行架构升级，而微服务是当下最合适的解决方案之一。
不过说实话，一开始我们也不是全盘接受微服务。毕竟，“拆了之后会不会更复杂？”、“分布式带来的一致性、性能等问题怎么解决？”这些问题让我们犹豫了很久。直到我们亲眼看到系统在一个高峰期彻底宕机超过2小时，才下定决心开始这场“拆解之旅”。
拆分前的痛点：真实项目中遇到的问题
我们的系统原本结构如下：
电商平台系统（Spring Boot）
│
├── 用户模块（登录/注册/权限）
├── 商品模块（商品信息/库存/分类）
├── 订单模块（创建/支付/取消）
├── 支付模块（调用第三方支付接口）
└── 后台管理模块（数据分析/配置管理等）
这个结构初看没问题，但实际上已经暴露出以下问题：
- 部署耦合严重：改一个地方就要重跑整个系统
- 数据库共享风险高：所有模块访问同一个 DB，表结构混乱且难以维护
- 资源争用明显：订单和支付功能占用大量线程，其他功能响应变慢
- 测试复杂：每次上线都要回归测试整个系统，耗时长还容易漏测
尤其是一次发布引入了一个商品模块的小 bug，结果导致整个系统无法登录，影响了几个核心流程。那一刻，我们都意识到不能再继续“凑合”了。
技术选型与架构设计思路
为了把这个问题系统改造为微服务架构，我们需要明确以下几个关键点：
1. 划分服务边界
我们采用了业务划分为主的方式，结合领域驱动设计（DDD）理念：
用户服务（User Service）
商品服务（Product Service）
库存服务（Inventory Service）
订单服务（Order Service）
支付服务（Payment Service）
网关服务（API Gateway）
认证授权中心（Auth Center）
每个服务独立运行、独立部署，并通过 REST 或 gRPC 进行通信。
2. 引入注册中心与服务治理
我们选择了 Nacos 作为服务注册中心和配置中心，主要原因有：
- 支持服务注册与发现
- 提供统一的配置管理
- 自带控制台，便于运维查看
- 社区活跃，文档丰富
3. 增加 API 网关处理路由与鉴权
前端请求先经过 Gateway（Spring Cloud Gateway），由它完成以下任务：
- 请求路由转发
- Token 校验与权限控制
- 请求熔断降级
- 流量控制与限流策略
这不仅减轻了各服务的安全负担，也实现了对外暴露统一入口。
4. 数据库拆分与一致性方案
最初我们想“一步到位”，直接做数据迁移。但在实际操作中发现，数据模型之间的依赖太多，很多字段存在冗余或不一致。
于是我们采取了渐进式方式：
- 先做逻辑拆分，按服务划分各自的数据库 Schema
- 对高频访问的数据做缓存（Redis），降低跨服务查询压力
- 使用 Saga 分布式事务模式（后来演进为最终一致性+异步补偿）
5. 日志、监控与链路追踪
微服务最大的挑战不是写代码，而是出问题时怎么定位。
所以我们引入了以下组件：
- ELK（Elasticsearch + Logstash + Kibana） 处理日志聚合
- Prometheus + Grafana 实现服务指标监控
- SkyWalking 实现全链路追踪
这些工具帮助我们在后续上线过程中及时发现并解决问题。
实践过程中的部分关键代码
示例一：Spring Cloud Gateway 的配置文件片段
spring:
cloud:
gateway:
routes:
- id: user-service
uri: lb://user-service
predicates:
- Path=/api/user/**
filters:
- StripPrefix=2
- AuthCheckFilter # 自定义过滤器校验 token
示例二：Feign 客户端调用库存服务的接口定义
@FeignClient(name = "inventory-service", fallback = InventoryServiceFallback.class)
public interface InventoryServiceClient {
@PostMapping("/api/inventory/deduct")
ResponseDTO<Boolean> deductStock(@RequestBody DeductStockRequest request);
}
示例三：使用 Nacos 获取动态配置（Spring Boot + Nacos）
spring:
application:
name: order-service
cloud:
nacos:
config:
server-addr: 192.168.10.10:8848
extension-configs:
- data-id: order-config.json
group: DEFAULT_GROUP
refresh: true
然后在 Java 中通过 @Value 或 @ConfigurationProperties 注入即可。
那些年我们一起踩过的坑
虽然方向明确，但实施过程中还是踩了不少坑：
🐷 坑1：服务间调用超时设置不合理
初期未合理配置 Feign + Ribbon 的超时参数，导致某个服务慢了一点，就引发连锁故障。后来我们统一设置超时时间+熔断机制，比如：
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 1000
ribbon:
ConnectTimeout: 500
ReadTimeout: 800
🐷 坑2：网关鉴权逻辑太重
我们曾经将 token 解密、权限验证等逻辑全部放在网关里，导致网关变成了性能瓶颈。优化方法是只保留 token 验证，具体的权限判断交给后端服务去处理。
🐷 坑3：数据库拆分导致关联查询难
有些报表需求需要跨服务查询数据，但我们不能随意开放数据库权限。最后采用“数据复制+异步拉取”的方式，在某些边缘场景使用 ETL 工具同步部分数据到统计库。
🐷 坑4：缺乏监控预警，事故处理滞后
微服务上线初期，没有完整的监控体系。当服务突然不可用时，只能靠人工逐个查日志。引入 Prometheus + SkyWalking 后，我们设定了多个健康检查指标和报警规则，大大提升了故障恢复速度。
架构升级后的效果对比
改造完成后，我们对两个大促活动做了压测对比（QPS 为每秒请求数）：
| 模块 | 单体架构 QPS | 微服务架构 QPS |
|---|---|---|
| 用户登录 | 320 | 750 |
| 创建订单 | 180 | 450 |
| 查询商品列表 | 400 | 900 |
不仅如此，日常开发效率也有了显著提升：
- 小团队可以独立开发、部署自己的服务
- 发布周期从原来的每周一次缩短到每天可多版本灰度发布
- 故障隔离能力增强，不再“牵一发而动全身”
经验总结与建议
在这趟旅程中，我总结了几条非常实用的经验，希望对你有所帮助：
✅ 1. 微服务不是银弹，不要为了拆分而拆分
如果你的系统功能简单，访问量不大，单体应用可能更适合你。微服务带来的是灵活性，但也意味着更高的运维成本。拆分前先问自己：“我真的需要吗？”
✅ 2. 拆分粒度要合适，初期不宜过细
我们一开始尝试将“订单”进一步拆分为“订单创建服务”、“订单支付服务”，结果发现它们之间交互过于频繁，反而增加了网络开销。后来合并成一个服务，效果更好。
建议遵循原则：高内聚、低耦合；优先按业务功能拆分。
✅ 3. 提前规划好公共能力和中间件
- 统一认证服务、日志中心、监控平台、异常上报平台这些设施要尽早搭建。
- 不然后期各个服务各自搞一套，会很乱，也会浪费大量重复劳动。
✅ 4. 接口设计要慎重，避免频繁变更
微服务之间通过网络通信，接口一旦变更，上下游都需要调整。推荐使用 OpenAPI 规范，制定清晰的接口文档和版本管理策略。
✅ 5. 建议引入 DevOps 文化和自动化流水线
我们使用 Jenkins + Docker + Harbor 构建了 CI/CD 流水线，每个服务的提交、构建、部署自动完成，节省了大量人力，也减少了人为失误。
✅ 6. 性能设计不能忽略，特别是数据库
数据库一定要提前做压力测试。我们有一段时间因为订单服务 DB 没有做好读写分离，导致系统整体卡顿严重。合理的索引、分页、缓存策略至关重要。
写在最后：技术是服务于人的工具
这两年，从最初的焦虑、担心失败，到如今看着系统稳定运行、团队分工明确、新功能快速上线，我觉得一切付出都是值得的。
微服务并不是终点，未来我们也会探索更多架构形态，比如云原生、Serverless 等。但无论如何，技术始终是服务于业务的工具。选择何种架构，还是要根据实际业务需求和团队能力来决定。
如果你也在做类似转型，愿你在拆分的路上少踩坑，多收获。如果有任何问题，欢迎随时交流，我们可以一起成长 💪。
作者：老张
某大型电商平台技术负责人，多年一线架构经验，热爱分享，擅长用通俗语言讲清楚复杂技术。
评论 0