架构模式 Pub/Sub 扩展和灾难恢复
我们将拥有一个通过 JMS 兼容的发布/订阅基础设施广播消息的源系统。 对于发布的大多数消息，订阅者将是使用消息中的数据更新屏幕的 GUI 应用程序。
然而，订阅者之一将是翻译服务。 对于发布的某些消息，翻译服务会将消息翻译成不同的格式，并将其发布到企业不同部分拥有的辅助消息传递基础设施上。
如何扩展我的翻译服务并提供理想的主动容错能力？ 一些注意事项：
- 消息需要按顺序发布到辅助消息基础设施上。
- 消息只能在辅助消息基础设施上发布一次。
基本上，如何确保只有 1 个翻译服务订阅者响应消息？ 我是否需要切换到基于队列的系统（但我的 GUI 仍然需要发布/订阅语义）？
请注意，翻译服务将使用 Windows Server 2003 中托管的 .Net 3.5 应用程序。我们提供 F5 Network 的 BigIP LTM/GTM。
需要更多详细信息请询问/评论。
提前致谢。
We will have a source system broadcasting messages over a JMS compliant pub/sub infrastructure. For the majority of messages published the subscribers will be GUI applications updating a screen with the data in the message.
One of the subscribers, however, will be a translation service. For certain messages published the translation service will translate the message into a different format and publish it onto a secondary messaging infrastructure owned by a different part of the enterprise.
How can I scale out my translation service and provide, ideally, active-active fault tolerance? Some notes:
- The messages need to be published onto the secondary messaging infrastructure in order.
- The messages must only be published once onto the secondary messaging infrastructure.
Basically, how do I make sure that only 1 translation service subscriber responds to the messages? Do I need to switch to a queue based system (but my GUIs will still need pub/sub semantics)?
Note that the translation service will bet a .Net 3.5 application hosted in Windows Server 2003. We have F5 Network's BigIP LTM/GTMs available.
Any more details required please ask/comment.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这可能会有所帮助：http://www.enterpriseintegrationpatterns.com/toc.html
This might help: http://www.enterpriseintegrationpatterns.com/toc.html
查看 wcf 中的可靠消息传递。 也许有帮助
Look at reliable messaging in wcf. Perhaps it helps