在重新设计遗留应用程序时,解耦是否有益?

时间:2010-08-17 12:36:49

标签: web-services soap business-logic decoupling

我正在经营一家经营多家互联网商店的公司。我们将完全重写整个代码:网站内容和产品管理,订单处理,合作伙伴关系,会计,客户群等。目前我们有一个系统,其中所有的东西(所有内部管理站点,业务逻辑和互联网商店网站)紧密耦合在单个LAMP实例上运行,并且绝对所有数据都位于字面上单个垃圾数据库中。正因为如此(也是因为10年的开发,部分改写自perl,php代码质量)引入新的网络商店,重新设计任何现有的或改变逻辑中的任何东西是一种不可能完成的任务。

为了不仅重写旧代码而且还优化系统架构,我肯定决定将网站(彼此相互分离)分开,将“业务核心”与网站和业务核心相互分离。

从某一点来说,所有的网店都主要销售一个共同的产品基础,它们是一种镜子,有时只是针对国际客户设计的不同(标题和描述可能会有所不同)。我们销售的产品是一种服务产品,取决于当地合作伙伴,但具有共同的预定义产品系列。但在一些城市我们有特价,在其他城市我们提供增强的产品范围和常见的范围。因此,我们还运营专注于单个城市的专用网站,仅销售特价商品的网站等。

与每个网站都有自己的产品数据库(有时是另一个的副本)的解决方案相比,我正在考虑将所有产品描述性信息,不同城市和/或不同地点的可用性和价格组合成一个孤立的产品管理系统,通过SOAP提供所有信息。每当任何用户访问任何站点时,站点将使用该服务(提供一些参数),然后列出产品。显然可以开发通用的访问库,将其包含在每个站点中。

1)该解决方案是否足够?没有缓存,它的执行速度是否足够快?我们的资源有限(1.5开发人员)所以我试图不引入(如果可能的话)其他技术复杂性,比如要求在每个站点上使用memcached。

2)假设,我以解耦的方式重建系统。利益是否足以让我自己参与memcached等的所有工作?

3)在SOAP服务器端缓存数据是合理的,但是在网站上没有,并继续发出数千个soap请求?

所有系统都将被解耦,其中一些与之相关的网站是例如订单处理,客户授权(所有网站都是通用的),支付接收集成等。如果订单处理需要订单时通过SOAP远程放置web站点将其置于处理系统中,然后依次暴露自己的SOAP服务器以接收订单状态更新。

4)这种解耦SOAP中心哲学是对吗?

使用的技术是nginx,php,MySQL

1 个答案:

答案 0 :(得分:0)

爱德华。我会尽力回答你的问题。首先,我会给出一个小序言,然后逐点说明:

予。显而易见,完全重写必须是系统架构的优化,只是为了有一定意义。在您的特定情况下,在架构中引入“一些”模块化是这种类型的优化。 (我还要强调,在你使用某种AR风格的应用程序框架之前,你的代码中必须至少有三个可识别的语料库:

1)模型现在是一个非常“通用”的术语,但是将域(对象和关系)的所有抽象知识与那些与那些没有多大关系的东西分开仍然是有意义的。 2)数据持久性组织,它基本上是一个“数据访问层”,但我希望它可以不是那么厚,因为你选择的ORM框架。
3)其他库代码,不属于上述

使用此设置,您可以将所有大量代码部分重新分发,并在可能需要的虚拟节点之间共享。

II。我可以做的一个小问题是关于应用质量的一般概念。您将被迫在系统的简洁性,项目截止日期和最终的性能指标之间找到平衡点。这些都是矛盾的要求,但我不能说你的主要内容是什么。但是过于笼统和抽象的代码可能难以维护,因此您必须至少对结果系统的功能要求进行有效描述。我认为至少有效期为3-5个月。


现在相关部分:
1)足够吗?至少它必须比你现在拥有的东西更加宽松。没有缓存它会快速执行吗?我真的不知道,但我认为简短的回答是“不” - 我想你的意思是确切的目标数据缓存(大数据集),我看不到任何类似memcache的东西。 (顺便说一句,你没有1.5开发人员,但是(1 - 0.25)开发人员,是什么让你0.75我猜:)) 2)作为一个建议,你可以用比PHP更糟糕的东西编写与业务逻辑相关的代理。除此之外 - 取决于您对可能涉及的技术的个人经验 3)我认为无论哪种方式都可行,我认为网络缓存更好,因为你可以消除可能的瓶颈
4)对于那个具体的例子?不在我的视野中。作为一个论点,我可以说,整合两个网站(!)通常是一个糟糕的过程。