008.使用响应式系统和《响应式宣言》

到目前为止，我们已经讨论了Rx如何为应用程序增加反应性。许多应用程序不是独立的，而是整个系统的一部分，该系统由更多应用程序(桌面、移动、web)、服务器、数据库、队列、服务总线和其他组件组成，您需要连接这些组件才能创建一个工作有机体。响应式编程模型(以及Rx作为该模型的实现)简化了应用程序处理更改传播和事件消费的方式。从而使应用程序具有响应性。但是怎样才能使整个系统反应呢?

作为一个系统，反应性是由响应性、弹性、灵活性和信息驱动来定义的。反应性系统的这四个特征在响应式宣言（www.reactivemanifest.org）中进行了定义，这是软件社区为定义构建反应性系统所需的最佳架构风格而进行的一项合作。你可以通过签署宣言并传播信息来加入提高人们对反应性系统认识的努力。

重要的是要明白，《响应式宣言》并没有发明任何新东西；反应式应用程序早在发布之前就已经存在。一个例子是已经存在了几十年的电话系统。这种类型的分布式系统需要对动态负载量（呼叫）做出反应，从故障中恢复，并保持可用，并对呼叫者和被呼叫者做出全天候响应，所有这些都是通过将信号（消息）从一个操作员传递到另一个操作员来实现的。

《响应式宣言》在这里是为了把响应式系统这个术语放在地图上并收集创建这样一个系统的最佳实践。让我们深入研究这些概念。

一、响应性
当你转到你最喜欢的浏览器并输入URL时，你预计你浏览的页面会在短时间内加载。当加载时间超过几毫秒时，你会有不好的感觉（甚至可能会生气）。您可能会决定离开该网站，然后浏览到另一个网站。如果你是网站所有者，你就失去了一个客户，因为你的网站没有响应。

系统的响应性由系统对其接收到的请求作出响应所花费的时间来确定。显然，更短的响应时间意味着系统的响应能力更强。系统的响应可能是积极的结果，例如您试图加载的页面、您试图从web服务获取的数据或您希望在金融客户端应用程序中看到的图表。响应也可能是否定的，例如指定作为输入提供的某个值无效的错误消息。

在任何一种情况下，如果系统响应所需的时间是合理的，则可以说应用程序是响应的。但是，合理的时间定义起来是有问题的，因为它取决于上下文和测量的系统。对于有按钮的客户端应用程序，假设应用程序响应按钮点击所需的时间为几毫秒。对于需要进行大量计算的web服务，一两秒也可能是合理的。在设计应用程序时，您需要分析所拥有的操作，并定义操作完成和响应所需的时间范围。反应性是反应性系统试图实现的目标。

二、弹性
每隔一段时间，您的系统可能会面临故障。网络断开、硬盘故障、电源关闭或内部组件出现异常情况。弹性系统是指在发生故障时保持响应的系统。换句话说，当您编写应用程序时，您希望以不妨碍用户获得响应的方式来处理故障。

为应用程序添加弹性的方式因应用程序而异。一个应用程序可能会捕获异常并将应用程序返回到一致状态。另一个应用程序可能会添加更多的服务器，这样，如果一个服务器崩溃，另一个服务器将进行补偿并处理请求。为了提高系统的弹性，您应该遵循的一个好原则是避免单点故障。这可以通过使应用程序的每个部分与其他部分隔离来实现；您可以将各个部分分离到不同的AppDomain、不同的进程、不同的容器或不同的机器中。通过隔离部件，可以降低系统整体不可用的风险。

三、灵活性
您正在编写的应用程序将被许多用户使用——希望是大量用户。每个用户都会向您的系统发出请求，这可能会导致您的系统需要处理的高负载。系统中的每个组件都有其可以处理的负载级别的限制，当负载超过该限制时，请求将开始失败，组件本身可能会崩溃。这种负载增加的情况也可能是由您的系统正在经历的分布式拒绝服务（DDoS）攻击引起的。

为了克服过载的原因，您的系统需要具有弹性：它需要随着负载的增加而跨越实例，并随着负载的减少而移除实例。自从云进入我们的生活以来，这种自动行为变得更加明显。当你在云上运行时，你会得到无限资源的幻觉；通过一些简单的配置，您可以根据定义的阈值将应用程序设置为向上或向下扩展。您只需要记住，成本与运行额外的服务器有关。

四、消息驱动
在这一点上，你可以说，响应性是你的目标，弹性是确保你保持响应的方法，弹性是保持弹性的方法之一。反应性系统的谜题中缺少的部分是系统各部分之间的通信方式，以允许我们所探索的反应性类型。

异步消息传递是最适合我们需求的通信过程，因为它允许我们在不限制生产者的情况下控制每个组件的负载级别——通常使用队列或服务总线等中间通道。它允许将消息路由到正确的目的地，并在组件崩溃时重新发送失败的消息。它还增加了内部系统组件的透明度，因为用户不需要知道内部系统结构
它可以处理的消息类型。信息驱动使所有其他反应概念成为可能。图1.12显示了使用消息队列的消息驱动方法如何帮助提高系统中的消息处理率，并实现弹性。

图1.12负载均衡和弹性的消息驱动方法的关系。在左边，消息以很高的频率到达，但系统处理以恒定的速率进行，并且队列的填充速度快于清空速度。在右侧，即使处理工作者角色崩溃，用户仍然可以填充队列；并且当系统恢复并添加新的工作者时处理继续。

在图中，参与者通过消息队列以消息驱动的方式进行通信。客户端发送一条稍后由服务器检索的消息。这种异步通信模型对系统中的处理提供了更大的控制——控制速率和处理故障。存在许多具有不同功能集的消息队列实现。有些允许消息的持久性，这提供了持久性，有些还提供了一种“事务”传递模式，锁定消息，直到消费者发出处理成功完成的信号。无论您选择哪个消息队列（或消息驱动的平台），都需要以某种方式获取已发送的消息并开始处理它们。这就是Rx的用武之地。

——未完待续

译者：重庆教主（QQ23611316） 2024.05.14

网站：WPF中文网 wpfsoft.com