如果一個微服務是公共，同時內部

作者
其中有選擇的能力和CRUD實體「作者」

書籍
它具有SELECT和CRUD實體的能力「book」

移動應用主機
專門爲移動客戶端構建，可以響應請求的完整數據模型，以便移動應用程序不會在其末尾「豐富」數據。

例：API「MobileHost.getAllBooksOfGivenAuthor」將與這兩個作者姓名和書名迴應，通過調用「Authors.getAuthorData（的AuthorID）」，併合並其數據「Books.getBooksByAuthorIds（AUTHORID）」所獲得的結構像這樣：

{ 
    "author" : { 
    "name" : "Winner", 
    "id" : 1 
    }, 
    "books" : [ 
    { 
     "name" : "Book A", 
     "id" : "13231231" 
    } 
    ] 
}

我問題是：
如果移動客戶端讀取通過「移動應用主機」的數據應該是做「添加作者」到「移動應用主機」還，還是確定以直接聯繫「作者」服務？在這種情況下CRUD應該被代理嗎？

來源

2017-02-08 user3765648

這取決於你的目標。

根據我的經驗，這樣的「主機」或「代理」服務往往會變得越來越大，沒有任何真正的責任。將多個班級，功能和責任結合在一個地方肯定是一個糟糕的主意 - 隨着時間的推移維護這種服務將很困難。

此外，如果僅需要擴大作者服務範圍，則可能非常困難且資源無法擴展此類服務的實例。因此，如果您要分別擴展不同的服務和活動，那麼當然，您不需要僅使用一個服務代理請求。例如，您可以擁有多個代理服務，以便單獨擴展它們或直接調用作者服務，並且擴展它們而不是代理服務器。

但是，如果您沒有看到提及的機會，那麼儘可能簡單 - 當您需要做到這一點時，您可以將服務及其代理分開，只需將所有內容分開即可。

來源

2017-02-08 16:33:05 cassandrad

感謝您的詳細回覆。對你來說還有一個問題：除了'主機'服務，你是否創建內部和外部的API？如果你這樣做，你能否說出你爲什麼這樣做的原因？謝謝。 – user3765648

由於緩存，我們對API服務有混合策略。 API緩存一些非常頻繁的數據，並從查詢中的緩存中返回數據。它還處理分頁和從服務只提取特定的「頁面」數據。如果存在不需要任何緩存系統的服務，我們直接調用它，因爲它減少了在高負載下可能相當昂貴的服務間通信量。但是我們的API服務在任何時候都被設計成分離的，他們遵循門面設計模式。如果我們注意到API服務的一小部分存在巨大的負載，我們會把它拿出來。 – cassandrad

謝謝，現在我有一個清晰的視野。 – user3765648

如果一個微服務是公共，同時內部

回答

相關問題