4

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

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

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

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

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

4

2 回答 2

7

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

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

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

寻找您稳定的业务概念并明确地建模。命令和事件模式在这里是你的朋友。遵循SOA原则将这些概念组合成“服务” 。

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

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

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

于 2013-06-23T17:31:02.770 回答
2

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

于 2013-06-23T21:05:27.110 回答