我很高兴宣布 Spring Statemachine 3.0.0.M1 的第一个里程碑版本，并且可以说 Statemachine 正在走向响应式编程。

Statemachine 本身不需要是响应式的才能执行，但是一旦机器走出其受控环境以执行用户定义的逻辑（例如 Actions 和 Guards），就无法保证这些功能不会阻塞。

当数据库方面变得更具响应性时，使用持久化功能的数据库用户将受益于响应式更改。 本质上，每次我们需要走出机器世界时，都可能会遇到阻塞的 IO 操作。

2.x 系列将在可预见的未来继续存在，而 3.x 将受益于新的变化。 这实际上取决于用户向 2.x 系列添加多少新功能。

在 2.x 中，机器执行完全基于 Spring TaskExecutor API。 这些执行将机器从一个状态转移到另一个状态。 在此执行过程中，当进入或退出状态时，会执行各种用户级别的 Actions。 Guards 可用于保护各种转换路径，我们无法控制它们的作用。 TaskScheduler API 主要用于触发定时器并在状态中执行 Actions。

由于一切都基于 TaskExecutor 和 TaskScheduler，因此用户能够简单地将它们切换为其他东西，以提供更多的并行执行和调度，这通常在处理需要在并行方式下执行的 statemachine 区域时需要。 所有这些使得内部线程模型相对复杂，并且多年来花费了大量时间来跟踪各种竞争条件。

现在，一切都完全基于 Reactor 及其功能，此内部线程模型变得更加可靠。 我们真的不需要再使用锁定，因为 Reactor 将保证其自身的流程执行可以正常工作。

我们有新的方法可以通过使用 Mono 和 Flux 消息进行交互。 返回的 Flux 具有更丰富的结果，说明特定事件发生了什么。 例如，从返回的 StateMachineEventResult 中，可以检查事件是否被接受或延迟以及哪个区域处理了它。

Flux<StateMachineEventResult<S, E>> sendEvent(Mono<Message<E>> event);
Flux<StateMachineEventResult<S, E>> sendEvents(Flux<Message<E>> events);

在旧的已弃用 API 中，您使用了类似这样的代码

boolean accepted = machine.sendEvent("EVENT");

现在，在您订阅返回的 StateMachineEventResult 的 Flux 之前，什么都不会发生。

Message<String> event = MessageBuilder.withPayload("EVENT").build();

machine.sendEvent(Mono.just(event))
  .doOnComplete(() -> {
    System.out.println("Event handling complete");
  })
  .subscribe();

同样的故事也适用于 actions，它只是一个接受 StateContext 并返回 Mono 的 Function。

public interface ReactiveAction<S, E>
  extends Function<StateContext<S, E>, Mono<Void>> {}

Guard 也是如此，期望您需要使用 Mono 返回一个 Boolean。

public interface ReactiveGuard<S, E>
  extends Function<StateContext<S, E>, Mono<Boolean>> {}

现在是尝试它并为下一个里程碑提供反馈的好时机。 我要感谢所有社区贡献，因为某些重构工作相对繁重。