哪个更好地设计这三个企业架构选项以及为什么?

时间:2015-10-01 06:25:07

标签: architecture soa

我有一个企业应用程序,其中有多个子应用程序执行不同的任务。这些子应用程序将通过Web服务相互交互,以在彼此之间共享功能,并为用户自己完成任务或从两个应用程序功能组合完成任务。

子应用程序中存在一组共同的大量资产(项目),表示这些子应用程序在其上工作的资产商店,它也通过其Web服务向所有这些子应用程序公开。此资产商店可能是外部系统,也可能未部署在同一环境中,也可能位于其他子应用程序所在的云外部。因此,性能可能会受到网络外的影响。

不,考虑到Sub App-1的用户想要对选定的一组资产执行任务,将登录到子应用程序1,转到将向他显示所有可用资产的屏幕。他选择这些资产并添加他的小猫来对他们执行一些操作,处理这些资产然后为他完成任务。同样,不同的子应用程序将访问此公共资产商店,以根据用户登录的子应用程序以不同方式处理它们。

在Sub App 1中处理这些资产时,我们可以通过三种方式进行处理:

  1. 我们对Asset Store子应用程序进行LIVE Web Services调用,以根据用户搜索或条件返回这些产品集。在这种情况下,我们到目前为止还没有在Sub App 1数据库中存储任何内容。用户选择资产后,在Sub App 1中处理它,我们只将该处理过的资产的ID存储在Sub App 1数据库中。

  2. 我们按照与1相同的步骤进行操作,但我们首先在Sub App 1的应用程序服务器上检查本地缓存,而不是总是将Live Web Services调用到Asset Store,如果它存在,则返回资产否则,实时调用Asset store来获取资产。接着进行相同的处理,我们只将资产ID存储在该处理过的资产的子app 1数据库中。

  3. 我在Sub App 1的数据库中复制Asset Store的所有资产数据,创建同步作业,以便在外部Asset Sore和Sub App 1之间每晚同步内容。现在,而不是对外部资产商店进行实时调用,我选择我的子应用程序1数据库,以返回本地数据库的结果,这将是非常快的响应。处理资产并在子app 1数据库中保存资产的关系ID,该数据库可用于提取所有其他信息。仅与子应用1的本地数据库关联到该资产。 但是,因为我说虽然我通过在本地复制资产数据库获得了性能。但是,由于此应用程序中的所有Sub应用程序都使用此公共资产商店进行某种处理或其他处理,我将不得不复制此数据并编写夜间作业以在所有这些应用程序和我的公共资产商店之间同步数据。

  4. 我的问题是,哪种方法最适合当前的应用环境?为什么?资产商店中的资产数量约为30-35000

    非常感谢任何有关定义原因的帮助。非常感谢。

1 个答案:

答案 0 :(得分:0)

使用HTTP的一大优势是它已经内置了相当强大的缓存模型。请阅读304 not modifiedCache Control headers。我非常成功地使用了这个。强大的HTTP客户端支持开箱即用的这些标头,可以大大简化您的生活。