微服务实战：从单体到分布式架构的演进之路

上一篇文章梳理了 Spring Cloud 各个组件的作用和学习路径。这次想聊聊更实际的问题：当你真正要把一个系统拆成微服务时，具体该怎么做？

我参考了github上面众多老师的 Spring Cloud 实战仓库（https://github.com/yinjihuan/spring-cloud），结合其中的完整项目案例，整理了一套从服务拆分、数据库设计到分布式事务的实战思路。

一、服务拆分：怎么拆才合理

1.1 拆分的核心原则

微服务拆分没有标准答案，但有几个基本原则可以参考：

按业务边界拆分

每个服务对应一个明确的业务领域，比如用户服务、订单服务、商品服务。这样服务之间的职责清晰，团队可以独立开发和部署。

高内聚、低耦合

服务内部的功能紧密相关，服务之间的依赖尽量少。如果两个服务频繁互相调用，可能说明拆分得不够合理。

数据独立性

每个服务应该有自己的数据库，避免多个服务直接操作同一张表。这是微服务和传统 SOA 的重要区别。

1.2 实战项目的服务拆分案例

参考仓库中的房产项目（fangjia-fsh），它的拆分方式如下：

拆分要点：

• 用户服务和房产服务是核心业务，独立拆分

• 认证逻辑抽离成独立服务，避免每个服务重复实现

• API 网关作为统一入口，对外暴露 REST 接口，对内路由到具体服务

二、数据库设计：每个服务一个数据库

2.1 数据库拆分的必要性

微服务架构中，每个服务应该拥有独立的数据库。这样做的好处：

• 服务之间解耦，一个服务的数据库变更不会影响其他服务

• 可以根据服务特点选择不同的数据库类型（MySQL、MongoDB、Redis 等）

• 便于独立扩展，热点服务可以单独做读写分离或分库分表

2.2 读写分离实战

当读请求远多于写请求时，读写分离是常用的优化手段。仓库中的fangjia-sjdbc-read-write模块展示了基于 ShardingJDBC 的实现：

spring: shardingsphere: datasource: names: master, slave master: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/master_db username: root password: 123456 slave: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/slave_db username: root password: 123456 masterslave: name: ms master-data-source-name: master slave-data-source-names: slave

关键点：

• 写操作路由到主库（master）

• 读操作路由到从库（slave）

• 主从同步由 MySQL 自身机制保证

2.3 分库分表实战

当单表数据量过大（通常超过千万级）时，需要考虑分库分表。仓库提供了两个示例：

分表（sharding-table）：同一数据库内，按某个字段将数据分散到多张表

spring: shardingsphere: sharding: tables: t_order: actual-data-nodes: ds0.t_order_${0..9} table-strategy: inline: sharding-column: order_id algorithm-expression: t_order_${order_id % 10}

分库分表（sharding-db-table）：数据分散到多个数据库的多张表

spring: shardingsphere: sharding: default-database-strategy: inline: sharding-column: user_id algorithm-expression: ds${user_id % 2} tables: t_order: actual-data-nodes: ds${0..1}.t_order_${0..9}

分片策略选择：

三、分布式事务：怎么保证数据一致性

3.1 为什么需要分布式事务

微服务架构下，一个业务操作可能涉及多个服务。比如下单操作：

1. 订单服务创建订单

2. 库存服务扣减库存

3. 用户服务扣减余额

这三个操作必须同时成功或同时失败，否则会出现数据不一致。

3.2 分布式事务解决方案对比

3.3 实战：基于可靠消息的分布式事务

仓库中的transaction-mq-service模块实现了一套可靠消息服务，核心思路：

┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 业务服务 │────▶│ 消息服务 │────▶│ 消息队列 │ │ (发起方) │ │ (可靠消息) │ │ (RocketMQ) │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ ▼ ┌─────────────┐ │ 消费服务 │ │ (接收方) │ └─────────────┘

核心流程：

1. 业务服务执行业务操作，同时向消息服务发送预消息

2. 消息服务将消息状态设为"待确认"，返回给业务服务

3. 业务服务执行业务逻辑，成功后调用消息服务确认消息

4. 消息服务将消息投递到 MQ

5. 消费服务消费消息，执行业务操作

消息表设计：

CREATE TABLE transaction_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, message_id VARCHAR(64) NOT NULL UNIQUE, message_body TEXT NOT NULL, destination VARCHAR(255) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0:待发送 1:已发送 2:消费成功 3:消费失败 send_times INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_status_time (status, create_time) );

定时补偿机制：

@Component public class MessageRetryTask { @Scheduled(fixedRate = 60000) // 每分钟执行 public void retry() { // 查询待发送和发送失败的消息 List<TransactionMessage> messages = messageService .findByStatusAndTime(MessageStatus.PENDING, 5); for (TransactionMessage msg : messages) { if (msg.getSendTimes() > 3) { // 超过重试次数，人工介入 msg.setStatus(MessageStatus.FAILED); messageService.update(msg); continue; } // 重新发送 rocketMQTemplate.asyncSend(msg.getDestination(), msg.getMessageBody(), new SendCallback() { @Override public void onSuccess(SendResult sendResult) { msg.setStatus(MessageStatus.SENT); messageService.update(msg); } @Override public void onException(Throwable e) { msg.setSendTimes(msg.getSendTimes() + 1); messageService.update(msg); } }); } } }

关键点：

• 消息先落库再发送，保证消息不丢失

• 定时任务补偿，处理发送失败的消息

• 消费端幂等处理，避免重复消费

• 超过重试次数的消息转入死信队列，人工处理

四、服务间调用安全：怎么防止接口被乱调

4.1 问题背景

微服务内部互相调用时，如果不对调用方进行校验，任何一个服务被攻破，都可能直接调用其他服务的内部接口。

4.2 解决方案：内部认证服务

仓库中的fangjia-auth-service实现了服务间调用的认证机制：

@FeignClient(name = "auth-service") public interface AuthClient { @PostMapping("/auth/token") AuthResponse getToken(@RequestBody AuthRequest request); @PostMapping("/auth/verify") boolean verifyToken(@RequestHeader("Authorization") String token); }

调用流程：

1. 服务 A 调用服务 B 前，先向认证服务申请 Token

2. 服务 A 在请求头中携带 Token 调用服务 B

3. 服务 B 通过拦截器验证 Token 的有效性

4. 验证通过才执行业务逻辑

@Component public class AuthInterceptor implements HandlerInterceptor { @Autowired private AuthClient authClient; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (StringUtils.isEmpty(token)) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); return false; } boolean valid = authClient.verifyToken(token); if (!valid) { response.setStatus(HttpStatus.FORBIDDEN.value()); return false; } return true; } }

五、项目结构组织：怎么放代码才清晰

5.1 多模块项目结构

参考仓库的组织方式，一个完整的微服务项目可以这样分层：

spring-cloud-project/ ├── api-gateway/ # API 网关 ├── service-common/ # 公共模块（工具类、常量、异常定义） ├── service-api/ # Feign 客户端定义（API SDK） ├── service-auth/ # 认证服务 ├── service-user/ # 用户服务 ├── service-order/ # 订单服务 ├── service-message/ # 消息服务（可靠消息） ├── eureka-server/ # 注册中心 ├── config-server/ # 配置中心 └── pom.xml # 父 POM，统一管理依赖版本

5.2 单个服务的内部结构

service-user/ ├── src/ │ ├── main/ │ │ ├── java/ │ │ │ └── com/example/user/ │ │ │ ├── UserApplication.java │ │ │ ├── controller/ # 对外接口层 │ │ │ ├── service/ # 业务逻辑层 │ │ │ ├── mapper/ # 数据访问层 │ │ │ ├── entity/ # 实体类 │ │ │ ├── dto/ # 数据传输对象 │ │ │ ├── config/ # 配置类 │ │ │ └── feign/ # Feign 客户端（调用其他服务） │ │ └── resources/ │ │ ├── application.yml │ │ ├── application-dev.yml │ │ └── mapper/ # MyBatis XML │ └── test/ └── pom.xml

六、写在最后

微服务架构的落地不是一蹴而就的。从单体到微服务，需要考虑：

1. 服务拆分是否合理— 拆得太细会增加调用复杂度，拆得太粗失去微服务的意义

2. 数据库设计— 独立数据库是原则，但数据一致性成为新的挑战

3. 分布式事务— 没有银弹，根据业务特点选择合适的方案

4. 服务安全— 内部调用也需要认证，不能假设内网就是安全的

5. 监控和治理— 服务多了之后，链路追踪、熔断降级、限流等能力必不可少

微服务不是目的，而是手段。不要为了拆分而拆分，根据团队规模和业务复杂度选择合适的架构方案，才是正确的做法。

参考资源：

• 配套源码：https://github.com/yinjihuan/spring-cloud

• 作者博客：http://cxytiandi.com/blogs/yinjihuan

• 第一版书籍：《Spring Cloud微服务-全栈技术与案例解析》

• 第二版书籍：《Spring Cloud微服务 入门 实战与进阶》