# 一、引言

**“老婆”和“媽媽”同時掉進水裡，先救誰？**

常言道：編碼五分鐘，解衝突兩小時。作為Java開發來說，第一眼見到ClassNotFoundException、NoSuchMethodException這些異常來說，第一反應就是排包。經過一通常規和非常規操作以後，往往會找到同一個Jar包引入了多個不同的版本，這時候一般排除掉低版本、保留高版本就可以了，這是因為一般Jar包都是向下相容的。但是，如果出現版本不相容的情況的時候，就會陷入“老婆和媽同時掉進水裡，先救誰”的兩難境地，如果恰恰這種不相容發生在中介軟體依賴和業務自身依賴之間，那就更難了。

如下圖所示，Project表示我們的專案，Dependency A表示我們的業務依賴，Dependency B表示中介軟體依賴，如果業務依賴和中介軟體依賴都依賴同一個Jar包C，但是版本卻不一樣，分別為0.1版本和0.2版本，而且最不巧的是這兩個版本還存在衝突，有些老的功能只在0.1低版本中存在，有些新功能只在0.2高版本中存在，真是“老婆和媽同時掉進水裡，先救誰都不行”。

![](https://static001.geekbang.org/infoq/10/1006bbe9cb07d3e6aad73fc5fe68c66c.png)

（圖片摘自：SOFAArk官網）

俗話說：沒有遇到過Jar包衝突的開發，一定是個假Java開發；沒有解決過Jar包衝突的開發，不是一個合格的Java開發。在最近的專案裡，我們需要使用Guava的高版本Jar包，但是發現中介軟體依賴的是低版本且與高版本不相容的Jar包，面對這種兩難，我們肯定是“老婆”和“媽媽”都要救，於是我們開始尋求解決方案。

# 二、不相容依賴衝突解決方案

**“老婆”和“媽媽”都要救，怎麼救？**

首先，我們想到的是，能不能把需要用到的Guava高版本的程式碼拷出來直接放到我們的工程中去，但是這樣做會帶來幾個問題：

-   Guava作為一個功能豐富的基礎庫，某一部分的程式碼往往與其他很多程式碼都存在依賴關係，這會造成牽一髮而動全身，工作量會比預想的要大很多；

-   複製出來的程式碼只能自己手動維護，如果官方修復了問題或者重構了程式碼或者增加了功能，我們想要升級的話，那麼只能重頭再來一遍。於是，我們只能另外想其他的方案，這個只能作為最後的兜底方案。

然後，我們在想，一個Java類被載入到JVM虛擬機器裡區別於另一個Class，其一是它們倆全路徑不一樣，是風馬牛不相及的兩個不同的類，但卻是被不同的類載入器載入的，在JVM虛擬機器裡它們仍然被認為是兩個不同的Class。所以，我們就在想從類載入器上來尋求解決方案。在阿里巴巴內部，有一個Pandora的元件，正如其名就像一個魔盒，它會把中介軟體的依賴都裝到Pandora裡（內部叫做Sar包），這樣的話，就能避免在中介軟體和業務程式碼直接出現“老婆和媽同時掉進水裡，先救誰”的兩難境地。

同樣，在類似的場景比如應用合併部署也能發揮威力。但是Pandora只在阿里內部使用並未開源。在螞蟻金服，也有一個這樣的元件，並且開源了，叫做SOFAArk（官方網址，感興趣的可以去官網瞭解SOFAArk的原理和使用），我們感覺已經找到了那個Mr.Right，於是我們開始研究SOFAArk如何使用。和Pandora一樣，SOFAArk也是透過使用不同的 ClassLoader 載入不同版本的三方依賴，進而隔離類，徹底解決包衝突的問題，這就要求我們需要將相關的依賴打包成Ark Plugin（參見SOFAArk官方文件）。

對於公司來說，這樣的方案收益是比較大的，打包成Ark Plugin後整個公司都能夠共享，業務方都能受益，但是對於我們一個專案來說，採用這樣的方案無疑過重了。於是，我們與中介軟體同學聯絡，詢問是否有計劃引入類似的隔離元件解決中介軟體和業務程式碼之間的依賴衝突問題，得到的答覆是公司目前包衝突並不是一個強烈的痛點，暫時沒有計劃引入。於是，我們只能暫且擱置SOFAArk，繼續尋找新的解決方案。

![](https://static001.geekbang.org/infoq/24/24fe7fe8dcb22b761c88922c0cfaf7a0.png)

接著，我們在想既然Pandora/SOFAArk採用類載入隔離了同一路徑的類，那麼如果我們把衝突的兩個版本庫的groupId變得不一樣，那麼即使同名的類全路徑也是不一樣的，這樣在JVM裡面必然是不同的Class。如果把Pandora/SOFAArk的隔離方式稱之為邏輯隔離的話，這種就相當於物理隔離了。要實現這一點，藉助IDE的重構功能或者全域性替換的功能就能比較容易的實現這一點。

正在我們準備擼起袖子動手乾的時候，我們不禁在想，這樣的痛點應該早就有人遇到，尤其像Guava、Commons這類的基礎類庫，衝突在所難免，前人應該已經找到了優雅的撓癢姿勢。於是，我們就去搜尋相關的文章，果不其然，maven-shade-plugin正是那優雅的撓癢姿勢，這個Maven外掛的原理正是將類的包路徑進行重新對映，達到隔離不相容Jar包的目的。

# 三、maven-shade-plugin解決依賴衝突

最後如何來配置和使用maven-shade-plugin將Guava對映成我們自己定製的Jar包，實現與中介軟體Guava的隔離。整個的過程還是比較清晰明瞭的，主要是建立一個Maven工程，引入依賴，配置我們要釋出的倉庫地址，引入編譯打包外掛和maven-shade-plugin外掛，配置對映規則（標籤之間部分），然後編譯打包釋出到Maven倉庫。pom.xml的配置如下：

```java
<?xml version="1.0" encoding="UTF-8"?>

<groupid>com.shaded.example</groupid>
    <artifactid>guava-wrapper</artifactid>
    <version>${guava.wrapper.version}</version>

<name>guava-wrapper</name>
    <url>https://example.com/guava-wrapper</url>

<dependencies>
        <dependency>
            <groupid>com.google.guava</groupid>
            <artifactid>guava</artifactid>
            <version>27.1-jre</version>
        </dependency>  
    </dependencies>

<build>
        <plugins>
            <plugin>
                <groupid>org.apache.maven.plugins</groupid>
                <artifactid>maven-compiler-plugin</artifactid>
                <version>3.3</version>
                <configuration>
                    <source>${maven.compiler.source}<source>
                    <target>${maven.compiler.target}</target>
                </configuration>
            </plugin>
            <plugin>
                <groupid>org.apache.maven.plugins</groupid>
                <artifactid>maven-jar-plugin</artifactid>
                <version>2.3.2</version>
                <executions>
                    <execution>
                        <id>default-jar</id>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                        <phase>package</phase>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupid>org.apache.maven.plugins</groupid>
                <artifactid>maven-source-plugin</artifactid>
                <version>2.4</version>
                <executions>
                    <execution>
                        <id>default-sources</id>
                        <goals>
                            <goal>jar-no-fork</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupid>org.apache.maven.plugins</groupid>
                <artifactid>maven-shade-plugin</artifactid>
                <version>2.4.1</version>
                <configuration>
                    <createdependencyreducedpom>false</createdependencyreducedpom>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>shade</goal>
                        </goals>
                        <configuration>
                                          
                            <relocations>
                                <relocation>
                                                      
                                    <pattern>com.google.guava</pattern>
                                                      
                                    <shadedpattern>com.google.guava.wrapper</shadedpattern>
                                </relocation>
                                <relocation>
                                    <pattern>com.google.common</pattern>
                                    <shadedpattern>com.google.common.wrapper</shadedpattern>
                                </relocation>
                                <relocation>
                                    <pattern>com.google.thirdparty</pattern>
                                    <shadedpattern>com.google.wrapper.thirdparty</shadedpattern>
                                </relocation>
                            </relocations>
                            <transformers>
                                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"></transformer>
                            </transformers>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

<distributionmanagement>
          
    </distributionmanagement>
</project>
```

專案引入這個新打包的guava-wrapper後，import選擇從這個包匯入我們需要的相關類即可。如下：

```
<dependency>
  <groupid>com.vivo.internet</groupid>
  <artifactid>guava-wrapper</artifactid>
  <version>27.1-jre</version>
</dependency>
```

# 四、結語

為了在同一個專案中使用多個版本不相容的Jar包，我們首先想到手動自行維護程式碼，但是工作量和維護成本很高，接著我們想到透過類載入器隔離（開源方案SOFAArk），但是需要將相關依賴都打包成Ark Plugin，解決方案無疑有點過重了，最後透過maven-shade-plugin外掛重新命名並打包，優雅地解決了專案中不相容多個版本Jar包的衝突問題。從問題出來，我們一步一步探尋問題的解決方案，最終的maven-shade-plugin外掛方案雖然看似與手動自行維護程式碼本質一致，看似回到了原點，但其實最終的方案優雅性遠比最開始高得多，正如人生的道路那樣，螺旋式上升，曲線式前進。

如果遇到類似需要支援版本不相容Jar包共存的場景，可以考慮使用maven-shade-plugin外掛，這種方法比較輕量級，可用於專案中存在個別不相容Jar包衝突的場景，簡單有效，成本也很低。但是，如果Jar包衝突現象比較普遍，已成為明顯或者普遍的痛點，還是建議考慮文中提到的類似Pandora、SOFAArk等類載入器隔離的方案。

> 作者：vivo網際網路伺服器團隊-Zhang Wei

版本不相容Jar包衝突該如何是好？

相關文章