这是鸟瞰图：
我们面向公众的网站是供应商在场外托管的订单输入系统(第三方购物车软件).我们每天每4小时下载订单信息.然后,我们的本土“集成系统”将这些数据进行按摩,该系统将此信息提供给我们的库存和仓库管理系统(WMS).它还向MS Great Plains,Pulse,PayFuse和第三方CMS等提供信息.
正如您可能已经猜到的那样,这种体系结构非常脆弱,并且轻微的事故(如SQL作业失败的FTP故障)可能会导致数据差异,从而产生多米诺骨牌效应.有时由于数据相关问题或复制问题可能导致整个仓库停滞不前,我们有时无法接受订单,处理或发货订单.
我的任务是重新构建我们的系统并消除系统的紧密耦合以实现业务增长.我需要研究哪些方面？我一直在研究ESB和SOA,但我被告知,我的公司无法承担与iWay或Talend相关的50万美元承诺.
有什么选择？内部开发是答案,是否比ESB实施便宜？有没有人经历过类似的成长痛苦,如果是这样,你是如何处理整合的？
这是我如何处理这个问题.>忘记单个“完美”系统的前端设计.
>忘记一次更换所有东西.
>找到导致很多痛苦的事情,相对容易更换,并且不会威胁到业务的存在.先做这件事.
在某些方面,存在“许多不同的第三应用程序的大杂烩”这一事实是一件好事.你可以把更好的那些放在适当的位置,同时专注于修复那些商业价值最高的那些.
寻找稳定的业务概念并明确地对其进行建模.命令和事件模式是你的朋友.按照SOA原则将这些概念分组为“服务”.
从您的文本来看,围绕SLA的讨论已经隐含地开始了.使这些SLA讨论明确,但重点是随着时间的推移实现目标而不是一夜之间的转变.
为这次改造而手动滚动的基础设施可能不值得花时间,但在你知道你去哪里之前在产品上花费6到7个数字也不明智.既然你提到过.Net,我使用了NServiceBus并发现它是一种愉快的编程体验.您专注于您的域和业务逻辑,让NSB处理管道/基础架构.对于低消息吞吐量,有一个免费选项.这使您可以在讨论预算和资金之前提供一些商业价值.除了网站上的文档之外,还有一个蓬勃发展的NServiceBus community可以帮助您入门.
.net领域还有其他选项,包括MassTransit和EventStore.我没有亲自使用它们,它们在功能上并不相同,所以你需要查看它们,看看哪些符合你的需求和团队的能力.