当我之前使用过像 MVVMLight 这样的 Pub/Sub 模式框架时，我已经看到订阅者的调用是同步处理的。从可扩展性的角度来看，像 Rx 这样的响应式框架是否有助于 pub 和 sub 完全解耦和可扩展的可扩展性？哪种模式有助于可扩展性？
【问题讨论】：
标签： reactive-programming publish-subscribe observer-pattern
我不知道 MVVMLight 的细节，但总的来说 Pub/Sub 是一种模式，其中：
现在，reactive programming 是一种用于模拟更改及其在多个参与者之间传播的模式。因此，它不太关心实现细节，而是更专注于提供一个抽象的、声明性的接口，这使得处理事件流和在它们之上执行处理变得更加容易。直接来自 ReactiveX 的文档：
ReactiveX 不偏向某些特定的并发或异步源。 Observables 可以使用线程池、事件循环、非阻塞 I/O、actor（例如来自 Akka）或任何适合您的需要、您的风格或您的专业知识的实现来实现。客户端代码将其与 Observables 的所有交互视为异步，无论您的底层实现是阻塞还是非阻塞，以及您选择如何实现它。
因此，解耦/可扩展性将主要取决于底层使用的实现；该框架的主要好处主要是提供了抽象的、声明性的接口。
关于 observer 模式（在问题的标题中提到）：它是一个相当低级的原语，可用于实现相同的目标，但可能会导致更复杂的代码库。与更抽象的响应式框架相比，有关观察者模式的陷阱的更多详细信息，您可以阅读以下论文：
【讨论】：
反应式编程范式通常以面向对象的语言呈现，作为观察者设计模式的扩展。您还可以将主要的反应流模式与熟悉的 Iterator 设计模式进行比较，因为所有这些库中的 Iterable-Iterator 对都具有双重性。一个主要区别是，虽然迭代器是基于拉的，但反应式流是基于推的。
使用迭代器是一种命令式编程模式，尽管访问值的方法完全由 Iterable 负责。实际上，由开发人员选择何时访问序列中的 next() 项。在反应式流中，上述对的等价物是 Publisher-Subscriber。但是当新的可用值到来时通知订阅者的是发布者，而这个推送方面是反应的关键。此外，应用于推送值的操作以声明方式而非命令方式表达：程序员表达计算的逻辑，而不是描述其确切的控制流程。
来源：https://projectreactor.io/docs/core/release/reference/#intro-reactive
【讨论】：