好的，没问题。
Spring Modulith：模块化单体应用领域事件发布的事务边界剖析
大家好，今天我们来深入探讨Spring Modulith中领域事件发布时遇到的事务边界问题，以及如何使用ApplicationModuleListener和@TransactionalEventListener来解决这些问题。我们将重点关注在模块化单体架构下，如何确保领域事件的可靠性和一致性。
模块化单体与领域事件
在传统的单体应用中，所有功能模块都紧密耦合在一起。而模块化单体则试图将应用拆分成多个逻辑上独立的模块，每个模块负责特定的业务领域。这种拆分带来诸多好处，例如：
- 更高的可维护性: 模块间的依赖关系更清晰，更容易进行修改和测试。
- 更好的可伸缩性: 可以独立伸缩不同的模块。
- 更快的开发速度: 团队可以并行开发不同的模块。
领域事件是实现模块间解耦的关键机制。一个模块在发生重要的业务变化时，会发布一个领域事件。其他感兴趣的模块可以监听这些事件并作出相应的响应。
例如，一个电商应用可能包含以下模块：
OrderModule: 负责处理订单相关的业务。PaymentModule: 负责处理支付相关的业务。InventoryModule: 负责处理库存相关的业务。CustomerModule: 负责管理客户信息。
当OrderModule创建一个新的订单时，它会发布一个OrderCreatedEvent。PaymentModule监听该事件并开始处理支付，InventoryModule监听该事件并预留库存。
领域事件发布的挑战：事务边界
在单体应用中，领域事件的发布通常与数据库事务密切相关。我们需要确保以下两点：
- 原子性: 如果事件发布失败，数据库事务应该回滚，避免数据不一致。
- 可靠性: 事件必须被成功发布，即使发生临时故障。
在Spring Modulith中，我们主要使用两种方式来处理领域事件：
ApplicationModuleListener: Spring Modulith提供的，模块内部的事件监听器，用于处理模块间的异步通信。@TransactionalEventListener: Spring提供的，基于事务的事件监听器，只有在事务成功提交后才会触发。
这两种机制各有优缺点，我们需要根据具体的业务场景选择合适的方案。
1. 事务边界不清晰的问题
在没有正确处理的情况下，领域事件发布可能导致事务边界不清晰，从而引发数据不一致的问题。以下是一些常见的场景：
- 事件发布早于事务提交: 如果在事务提交之前发布事件，那么其他模块可能会收到一个尚未持久化的数据状态。如果后续事务回滚，那么其他模块基于错误的数据状态执行的操作也会失效。
- 事件发布晚于事务提交: 如果在事务提交之后发布事件，那么可能会出现事件丢失的情况。例如，如果在事务提交之后，但在事件发布之前，应用崩溃，那么其他模块将永远不会收到该事件。
- 事件处理失败，事务未回滚: 假设
OrderModule发布OrderCreatedEvent，PaymentModule监听该事件并处理支付。如果PaymentModule处理支付失败，但是OrderModule的事务已经提交，那么订单已经创建成功，但是支付却失败了，导致数据不一致。
为了解决这些问题，我们需要仔细考虑事件发布的时机和事件处理的可靠性。
2. ApplicationModuleListener的特性与使用
ApplicationModuleListener是Spring Modulith的核心组件之一，它允许我们在模块内部监听并处理事件。ApplicationModuleListener的主要特点包括：
- 异步性: 事件处理通常在独立的线程中执行，不会阻塞事件发布者的事务。
- 模块内部: 事件只能在模块内部发布和监听，不能跨模块使用。
- 简单易用: 使用
@ApplicationModuleListener注解即可注册事件监听器。
// OrderModule
@Service
public class OrderService {
private final ApplicationEventPublisher eventPublisher;
public OrderService(ApplicationEventPublisher eventPublisher) {
this.eventPublisher = eventPublisher;
}
@Transactional
public Order createOrder(Order order) {
// 创建订单
Order savedOrder = orderRepository.save(order);
// 发布订单创建事件
eventPublisher.publishEvent(new OrderCreatedEvent(savedOrder.getId()));
return savedOrder;
}
}
@Component
class OrderEventlistener {
@ApplicationModuleListener
void onOrderCreated(OrderCreatedEvent event) {
System.out.println("Order created with ID: " + event.orderId());
// 在这里处理与订单创建相关的逻辑，例如发送邮件、更新统计信息等
}
}
record OrderCreatedEvent(Long orderId) {}在这个例子中，OrderService在创建订单后，使用ApplicationEventPublisher发布一个OrderCreatedEvent。OrderEventlistener通过@ApplicationModuleListener注解监听该事件，并在独立的线程中执行事件处理逻辑。
ApplicationModuleListener的问题：
由于ApplicationModuleListener是异步的，因此它无法保证事件处理和数据库事务的原子性。如果在OrderEventlistener中发生异常，OrderService的事务已经提交，导致数据不一致。
3. @TransactionalEventListener的特性与使用
@TransactionalEventListener是Spring提供的，基于事务的事件监听器。它允许我们在事务的不同阶段（例如：AFTER_COMMIT、AFTER_ROLLBACK、AFTER_COMPLETION）监听事件。@TransactionalEventListener的主要特点包括：
- 事务感知: 只有在事务成功提交后，才会触发事件监听器。
- 同步性: 事件处理通常在与事件发布者相同的线程中执行，可以保证事务的原子性。
- 灵活的监听时机: 可以选择在事务提交后、回滚后或完成时监听事件。
// OrderModule
@Service
public class OrderService {
private final ApplicationEventPublisher eventPublisher;
public OrderService(ApplicationEventPublisher eventPublisher) {
this.eventPublisher = eventPublisher;
}
@Transactional
public Order createOrder(Order order) {
// 创建订单
Order savedOrder = orderRepository.save(order);
// 发布订单创建事件
eventPublisher.publishEvent(new OrderCreatedEvent(savedOrder.getId()));
return savedOrder;
}
}
@Component
class OrderEventlistener {
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
void onOrderCreated(OrderCreatedEvent event) {
System.out.println("Order created with ID: " + event.orderId());
// 在这里处理与订单创建相关的逻辑，例如发送邮件、更新统计信息等
}
}
record OrderCreatedEvent(Long orderId) {}在这个例子中，OrderEventlistener通过@TransactionalEventListener注解监听OrderCreatedEvent，并且指定phase = TransactionPhase.AFTER_COMMIT，表示只有在OrderService的事务成功提交后，才会执行事件处理逻辑。
@TransactionalEventListener的局限性：
虽然@TransactionalEventListener可以保证事务的原子性，但是它也有一些局限性：
- 同步性: 由于事件处理在与事件发布者相同的线程中执行，因此可能会阻塞事件发布者的事务。
- 跨模块问题:
@TransactionalEventListener通常用于同一个模块内部的事件处理，对于跨模块的事件处理，需要额外的配置。
4. 如何选择合适的事件处理方案
选择合适的事件处理方案取决于具体的业务场景。以下是一些建议：
- 对数据一致性要求高: 如果事件处理必须与数据库事务保持原子性，那么应该使用
@TransactionalEventListener。例如，在创建订单后，必须立即预留库存，那么应该使用@TransactionalEventListener来处理OrderCreatedEvent。 - 对性能要求高: 如果事件处理可以异步执行，并且可以容忍一定程度的数据不一致，那么可以使用
ApplicationModuleListener。例如，在创建订单后，发送一封欢迎邮件，那么可以使用ApplicationModuleListener来处理OrderCreatedEvent。 - 跨模块事件处理: 对于跨模块的事件处理，可以结合使用
ApplicationModuleListener和消息队列。OrderModule使用ApplicationEventPublisher发布事件，PaymentModule监听消息队列中的事件，并执行相应的操作。
为了更清晰地说明，我们可以使用表格来总结这两种方案的优缺点：
| 特性 | ApplicationModuleListener |
@TransactionalEventListener |
|---|---|---|
| 异步性 | 是 | 否 |
| 事务性 | 否 | 是 |
| 监听时机 | 立即 | 事务提交后、回滚后、完成时 |
| 适用场景 | 对数据一致性要求不高，性能要求高 | 对数据一致性要求高 |
| 跨模块事件处理 | 需要结合消息队列 | 需要额外配置 |
5. 跨模块事件处理的策略
在模块化单体应用中，跨模块的事件处理是一个常见的需求。例如，OrderModule需要通知PaymentModule处理支付，InventoryModule需要监听OrderModule的订单创建事件，以便预留库存。
以下是一些跨模块事件处理的策略：
- 消息队列: 使用消息队列（例如：RabbitMQ、Kafka）作为事件传递的媒介。
OrderModule将事件发布到消息队列，PaymentModule和InventoryModule监听消息队列中的事件，并执行相应的操作。 - REST API:
OrderModule通过REST API调用PaymentModule和InventoryModule的接口，通知它们执行相应的操作。 - 共享数据库:
OrderModule将事件信息写入共享数据库的事件表，PaymentModule和InventoryModule定期轮询事件表，并执行相应的操作。
使用消息队列进行跨模块事件处理的例子：
OrderModule:
// OrderModule
@Service
public class OrderService {
private final ApplicationEventPublisher eventPublisher;
public OrderService(ApplicationEventPublisher eventPublisher) {
this.eventPublisher = eventPublisher;
}
@Transactional
public Order createOrder(Order order) {
// 创建订单
Order savedOrder = orderRepository.save(order);
// 发布订单创建事件到消息队列
eventPublisher.publishEvent(new OrderCreatedEvent(savedOrder.getId()));
return savedOrder;
}
}
@Component
class OrderEventlistener {
private final KafkaTemplate<String, OrderCreatedEvent> kafkaTemplate;
public OrderEventlistener(KafkaTemplate<String, OrderCreatedEvent> kafkaTemplate) {
this.kafkaTemplate = kafkaTemplate;
}
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
void onOrderCreated(OrderCreatedEvent event) {
System.out.println("Order created with ID: " + event.orderId());
// 发布事件到 Kafka 主题
kafkaTemplate.send("order-created-topic", event);
}
}
record OrderCreatedEvent(Long orderId) {}在这个例子中，OrderModule使用KafkaTemplate将OrderCreatedEvent发布到名为order-created-topic的Kafka主题。@TransactionalEventListener确保只有在订单创建事务成功提交后，才会发布事件。
PaymentModule:
// PaymentModule
@Service
public class PaymentService {
@KafkaListener(topics = "order-created-topic", groupId = "payment-group")
public void processOrderCreatedEvent(OrderCreatedEvent event) {
System.out.println("PaymentModule received OrderCreatedEvent with ID: " + event.orderId());
// 处理支付逻辑
processPayment(event.orderId());
}
@Transactional
public void processPayment(Long orderId) {
// 模拟支付处理
System.out.println("Processing payment for order ID: " + orderId);
// ... 支付处理逻辑 ...
}
}
record OrderCreatedEvent(Long orderId) {}PaymentModule使用@KafkaListener注解监听order-created-topic主题，并使用processOrderCreatedEvent方法处理OrderCreatedEvent。
可靠性保证：
为了保证消息的可靠性，可以使用以下策略：
- 事务性消息: Kafka支持事务性消息，可以保证消息的原子性。如果发送消息的事务回滚，那么消息也会被回滚。
- 幂等性: 确保事件处理逻辑是幂等的，即多次处理同一个事件不会产生副作用。
- 死信队列: 将处理失败的消息发送到死信队列，以便后续进行分析和处理。
6. 最佳实践
在Spring Modulith中，以下是一些关于领域事件发布的最佳实践：
- 明确事务边界: 仔细考虑事件发布的时机和事件处理的可靠性，确保事务边界清晰。
- 选择合适的事件处理方案: 根据具体的业务场景选择
ApplicationModuleListener或@TransactionalEventListener。 - 使用消息队列进行跨模块事件处理: 使用消息队列可以实现模块间的解耦，并提高系统的可伸缩性和可靠性。
- 保证消息的可靠性: 使用事务性消息、幂等性处理和死信队列等策略，确保消息的可靠性。
- 监控和日志: 监控事件的发布和处理情况，并记录详细的日志，以便进行故障排除。
7. 代码示例总结：
以下代码展现了一个简单的使用ApplicationModuleListener和@TransactionalEventListener的组合示例，来确保在不同的场景下，订单创建事件的正确处理。
//OrderModule
@Service
public class OrderService {
private final ApplicationEventPublisher eventPublisher;
public OrderService(ApplicationEventPublisher eventPublisher) {
this.eventPublisher = eventPublisher;
}
@Transactional
public Order createOrder(Order order) {
// 创建订单
Order savedOrder = orderRepository.save(order);
// 发布订单创建事件
eventPublisher.publishEvent(new OrderCreatedEvent(savedOrder.getId()));
return savedOrder;
}
@Transactional
public void updateOrder(Long orderId) {
// 更新订单
Order order = orderRepository.findById(orderId).orElseThrow(() -> new RuntimeException("Order not found"));
order.setStatus("SHIPPED");
orderRepository.save(order);
// 发布订单发货事件
eventPublisher.publishEvent(new OrderShippedEvent(orderId));
}
}
@Component
class OrderEventListeners {
private final KafkaTemplate<String, Object> kafkaTemplate; // 假设使用Kafka
public OrderEventListeners(KafkaTemplate<String, Object> kafkaTemplate) {
this.kafkaTemplate = kafkaTemplate;
}
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleOrderCreatedEvent(OrderCreatedEvent event) {
System.out.println("Transactional: Order created with ID: " + event.orderId());
// 重要业务逻辑，例如：通知支付系统
kafkaTemplate.send("order-created-topic", event); //发送到消息队列
}
@ApplicationModuleListener
public void handleOrderShippedEvent(OrderShippedEvent event) {
System.out.println("Async: Order shipped with ID: " + event.orderId());
// 非重要业务逻辑，例如：发送通知邮件
sendShippingNotification(event.orderId());
}
private void sendShippingNotification(Long orderId) {
// 模拟发送邮件
System.out.println("Sending shipping notification for order ID: " + orderId);
}
}
record OrderCreatedEvent(Long orderId) {}
record OrderShippedEvent(Long orderId) {}在此代码中：
OrderCreatedEvent使用@TransactionalEventListener进行处理。 这个是比较关键的事件,只有在事务成功提交后才发送到Kafka队列中，确保数据的一致性。OrderShippedEvent使用@ApplicationModuleListener进行处理。这是一个非关键的事件，允许异步处理，提高性能。
领域事件是解耦利器，小心使用，合理选择
通过以上讨论，我们了解了Spring Modulith中领域事件发布的事务边界问题，以及如何使用ApplicationModuleListener和@TransactionalEventListener来解决这些问题。选择合适的事件处理方案，并遵循最佳实践，可以帮助我们构建可靠、可伸缩、易维护的模块化单体应用。