Java 中的响应式系统

第 7 章 叛变：事件驱动的反应式编程 API

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在第 5 章中，我们介绍了反应式编程以及它如何帮助实现反应式应用程序。 然后，在第 6 章中，我们讨论了 Quarkus 如何使用 Mutiny 来实现反应式应用程序。 本章重点介绍 Mutiny 本身。¹

本章介绍了 Mutiny 的概念和常用模式，这将有助于你理解后面几章的内容。 Mutiny 是用于 Quarkus 所有反应式相关功能的 API。 在深入研究使用 Quarkus 构建反应式应用程序和系统时，你会看到更多关于它的内容。

为什么需要另一个反应式编程库？

这是个好问题！正如你在第 5 章中看到的，目前已有其他流行的反应式编程库。 那么，为什么还要再开发一个呢？

在过去几年中，我们观察了开发人员如何开发反应式系统和使用反应式编程库。 通过这些经验，我们观察了开发人员面临的挑战。 简而言之，反应式编程难学难读。 编写和维护反应式代码造成了很大的负担，延缓了反应式方法的采用。

当我们观察反应式编程的使用时，我们会立即看到一个陡峭的学习曲线，这使得反应式编程仅限于一流的开发人员。 事实上，反应式编程的函数式编程根源既优雅又有局限性。 并非每个开发人员都有函数式编程背景。我们看到开发人员迷失在map 和flatMap 的丛林中，试图从单子构成的迷宫中找到出路。

单体？

单元来自范畴理论，但在函数式编程中得到了广泛应用。单元代表一种计算形式。 单元可以实现操作链。 在单元中，每个链式操作的输入都是前一个操作的输出。

即使对于经验丰富的开发人员来说，有些概念也是抽象而令人困惑的。例如，传统反应式编程库中的两个主要运算符flatMap 和concatMap 之间的区别就会导致许多错误，包括生产失败。 这些反应式编程库需要函数背景和对可用运算符的良好理解。 掌握数百个运算符需要时间。

另一个方面是 API 建模。 现有的库通常实现了Reactive Extensions（ReactX），并提供了包含数百个方法的 Java 类。 即使使用现代集成开发环境，要找到正确的方法也无异于大海捞针。 为了找到正确的方法，滚动方法列表是常有的事，甚至不看方法名称，只看签名，希望能找到最好的方法。

最后，这是一个更具哲学意义的方面，现有的反应式编程库并没有反映出反应式原则的事件驱动性质。 虽然它使用了数据流这种异步结构，但应用程序接口并没有传达出事件的概念。 反应式架构应有助于实现基于事件的流程，而这些方法并不完善，需要在业务流程与其实现之间进行额外的思维映射。

为了解决这些问题，我们决定创建 Mutiny，这是一个全新的反应式编程 API，注重可读性和维护，并将事件概念置于中心位置。

是什么让 Mutiny 与众不同？

Mutiny 是 Java 的一个直观、事件驱动的反应式编程库。 Mutiny 使用事件的概念来传达事情的发生。 这种事件驱动的特性非常适合分布式系统的异步特性（如第 3 章所述）。 使用 Mutiny，当事件发生时，你会收到通知，并对其做出反应。因此，Mutiny 是围绕onItem 和onFailure 等方法来构建自身的。每个方法都能让你表达在接收到事件时想做什么。例如，onItem.transform 接收一个项目事件并对其进行转换，或者onFailure.recoverWithItem 在失败事件发生后用一个后备项目来恢复。

我们希望解决 API 的导航问题，避免