Java 中的响应式系统

第 4 章 反应式系统的设计原则

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

在第 3 章中，我们探讨了分布式系统背后的挑战。 现在是时候看看 Reactive 能提供什么了。 Reactive 可以被看作是构建分布式系统的一套原则，是一种核对表，用于验证在架构和构建系统时是否忽略了已知的主要问题。 这些原则主要集中在以下几个方面：

响应能力

面对故障或负载高峰时处理请求的能力

效率

用更少的资源做更多的事

在本章中，我们将介绍反应式系统所倡导的原则。

反应式系统 101

2013 年，一群分布式系统专家聚集在一起，撰写了第一版"反应式宣言"。他们在这份白皮书中汇集了自己在构建分布式系统和云应用程序方面的经验。虽然 2013 年的云还不是今天的云，但动态创建短暂资源已经是一种众所周知的机制。

"反应式宣言》将反应式系统定义为具有四个特征的分布式系统：

响应式

能够及时处理请求

弹性

能够从容应对故障

弹性

能够根据负载和资源情况扩大或缩小规模

信息驱动

在组成系统的组件之间使用基于消息的异步通信

这四个特征如图 4-1 所示。

图 4-1. 反应式系统特征

如果你是第一次看到这幅图，可能会被所有的箭头弄糊涂。 它看起来像是一场精心策划的营销活动。 其实不然，让我们来解释一下为什么这些支柱在构建云原生和 Kubernetes 原生应用程序时非常有意义。 让我们从图的底部开始。

它们使用异步消息传递来建立组件之间的连接组织。异步消息传递确保了松散耦合、隔离和位置透明。 在反应式系统中，交互依赖于发送到抽象目的地的消息。 异步消息传递还能提高资源利用率。 采用非阻塞通信（我们将在本章后面介绍这部分内容）可以让空闲组件几乎不消耗 CPU 和内存。 异步消息传递可以实现弹性和恢复能力，如图 4-1 中底部的两个箭头所示。

弹性意味着系统可以调整自身或部分自身，以处理波动的负载。 通过观察各组件之间的信息流，系统可以确定哪些部分达到了极限，并创建更多实例或将信息路由到其他地方。 云基础设施可以在运行时快速创建这些实例。 但弹性不仅是向上扩展，它还可以向下扩展。 系统可以决定缩减未充分利用的部分，以节省资源。 在运行时，系统会进行自我调整，始终满足当前需求，避免瓶颈、溢出和资源超额承载。 可以想象，弹性需要可观察性、复制和路由功能。 可观察性将在第 13 章中介绍。 一般来说，后两者由基础设施（如 Kubernetes 或云提供商）提供。

弹性意味着优雅地处理故障。 如第 3 章所述，故障在分布式系统中是不可避免的。 React 系统不是将故障隐藏起来，而是将故障视为一等公民。 系统应能够处理故障并对其做出反应。 故障包含在每个组件中，组件之间相互隔离。 这种隔离确保了系统的部分组件能够在不危及整个系统的情况下发生故障并恢复。 例如，通过复制组件（弹性），即使某些组件出现故障，系统也能继续处理传入的信息。 弹性的实现由应用程序（需要感知故障、控制故障，并在可能的情况下优雅地处理故障）和基础架构（监控系统并重启故障组件）共同承担。

最后一个特性是反应式系统的全部目的：反应灵敏。 即使在负载波动（弹性）和面临故障（弹性）时，系统也需要保持反应灵敏--及时响应。 ...