.net - 本土集成系统还是 ESB？

Question

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

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

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

我的任务是重新构建我们的系统并消除系统的紧密耦合以允许业务增长。我需要研究哪些领域？我一直在研究 ESB 和 SOA，但被告知我的公司无法承担 iWay 或 Talend 等 50 万美元的费用。

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

Answer 1

这是我将如何解决这个问题。

忘记单个“完美”系统的前期设计。

忘记一次更换所有东西。

找到引起很多痛苦的东西，相对容易更换，并且不会威胁到企业的生存。先解决这个问题。

在某些方面，存在“许多不同的第三应用程序的杂烩”这一事实是一件好事。您可以将更好的留在原地，同时专注于修复最具商业值(value)的那些。

寻找您稳定的业务概念并对其进行明确建模。命令和事件模式是您的 friend 。按照 SOA 将这些概念分组为“服务”原则。

从您的文字中可以看出，围绕 SLA 的讨论已经隐含地开始了。使这些 SLA 讨论明确，但重点是随着时间的推移朝着目标改进，而不是一夜之间的转变。

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

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