企业架构的这三个选项哪个更好设计，为什么？

Question

我有一个企业应用程序，其中有多个子应用程序执行不同的任务。这些子应用程序将与 Web 服务相互交互，以相互共享功能，并为用户单独完成任务，或者将两个应用程序功能组合在一起。

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

不，考虑到 Sub App - 1 的用户想要对一组选定的这些资产执行任务，将登录到 Sub App 1，转到一个屏幕，该屏幕将向他显示所有可用资产。他选择这些资产并添加他的小猫以对它们执行一些操作，处理这些资产，然后为他完成任务。同理，不同的子应用会根据登录的子应用用户访问这个通用的Asset store，以不同的方式进行处理。

在子应用 1 中处理这些资产时，我们可以通过三种方式进行：

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

2. 我们遵循与 1 相同的步骤，但不是总是对资产存储进行实时 Web 服务调用，而是首先检查子应用 1 的应用程序服务器的本地缓存，以防它存在于那里，返回资产否则对资产商店进行实时调用以获取资产。接下来进行相同的处理，我们只需将资产 ID 存储在子应用程序 1 数据库中处理的资产。

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

我的问题是，这些方法中的哪一种最适合应用程序的当前上下文，为什么？资产商店的资产数量在30-35000左右

非常感谢您在定义原因方面的任何帮助。非常感谢。

Answer 1

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