2015-10-01 86 views
0

我有一個企業應用程序,其中有多個子應用程序執行不同的任務。這些子應用程序將通過Web服務互相交互以在彼此之間共享功能,併爲用戶完全獨自完成一項任務,或者與兩項應用程序功能相結合。哪個更好地設計企業架構的這三個選項,爲什麼?

還有就是大量資產(項目)存在於子應用一組通用的說資產存儲在這些副應用工作,這也暴露於通過其Web服務所有這些子應用程序。此資產商店可能是外部系統,或者未部署在同一環境中,或者可能位於其他子應用程序所在的雲外部。所以,性能可能會在網絡之外受到打擊。

沒有考慮子應用的用戶 - 1誰想要在一組選定的這些資產中執行任務時,會登錄到子應用程序1,去一個屏幕,該屏幕會顯示他所有可用的資產。他選擇這些資產並添加他們的小貓,對他們執行一些操作,處理這些資產,然後爲他完成任務。同樣,不同的子應用程序將訪問此公用資源商店,以基於用戶登錄的子應用程序以不同方式處理它們。

而撒哈拉處理這些資產應用1,我們可以做到這一點的方法有三種:

  1. 我們做LIVE Web服務調用資源商店子應用程序返回我們設置這些產品的基於用戶搜索或標準。在這種情況下,我們到現在爲止不在Sub App 1數據庫中存儲任何內容。一旦用戶選擇了資產,在子應用程序1中處理它,我們只在子應用程序1數據庫中存儲處理資產的ID。

  2. 我們遵循與1相同的步驟,但不是總是將Live Web Services調用到Asset Store,我們首先檢查Sub App 1的應用程序服務器上的本地緩存,以防其存在時返回資產直接致電資產商店以獲取資產。其餘的處理過程如下,我們只將資產ID存儲在該應用程序1的數據庫中。

  3. 我複製了子應用程序1的數據庫中Asset Store的所有資產數據,創建同步作業以每晚在外部資產傷害和子應用程序1之間同步內容。現在,不需要對外部資產存儲進行實時調用,我選擇我的子應用程序1數據庫來返回本地數據庫的結果,這將是相當快的響應。處理資產並將資產的關係ID保存在可用於提取所有其他信息的子應用程序1數據庫中。關聯到該資產從本地DB只子應用程序1. 然而,因爲我說,雖然我已經在本地複製資產數據庫獲得的性能。但是,由於此應用程序中的所有Sub應用程序都將此公用資產存儲用於某種處理或其他應用程序,因此我將不得不復制此數據並編寫夜間作業以在所有這些應用程序和我的公共資產存儲之間同步數據。

我的問題是,哪種方法最適合當前的應用環境,爲什麼?資產商店中的資產數量約爲30-35000

任何有關定義原因的幫助都將得到高度讚賞。非常感謝。

回答

0

使用HTTP的最大優點之一是它已經內置了一個相當健壯的緩存模型。請閱讀304 not modifiedCache Control headers。我非常成功地使用了它。強大的HTTP客戶端支持這些開箱即用的頭文件,並且可以大幅簡化您的生活。