响应式(Reactive)介绍

大家好，欢迎来到IT知识分享网。

Reactive 是一个重载的词。 您可能已经使用搜索引擎搜索过响应式以了解它的全部内容。 如果你没有，不用担心——你已经为自己省去了很多困惑。 有很多响应式的东西：响应式系统、响应式编程、响应式扩展、响应式消息传递。 每天都有新的出现。 所有这些 “reactives” 是否都具有相同的响应性？ 它们不同吗？

这些是我们将在本文中回答的问题。 我们将看一下响应式环境，以识别并帮助您理解 reactive 的各种细微差别、它们的含义、与之相关的概念以及它们之间的关系。 不用过多猜测，所有这些 “reactives” 都是相关的。

我们所说的响应式是什么意思？

让我们从头开始。 暂时忘掉软件和 IT，使用老式的方法。 如果我们在牛津英语词典中寻找 reactive，我们会发现以下定义：

reactive (形容词)

表现出对刺激的反应。 1.1 对情况做出反应，而不是创造或控制它。 1.2 有化学反应的倾向。 1.3（生理学）显示对特定抗原的免疫反应。 1.4 （疾病或疾病）由对某事的反应引起的。 1.5（物理）与电抗有关。

在这些定义中，有两个在我们的上下文中是相关的。 第一个定义，显示对刺激的反应，是指某种反应。 响应式意味着对刺激做出反应，无论它们是什么。 子定义 1.1 说，被动反应也是面对意外和不受控制的情况。 您将在系列的文章中看到云原生应用程序和一般的分布式系统面临大量此类情况。 虽然这些定义很有趣，但它们并不适用于软件。 但是我们可以将这些定义考虑在内，为软件创建一个新的定义：

1.6（软件）对刺激做出反应的应用程序，例如用户事件、请求和故障。

然而，正如您将在本系列文章中看到的那样，今天的响应式超越了这一点。 响应式是一种根据事件和流来设计、实现和推理系统的方法。 Reactive 是关于构建响应式、容错性和弹性的应用程序。 响应式还涉及通过有效管理资源和通信来利用资源。 换句话说：响应式是关于设计和构建更好的分布式系统——更健壮、更高效。 我们称它们为响应式系统。

响应式软件并不新鲜

我们刚刚给出的定义（1.6）并不是开创性的。 相反，你可能会觉得有些似曾相识，不是吗？ 软件的本质不是对用户输入和操作系统信号做出反应吗？ 当您敲击键盘时，软件的行为如何？ 它会做出反应。 那么，如果 Reactive 只是普通软件，为什么会有这么多关于 Reactive 的书籍、演讲和辩论呢？

响应式并不新鲜。 它实际上已经挺老了。 我们可以追溯到 50 年代计算机出现之后的反应式软件背后的想法的基础。 DYSEAC 是第一代计算机（1954 年投入使用），已经使用硬件中断作为优化，消除了轮询循环中的等待时间。 这台计算机是最早使用响应式和事件驱动架构的系统之一！

对事件做出反应意味着是事件驱动的。 事件驱动软件接收和产生事件。 接收到的事件决定了程序的流程。 事件驱动的一个基本方面是异步性：您不知道何时将接收事件。 这正是上一节的定义 1.1。 您无法计划何时接收事件，无法控制您将获得哪些事件，并且您需要准备好处理它们。 这就是响应式的本质：异步。

响应式景观

从这种异步和事件驱动的思想出发，出现了许多形式的 Reactive。 响应式景观广阔而拥挤。 图 1 描述了这种情况的汇总以及主要响应事物之间的关系。

图 1

但不要忘记我们的目标：构建更好的分布式系统——响应式系统。 其他 “reactives” 在这里帮助我们实现这些系统。

响应式的原因，特别是响应式系统，来自分布式系统。 2013 年，分布式系统专家编写了《The Reactive Manifesto》的第一版，并介绍了响应式系统的概念。

您可以在不应用响应式原则的情况下构建分布式系统。 Reactive 提供了一个蓝图，以确保在构建和开发系统时不会忽略任何重大的已知问题。 另一方面，您可以将这些原则应用于非分布式系统。

响应式系统首先是响应式的。 即使在负载下或面临故障时，它也必须及时处理请求。 为了实现这种响应，宣言建议使用异步消息传递作为在构成系统的组件之间进行通信的主要方式。 您将在后续文章看到这种通信方法如何实现容错性和弹性，这是可靠分布式系统的两个基本属性。 本书的目的是向您展示如何使用 Quarkus 构建这样的响应式系统。 因此，构建响应式系统是我们的主要目标。

将异步消息传递注入分布式系统的核心并非没有后果。 您的应用程序需要使用异步代码和非阻塞 I/O，这是操作系统提供的将 I/O 交互排入队列而无需主动等待完成的能力。 （后面将在介绍非阻塞 I/O）。 后者对于提高资源利用率至关重要，例如 CPU 和内存，这是 Reactive 的另一个重要方面。 今天，许多工具包和框架，例如 Quarkus、Eclipse Vert.x、Micronaut、Helidon 和 Netty，都出于这个原因使用非阻塞 I/O：用有限的资源做更多的事情。

然而，拥有一个利用非阻塞 I/O 的运行时还不足以成为响应式。 您还需要编写包含非阻塞 I/O 机制的异步代码。 否则，资源利用的好处就会消失。 编写异步代码是一种范式转变。 来自传统的（命令式），do x; do y;，你现在将把你的代码改造成 on event(e) do x; on event(f) do y;。 换句话说，要具有响应式，您的系统不仅是事件驱动的架构，而且您的代码也将成为事件驱动的。 实现此类代码的最直接的方法之一是回调：您注册在收到事件时调用的函数。 与 futures、promise 和 coroutines 一样，其他所有方法都基于回调并提供更高级别的 API。

系列文章中提到的响应式编程也是一种编写异步代码的方法。 它使用数据流来构建您的代码。 您观察这些流中传输的数据并对其做出反应。 响应式编程提供了强大的抽象和 API 来塑造事件驱动的代码。

但是使用数据流会带来一个问题。 如果你有一个快速的生产者直接连接到一个慢的消费者，你可能会淹没消费者。 正如您将看到的，我们可以在两者之间缓冲或使用消息代理，但想象一下在没有它们的情况下淹没消费者。 这与 Reactive 所提倡的响应能力和反脆弱性理念背道而驰。 为了帮助我们解决这个特定问题，Reactive Streams 提出了一种异步且非阻塞的背压协议，其中消费者向生产者发出其可用性信号。 可以想象，这可能并不适用于所有地方，因为某些数据源不能放慢速度。

在过去的几年里，Reactive Streams 的受欢迎程度有所增加。 例如，RSocket 是一种基于 Reactive Streams 的网络协议。 R2DBC 建议使用 Reactive Streams 进行异步数据库访问。 此外，RxJava、Project Reactor 和 SmallRye Mutiny 采用反应式流来处理背压。 最后，Vert.x 允许将 Vert.x 背压模型映射到 Reactive Streams。

我们对响应式环境的快速浏览到此结束。 正如我们所说，它挤满了许多术语和许多工具。 但永远不要忽视 Reactive 的总体目标：构建更好的分布式系统。

为什么响应式架构如此适合云原生应用程序？

云——公共的、私有的或混合的——已经把 Reactive 放在了聚光灯下。 云是一个分布式系统。 当您在云上运行应用程序时，该应用程序面临着高度的不确定性。 应用程序的配置可能很慢，也可能很快，甚至失败。 由于网络故障或分区，通信中断很常见。 您可能会遇到配额限制、资源短缺和硬件故障。 您正在使用的某些服务有时可能不可用或移至其他位置。

虽然云为基础设施层提供了出色的设施，但它只覆盖了一半。 后半部分是你的申请。 它需要被设计成分布式系统的一部分。 它需要了解成为这样一个系统的一部分所面临的挑战。

我们在本系列文章中介绍的响应式原则有助于接受分布式系统和云应用程序固有的不确定性和挑战。 它不会隐藏它们——相反，它会拥抱它们。

随着微服务和 serverless 计算成为突出的架构风格，响应式原则变得更加重要。 它们可以帮助确保您在坚实的基础上设计系统。

响应式不是灵丹妙药

与所有事物一样，Reactive 有利有弊。 它不是魔法武器。 没有解决方案适用于任何地方。

还记得 2010 年代后期的微服务吗？ 它们很快变得非常流行，许多组织在它们可能不适合的领域实现了它们。 这通常以一组问题换另一组问题。 就像微服务架构一样，响应式架构也有非常适合的领域。 它们适用于分布式和云应用程序，但在更单一和以计算为中心的系统上可能是灾难性的。 如果您的系统依赖于远程通信、事件处理或高效率，那么 Reactive 将会很有趣。 如果你的系统主要使用进程内交互，每天只处理几个请求，或者是计算密集型的，那么 Reactive 只会带来复杂性。

使用 Reactive，您将事件的概念置于系统的核心。 如果您习惯于构建应用程序的传统同步和命令式方式，那么变得响应式的路径可能会很陡峭。 变得异步的需求破坏了大多数传统框架。 我们正在远离众所周知的远程过程调用 (RPC) 和 HTTP 端点。 所以，有了这个免责声明，是时候开始我们的旅程了！