微服務項目中的Maven可傳遞依賴項

Question

我目前正在從事有關微服務架構的項目。 它有大約100多個模塊，這些模塊是git上不同存儲庫中的單個項目。 其中很少有可運行的啟動應用程序，而其他則是API和實現，它們作為jar包含在可運行項目中，並且在需要時也可以相互包含。

模塊之間的依賴關系圖是一團糟，我們在test范圍內指定了所有依賴關系，許多模塊從其依賴關系的依賴關系中使用了api。

發行版本是一項艱巨的任務，因為它要求我們對100多個存儲庫中的直接和間接依賴項進行所有版本更新。

有人可以分享一些可以簡化這種混亂情況的最佳做法嗎？是否有任何工具可以用來以更可控和更可靠的方式可視化/管理傳遞依賴關系？

Answer 1

不需要微服務就傳遞依賴項保持同步，並且您不會一次部署全部堆棧。 例如，每個服務都是可以獨立部署的獨立代碼。

如果您擁有共享代碼，則應將其視為外部依賴項（保存在Nexus等中央存儲庫中），可以根據每個服務進行獨立更新。

存在的唯一硬依賴性是服務之間的公共API。 例如，您可以通過REST在具有基於JSON的API的服務之間進行通信。 如果這些API之一以非向后兼容的方式更改，那么您需要注意/仔細考慮部署順序。

除了思考諸如API應該或不應該暴露什么，每個服務的適當大小和職責以及體系結構簡單性之類的事情之外，別無選擇。 如果您弄錯了這些事情，那么無論您編寫微服務還是編寫整體程序，都將陷入無法維護的困境。

編輯：通常（當我這樣做時）如果service2要調用service1，則它使用REST API進行通信，並在service2本身內實現與該API進行通信所需的一切。 例如，有一個連接的RestTemplate ，一個將@Autowire的RestTemplate實例的Service1.java ，以及為service1的請求和響應建模的POJO，直接在service2中實現。 例如，不存在共享代碼依賴關系，而存在API合同依賴關系。 正如我最初提到的，您也可以采用將客戶端庫放在Nexus之類的“共享代碼方法”，但是我個人發現這比其價值更麻煩。 很多時候，我發現即使一個服務有多個調用者，不同的調用者實際上也會使用不同的API，並且任何給定的服務僅會建模API的一部分（端點和子集）需要/適用的POJO）。 而且，如果是這種情況，則共享庫實際上並不涉及共享，因為它模糊了特定的API更改會影響哪個服務。