批量 - 從不同的微服務獲取請求

我將一個單一的服務分成微服務體系結構。我所做的是分開的服務，現在REST的呼叫是分佈式的，但問題是，如果我打電話service A，它返回10000個實例，它依賴於其他service B，所以來電service A和每個實例，呼叫去service B以獲取其數據，因此將單個呼叫轉換爲10000個額外的呼叫，現在呼叫需要很長時間。批量 - 從不同的微服務獲取請求

我想在一個請求中創建多個獲取請求。

我搜索的是使用批量請求來POST不同的實例，但建議在創建&一起更新多個實例。這也可以用來獲取信息嗎？

還有其他方法可以做到嗎？

編輯：一個類似的用例，以我的例如。有兩種服務可以獲得學生的詳細信息，另一種獲得教師的詳細信息。在教師表中有學生的ID，它並不是一個外鍵，而是一個簡單的鍵，現在在老師的UI中，它顯示了教師的詳細信息，學生ID和學生姓名及其所屬的類別，以便獲得學生姓名和課程細節，我必須用學生的身份證件給學生的服務打電話。

來源

2017-05-09 Ali Kahoot

爲什麼你需要從'服務B'請求額外的信息？你能給一個具體的情況嗎？ –

用示例編輯問題 –

您是否使用事件驅動架構？如果是，那麼'service B'是否暴露這些事件（例如，在'/ events'等REST端點處）？ –

爲了更清楚地說明，微服務本身在不依賴任何其他服務的情況下履行其業務職責。在你的情況下，'ServiceA'不是一個微服務，但它只是一個服務，因爲它依賴於另一個服務來完成它的工作。

那麼你能否改變服務合同？例如，修改ServiceB輸入&輸出以每個呼叫而不是1個返回/維護100個實例。它將提供更少的請求和更少的時間。有意義的是，如果您開發批處理行爲應用程序/服務，則管理集體數據的依賴服務將幫助您節省網絡和運行時總成本。但在這種情況下，'serviceA'不會成爲微服務。

所以，如果你真的決定讓它成爲一個真正的「微服務」，只需將服務A和服務B結合在一起。微服務的概念並不是將服務變得「微」。微服務只負責完成與其業務領域相關的工作，而不依賴於其他域/服務/模塊等。

將處於同一域中的2個服務合併爲1並處理該服務中的一些批量數據不違反微服務概念。

來源

2017-05-09 13:29:15 Tunceren

「微服務本身，履行其業務責任，而不依賴任何其他服務」 - 我不同意。當ms需要來自另一個數據的數據時有很多情況......它被稱爲「依賴關係」。它不能被消除。它可以被倒置，最小化和延遲，但不會被消除。 –

有些權威人士稱您稱之爲SOA架構。我知道微服務已經是SOA的一個子集。但通常有些人同意微服務可以依賴另一個，但另一個人認爲微服務不能依賴於另一個因素，因爲另一個服務是不可行的，它不能完成它的工作。我同意第二組，你是第一組。這就是它:)所以這就是爲什麼有這樣的Micrservice編排（以通信方式 - 而不是關於部署），API網關等。 – Tunceren

微服務是SOA的子集。我給你舉個例子：授權。它在另一個微服務中（在任何好的架構中）以及所有其他客戶端微服務使用它。你說的是什麼叫做「彈性」（被認爲是級聯失敗），並且有技術可以增加它（如緩存或預加載數據）。 –

您正在尋找的圖案是API Gateway。有時也稱爲「Edge」或「EdgeService」。它可以用作羣集的單個入口點並彙總服務調用結果。其他用例包括中央認證和/或授權以及路由，監控和彈性。通過聚合API網關可能會使您的服務解耦（但當然，這也取決於您的用例實際是什麼，因爲您沒有提供任何詳細信息）。

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

這裏是一些技術來考慮：

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

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

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

來源

2017-05-10 00:14:40

批量 - 從不同的微服務獲取請求

回答

相關問題