当我以前使用过像MVVMLight这样的Pub/Sub模式框架时，我看到订阅者的调用是同步处理的。从可伸缩性的角度来看，像 Rx 这样的反应式框架是否有助于发布和订阅完全解耦和可扩展的可扩展性？哪种模式有助于可扩展性？
MVVMLight 的细节，但总的来说，Pub/Sub 是一种模式，其中：
- 发布者和订阅者彼此不了解。他们只知道一个代理，他们在哪里发布/消费消息。
- 因此，消息的发布和使用是异步完成的，并且完全分离。这意味着出版/消费端可以独立扩展，如果一部分发生故障，另一部分能够继续工作。
现在，响应式编程是一种用于对更改及其在多个参与者之间的传播进行建模的模式。因此，它不太关心实现细节，而是更专注于提供一个抽象的声明性接口，这使得处理事件流和在它们之上执行处理变得更加容易。直接来自ReactiveX的文档：
ReactiveX 不偏向于某些特定的并发或异步源。可以使用线程池、事件循环、非阻塞 I/O、参与者（例如来自 Akka）或任何适合您的需求、风格或专业知识的实现来实现可观察量。客户端代码将其与可观察量的所有交互视为异步，无论您的基础实现是阻塞还是非阻塞，以及你选择如何实现它。
因此，解耦/可伸缩性将主要取决于下面使用的实现;框架的主要好处主要是提供的抽象的声明性接口。
关于观察者模式（在问题标题中提到）：它是一个相当低级的原语，可用于实现相同的目标，但可能会导致更复杂的代码库。有关观察者模式与更抽象的响应式框架相比的陷阱的更多详细信息，您可以阅读以下论文：
使用 Scala.React 弃用观察者模式
响应式编程范式通常在面向对象的语言中呈现，作为观察者设计模式的扩展。您还可以将主反应式流模式与熟悉的迭代器设计模式进行比较，因为所有这些库中的可迭代迭代器对都具有双重性。一个主要区别是，虽然迭代器是基于拉取的，但反应式流是基于推送的。
使用迭代器是一种命令式编程模式，即使访问值的方法完全是可迭代对象的责任。实际上，由开发人员选择何时访问序列中的 next（） 项。在反应式流中，上述对的等效项是发布者-订阅者。但是，发布服务器会在新可用值到来时通知订阅者，而这种推送方面是响应的关键。此外，应用于推送值的操作以声明方式而不是命令式表示：程序员表达计算的逻辑，而不是描述其确切的控制流。
来源： https://projectreactor.io/docs/core/release/reference/#intro-reactive