当发布/订阅模式遇上.NET

日常开发中，我们通常会在同一个体系架构中部署了多个不同角色的应用程序，而这些应用程序需要某种机制来通知彼此发生了哪些事件。这些事件可能是临时的（在运行时临时所做的更改），也可能是数据库事件（由于数据库中的更改）。如何应对这种复杂多变的分布式事件，一直是件相当棘手的问题。而这正是发布-订阅设计模式的用武之地。

众所周知，发布-订阅模式在众多设计模式中，可能是最常见、最有名的一个了。它定义了一种一对多的关系，让多个订阅者对象同时监听某一个主题对象，当这个主题对象的状态发生变化时就会通知所有订阅自己的订阅者对象，使得他们能够自动更新自己。

在“发布-订阅”的消息传递范式中，消息的发送者（发布者）并不知道预期的收件人（订阅者）。此外，发布者和订阅者应用程序之间并不直接交互，而是依赖于称为“主题”的公共媒体。因此，发布-订阅模式是一个松散耦合的消息传递cdxxd模型。

正是基于这些特性，发布-订阅模式（简称为“发布/订阅”）成为了构建企业级.NET应用程序不可或缺的工具。

PART 01

分布式事件驱动架构探索

为了设计分布式事件驱动体系架构，开发人员以往倾向于采用以下方案之一。

1、RDBMS提供数据通知

如果数据存储仅限于关系数据库，数据库通知功能的确可以做到。除了允许向数据库服务器注册事件外，该功能还会在数据库结果集因更新、添加或删除而发生更改时，通知到应用程序侧。

但这里有一个问题， RDBMS本质上是不可扩展的 ，很容易成为应用程序的性能瓶颈。典型情况下，开发者不想让数据库承担不必要的额外任务。此外，数据库通知功能本身速度也较慢，而且不支持运行时数据共享。

这就不难理解，将数据库用作消息传递介质并不是最佳设计选择。

2、消息队列

另一种选择是在体系架构中引入单独的消息队列。虽然这些消息队列在帮助您在应用程序之间传输消息方面做得很好，但这些队列并不是以数据为中心的，即它们不监视数据库或任何其他源中的数据更改。此外，这些消息队列无法与应用层一起扩展。

3、自定义解决方案

剩下的最后一个选择是，打造适合自己需要的消息平台。定制解决方案这个想法乍一看很诱人，但是在所需的时间和资源方面都可能难以预估，因为构建和管理一个健壮且可扩展的消息传递平台是一项非常艰巨的任务。

问题症结在于：究竟哪种解决方案更易于合并、可扩展、高可用且非常可靠？

PART 02

以分布式缓存作为消息传递平台

这里分享一种使用分布式缓存消息传递平台NCache。事实证明，这不仅是一个简单可行的解决办法，而且也是整合健壮消息传递平台的一种更现代化的方法。NCache是目前市场上提供的唯一真正的本地.NET