我有一个与金融市场相连的系统，它非常大量地使用事件。
所有代码都结构化为事件级联，中间有过滤器、聚合等。
最初，该系统是用 C# 编写的，然后移植到 F#(回想起来，这是一个伟大的举措(，C# 代码中的事件被 F# 中的事件替换，没有多想。
我听说过观察者模式，但我还没有真正了解这个话题。最近，我通过一些随机浏览阅读了有关 F# 的邮箱处理器的信息。
我读了这个：观察者模式和事件驱动方法之间的区别，我没有明白，但显然超过150人投票认为答案不太清楚:)
在这样的文章中：https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c 似乎观察者模式与事件严格相同......
乍一看，他们似乎在解决相同的问题，只是界面不同，但这让我想到了 2 个问题：
-
邮箱处理器真的是正在使用的东西吗？ 它似乎主要出现在较旧的文档中，并且在我使用的软件包中，我没有遇到任何使用它的人
-
关于观察者模式，在我们使用的大量包中，只有一个包在内部使用它，但其他一切都只是使用基本事件。
是否有适合可观察模式和邮箱处理器的特定用例？它们是否具有独特的功能？或者它们最终只是围绕事件的语法帮助？
尽可能简化：
邮箱
这是执行组件模型的最小实现。 将消息发布到队列，循环会逐个读取队列中的消息。也许它会发布到另一个邮箱，或者对邮件执行某些操作。
- 任何操作只能在收到消息时执行。
- 发布到队列是非阻塞的，即没有背压。
- 捕获所有异常并将其作为邮箱上的事件公开。它们应该由上面的演员处理。
- 其他参与者框架提供主管、合同、故障转移等功能。
事件
事件是一种语言支持的回调机制。
这是一个简单的实现。您注册一个回调委托，当引发事件时，将调用您的委托。
- 委托按添加顺序调用。
- 事件是阻塞的，并且是同步的。一个代表阻止，其余的延迟。 事件
- 是关于编写代码来响应事件，而不是之前的事件，即轮询。 事件的
- 处理程序通常是该事件的最终终结点，并且通常具有副作用。
- 共享处理程序很常见。例如，十个按钮可能具有处理单击的相同函数，因为事件的发送者是已知的。
- 您自己处理异常，通常在处理程序代码中
可观察量
有一个源(可观察(，你可以使用接收器(观察者(订阅它。可观察量表示有界或无界的值流。无限流(永不完成的可观察量(似乎类似于事件，但可观察量有几个重要的属性。
- 可观察量发出一系列通知，这些通知遵循以下协定：
OnNext* (OnError|OnCompleted)+
- 所有通知都序列化
- 通知可能是同步的，也可能不是同步的。不能保证背压。
- 可观察量的价值在于它们是可组合的。
- 可观察量表示未来通知流，操作员会执行转换此流的操作。
- 此方法有时称为复杂事件处理 (CEP(。
- 异常处理是管道的一部分，有许多组合器来处理它。
- 您通常从不自己实现观察器。您可以使用组合器来设置管道，该管道对所需行为进行建模。