Biztalk用于EAI和ESB用于EAI场景的比较

Question

Biztalk用于EAI和ESB用于EAI场景的比较

4

我对ESB或Biztalk并不太熟悉，但我正在努力理解如果您已经拥有Biztalk，从EAI的角度来看哪种方案最合理。据我了解，Biztalk是消息代理（集线器和分支），而ESB模式是反代理，其中概念上的“总线”由相互通信的单个分布式组件组成。与ESB不同，消息代理固有地代表单点故障，其中一个组件失败不会使“总线”作为整体崩溃。此外，我的理解是，Biztalk在消息传递、编排方面是单块的，耦合度高，扩展性有问题。

如果现有情况是：

- Biztalk已被主要用于基于从外部方收到的不同文件运行不同编排。 - 大量内部自定义应用程序目前与CRM和工资单等系统紧密耦合，需要重构以抽象出这些依赖关系。

那么使用Biztalk直接或Biztalk ESB工具包实现ESB功能是否有意义，或者使用像NServiceBus或基于Azure Service Bus的Service Bus for Windows这样的适当的ESB实现是否有意义。使用Biztalk直接实现EAI与使用适当的ESB的利弊是什么？每个应用程序是否都会对Biztalk产生严格的依赖关系，这是否可取？

由于没有正确或错误的答案，因此我将把这留作开放式讨论。

@StuartLC：

感谢您的回复。我已阅读了您发布的几个链接，但仍然没有清晰地了解Biztalk作为ESB解决方案是否有意义，而不是使用NServiceBus之类的东西。两者似乎都以某种方式实现“ESB”模式。问题在于哪一个具有更干净的实现、更好的开发体验和低的上手时间。到目前为止（仅从纯研究角度），我的评估是：是的，Biztalk可以使用，但是需要非常专业的开发技能，延迟和扩展性存在问题，并且Biztalk最终将被吸收到（Azure？）服务总线中，Biztalk SKU将停止存在。另一方面，像NService bus这样的框架具有相对较低的上手时间，可以很容易地被通常具有良好.NET编程技能的开发人员掌握，并且可以轻松地与Biztalk接口。鉴于以上情况，即使您目前拥有Biztalk，是否仍然有意义选择Biztalk路线，还是选择适当的ESB，例如NService Bus，以未来保护自己？

- Abhijeet Patel

我的建议是：我认为选择像NServiceBus、MassTransit或Windows Service Bus这样的ESB解决方案会是更好的选择。让开发人员熟悉BizTalk的细节可能需要花费很多时间，至少从我的经验来看是这样的。 - HashName

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- StuartLC · Accepted Answer

我认为你开放式问题的许多组成部分已经在SO上被涵盖了:

然而，在我看来，这只是一种有缺陷/短视的实现方式，会导致应用程序和端点之间的紧密耦合。松散耦合很容易实现：（即使没有ESB工具包）：

通过使用多部分消息和规范的内部模式来解耦依赖关系。
通过发布消息至消息框架，编排和端口应解耦。

也可以避免单点故障:

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

在使用BizTalk作为ESB时IMO的Achilles腱是缺乏保证的延迟，例如此处，如果BTS进入限流状态，这种情况会加剧。

更新

在我看来，选择问题归结为是否对环境中的所有系统具有控制权。

如果您正在集成一个仅由同质、现代（大多属于 SOA 和 EDA）应用程序组成的内部企业，并且您可以直接控制这些应用程序，MassTransit 或 NServiceBus 可能更适合您，可以提高您的生产力和启动时间。