我们很高兴地宣布 Spring Statemachine 1.0.0 发布。首先，我要感谢所有为此做出贡献的人。构建产物可从 Maven Central 或 Spring Repository 获取。

本次首个版本包含的内容

• 易于使用的扁平化单层状态机，适用于简单用例。
• 分层状态机结构，简化复杂状态配置。
• 状态机区域，提供更复杂的状态配置。
• 触发器、转换、守卫和动作的使用。
• 类型安全的配置适配器。
• 构建器模式，方便在 Spring Application context 外部实例化使用。
• 常见用例示例
• 基于 Zookeeper 的分布式状态机
• 状态机事件监听器。
• Spring IOC 集成，将 bean 与状态机关联。

让我们快速回顾一下这个项目是如何诞生的，以及它是如何从首次导入 GitHub 发展到发布。这也能稍微了解一下一个新的 Spring 项目是如何诞生或可能诞生的。该项目于今年早些时候基于 Spring Hadoop 的基础工作启动。

在达拉斯举行的 SpringOne 2014 上，我们将一个新的容器分组特性推入 Spring YARN，这在 YARN 容器之上增加了更高级的功能。如今，Spring XD 的 YARN 运行时和新的 Spring Cloud Dataflow YARN 部署器都基于此。与 Hadoop YARN 资源管理器的通信本质上是异步的，因此我试图在不使用合适的状态机概念的情况下实现代码库的这一特定部分时遇到了很多麻烦。相信我，我尝试了，真的很努力地尝试不使用合适的状态，大约一周后，我不得不面对现实，承认我试图用自己的代码来取代我自己的代码。我最后得到了一些勉强能工作的东西，但如果我碰触代码的任何部分，就会乱套。我删除了所有东西，对自己说：“天哪 Janne，我需要一个状态机”。

在我完成状态机的基本实现后，我所有的问题都消失了，原因很简单，因为状态机现在控制着所有必须按特定顺序发生的逻辑，而与 YARN 资源管理器的所有通信仍然是异步发生的。是的，现在我们进入了发布阶段，这给了我们一个选择，可以用这个版本替换 Spring YARN 的内部状态机。

于是产生了这样的想法：将这段特定的状态机代码分支出一个独立的项目，稍微增强一下，然后启动一个新的 Spring 项目，看看它是否能获得关注，这可能是一个非常好的主意。说实话，对于这项已有 50 多年历史的技术能获得如此大的兴趣，我有点惊讶。优秀而扎实的概念不会消亡，也不需要消亡！

关于我在这段从想法到发布的旅程中遇到的一些挑战

• 没有嵌套状态和实现钩子（即监听器）的简单状态机非常容易实现。
• 引入深度嵌套状态会使事情变得有点复杂，特别是当你加入入口/出口动作、不同的转换类型和守卫等各种其他特性时。我遇到了很多关于不同父状态的子状态之间的转换问题。
• 添加正交区域会使事情更加复杂，因为理论上状态机是单线程的，但区域是独立的并且可以并行执行。为了支持独立执行区域，我们投入了大量工作。
• 基于 zookeeper 的分布式状态机（通过 SPI 抽象）是一件有点疯狂的事情。有些人甚至不会尝试它，而且测试是个噩梦（无法通过简单的单元测试完成）。我使用了 Aphyr's 的 Jepsen 框架来做这件事，温和地说，它让一切变得支离破碎，但最终让我发现了当你从单个 JVM 中跳出来并开始处理分布式 JVM 时遇到的各种 bug。这是一段痛苦但有趣的旅程。

很多人问我们是否有路线图？简短的回答是：有，也没有。有是因为我们确实有很多想实现的功能；没有是因为项目一直以来都是由社区的请求驱动的。我最初是按照 UML 状态机规范来实现基本功能，但最终约 50% 的额外功能是用户请求的。UML 规范在其某些规范功能方面非常模糊，并留下许多细节给实现者。如果你想要什么，请直言并在 GitHub Issues 上提出。想贡献代码，欢迎提交 PR（即使只是一个简单的拼写错误修复也万分感谢！）。

我们目前已知的信息

• 1.0.x 版本不会添加任何改变核心概念的新功能，但会继续进行常规维护/bug 修复。我们可能会添加增强现有概念的新功能。
• 1.1.x 版本将专注于安全和执行模型等主题。我们希望轻松集成 Spring Security、Spring Session 以保护状态机操作。对于执行，我们正在考虑用 Reactor 替代或尝试使用它，而不是使用常规的 Framework 任务调度/执行。
• 2.x 版本（在可预见的未来）将提升基线至 Spring Framework 5 和 JDK8。1.x 系列将保持基于 Spring Framework 4 和 JDK7 的基线。

试一试，感受一下，体验一下，然后告诉我们您的想法！