这是使用服务总线的一个很好的理由,请选择替代品

时间:2010-10-10 15:10:37

标签: asp.net-mvc design-patterns architecture esb

我正处于新网站的规划阶段 - 它是我们构建的一些移动应用的扩展。我们希望为用户提供通信的中心点,并为不想/不能使用移动应用的用户提供功能。我们正在寻求添加的功能之一是与SO徽章系统性质相似的声誉系统。我们正在设计系统以使用SOA。

我不想将所有这些逻辑编码到主应用程序中作为谨慎的块。我正在考虑创建一种方法来实现这一目标,这将允许我们定义新的阈值和规则以获得声誉并将它们注入某些服务。到目前为止,我想到的两种方法是:

  1. 要在用户操作中查找某些特征并做出响应,这意味着要运行一个可以通过“插入”奖励定义运行的服务,并检查已达到的阈值并做出相应的响应。
  2. 在用户执行操作时触发事件 - 聆听这些事件并做出适当的响应。因为将执行这些操作的服务可能在不同的应用程序域中运行,可能在不同的服务器上,我可以看到有一个中央消息总线来监听和响应这些事件的唯一方法是使用MassTransit,nServiceBus或Rhino.Esb之类的东西。 。
  3. 我知道使用服务总线很容易被不恰当地设计到一个根本不需要它的应用程序中,而且大多数时候 - 除非你整合了不同的异构系统 - 你很可能在设计时不需要一个新的系统,但我有点失去选择,以最好的方式来做到这一点。我不喜欢在后台随时使用服务锤击Db的想法。但它确实听起来像早期可能更简单 - 后来 - 我害怕思考!

    这里有没有人设计过这样的系统?你是怎么做到的?我们正在设计高吞吐量,因为我们预计有时候系统需要能够应对突发的用户。

1 个答案:

答案 0 :(得分:4)

我设计了一个具有类似要求的系统。为实现这一目标,关键要素是:

  • 插件
  • 事件消息 - 使用Emesary

基本概念是核心并不知道哪个模块将执行任何给定任务。

定义消息,并在系统内的各个点调度消息。发件人不知道是否需要该邮件。这有效地解耦了系统的大部分内容。

为了执行一项工作,插入一些代码,该代码注册事件消息传递总线并将接收消息。当它收到需要处理的消息时,它将处理它。

Emesary代码在我称之为Emesary的第一个实例中非常小且高效,您可以自由使用它;或者来自Emesary CodePlex

随着系统变得越来越复杂,有可能会有很多事件在飞来飞去,如果你的速度超过每秒20k,那么在我的设计中总是添加过滤和路由(通过扩展接收器接口来实现收件人在注册时指定要接收的邮件。我从来不需要添加这个过滤,因为Emesary足够高效,它是处理消耗时间的消息。

我已经构建了一个版本的Emesary,它使用WCF,Corba和TCP / IP在不同的系统中桥接两个通知程序。我使用RabbitMQ进行了调查,并决定如果需要可以在Emesary下面使用它。

基类图

Emesary Class Diagram

可扩展服务器。

这是一个相当复杂的例子,但它显示了Emesary适合的位置。在此图中,任何带有投影的东​​西都可以有多个实例,这是在我试图解释的范围之外进行管理。

scalable application server