本土集成系统还是 ESB？答案

【问题标题】：Homegrown integration system OR ESB?本土集成系统还是 ESB？
【发布时间】：2013-06-17 21:12:29
【问题描述】：

我最近刚开始在一家小公司工作，该公司目前正经历着成长的痛苦。我不确定我要在这里描述的是什么样的系统。本质上，我们有许多不同的 3rd 应用程序，它们通过一个本土的“集成系统”相互通信，该系统混合了 SQL 作业、用 .NET 编写的后台服务、FTP 传输和 SSIS 等。

这是鸟瞰图：我们面向公众的网站是一个由供应商在场外托管的订单输入系统（第三方购物车软件）。我们每天每 4 小时下载一次订单信息。然后，这些数据会被我们自己开发的“集成系统”处理，该系统会将这些信息提供给我们的库存和仓库管理系统 (WMS)。它还向 MS Great Plains、Pulse、PayFuse 和第三方 CMS 等提供信息。

正如您可能已经猜到的那样，这种架构非常脆弱，一个轻微的意外（例如 FTP 失败的 SQL 作业失败）可能会导致数据的差异，从而产生多米诺骨牌效应。有时，由于数据相关问题或复制问题可能导致整个仓库停滞不前，我们有时无法接受订单、处理或运送订单。

我的任务是重新构建我们的系统并消除系统的紧密耦合以促进业务增长。我需要研究哪些领域？我一直在研究 ESB 和 SOA，但有人告诉我，我的公司负担不起与 iWay 或 Talend 相比的 50 万美元。

有哪些选择？内部开发是答案吗？它是否比 ESB 实施便宜？有没有人经历过类似的成长烦恼？如果有，您是如何处理整合的？

【问题讨论】：

首先：以下软件是我自己开发的（大部分）---你可以试试我的FOSS项目Shuttle（shuttle.codeplex.com）。在托管环境中，您可以从 sql server 表中运行队列。它正在一家大型国际保险公司和南非四大银行之一的生产中运行。也可以在其他地方使用，但我不会意识到这一点。试一试，如果你想看看，请告诉我你的想法。

标签： .net architecture integration soa esb

【解决方案1】：

下面是我解决这个问题的方法。

忘记单一“完美”系统的前期设计。
忘记一次性更换所有东西。
找一些会引起很多痛苦、相对容易更换、不会威胁到企业生存的东西。先解决这个问题。

在某些方面，存在“许多不同的第三种应用程序的杂烩”这一事实是一件好事。您可以将更好的保留在原地，而专注于修复具有最大商业价值的部分。

找出您稳定的业务概念并明确地对其进行建模。命令和事件模式在这里是你的朋友。按照SOA 原则将这些概念分组到“服务”中。

从您的文字来看，围绕 SLA 的讨论似乎已经隐含开始。明确这些 SLA 讨论，但要关注随着时间的推移朝着一个目标而改进，而不是一夜之间的转变。

这种转变的手动基础设施可能不值得花时间，但在你知道你要去哪里之前花 6 或 7 位数购买一个产品也是不明智的。既然您提到了.Net，我就使用了NServiceBus，并发现它是一种愉快的编程体验。您专注于您的领域和业务逻辑，让 NSB 处理管道/基础设施。对于低消息吞吐量，有一个免费选项。这使您可以在讨论预算和资金之前提供一些商业价值。除了网站上的文档之外，还有一个蓬勃发展的NServiceBus community 可以帮助您入门。

.net 空间中还有其他选项，包括MassTransit 和EventStore。我没有亲自使用过这些，而且它们在功能上并不相同，因此您需要仔细查看它们，看看有什么满足您的需求和团队的能力。

【讨论】：

海事组织的好答案。我同意 Kijana 的做法。在第一次修复之后，重点改进保持业务运行的流程：即接受订单，并确保系统可用且不丢失数据。以小步骤优化架构，随时增加价值和稳定性。根据我的经验，Kajina 提到的产品确实很有帮助。我会远离昂贵的经纪人类型的产品，因为它们往往只会引入另一个故障点和复杂性，并且在解决任何问题之前都会花费你很多美元。这是一项艰巨的任务，您无法一次全部解决。
我正在一个项目中工作，该项目用于 Java 部分 Talend ESB。我们的开发团队使用 .NET 和 NServiceBus。我们开发了一个定制的 ActiveMQ 传输层，用于在几周内与 Talend 解决方案进行本地集成。社区，尤其是 NServiceBus 周围的人们帮助我们解决了这些问题。社区是 NServiceBus 的最大好处。我不会尝试自行推出，因为管理事务等事情会延迟您的功能输出几个月......
虽然我喜欢一个社区，但很难卖出这样的东西。特别是因为我自己和 Umbraco 一起爱上了它。最新版本应该很棒并且支持 MVC 并且有一个很棒的社区。直到 Umbraco 组织。决定放弃那个版本，因为它的架构设计很糟糕。我们几乎在其中投入了大量资金。很高兴我们稍微推迟了这个项目。幸运的是 NServiceBus 已付费支持：particular.net/support
同意 Kijana，很好的答案。尝试找到处于流程结束开始的组件。听起来您的集成点是不错的候选者。使用 SOA 和 EDA 可以更轻松地将这些从大泥球中提取到自主组件中。

【解决方案2】：

在过去的几年里，我们一直在解决一些类似的问题。利用 ESB 将帮助您减少它。一旦团队开始欣赏这种解耦，这就会开始给你带来好处，它将加速这个过程。我最熟悉 NServiceBus，我们发现它的进入门槛非常低。开发人员快速上手，而且试用成本低。我同意您希望从对业务最关键的领域开始，并首先将其打下坚实的基础。

【讨论】：