内存总线中的消息总线模式v

Question

我很难理解何时使用这两种方法：

1)消息总线:用于在Microservices之间发送集成事件。例如，Microservice A可以发布一个集成事件，该集成事件由Microservice B和Microservice C处理。消息总线例如RabbitMQ的好处是，如果其中一个微服务停机，那么它以后可以处理该事件。它还保证交货。

2) Mediatr (Mediator模式)：使用CQRS，Mediatr模式可以用来解耦命令和事件，使MVC控制器/服务变得更稀薄。

我知道这两种模式是如何在相同的环境中使用的。然后我看到这样的代码：

3)内存总线：https://github.com/gregoryyoung/m-r/blob/master/SimpleCQRS/FakeBus.cs。它是内存总线。

使用Mediatr和内存总线有什么区别？我目前的想法是，Mediatr在使用观察者模式时更合适，而在内存总线中使用publisher/subsciber模式时更合适。我理解得对吗？

对于单个微服务(域事件)使用InMemory总线，为集成事件(在Microsservices之间)使用持久消息总线合适吗？

Answer 1

中介模式在两个微服务之间创建了一个灵活的解耦接口。消息被发送到和从每个微服务，而不一定要知道所有的显式工作的另一个。

如果您认为这两者之间的关系将来可能会发生重大变化，那么这种模式是非常理想的。中介可以是独立的，如果传递失败，它可以持久化消息，因此它可能和消息总线一样稳定。

发布订阅模式基本上是您的消息总线，它不只是用于两个接口。它可能用于多个接口，允许最大的灵活性。灵活性还扩展到消息本身，这意味着当事件发生时，任何有兴趣接收消息的人都必须轻松地发送和接收消息。这也意味着，如果您不小心，您可能会在版本控制方面遇到问题，因为传递的消息的更改必须在微服务中得到一致的解释，这与中介器不同。当消息发生变化时，只有中介方绝对需要更新才能使一切正常工作。

内存总线与其说是一种模式，不如说是一条没有持久性的消息总线。它更快，但在出现意外故障时也不理想，因为您不知道错误发生在哪里，并且很难恢复以前的情况。在任何生产环境中，我都不推荐这样做，即使它写入了日志文件。

我希望这能回答你的问题！

Answer 2

这并不是那么简单，当然“这取决于”：

我不记得在哪里，但我记得我读过Roger这样的文章：“如果您的参与者将是唯一的消费者，请不要使用企业队列来排队”。

这指的是通过企业总线(而不是在内存中)序列化消息的超高成本，为了使“持久”必须首先写入持久存储(通常是磁盘)，并在继续之前获得成功写入的确认。(加上其他成本、序列化、反序列化、网络延迟、数据包重新组合等)这可能比B类的A类调用方法(或者A类使用Mediator对B类调用)慢10万倍(随机数字非常大，但您明白我的意思)，在处理方法调用不持久的情况下，如果您加快了100 000次，那么如果失败，则重放整个消息链是父级的责任，通常是它自己的尝试捕获。所以系统崩溃了，那又怎样呢？(面对系统故障，我笑啊！)小猫)，当它开始的时候，哦，所以这样的传奇没有完成，重播它，所有它的孩子的信息都被重放。

这里的关键教训是使微服务的入口点消息“持久”，对于所有内部消息来说，使它们变得像地狱一样快，并且是幂等的。(这里有很粗略的解释)

微服务的入口点应该是处理从一些持久消息总线中获取的消息的服务。在内部，考虑使用诸如内存总线或参与者框架之类的模式，例如Akka.net、TPL DataFlow等库，并尽可能地使用除了主消息处理管道的输入和输出边缘以外不需要持久性的设计。

• 在内存中，消息总线通常不会“队列”工作，也就是说，Gregory的FakeBus链接到上面只是在后台线程中启动工作，所以您必须担心并发性。
• 并发框架(如Akka.net和TPL DataFlow )分别为您提供了用于管理工作(线程)并发的高级和低级工具。消除大部分软件工程问题。Akka.net侧重于围绕参与者模式的更高抽象，而TPL DataFlow提供了低级别的线程“管道”并发管理。我强烈建议您在选择任何一种工具之前完成这两种工具的介绍性培训。

如果您自己工作，非常详细，或者编写一个库，那么可能考虑TPD DataFlow。如果您在一个大型团队中工作，并且主要构建业务应用程序，请考虑Akka.net或类似的参与者框架。

消息总线

• 用于发送大域命令或事件。例如InvoiceCreated，PaymentMade
• 微型服务的进出处使用

调解人模式

• 如前面所述，使用它来简化代码。根据我的经验，它使代码变得不那么脆弱，更容易重构，更容易快速阅读(扫描)。
• 通常，它可以使DI变得更干净，而不必注入如此庞大的复杂依赖项。
• 不会使消息持久，也不会为并发性做任何事情。

内存总线中的

• 解耦元件的高速方式
• 用于处理服务组件之间的私有内部消息。
• 随着服务的增长，服务可能成为微服务的协作。只有在存在可以监视任何长时间运行的sagas的父服务器时，才使用内存总线在微服务之间进行通信。通常，由于响应持久的“消息总线”消息，整个传奇的持久性可能由父方管理。

最后，由于我还没有回答OP的问题，所以->“对于单个微服务(域事件)使用InMemory总线，为集成事件(在Microsservices之间)使用持久消息总线合适吗？”

我会说..。是的，注意点。

希望这能帮上忙？