自产的集成系统或ESB？

Question

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

以下是鸟瞰图： 我们面向公众的网站是供应商在场外托管的订单输入系统（第三方购物车软件）。我们每天每4小时下载订单信息。然后，我们的本土“集成系统”将这些数据进行按摩，该系统将此信息提供给我们的库存和仓库管理系统（WMS）。它还向MS Great Plains，Pulse，PayFuse和第三方CMS等提供信息。

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

我的任务是重新构建我们的系统并消除系统的紧密耦合以实现业务增长。我需要研究哪些方面？我一直在研究ESB和SOA，但我被告知，我的公司无法承担与iWay或Talend相关的50万美元的承诺。

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

Answer 1

以下是我如何解决这个问题。

1. 忘掉单个“完美”系统的前期设计。
2. 忘记一次更换所有东西。
3. 找到导致很多痛苦的事情，相对容易更换，并且不会威胁到业务的存在。首先开展工作。

在某些方面，存在“许多不同的第三应用程序的大杂烩”这一事实是一件好事。你可以把更好的那些放在适当的位置，同时专注于修复那些商业价值最高的那些。

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

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

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

.net空间中还有其他选项，包括MassTransit和EventStore。我没有亲自使用它们，它们在功能上并不相同，所以你需要查看它们，看看它们满足你的需求和团队的能力。

Answer 2

在过去的几年里，我们一直在努力解决一些类似的问题。利用ESB将帮助您消除它。一旦团队开始欣赏脱钩，这开始给你带来它将加速这个过程。我对NServiceBus最熟悉，我们发现它的入门门槛非常低。开发人员快速捡起它，尝试的成本很低。我同意你想从对业务最关键的领域开始，并首先在坚实的基础上实现这一目标。