微服务架构解决了单体应用的扩展瓶颈，但引入了分布式事务、服务治理等新问题。本文以Spring Boot框架为基座，覆盖高并发设计、消息中间件集成和分布式事务处理，提供经过验证的工程方案。
一、微服务拆分原则与Spring Boot项目搭建
微服务拆分的核心原则是”高内聚低耦合”，按业务领域而非技术层划分服务。拆分粒度太粗失去微服务意义，太细则运维成本激增。实操中建议按限界上下文（Bounded Context）拆分，每个服务对应一个业务子域。
Spring Boot 3.x项目标准结构：
order-service/
├── pom.xml
├── src/main/java/com/yunthe/order/
│ ├── OrderApplication.java # 启动类
│ ├── config/ # 配置类
│ ├── controller/ # REST接口层
│ ├── service/ # 业务逻辑层
│ │ └── impl/
│ ├── repository/ # 数据访问层
│ ├── domain/ # 领域模型
│ │ ├── entity/
│ │ ├── dto/
│ │ └── event/
│ ├── client/ # Feign远程调用
│ └── common/ # 公共组件
└── src/main/resources/
├── application.yml
└── mapper/ # MyBatis映射文件API接口规范遵循RESTful风格，统一响应格式：
@RestController
@RequestMapping("/api/v1/orders")
@RequiredArgsConstructor
public class OrderController {
private final OrderService orderService;
@PostMapping
public Result<OrderVO> createOrder(@Valid @RequestBody CreateOrderDTO dto) {
return Result.success(orderService.createOrder(dto));
}
@GetMapping("/{id}")
public Result<OrderVO> getOrder(@PathVariable Long id) {
return Result.success(orderService.getById(id));
}
@GetMapping
public Result<PageResult<OrderVO>> listOrders(
@Valid OrderQueryDTO query,
@RequestParam(defaultValue = "1") int page,
@RequestParam(defaultValue = "20") int size) {
return Result.success(orderService.pageQuery(query, page, size));
}
}
// 统一响应体
@Data
@Schema(description = "统一响应结构")
public class Result<T> {
private int code;
private String message;
private T data;
private long timestamp;
public static <T> Result<T> success(T data) {
Result<T> r = new Result<>();
r.setCode(200);
r.setMessage("success");
r.setData(data);
r.setTimestamp(System.currentTimeMillis());
return r;
}
public static <T> Result<T> error(int code, String message) {
Result<T> r = new Result<>();
r.setCode(code);
r.setMessage(message);
return r;
}
}二、高并发设计：缓存与限流降级
高并发设计的三板斧是缓存、异步、降级。缓存层使用Redis，核心是保证缓存与数据库一致性。推荐延迟双删策略：
// Redis缓存操作 - 延迟双删保证一致性
@Service
@RequiredArgsConstructor
public class ProductCacheService {
private final StringRedisTemplate redisTemplate;
private final ProductMapper productMapper;
private static final long CACHE_TTL = 3600; // 1小时
private static final long DOUBLE_DELETE_DELAY = 500; // 500ms
public Product getProduct(Long id) {
String key = "product:" + id;
String cached = redisTemplate.opsForValue().get(key);
if (cached != null) {
return JSON.parseObject(cached, Product.class);
}
// 缓存未命中 - 查询数据库
Product product = productMapper.selectById(id);
if (product != null) {
// 防止缓存穿透 - 空值也缓存，短TTL
redisTemplate.opsForValue().set(key,
JSON.toJSONString(product),
product.getId() == null ? 60 : CACHE_TTL,
TimeUnit.SECONDS);
}
return product;
}
@Transactional
public void updateProduct(Product product) {
// 第一次删除缓存
String key = "product:" + product.getId();
redisTemplate.delete(key);
// 更新数据库
productMapper.updateById(product);
// 延迟第二次删除（异步执行避免阻塞）
CompletableFuture.runAsync(() -> {
try {
Thread.sleep(DOUBLE_DELETE_DELAY);
redisTemplate.delete(key);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
});
}
}限流使用Sentinel，支持QPS限流、线程数限流和熔断降级。以下为Sentinel资源保护配置：
@Configuration
public class SentinelConfig {
@PostConstruct
public void initRules() {
// 订单创建接口限流: QPS 100
FlowRule orderRule = new FlowRule();
orderRule.setResource("createOrder");
orderRule.setGrade(RuleConstant.FLOW_GRADE_QPS);
orderRule.setCount(100);
// 熔断规则: 慢调用比例阈值0.5, RT阈值200ms
DegradeRule degradeRule = new DegradeRule();
degradeRule.setResource("createOrder");
degradeRule.setGrade(RuleConstant.DEGRADE_GRADE_RT);
degradeRule.setCount(200); // 最大响应时间200ms
degradeRule.setSlowRatioThreshold(0.5);
degradeRule.setTimeWindow(10); // 熔断持续时间10秒
degradeRule.setMinRequestAmount(20);
degradeRule.setStatIntervalMs(1000);
FlowRuleManager.loadRules(List.of(orderRule));
DegradeRuleManager.loadRules(List.of(degradeRule));
}
}三、消息中间件：异步解耦与削峰填谷
消息中间件是高并发场景削峰的关键组件。RabbitMQ适合复杂路由场景，Kafka适合高吞吐日志流，RocketMQ在电商订单场景表现优秀。以RocketMQ处理订单异步流程为例：
// 订单服务 - 发送事务消息
@Service
@RequiredArgsConstructor
public class OrderService {
private final RocketMQTemplate rocketMQTemplate;
private final OrderMapper orderMapper;
@Transactional
public Order createOrder(CreateOrderDTO dto) {
Order order = buildOrder(dto);
orderMapper.insert(order);
// 发送事务消息确保最终一致性
Message<OrderCreatedEvent> message = MessageBuilder
.withPayload(new OrderCreatedEvent(order.getId(), order.getUserId()))
.build();
rocketMQTemplate.sendMessageInTransaction(
"order-topic:created",
message,
order // 传递给本地事务执行器
);
return order;
}
}
// 事务消息监听器 - 本地事务执行+回查
@RocketMQTransactionListener
public class OrderTransactionListener
implements RocketMQLocalTransactionListener {
@Resource
private OrderMapper orderMapper;
@Override
public RocketMQLocalTransactionState executeLocalTransaction(
Message msg, Object arg) {
Order order = (Order) arg;
try {
// 本地事务已在外层@Transactional中执行
// 此处可以做一些附加操作，如扣减库存
return RocketMQLocalTransactionState.COMMIT;
} catch (Exception e) {
return RocketMQLocalTransactionState.ROLLBACK;
}
}
@Override
public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
// 事务回查 - 检查订单是否创建成功
String orderId = msg.getHeaders().get("orderId", String.class);
Order order = orderMapper.selectById(orderId);
return order != null
? RocketMQLocalTransactionState.COMMIT
: RocketMQLocalTransactionState.ROLLBACK;
}
}四、分布式事务：Saga模式实战
分布式事务在微服务架构下不可完全避免。2PC性能差且锁定资源，TCC开发成本高。Saga模式通过补偿事务实现最终一致性，适合长流程业务场景。Seata框架的Saga模式工作流编排方案如下：
// Saga业务流程定义 - 订单创建流程
// 步骤1: 创建订单 - 补偿: 删除订单
// 步骤2: 扣减库存 - 补偿: 恢复库存
// 步骤3: 扣减积分 - 补偿: 恢复积分
// 步骤4: 发送通知 - 补偿: 无（不可补偿操作置于最后）
@RestController
@RequestMapping("/api/v1/saga")
@RequiredArgsConstructor
public class SagaOrderController {
private final SagaCoordinator sagaCoordinator;
@PostMapping("/order")
public Result<String> createOrderSaga(@RequestBody CreateOrderDTO dto) {
String sagaId = sagaCoordinator.start("order-create-saga", Map.of(
"userId", dto.getUserId(),
"productId", dto.getProductId(),
"quantity", dto.getQuantity(),
"totalAmount", dto.getTotalAmount()
));
return Result.success(sagaId);
}
}
// Saga补偿示例 - 库存服务
@Service
public class InventorySagaService {
@SagaAction(name = "deductInventory", compensate = "restoreInventory")
public boolean deductInventory(Long productId, int quantity) {
int rows = inventoryMapper.deductStock(productId, quantity);
if (rows == 0) {
throw new BusinessException("库存不足");
}
return true;
}
@SagaCompensate(forAction = "deductInventory")
public boolean restoreInventory(Long productId, int quantity) {
inventoryMapper.restoreStock(productId, quantity);
return true;
}
}服务治理还包括链路追踪。通过Spring Cloud Sleuth + Zipkin或SkyWalking实现全链路调用追踪，定位跨服务调用延迟瓶颈：
# application.yml - 链路追踪配置
spring:
sleuth:
sampler:
probability: 1.0 # 生产环境建议0.1采样率
propagation:
type: B3 # 使用B3传播协议
zipkin:
base-url: http://zipkin.observability.svc:9411
service:
name: order-service
# 日志格式注入TraceId
logging:
pattern:
level: "%5p [${spring.application.name},%X{traceId:-},%X{spanId:-}]"微服务架构没有银弹。Spring Boot框架提供了丰富的技术组件，但高并发设计需要根据实际业务特点选择性地使用缓存、限流、异步消息等手段。业务中台建设的关键是定义清晰的服务边界和接口契约，分布式事务的处理策略应遵循”能异步不同步，能补偿不锁定”的原则。服务治理是一个持续优化的过程，需配合监控数据和压测结果不断调整阈值和策略。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/wei-fu-wu-jia-gou-fen-bu-shi-shi-wu-shi-zhan-ben-di-xiao-xi/
