我们很高兴地宣布 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's 的 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 作为基线。

尝试一下，感受它，嗅一嗅，并让我们知道你的想法！