2017-10-04 40 views
0

在客戶端應用程序中,我們將單一系統的部分移動到微服務架構。以一種非常簡單的方式,它看起來如此: - 核心應用程序擁有自己的產品數據庫 - 微服務擁有自己的數據庫和各種對象,這些對象可能與產品有關。從微服務(api)獲取數據並將其與主應用程序數據加入

情景1: 我們要在頁面上顯示產品「Apple」,並附帶microservice的相關數據。這很容易:只需從核心應用程序數據庫獲取「Ap​​ple」,並從微服務中檢索此產品的其他數據即可。好。

場景2: 我們希望顯示具有core-app數據庫的各種條件的產品列表以及microservice數據庫的其他條件。怎麼做? 我是否應該從數據庫(核心應用程序)中獲得1000個產品並調用微服務以獲取這些產品的其他數據?但是如何?我應該發送一個包含1000個ID或1000個API調用的查詢,還是以部分方式從API服務獲取數據,例如,10個API調用100個項目?我不喜歡這些選項。

場景3: 我們有「倉庫」微服務。

我想要列出按名稱排序的前100個產品,按升序排列,倉庫中的標誌可用= true。怎麼做?如果我從核心應用程序數據庫獲得100個產品,然後調用API檢查標誌,則產品的最終列表可能會低於100. 獲取倉庫中所有可用項目的列表是一個壞主意,因爲可能有數百萬項目,所以執行時間和API響應大小將不被接受。

通常,我需要一個想法,如何合併來自一個數據庫的某些數據和來自其他數據庫的某些數據並將其返回給用戶視圖。

該應用程序是用PHP編寫的,但也許一些在J2EE方面有經驗的人知道這些問題的解決方案?

編輯:我發現:http://microservices.io/patterns。我會仔細看看它。

回答

0

首先,雖然我認爲一般來說,微服務應處理給定的有界上下文/域。所以我想知道你想要添加到產品中的這個「附加」數據是什麼,以及它是否不屬於產品微服務。

如果您確定不應該這些是獨立的域,那麼這是您的API設計問題。如果您預測會經常查詢具有1000個ID的另一個微服務,請構建一個可處理1000個ID(或最好是任何長度的ID列表)的API。

至於情況3 - 如果我會得到這樣的任務,我會創建一個處理排序和過濾的API,以便所有那些數據庫擅長的操作都將由數據庫處理。

總的來說,我的觀點是API應該由您的業務需求驅動,並且不應該限制您快速提供高質量的解決方案。所以如果簡單的CRUD API不適合你(而且很少這麼做),只需要改變它。

相關問題