我们很高兴地宣布 Spring Statemachine 1.0.0.RC1 的第一个候选版本。
此版本的重点是使核心框架更加稳定，并最终为分布式状态机添加 jepsen 测试。我们还添加了第一个版本的测试支持。可以从
RC1 问题
中找到已解决的 github 票证。我们相对接近发布发布版本，这意味着如果没有重大弹出窗口，下一个版本将是
1.0.0.RELEASE
。如果出现紧急情况，我们将在发布前执行
1.0.0.RC2
。
说到这里，让我们破解它，看看我们在这个版本中有什么新特性。
除了通常的错误修复之外，这里还列出了主要的新功能：
- 测试支持
- Jepsen 测试分布式状态机
测试支持
测试状态机并不是最容易完成的任务，因此我们引入了新的
spring-statemachine-test
模块，它将简化为 Spring Statemachine 进行单元测试的过程。由于依赖性，它未在核心系统中使用，但用于
recipes
和
Zookeeper
集成的内容已用于测试这些模块。
在测试中测试一个简单的状态机看起来很简单：
StateMachine<String, String> machine = buildMachine();
StateMachineTestPlan<String, String> plan =
StateMachineTestPlanBuilder.<String, String>builder()
.defaultAwaitTime(2)
.stateMachine(machine)
.step()
.expectStates("SI")
.and()
.step()
.sendEvent("E1")
.expectStateChanged(1)
.expectStates("S1")
.and()
.build();
plan.test();
如果将状态机定义为：
StateMachine<String, String> machine = buildMachine();
StateMachineTestPlan<String, String> plan =
StateMachineTestPlanBuilder.<String, String>builder()
.defaultAwaitTime(2)
.stateMachine(machine)
.step()
.expectStates("SI")
.and()
.step()
.sendEvent("E1")
.expectStateChanged(1)
.expectStates("S1")
.and()
.build();
plan.test();
杰普森测试
我们对在 Zookeeker 中使用分布式状态的支持结果证明相对难以用一组正常的单元测试来测试，因此我们在测试覆盖率上碰壁了。我想利用这一刻来讲述一些关于使用 jepsen 测试分布式系统的事情。
Kyle Kingsbury（又名
@aphyr
）的
Jepsen
测试框架是一个可用于测试分布式系统的系统，具有同步事件发送到节点和导致网络上的大脑分裂等功能。 Jepsen 将成为我们系统的核心，以确保我们的分布式支持能够完成它应该做的事情。这是测试由
Zookeeper
支持的 Spring 分布式状态机的一流系统。
将有一个单独的博客文章，但初步结果可以从我们的参考文档 分布式状态机技术论文 中找到。请继续关注该博客文章！
在这里，我们从我们的 jepsen 测试中窥视一下，以显示当集群遭受分裂导致 zookeeper 整体完全崩溃时会发生什么，以及当网络中断和修复时会发生什么。
在上图中，我们有一个 5 节点集群共享一个由
Zookeeper
集成支持的相同状态机配置，其中每个节点都连接到自己的本地实例。首先，事件
C
被发送到所有机器（只有一个将处理分布式状态更改），这将启动从状态
S21
到
S211
的分布式转换。然后网络中断，图表显示每台机器最终将如何进入错误状态。当网络和
Zookeeper
ensemble 稍后被修复时，所有机器将重新加入一个 ensemble 并同步它们的状态。最后，事件
K
再次发送到所有机器，以表明在修复网络问题后所有机器都在正常工作。
正如我们的文档中提到的，如果现有的 zookeer leader 保持少数状态，则所有实例都将与 ensemble 断开连接，从而导致所有状态机进入错误状态。当网络恢复并且 zookeeper emsemble 修复自身并且连接到它的状态机可以重置它们自己的状态时，这种情况会在稍后自动解决。
SpringOne 2GX 2015 指日可待！
赶快在华盛顿特区的 SpringOne2GX 预订您的位置吧。这是最好的机会，可以直接了解所有正在发生的事情并提供直接反馈。