针对EAI场景的EAI与ESB的Biztalk

Question

我不太熟悉ESB或Biztalk,如果你已经拥有Biztalk,我试图从EAI的角度来看看最有意义的东西.据我所知,Biztalk是一个消息代理(hub和spoke),ESB模式是一个反代理,其中概念"总线"由各个分布式组件组成,这些组件以某种方式相互通信.消息代理本质上代表单点故障,而不是ESB,其中一个组件发生故障并不会导致整个"总线"失效.另外我的理解是Biztalk是单片式的,因为消息传递,编排是紧密耦合的,并且缩放是有问题的.

如果手头的情况是:

• Biztalk主要用于根据从外部各方收到的不同文件运行不同的编排.
• 这是目前紧密耦合到系统,诸如客户关系管理和工资需要点播服务定制appications一束被重构抽象出这些依赖关系.

直接使用Biztalk或Biztalk ESB工具包实现ESB功能是否有意义,或者使用适当的ESB实现(例如基于Azure Service Bus的NServiceBus或Service Bus for Windows)是否有意义.使用Biztalk直接实现EAI与使用适当的ESB相比有哪些优缺点.每个应用程序是否会严格依赖Biztalk以及这是否可取？

由于没有正确或错误的答案,我将把这作为一个开放式的讨论.

@StuartLC: 谢谢你的回复.我已经阅读了您发布的几个链接,但仍然没有清楚地了解Biztalk作为ESB解决方案与使用NServiceBus之类的东西是否有意义.两者似乎都以这种或那种方式实现了"ESB"模式.问题是哪一个具有更清洁的实施,更好的开发经验和低的加速时间.到目前为止我的评估(仅来自纯粹的研究)是可以使用Biztalk,但它很痛苦,需要非常专业的开发.技能.延迟和扩展是有问题的,Biztalk最终会被同化到(Azure？)Service Bus和Biztalk SKU这一事实将不复存在.另一方面,像NService总线这样的框架具有相对较低的加速时间,可以很容易地被开发人员接收.具有良好的.NET编程技能,可以与Biztalk轻松连接.考虑到上述情况,即使您目前在内部拥有Biztalk或未来证明自己使用适当的ESB(例如NService Bus),仍然可以使用Biztalk路线吗？

Answer 1

我相信您的开放式问题的许多组成部分已经涵盖在SO上:

• 使用BizTalk而不是NServiceBus或MassTransit的优点/缺点
• 哪些ESB系统最适合.Net堆栈？
• Microsoft BizTalk Server与Azure AppFabric Service Bus ...？
• BizTalk 2009 ESB混乱
• BizTalk是ESB吗？

但是,IMO只是一个有缺陷/短视的实现,它会导致应用程序和端点之间的紧密耦合.容易实现松耦合:(即使没有ESB工具包):

• 通过使用多部分消息和规范内部模式来解耦依赖性.
• 应通过消息框发布来解耦业务流程和端口

单点故障也是可以避免的:

• 在通信适配器上配置重试和备用/备份传输
• 通过服务器组和群集实现冗余
• 并使用补偿失败的交付回退

IMO使用BizTalk阿喀琉斯之踵时,作为ESB是缺乏保证的延迟例如这里如果BTS进入一个被exarcebated 节流状态.

更新

IMO的选择归结为您是否可以控制环境中的所有系统.

如果您正在整合一个内部企业,该企业仅包含您可以直接控制的同类,当代(以及主要是SOA和EDA)应用程序,MassTransit或者NServiceBus可能不仅仅是提供工作,而且您可以提高工作效率并缩短时间.