ESB - 购买还是自建？

引言

在之前的文章中，我讨论了通用的ESB概念、路由和消息格式，以提供一种实用的ESB模式方法。在本文中，我将讨论如何选择技术，更具体地说，是应该自己编写ESB还是选择商业解决方案，如MS BizTalk、Mulesoft、WSO2、Azure Services、Tibco等——这场讨论将从两个角度进行：技术角度和法律、合规或公司角度。

首先，什么是ESB？

首先，我将花一点时间讨论什么是ESB，主要是因为CodeProject的一位成员指出，不解释文章的关键缩写是不被接受的（谢谢！），而且这也为接下来的讨论提供了一个很好的框架。

ESB（企业服务总线）是一种允许系统之间共享数据的机制，通常是ERP、CRM等业务系统，以实时但异步的方式进行。基本原理或模式是发布-订阅，这意味着系统发布数据（以消息的形式，通常与某个对象/实体的更改有关），而其他系统订阅这些数据并以它们能够理解的形式接收消息。

换句话说，它通常是一对多的通信，因此源系统只会知道其发布的消息已被ESB接收，而不知道是否已成功传递到任何目标系统。

这种模式有很多优点，但不出所料，也有一些需要注意的地方。

首先，它是一种避免点对点集成的方法，这种方法将导致任何应用程序（SaaS或本地部署，无论集成是自制的还是商业插件）的缓慢消亡，但它也提供了许多管理、监控、节流、日志记录和调节通信的机会，否则这些将是困难的，甚至是不可能的。

另一方面，ESB的解耦特性意味着可能很难知道系统是否真的得到了更新，因此可能需要一个报告框架和对账例程来弥补这些缺点（我在一篇之前的文章中讨论过这一点）。

技术视角

由于ESB的异步性质——实际上是发布-订阅模式的异步性质，ESB可以高度组件化。ESB包括

• 接收机制
  源系统发布数据，ESB接收
• 路由机制
  消息被复制并分发给所有相关的订阅者
• 转换机制
  将消息转换为订阅目标系统相关的消息
• 传输机制
  能够将消息传输到目标系统

这些组件中的每一个都可以实现为完全独立的系统，它们甚至可以在各自的环境中运行在各自的服务器实例上。因此，它们也可以用各自的技术来实现——尽管这可能很少是理想的。

在大型组织中，ESB——或总的来说，集成——通常由一个专门的团队创建和维护，通常具有相当统一的技能集。逻辑上的结果是在这个范围内使用技术实现。然而，也可能做出了选择，例如，用某种经过验证的健壮且经过严格监控的技术实现所有面向外部的端点。ESB很容易适应这一点，因为它只会影响接收机制。

组件列表仍然看起来令人生畏，需要实现很多功能，但正如我在之前的文章中所展示的，它可能不像看起来那么糟糕。首先，你应该总是尽量只实现对你的需求至关重要的功能——如果你有选择的话。

纵观组件列表，路由机制就是一个已经存在的现有功能的例子，在大多数情况下，重新实现它只会导致一个效率不如选择一些现成解决方案的结果，比如传统数据库（如BizTalk使用的SQL Server）、具有特定发布-订阅功能的内存数据库（如Redis）或者我个人最喜欢的AMQP消息队列RabbitMQ。

大多数开发团队可能都有数据库技能，数据库解决方案似乎是显而易见的.一个数据库有很多引人注目的优点，比如可以随时查看其中数据的详细信息。

然而，根据我的经验，即使简单的消息分发看起来是可以实现的（插入行、复制行、读取行、标记为已读、删除或移动已读行），保持数据库为空（所有消息都已发送）会成为一个挑战，随着时间的推移，会越来越难以弄清楚发生了什么，该做什么，数据库中的数据有多重要等等。这会变成一个运维问题。

我坚信路由机制应该是事件驱动的，而对于传统的RDBMS，这需要编写触发器。设计复杂度增加。

根据我所经历的用例，ESB提供高水平的传输可靠性一直是其关键特性。出于同样的原因，我从未将Redis的发布-订阅功能视为一个选项，因为它（据我所知）要求接收方始终在线，才能确保收到所有消息。尽管如此，这仍然可能有适用的用例。

这样我们就只剩下消息队列了。它有（可选的）持久性，它是事件驱动的，它的简单性带来了相当简单的运维场景、简单的监控、告警等，并且它有简单的、基于元数据的路由键机制。这是我喜欢的路由机制。（请查看www.rabbitmq.com）。

这仍然意味着接收位置、转换和传输组件需要手动实现！是的，确实如此。这就是你特定的集成需求变得可见的地方，成为待完成工作需求规格的一部分。

接收位置和消费者都可以单独实现。如前所述，它们甚至可以是混合技术的。虽然这可能不是理想的，但它确实为技术实验提供了机会。用Go语言编写的特定消息类型的消费者可以与一个使用相同消息类型的Mulesoft流共存。

那么商业产品能给你带来什么呢？好吧，它们各不相同！但很多情况下，你会得到一种应用程序服务器；通常附带一个管理控制台，有时还有一个开发环境。

我不认为应用程序服务器能带来什么好处！它们通常代表一个额外的单点故障，但更糟糕的是，它们可能会让一个组件中的错误扩散到所有其他组件。我曾经历过一个Mulesoft流崩溃，导致整个服务器宕机，以及其他所有运行的流。因此，我建议为每个流运行独立的服务器实例——就像Mulesoft的云版本提供的那样，或者我选择一个不包含应用程序服务器的更精简的方向。

说到Mulesoft，它提供了一个IDE，可以在图形用户界面中构建流，基本上是将功能性微组件连接起来。我是一名程序员，不太喜欢不知道确切运行的是什么代码并且无法访问它。不过，我必须说，这些流的图形表示很容易理解，并且对于那些没有创建它们的人来说更容易访问。

如果我要为应用程序服务器辩护，我会强调它们的管理和报告功能。它们通常能够提供关于正在运行的组件的详细信息，并提供启动和停止它们的句柄，而这些是你需要以某种方式实现的。

在生产力或开发速度方面，我没有经历过选择商业产品带来显著差异，但如果你是第一次实施，选择一个事物以特定方式完成的环境可能会有益。你会在过程中收到请求，如果你对你的设计经验有限，可能会很难坚持你的设计。

所以从技术角度来看，没有正确的答案。你必须考虑你组织的开发技能集——你能否保持在你当前的技能集内，还是必须进行扩展？如果你选择购买商业解决方案，你将不得不培训你的开发者正确使用它。如果你选择自己构建解决方案，你应该在你的设计和架构方面培训你的开发者。

同样，你应该考虑你的运维环境。交付成果会是什么样子，如何监控？当问题发生时，你的运维团队能做什么等等。你的技术栈中已经有什么了？

法律/合规视角

ESB很少作为业余项目实现，恰恰相反，它通常是企业应用程序的一部分，因此必须在许多方面契合——如前所述的可用技能集、运维可能性、法律/合规性要求等。

法律和合规方面很少被认识到，但实际上至少与技术方面一样重要。

在审计/合规的背景下，内部开发的解决方案充其量可能是一个耗时的经历。审计员会将内部开发的 कोड 视为一种负债，并且需要深入了解数据发生了什么和未发生什么，风险和安全级别是什么等等。你可能需要考虑将“可审计性”作为设计中的一个非功能性需求；基本上，这将是为了提供检查点供审计员查看正在发生的事情，并在相关点进行日志记录（主要是输入和输出）。

同样，你的法务部门将需要了解你可能依赖的所有库的许可信息。如果你不小心侵犯了你实施深层代码中的某些库的所有权，成本后果可能会非常严重。

因此，你应该至少有完善的设计文档，并且所有许可证都应易于获取且处于最新状态，反映你正在使用的各种代码库的版本（包括你可能与库“继承”的依赖项）。

这通常不是商业产品的状况。开源产品的情况有些不确定。它们可能无法保证不依赖第三方代码，因此很少被法律部门欢迎用于任务关键型软件。对于大多数成熟的开源项目，存在销售和支持该产品的公司，并承担法律责任。你需要在每个实例中自行考虑你如何评价这种类型的保证。

底线是，虽然使用自己的代码完全有可能符合PCI、SOX、CFR第11条或类似框架的要求，但这将使过程复杂化。

结论

总的来说，选择ESB与选择其各个组件的原则是相同的：你应该只在差异化流程上投入开发精力。然而，ESB中除了路由机制和一些连接组件之外，并没有多少是标准的。我认为，是购买还是自建的选择主要取决于你的组织。然而，我希望我已经提供了一些观点，可以帮助你更清晰地做出选择。