避免微服務中的瓶頸

我將爲我的Datawarehouse應用程序應用微服務。在應用程序中有4個主要的微服務：避免微服務中的瓶頸

1）數據服務：將外部數據源導入/導出到DWH並從DWH查詢數據。

2）分析服務：圖表的可視化上UI

3）機器學習：用於推薦系統

4）報告：用於報告生成

如下圖：

每個服務都有自己的DB，它們通過TCP和Th直接相互通信ift序列化。這裏的問題是Data Service受到來自其他服務的高負載，並且可能成爲應用程序的SPOF。 DWH中的數據也很大（可能高達數百萬記錄）。在這種情況下如何避免數據服務的瓶頸？或者我如何定義一個正確的有界上下文來避免瓶頸？

來源

2017-02-28 Barcelona

你可能想

分裂Data Service到幾個微服務的基礎上，一些業務邏輯;
修改Data Service（如果需要）支持多個服務實例。然後使用負載均衡器在這些實例之間分割請求。

負載平衡器是充當反向代理和跨多個服務器分配網絡或應用流的裝置。負載平衡器用於增加容量（併發用戶）和應用程序的可靠性。

關於「一個數據庫，多種服務」：

每個微服務需要有自己的數據存儲，否則，你沒有分解。如果我們談論的是關係型數據庫，那麼可以使用以下方式之一來實現：

每個服務專用表 - 每個服務擁有一組表，這些表必須由該服務
架構進行訪問perService - 每個服務都有一個對該服務來說是私有的數據庫模式
數據庫每個服務 - 每個服務都有自己的數據庫。

如果使用單獨的表從數據庫Data Warehouse您的服務和Data Service不作任何額外的處理邏輯提供接入層到數據庫中，那麼，你可能會刪除Data Service和移動數據訪問邏輯相應的服務。但另一方面想想 - 現在你只有一個地方（Data Service），知道如何訪問和操作微服務所關心的Data Warehouse。

來源

2017-02-28 13:56:25 Set

我可以讓其他微服務（如Analytics，Reports，ML）直接訪問DWH數據庫嗎？所以在這種情況下，它將成爲「一個數據庫，多個服務」。因爲DWH中的數據很大並且數據定期更新。 – Barcelona

@Barcelona我已更新答案 – Set

DataService（DS）僅向其他服務提供數據訪問邏輯（基本CRUD），並且不提供其他處理邏輯。其他處理邏輯（如導入，導出...）用於客戶端調用。我想讓其他服務與DS通信的原因是因爲我想隱藏如何訪問，查詢和更新DWH到其他服務的邏輯。其他服務只需調用DS即可獲取或更新數據。 – Barcelona

避免微服務中的瓶頸

回答

相關問題