F# 中的事件、观察者和 MailboxProcessor 的澄清

Question

我有一个与金融市场相连的系统，它大量使用事件。

所有代码都被构造为事件级联，其间有过滤器、聚合等。

最初系统是用 C# 编写的，然后移植到 F#（回想起来这是一个伟大的举动），C# 代码中的事件被 F# 中的事件取代，没有多加考虑。

我听说过观察者模式，但我还没有真正了解这个主题。最近，我通过一些随机浏览阅读了有关 F# 的邮箱处理器的信息。

我读过这篇文章：观察者模式与事件驱动方法之间的差异，我没有明白，但显然超过 150 人投票认为答案也不太清楚:)

在这样的文章中：https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c看起来观察者模式与事件完全相同......

乍一看，他们似乎在解决同一类问题，只是接口不同，但这让我思考了两个问题：

• 邮箱处理器真的是被使用的东西吗？它似乎主要出现在较旧的文档中，并且在我正在使用的软件包中，我还没有遇到任何使用它的情况

• 关于观察者模式，我们使用的大量包中只有一个包在内部使用它，但其他所有东西都只是使用基本事件。

是否有适合 Observable 模式和 MailboxProcessor 的特定用例？他们有独特的功能吗？或者它们最终只是围绕事件提供语法帮助？

Answer 1

尽可能简化：

邮箱

这是参与者模型的最小实现。您将消息发布到队列中，然后循环从队列中一条一条地读取消息。也许它会发送到另一个邮箱或对消息进行某些处理。

• 任何操作只有在收到消息后才会发生。
• 发布到队列是非阻塞的，即没有背压。
• 所有异常都会被捕获并作为邮箱上的事件公开。它们预计将由其上方的演员处理。
• 其他参与者框架提供了主管、合约、故障转移等功能。

活动

事件是一种语言支持的回调机制。

这是一个简单的实现。您注册一个回调委托，当引发事件时，您的委托将被调用。

• 代表按照添加顺序被召集。
• 事件是阻塞的、同步的。一名代表受阻，其余代表被延迟。
• 事件是关于编写代码来响应事件，而不是之前的轮询。
• 事件的处理程序通常是该事件的最终端点，并且通常具有副作用。
• 共享处理程序很常见。例如，十个按钮可能具有相同的处理点击的功能，因为事件的发送者是已知的。
• 您自己处理异常，通常在处理程序代码中

观测值

有一个源（Observable），您可以使用接收器（Observer）来订阅它。可观察量表示有界或无界的值流。无界流（永远不会完成的 Observable）看起来与事件类似，但 Observable 有几个重要的属性。

• Observable 会发出一系列通知，这些通知遵循以下约定：

    OnNext* (OnError|OnCompleted)+

• 所有通知均已序列化
• 通知可能是同步的，也可能不是同步的。无法保证背压。
• Observables 的价值在于它们是可组合的。
• 可观察量代表未来通知的流，操作员负责转换该流。
• 这种方法有时称为复杂事件处理 (CEP)。
• 异常处理是管道的一部分，有很多组合器来处理它。
• 您通常永远不会自己实现观察者。您可以使用组合器来设置一个管道来模拟您想要的行为。