Pub / Sub Vs Observer Vs Reactive

Question

之前我曾经使用像MVVMLight这样的Pub / Sub模式框架，我已经看到订阅者的调用是同步处理的。从可扩展性的角度来看，像Rx这样的反应式框架是否有助于将pub和sub完全解耦和扩展的可伸缩性？哪种模式有助于扩展？

Answer 1

反应式编程范例通常以面向对象的语言表示，作为 Observer 设计模式的扩展。您还可以将主要的反应流模式与熟悉的Iterator设计模式进行比较，因为所有这些库中的Iterable-Iterator对都有双重性。一个主要区别是，虽然Iterator是基于请求的，但反应流是基于请求的。

使用迭代器是命令式编程模式，即使访问值的方法仅由Iterable负责。实际上，由开发人员决定何时选择序列中的next（）项。在反应式流中，上述对等效为发布者-订阅者。但是是发布者将新的可用值通知订阅者，而这种推送方面是做出反应的关键。另外，应用于推入值的操作以声明方式而不是命令方式表示：程序员表示计算的逻辑，而不是描述其确切的控制流程。

来源：https://projectreactor.io/docs/core/release/reference/#intro-reactive

Answer 2

我不知道MVVMLight的具体细节，但一般来说 Pub/Sub 是一种模式，其中：

• 发布商和订阅者彼此不了解。他们只知道一个经纪人，他们在那里发布/消费消息。
• 因此，消息的发布和消费是异步完成的，并且完全解耦。这意味着发布/消费方可以独立扩展，如果一个部分出现故障，另一部分可以继续工作。

现在， reactive programming 是一种模式，用于模拟更改及其在多个角色中的传播。因此，它并不关心实现细节，而是更专注于提供抽象的声明性接口，这使得更容易处理事件流并在它们之上执行处理。直接来自ReactiveX的文档：

  

ReactiveX并不偏向某些特定的并发或异步性源。可以使用线程池，事件循环，非阻塞I / O，演员（例如来自Akka）或任何适合您的需求，风格或专业知识的实现来实现Observable。客户端代码将其与Observables的所有交互视为异步，无论您的底层实现是阻塞还是非阻塞，然而您选择实现它。

因此，解耦/可伸缩性将主要依赖于下面使用的实现，框架的主要好处主要是提供的抽象，声明性接口。

关于观察者模式（在问题标题中提到），它是一个相当低级的原语，可用于实现相同的目标，但可能会导致更多复杂的代码库。有关观察者模式与更抽象的反应性框架相比较的缺陷的更多细节，您可以阅读以下文章：

Deprecating the Observer pattern with Scala.React