我们应该引入 BizTalk/ESB 吗？

Posted 2023-02-15

【中文标题】我们应该引入 BizTalk/ESB 吗？

【英文标题】：Should we introduce BizTalk/ESB?

【发布时间】：2010-09-25 07:50:50

【问题描述】：

我的公司即将实施一个新架构，我们在其中提出了 BizTalk（我们是一家 Microsoft 商店）作为 SOA（请不要引用面向服务的歧义）环境中的企业服务总线 (ESB)。

我们的业务是通过我们的新订单捕获 GUI 接收订单，该 GUI 必须连接到我们的客户数据库、产品目录、订购系统和其他一些辅助系统，每个系统都将作为 WCF 服务公开，然后将订单传递给我们的订单管理和其他下游系统用于履行，最后到我们的计费系统进行开发票。目前，每个系统都有自己的 GUI，并使用手动过程在它们之间传递信息，以实现自动化和集成，自然的想法是引入 ESB 来连接它们。

我对 ESB 的一些基本原理是，总线会担心如何连接系统（每个系统都是不可知的，对任何其他系统一无所知）以及如何格式化/翻译信息。将来很有可能将某些现有系统替换为新系统或我们公司家族中的系统。

这对我来说似乎很有意义，但我现在遇到了一些阻力，即为什么在点对点解决方案足够的情况下引入它。

不幸的是，在公司历史上（在我任命之前），引入 BizTalk 的初步尝试失败了，但我相信它有一席之地并且我可以交付它。

我的问题可能不是关于 BizTalk，而是 ESB 在我所描述的场景中是否是一个好主意，何时引入 ESB 有意义？

【参考方案1】：

好的。来自规范架构组的 Biztalk 的 ESB 指南 - http://msdn.microsoft.com/en-us/library/cc487894.aspx

我们在我工作的地方使用 BizTalk 来做很多事情。他有一些简单的积分。我们与高度定制的适配器和管道进行了一些更复杂的点集成。我们有针对客户主数据、产品信息和价格以及订单报价的部门企业系统集成。这些都是单独的 BizTalk 应用程序。有些很小，有些很大。我们主要使用 BizTalk 进行点对点/多点解决方案，而不使用 ESB 模式。 ESB 的实现意味着总线本身的治理水平和总线上允许的企业消息标准。如果您将与具有大量不同格式的大量系统交互 - ESB 非常有意义。如果您想要实现的集成不那么雄心勃勃，那么 ESB 可能是矫枉过正。话虽如此，它是一个干净且可扩展的架构。您必须做出成本价值决定。

BizTalk 也是一个复杂的野兽，但所有活动部件都具有一定程度的灵活性，非常棒。但要为学习曲线或一些顾问费用做好准备。

【参考方案2】：

一位同事刚刚问了我同样的问题，这就是我对他说的：

在大多数集成场景中，您可以 在使用某物之前走很远 像 BizTalk。我会确保 我不能做更多的整合 只是在使用 BizTalk 之前。

仅当似乎集成 解决方案需要扩展到高 具有低延迟的卷（它有一个 奇妙的异步 发布-订阅机制），而你 需要容错（它有 冗余、扩展和消息重试 功能）和治理 解决方案（它有业务活动 监控）你真的有吗 考虑使用的有力论据 商务对话。如果你知道那里 是多个未来的集成， 将需要然后它变得真的 令人信服地使用 BizTalk。

另一方面，您需要 确保技能可用于 操作这个东西。需要一段时间 学习和范式转变 系统的开发人员。然而 它是在 .NET 中从头开始构建的 和 SQL Server，所以有很多 熟悉工具和 概念。

我认为关键是获得 解决方案的概念架构 权利考虑到 非功能性需求，例如 性能、可用​​性、 可扩展性、弹性、鲁棒性、 和可扩展性，并确保它们 得到妥善解决 技术设计。你可能会发现它 为每个 CPU 支付 35k 美元更便宜 BizTalk 为您提供的许可 盒子比开发所有这些 NFR。

此外，我最近在一个客户处实现了新的 ESB Toolkit 2.0，对此我感到非常满意。 Itinerary（参见 Routing Slip 模式http://www.enterpriseintegrationpatterns.com/RoutingTable.html）处理功能确实使编写 Web 服务变得简单、灵活和快速。

【参考方案3】：

我认为根据您描述的要求拥有一个数据代理是有意义的，但我个人认为 BizTalk 不是您情况下的最佳选择。 对于您描述的集成类型，我将查看硬件数据代理设备。我见过运行良好的有 IBM DataPower、Vordel 的设备和 Layer7 的设备。对于您将使用它的呼叫类型，设备是理想的。它们提供路由、转换和翻译，此外它们还可以防止模式中毒等问题。他们还将通过将其链接到您的用户存储来处理授权、身份验证和审核（我猜您有一个基于您描述的环境的 Active Directory 用户存储，但它也适用于 LDAP）

就拥有成本（无支持成本）而言，设备将是 BizTalk 或任何其他软件解决方案，并且任何设备的性能都可能比 BizTalk 高一个数量级。

【参考方案4】：

我倾向于避免使用 ESB 术语，因为我认为它严重超载；归根结底，在我听到的所有各种描述中，它只是一种模式，曾经是 BizTalk 非常支持的模式。

那么 - 我认为 BizTalk 是否符合您的要求？绝对是的。 我认为避免点对点连接是正确的吗？也是的，但是，就像任何重用重构练习（包括任何 SOA 计划）一样，您必须考虑您期望有多少变化和现在多少重用来决定多远你正在“脱钩”练习。

【参考方案5】：

您需要谈谈延迟和吞吐量。其他一切都只是废话。

【参考方案6】：

这是一个非常独特的模式。通常，当您从系统 A 向系统 B 发送消息时，您会将系统 A 的格式直接转换为系统 B 想要的格式。当您拥有 ESB 时，您将系统 A 的消息转换为 ESB 格式（即通用 PO、订单等），然后转换为系统 B 所需的格式。这是对 1 的两次转换，而且总线模式需要每个消息都有一个动词（即添加、删除、更新等）。这是一个真正重要的区别，也是 ESB 在与许多参与系统集成时非常有用的原因。