问BizTalk是企业服务总线吗？

EN

微软认为BizTalk具有企业服务总线功能--参见BTS ESB toolkit

然而，“企业服务总线”这个术语涵盖了一个非常复杂的broad field，关于企业服务总线的确切定义有很大的主观性。在BizTalk声称作为ESB是全面的(在> 2010定义的术语中)中有一些弱点。

• BTS起源于中心辐射式企业应用集成时代，在企业服务总线成为widespread.
• BTS之前，它更适合于异步流程而不是同步流程-延迟会因系统负载、节流状态等而异。
• BTS在简化服务和架构的版本控制(需要新的部署)时很麻烦
• BTS在管理许多服务时很麻烦(例如，将BizTalk用作公司全部5000个SOA /服务的外观将是痛苦的)

FWIW我们发现BTS非常适合：

Biztalk

• 我们所有的同步和异步企业应用集成(即主要LOB系统之间以及与贸易伙伴之间的正式集成合同)，大量适配器有助于集成大量的Biztalk业务流程和业务监控以及事务和交付可靠性-
• 具有重试、跟踪和恢复挂起消息的功能，这在不可靠的网络上或与不可靠的系统集成时非常有用。

更新，有更多的比较经验

Server是非常集中的--归根结底，即使是多服务器的BizTalk集群/组也依赖于-

• 。基于队列的企业服务总线产品往往更加分散(逻辑上和物理上)，因此失去一些端点或队列服务器不应该拖累整个企业。
• 许多基于队列的企业服务总线构建在开源技术之上，着眼于避免单一供应商锁定
• 许多当代企业服务总线似乎采用commodity-computing方法进行扩展。使用像BizTalk这样的产品向外扩展可以成为一个好的方面，像BTS这样的商业产品的监控和管理能力不应该被低估-确保您正在考虑的任何企业服务总线都具有足够的审计、检测、重试和诊断(WMI / SNMP / SCOM等)功能-您将需要一个仪表板来监控总线的健康状况，没有什么比不知道消息去了哪里更糟糕的了。在这里，集中管理和诊断是一个优势。

BizTalk是一个消息传递和工作流编排平台，您可以在其上构建企业服务总线行为和功能。为了简化这一点，并标准化BizTalk上的企业服务总线实现，微软发布了BizTalk企业服务总线工具包-一组指南、模式和代码。

企业应用集成和业务流程管理的概念已经存在了一段时间，因此有许多公司利用BizTalk来创建这些问题的解决方案。在BizTalk服务器上托管完整的企业服务总线的公司要少得多，而且随着WCF/WF/NServiceBus和Azure Service Bus的出现，采用速度肯定会变慢。

所以总而言之，BizTalk是开箱即用的，而不是企业应用集成或企业服务总线，但可以通过大量的开发人员来解决这两个问题。

通过“ESB或”，我猜你想知道BizTalk是遵循中心辐射式还是总线架构。

从架构模式的角度来看，集成解决方案大致属于以下两种模式之一：

• The中心和分支：这涉及到一个集中的消息代理将消息发送到不同的接收方，而所有发送方只向该代理发送消息。因此，发送者和接收者都不需要知道对方。这通常就是许多人所说的EAI (尽管完全可以实现遵循总线模式的EAI解决方案)。遵循此模式的解决方案易于开发和管理。所有的路由逻辑都集中在一个地方进行管理-在集线器中。但正如您所猜到的，这有一个明显的缺点-单点故障。如果集线器崩溃，一切都会停止。此外，此模型的可伸缩性不是很强，围绕此模式开发的企业集成解决方案通常称为企业服务总线( well.
• BUS：)。这里没有智能的中央权威机构。所有发送者都在总线上发布他们的消息。接收器需要足够智能，以确定哪些消息是要发送给它们的，并将它们从总线上移除。因此，发送者和接收者只需要知道总线。但在这里，路由逻辑分布在接收器上，因此不存在单点故障。此外，该模型具有很高的可扩展性。然而，这样的解决方案相当复杂，很难管理。

关于BizTalk遵循哪种模式的问题--它是这两种模式的混合体。

集线器的外观非常明显，它的集中式消息传递引擎和一个中央MessageBox数据库。这提供了管理的简单性和易用性，这是集线器方法的典型特征。

但是，如果您查看BizTalk体系结构，您可以拥有一个主机，其主机实例分布在多个服务器上。也可以在不同的服务器上配置不同的BizTalk数据库，如MessageBox、Tracking、Ent SSO等。这使得BizTalk解决方案比普通的集线器实现更具可伸缩性和容错性-这是一种通常归因于总线方法的行为。

希望这能回答你的问题。