异步消息传递(特别是pub/sub-style消息传递)是作为域服务体系结构还是只在面向SOA的环境中可行?

好问题:)。异步消息传递的主要问题是,当人们使用过程性或面向对象的语言时,以异步或基于事件的方式工作通常非常复杂,程序员很难阅读和理解。如果业务逻辑以某种同步方式构建(调用方法并立即获得结果等),则通常会简单得多。

我的经验法则通常是尝试在微级别使用简单的同步编程模型来实现业务逻辑;然后在宏级别使用异步和SEDA。

例如,提交采购订单可能只是将消息写入消息队列;但采购订单的处理可能需要10个不同的步骤,所有这些步骤在高性能分布式系统中都是异步和并行的,有许多并行进程和线程并行处理单个步骤。因此,宏级连接基于一种SEDA方法,但是在微级,单个10个步骤的代码大部分可以用同步编程风格编写。

像许多架构和设计问题一样,答案是“它取决于”。

根据我的经验,异步消息传递的优势在于它为设计带来的松耦合。联轴器可以位于:

• 时间请求可以异步处理,有助于整体的可伸缩性。
• 空间——正如您所指出的,允许以比许多同步设计更可靠的方式进行分布式处理。
• 技术-消息和队列是弥合技术差异的一种方法。

记住,消息和队列是一种抽象,可以有多种实现。您不一定需要使用符合JMS的事务性高性能消息传递框架。正确实现后,关系数据库中的表可以充当队列,行作为消息。我已经看到两种方法都曾产生过巨大的效果。

我也同意@brads的观点。

顺便说一句 here's a way of hiding the middleware from your business logic 同时仍然获得了松散耦合的好处&seda—同时能够轻松地在各种不同的中间件技术之间切换—从内存中的seda到JMS,从amqp到javaspace,再到数据库、文件或ftp等