微服務體系結構中用於UI的數據聚合的最佳位置在哪裏

我正在使用微服務體系結構構建應用程序。它有五個Rest API和一個UI（單頁應用程序）微服務。微服務體系結構中用於UI的數據聚合的最佳位置在哪裏

誰能告訴我這是做數據彙總的最佳選擇？

製作UI應用程序作爲靜態Web應用程序並執行所有API請求從前端（使用JavaScript框架的瀏覽器），所有數據聚集前端本身和渲染呢？
將UI應用程序作爲動態Web應用程序，並在Web應用程序後端執行所有API請求和數據聚合？

2017-05-04 Dinusha

與往常一樣，我會使用選項2與Api網關，將處理一些擔心，如身份驗證和https終止 –

哪種情況下是選項1的最佳用例？ – Dinusha

如果您沒有身份驗證，或者您不想監視微服務的運行狀況，或者您不使用負載平衡，不使用速率限制等（所有這些都可以與選項1一起使用但更難）。在此處瞭解使用API網關的優點或情況http://microservices.io/patterns/apigateway.html –

這聽起來像你正在尋找的模式是API Gateway。有時也稱爲「Edge」或「EdgeService」。它可以用作羣集的單個入口點並彙總服務調用結果。其他用例包括中央認證和/或授權以及路由，監控和彈性。

有些人只通過網關路由外部呼叫，其他人通過網關路由內部呼叫。

這裏是一些技術來考慮：

Zuul從Netflix堆棧。你已經寫了一個聚合過濾器。見this文件。

Amazon API gateway - 如果您在AWS上運行。您通常會使用您自己的lambda服務進行聚合。

Kong。沒有本地聚合支持，但您可以轉發到您提供的單獨聚合服務。

來源

2017-05-04 18:03:34

如果微服務平臺具有多個UI，那麼它必須使用多個API網關？如果我每次使用API網關作爲我的UI數據聚合器，如果我在Rest API微服務器上進行更改，則必須在API網關上進行更改。然後我也必須部署。也可能成爲瓶頸和單點故障。我同意API網關可以使用中央身份驗證和/或授權以及路由和監視我的API。 – Dinusha

如果您正確實施了一個聚合服務，API網關不應該改變。對於我來說，多個用戶界面僅僅意味着您爲客戶端提供了幾組不同的（靜態）JavaScript庫。如果在UI中使用哪些服務存在重疊，那麼我希望客戶端綁定不會被複制，而是作爲這些JavaScript庫中的依賴項共享。 –

感謝您的回答。根據你的回答，我覺得最好的方式來解決這個問題，以創建一個靜態Web應用程序，並通過API網關傳遞Rest API。沒有Web應用程序後端。在這種情況下，Web應用程序中將沒有後端。只包含用於UI的客戶端JavaScript。這是好方法嗎？ – Dinusha

微服務體系結構中用於UI的數據聚合的最佳位置在哪裏

回答

相關問題