每個MicroService客戶端與通用客戶端|誰負責微服務客戶端？

Question

我有一個microService體系結構和10個microServices，每個都提供一個客戶端。在由microService團隊管理/控制的客戶端內部，我們只收到參數並將它們傳遞給一個通用的http調用者，該調用者接收端點和N個參數，然後進行調用。 所有microService都使用http和web api（我想技術並不重要）。

對於我來說microService團隊提供一個客戶端是沒有意義的，應該是消費者的責任，如果他們想要創建一些抽象或直接調用它們是他們的問題，而不是微服務問題。我看到一個web API的方式就像一個合同。所以我認爲我們應該在microService端刪除所有客戶端（將責任傳遞給消費者），並在消費者端創建一個使用泛型調用者到達端點的服務層。

圖像下面表示其中紅線定義界限，誰負責什麼所有組件：

• 網關有適配層
• 適配層引用了微服務客戶端軟件包
• MicroService客戶端包引用通用HTTP調用者包

另一方面是因爲我們可能有N個消費者，他們都重複客戶端的代碼。如果microService提供客戶端，我們有一個獨特的/中心的地方來控制它。

哪一種方法是正確的？客戶是微服務還是消費者的責任？

這是一個內部的產品。

Answer 1

我在工作中有一個類似的設置，有幾個微服務（〜40）和十幾個團隊。我被問了幾次相同的問題，我的回答是消費者負責消費。如果API按照設計和預期工作，那麼讓提供團隊負責任何事情都沒有意義。

提供服務的團隊（團隊a），可能提供客戶，如果他們想（有疑問，沒有保修）。消費隊（B隊）可以使用，如果他們希望客戶端（採取一切包括風險）。 唯一的合同應該是API，其他的一切都應該是一個團隊可能提供的好東西。如果團隊有提供客戶端，爲什麼他們提供一個API？

鑑於兩隊都鬆散耦合，並可以使用不同的技術（例如，或不同的彈簧框架的版本），提供客戶端庫，其他球隊證明帶來比任何解決更多的問題。在Java + spring-boot世界中，例如您會非常快地陷入依賴性問題，特別是如果您包含來自不同服務提供團隊的幾個客戶，這些客戶的時間演變程度各不相同。

而且更糟糕的是什麼，如果A隊的客戶端庫，使B隊的系統不穩定，並介紹了錯誤？現在誰負責解決這個問題？

如果您想減少您的消費團隊所需的工作，因爲重新編寫客戶端的工作量非常大，您的API可能會變得複雜，並且/或者您的微服務可能根本就不是微服務。 想象一下，在一個平靜的API上使用HATEOAS--爲此編寫一個客戶端只需幾行代碼即使包含了API瀏覽器，文檔和其他東西。見例如spring-rest-docs，hal-browser，swagger和各種其他技術，使得閱讀/瀏覽/記錄API和實現客戶端變得輕而易舉。

以上情況用兩個團隊來描述，想象一下10.我們有一個由一個團隊提供的「客戶端庫」，由另外4個團隊使用。你可以猜測它有多快，它變成了一個完整的混亂，直到它被刪除:)