爲了擺脫絲帶和傳遞依賴的,一會加在其pom.xml
如下:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-ribbon</artifactId>
</exclusion>
<exclusion>
<groupId>com.netflix.ribbon</groupId>
<artifactId>ribbon-eureka</artifactId>
</exclusion>
<!-- Eureka needs com.netflix.http4.MonitoredConnectionManager
so don't exclude this dependency
<exclusion>
<artifactId>ribbon-httpclient</artifactId>
<groupId>com.netflix.ribbon</groupId>
</exclusion>
-->
<exclusion>
<groupId>com.netflix.ribbon</groupId>
<artifactId>ribbon-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.netflix.ribbon</groupId>
<artifactId>ribbon-loadbalancer</artifactId>
</exclusion>
</exclusions>
</dependency>
最後,這消除關於從最終工件依賴關係的3MB。
這遠遠不僅僅是排除像spring-cloud-starter-ribbon
這樣的單一依賴關係,而且它需要更深入的Spring Cloud Netflix庫內部知識來發現哪些依賴關係可以被刪除。
@spencergibb:我理解你的觀點,但如果讓用戶自己去做「這麼簡單」,我不明白爲什麼你在爲Consul和其他人提供支持時不能在框架內做到這一點。至少,只有那些知道自己在做什麼並會讓整個社區受益的人才會這樣做。
讓功能區退出遊戲還可確保功能區組件在構建不需要它們的應用程序時不會被「初始化」。
我明白了,但它可能已經被顛倒過來了:只有Eureka支持的'spring-cloud-starter-eureka'和帶有所有Ribbon功能的'spring-cloud-starter-ribbon',包括Ribbon-Eureka支持。 這將提供更大的靈活性,因爲人們更有可能使用沒有功能區的Eureka,而不是使用尤里卡的功能區(大多數「獨立」服務僅需要向Eureka註冊)。 這不僅減少了應用程序的大小,而且還減少了潛在的問題。在類路徑上額外使用無用的庫可能會觸發可能會干擾其他應用程序的自動配置。 –
我不會做相反的事情,我需要絲帶沒有尤里卡其他實現發現(領事,動物園管理員等)。排除一個是否是一件大事? – spencergibb