我们很高兴地宣布 Spring Statemachine 1.0.0 正式发布。我想首先感谢所有为实现这一目标做出贡献的人。您可以从 Maven Central 或 Spring Repository 获取工件。

我们在此次首次发布中实际完成的内容

• 易于使用的扁平单层状态机，适用于简单的用例。
• 分层状态机结构，简化复杂状态配置。
• 状态机区域，提供更复杂的状态配置。
• 使用触发器、转换、守卫和动作。
• 类型安全的配置适配器。
• 采用建造者模式，便于在 Spring 应用程序上下文之外进行实例化。
• 常见用例的示例。
• 基于 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 的 Jepsen 框架，这个框架，说得轻一点，让事情变得混乱，但最终让我能够发现各种 bug，当你跳出单个 JVM 并开始处理分布式 JVM 时。这是一段痛苦但有趣的旅程。

许多人问我们是否有路线图？简短的回答是“有”和“没有”。“有”，因为我们肯定有很多东西想要实现；“没有”，因为项目一直由社区的请求驱动。我开始遵循 UML 状态机规范来获取基础功能，但最终约 50% 的额外功能是由用户请求的。UML 规范对于其某些规范功能非常模糊，并将许多细节留给了实现本身。如果您想要什么，请说出来，并前往 GitHub Issues。想贡献，请提交 PR（即使是简单的拼写错误修复也非常感谢！）。

我们目前所知

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

尝试一下，感受一下，嗅探一下，然后让我们知道您的想法！