该应用程序涉及许多单独的Web应用程序 – 其中一些本质上是接收数据的WCF服务,一些是用户管理数据的站点.另外,还需要一个在后台运行的worker服务,它将以各种方式处理数据.
我非常希望为此使用解耦体系结构.理想情况下,我希望组件(即Web应用程序和工作人员服务)尽可能少地了解彼此.似乎使用消息队列将是最好的解决方案 – 网络应用程序可以将工作单元的消息排入队列,并且工作服务可以根据需要选择它们并处理它们.
不过,我想为此做出一整套技术,同时考虑到我最终将转向Azure,并希望尽量减少迁移到云端时需要做的重新工作量. . Azure具有内置的队列组件,其中看起来非常适合我的需要.我想做的是创造一些自己会尽可能模仿的东西.
看起来有几个选项(我在Windows上使用.NET,sql Server 2005后端) – 我发现的到目前为止：
> MSMQ
> sql Server服务代理
>使用数据库表和一些存储过程滚动我自己
我想知道有没有人对此有任何建议 – 或者如果有人做了类似的事情,并且有关于要做/避免的事情的建议.我意识到每一种情况都是不同的,但在这种情况下,我认为我的排队要求是非常通用的,所以我很乐意听到任何人对最好的方式的想法.
提前致谢,
约翰
解决方法
一个快速3048米的MSMQ与SSB的比较(我将离开一个自定义的排队比赛,因为它真的取决于你如何实现它…)
>部署：MSMQ是Windows组件,SSB是sql组件. SSB需要一个sql实例来存储任何消息,所以断开的客户端需要访问一个实例(可以是Express). MSMQ需要在客户端部署MSMQ(部分操作系统,但可选安装).
>可编程性：MSMQ提供了一个完整的,受支持的WCF通道. SSB在http://ssbwcf.codeplex.com仅提供实验性WCF频道
>性能：在交易模式下,SSB将显着快于MSMQ.如果允许以非交易模式运行,MSMQ将更快(尽力而为,无序,交付)
>可查询性：SSB队列可以被选中(查看任何消息,完整的sql JOIN / WHERE / ORDER / GROUP权限),MSMQ队列可以被偷看(只有下一个消息)
>可恢复性：SSB队列集成在数据库中,以便与数据库进行备份和还原,并保持与应用程序状态一致. MSMQ队列备份在NT文件备份子系统中,因此为了使备份保持同步(一致),必须暂停队列和数据库.
>事务(由于每个入队/出队总是伴随着数据库更新)：SSB完全集成在sql中,因此出队和入队是本地事务操作. MSMQ是一个单独的TM(事务管理器),所以队列/出队必须是分布式事务操作,以在事务中注册sql和MSMQ.
>管理与监控：两者都不好.没有任何工具
>相关消息处理：SSB可以通过内置的Conversation Group Locking来阻止相关消息的处理.
>事件驱动：SSB有Activation启动存储过程,MSMQ使用Windows Activation服务.类似.由于WAITFOR(RECEIVE)和MAX_QUEUE_READERS的交互方式,SSB具有自负载平衡功能.
>可用性：SSB搭载sql Server高可用性故事,可以在集群或数据库镜像环境中工作. MSMQ仅适用于Windows群集故事.数据库镜像比作为HA解决方案的集群便宜得多.
另外我补充说,SSB和MSMQ在它们提供的原语水平上有很大差异：SSB原语是一个对话,而MSMQ原语是一个消息.认为TCP与UDP语义.
