Java依賴沖突高效解決之道
一、概述
由于阿里媽媽聯(lián)盟團隊負責業(yè)務的特殊性，系統(tǒng)有龐大的對外依賴，依賴集團六七十個團隊服務及N多工具組件，通過此文和大家分享一下我們積累的一些復雜依賴有效治理的經(jīng)驗，除了簡單技術技巧的總結外，也會探討一些關于這方面架構的思考，希望此文能系統(tǒng)徹底的解決java依賴沖突對大家的困擾。
二、依賴沖突產(chǎn)生的本質(zhì)原因
要解決依賴沖突，首先要理解一下java依賴沖突產(chǎn)生的本質(zhì)原因。
圖1
以上圖為例，目前阿里大部分Java工程都是maven工程，此類工程從開發(fā)到上線要經(jīng)歷以下兩個重要步驟：
1.編譯打包
平時我們編寫的應用代碼，用maven編譯應用代碼時，maven只依賴第一級jar包(A.jar，B.jar，*.jar)既完成應用代碼的編譯，至于傳遞依賴的jar包(Y.jar，Z.jar)maven首先會對同名不同version的jar包進行依賴仲裁，然后依據(jù)仲裁結果下載對應的jar放到指定目錄下(例如上圖中Y.jar最終只會仲裁1.0或2.0一個版本，此處假定仲裁到2.0版本，Z.jar即便內(nèi)容與Y.jar一致，但名稱不一樣所以不屬于maven仲裁范疇)。
有一點需注意不同maven版本可能會有差異，這會導致有時本地環(huán)境和日常、預發(fā)打包不一致造成應用邏輯表現(xiàn)不一致的情況(說明一下這種情況還有其他一些原因會導致，不是說一定是maven版本不一致仲裁結果不一致導致的)。
2.發(fā)布上線
先明確一個概念，在JVM中，一個類型實例是通過它的全類名和加載它的類加載器(ClassLoader)實例來唯一確定的。所以所謂的“類隔離”，實際就是通過不同的類加載器實例去加載需要隔離的類來實現(xiàn)的，這樣即便兩個全類名完全相同但內(nèi)容不同的類，只要他們的類加載器實例不同，就能在一個容器進程中共存，并且各自運行互不干擾。
發(fā)布啟動容器時，不管是tomcat、taobao-tomcat還是PandoraBoot，還是其他容器， 首先都是用特定的類加載器實例先加載容器本身依賴的jar包，容器一般都會有多個類加載器實例，容器自身所依賴的jar包一般由專門的類加載器實例加載實現(xiàn)與應用包的絕對隔離，像Pandroa還有專門的類加載器實例加載淘系中間件避免中間件與應用類沖突，如下圖所示：
容器內(nèi)部依賴jar加載完成后，才輪到必然的一步：由某個應用ClassLoader實例(一般與容器類加載器實例不是一個)來加載編譯打包階段打出來的應用jar包及應用.class程序，這樣容器才能運行業(yè)務，同時確保應用不會干擾容器的運行。
例如圖1中，最終打出的應用包中Y.jar-2.0，Z.jar都有com.taobao.Cc.class類，但一個應用ClassLoader實例僅能加載V3或V2中一個版本的com.taobao.Cc.class類。
那到底會加載哪個版本的com.taobao.Cc.class類呢?答案是不一定，這個取決于容器應用類加載實現(xiàn)策略， 從以往遇到的情況看，tomcat，taobao-tomcat、Pandora的做法都是直接裝載應用lib包下所有.jar包文件列表(上例是A.jar,B.jar,*.jar,Y.jar,Z.jar。除tomcat外都沒看源碼核實過，有錯歡迎糾正)。但Java 在裝載一個目錄下所有jar包時， 它加載的順序完全取決于操作系統(tǒng)!而Linux的順序完全取決于INode的順序，INode的順序不完全能一致，所以筆者之前就遇到類似的問題，上線20臺機器，用同一個鏡像，有2臺就是起不來的情況。遇到這種情況目前就只能乖乖按以下章節(jié)中的手段去解決了。理論上最正確的做法應該是容器裝載應用 jar包時，按指定順序加載。
基于以上分析，我們可以得出結論，基本所有的類沖突產(chǎn)生的本質(zhì)原因：要么是因為maven依賴仲裁jar包不滿足運行時需要，要么是容器類加載過程中加載的類不滿足運行時需要導致的。
關于容器類加載隔離策略，網(wǎng)上ATA上有很多資料介紹，本文重點向大家講解遇到?jīng)_突的各種解決之道，解決沖突大家只需要知道以上重點原理就夠了。
理解了依賴沖突產(chǎn)生的本質(zhì)原因，那么發(fā)生依賴沖突如何高效定位具體是哪些jar包引起的沖突呢?請繼續(xù)看下一章節(jié)。
三、依賴沖突問題高效定位技巧
發(fā)生依賴沖突主要表現(xiàn)為系統(tǒng)啟動或運行中會發(fā)生異常，99%表現(xiàn)為三種NoClassDefFoundError、ClassNotFoundException、NoSuchMethodError。下面逐一講解一下定位技巧。
1.NoClassDefFoundError、ClassNotFoundException排查定位步驟
STEP1、發(fā)生NoClassDefFoundError首先要看完整異常棧，確認是否是靜態(tài)代碼塊發(fā)生異常，靜態(tài)代碼塊發(fā)生異常堆棧與jar包沖突有很明顯的區(qū)別，出現(xiàn)"Could not initialize"、"Caused by: ..."關鍵字一般是靜態(tài)代碼塊發(fā)生異常導致類加載失敗:
- java.lang.NoClassDefFoundError: Could not initialize class testing.User
- at testing.Test.main(Test.java:23)
- Caused by: java.lang.RuntimeException: UserId Not found
- at testing.User.getUserId(Test.java:41)
- at testing.User.<clinit>(Test.java:35)
- ... 1 more
因為靜態(tài)代碼塊發(fā)生異常導致NoClassDefFoundError，修改靜態(tài)代碼塊避免拋出異常即可。如果不是靜態(tài)代碼塊發(fā)生異常導致的問題，繼續(xù)下一步。
STEP2、如果不是靜態(tài)代碼塊發(fā)生異常導致加載失敗，異常message關鍵字中會明確顯示缺失的類名稱，例如：
- java.lang.NoClassDefFoundError: org/apache/commons/lang/CharUtils
- at testing.Test.main(Test.java:19)
STEP3、在IDEA中(快捷鍵Ctrl+N)查找異常棧中提示缺失的類在哪些版本的jar包中有，如上例中的org.apache.commons.lang.CharUtils
STEP4、查看應用部署機器上應用lib包目錄下(一般是/home/admin/union-uc/target/${projectName}/lib或union-pub/target/${projectName}.war/WEB-INF/lib)是否存在上一步驟中查出對應版本的jar包，以上情況一般是因為此時應用依賴的是低版本jar包，而jar包中又沒有沖突的類，絕大部分情況下NoClassDefFoundError、ClassNotFoundException定位確認都是因為maven依賴仲裁最終采納的jar包版本與運行時需要的不一致導致。
2.NoSuchMethodError排查到位步驟
STEP1、發(fā)生NoSuchMethodError，異常堆棧日志核心片段(異常棧中處于棧底的片段，見過很多同學發(fā)生異常亂翻一通，那樣毫無意義，要有目的的翻關鍵地方，不要亂翻)會明確顯示具體是哪個類，缺失了哪個方法，異常堆棧核心片段示例如下：
- Caused by: java.lang.NoSuchMethodError: org.springframework.beans.factory.support.DefaultListableBeanFactory.getDependencyComparator()Ljava/util/Comparator;
- at org.springframework.context.annotation.AnnotationConfigUtils.registerAnnotationConfigProcessors(AnnotationConfigUtils.java:190)
- at org.springframework.context.annotation.ComponentScanBeanDefinitionParser.registerComponents(ComponentScanBeanDefinitionParser.java:150)
- at org.springframework.context.annotation.ComponentScanBeanDefinitionParser.parse(ComponentScanBeanDefinitionParser.java:86)
- at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
首先需確認JVM中當前加載的缺失方法類，如上"org.springframework.beans.factory.support.DefaultListableBeanFactory"類到底來自哪個jar包，目前最高效的辦法：
外部環(huán)境容器下，或者某些容器版本過低不支持Arthas在線診斷的情況下，可以通過在JVM啟動參數(shù)中增加" -XX:+TraceClassLoading"，然后重新啟動系統(tǒng)，在系統(tǒng)工程日志中即可看到JVM加載類的信息。從中即可找到JVM是從哪個jar包中加載的。
STEP2、在IDEA中(快捷鍵Ctrl+N)查找異常棧中提示缺失的類在哪些版本的jar包中有，如下圖所示：
然后依次查看各版本jar包中沖突類的源碼，工程中部分jar打包時附帶了源碼包可直接看到源碼，不帶源碼的需要用IDEA插件(推薦jad)反編譯一下。然后依次搜尋各個jar包中的沖突類，搜尋第一步是點擊上圖中某個版本類，在IDEA中查找類級次關系(快捷鍵Ctrl+H)，如下圖所示：
然后在沖突類及所有沖突類的父類源碼中找到NoSuchMethodError異常信息中描述缺失的方法，以上例子中就是"getDependencyComparator()Ljava/util/Comparator"。
上例中通過搜尋可以發(fā)現(xiàn)spring-beans-3.2.1.RELEASE.jar，spring-2.5.6.SEC03.jar兩個版本DefaultListableBeanFactory類及父類中沒有"getDependencyComparator()Ljava/util/Comparator"方法，spring-beans-4.2.4.RELEASE.jar，spring-beans-4.3.5.RELEASE.jar兩個版本DefaultListableBeanFactory類中有缺失的"getDependencyComparator()Ljava/util/Comparator"方法。
STEP3、查看應用部署機器上應用lib包目錄下(一般是/home/admin/union-uc/target/${projectName}/lib或union-pub/target/${projectName}.war/WEB-INF/lib)下，找到相關jar包的版本，如上例中：
致此定位問題根本原因是應用啟動時加載"org.springframework.beans.factory.support.DefaultListableBeanFactory"類未加載到運行時預期所需的spring-beans-4.3.5.RELEASE.jar版本，而是加載了spring-2.5.6.SEC03.jar導致。
按照以上流程步驟，基本99%的依賴沖突都可以定位到根本原因。定位到原因后如何解決沖突呢?事實上有些時候解決沖突遠沒有內(nèi)網(wǎng)上很多帖子描述的"mvn dependency:tree"一下，排排jar那么簡單。具體細節(jié)請繼續(xù)看下一章節(jié)。
四、通過maven調(diào)整依賴jar解決依賴沖突
1.升降級jar包解決依賴沖突
上一章節(jié)中的第一個例子中，最簡單的情況，如果發(fā)生沖突的jar包高版本是完全兼容低版本功能的情況下，只需在pom中簡單升級jar包版本即可。
但如果沖突 jar包高版本不兼容低版本，且應用依賴不是很復雜的情況下，可以分析升級沖突jar包后會對哪些業(yè)務有影響，具體做法推薦通過IDEA Maven Helper 插件查找沖突jar包有哪些業(yè)務依賴(此處不推薦"mvn dependency:tree"，目前本人見過的大部分Maven工程都有多個Module，比如*-dal,*-Service,*-Controller，這類工程結構如果module未單獨打包上傳Maven倉庫，"mvn dependency:tree"是不能完整分析依賴關系的)，記錄下來。如下圖所示：
然后升級沖突包，通過回歸測試受到影響的二方庫對應的業(yè)務點。
如果應用依賴非常復雜(例如沖突包有幾十個二方庫依賴，或者依賴沖突包的二方庫是個基礎包，業(yè)務系統(tǒng)中無法清晰枚舉出使用受影響二方庫的業(yè)務點)，這種情況下，如果要通過升級jar包解決依賴沖突，必須完整回歸整個應用功能。筆者有幾次因為回歸不全面引發(fā)故障的慘痛經(jīng)歷，希望大家不要重蹈覆轍。通過這幾次事例，筆者深刻理解到我們這個時代最偉大的計算機科學家Dijkstra大神“簡單是可靠的先決條件”這句至理名言，深深的體會到如果一個系統(tǒng)復雜到你完全無法理清楚他錯綜復雜的依賴關系的時候，那說明你該重構你的系統(tǒng)了，否則系統(tǒng)維護將會逐步變成噩夢。
當然不是所有情況都可以通過升降級jar解決沖突，舉個例子：
如上圖假設應用系統(tǒng)同時依賴A.jar，B.jar，而A.jar，B.jar都依賴protobuf-java，系統(tǒng)運行時都會分別用到A.jar，B.jar中protobuf部分的功能，而且A.jar，B.jar依賴的protobuf版本無法通過升高降低版本調(diào)整到一致。由于protobuf-java3.0版本序列化協(xié)議，類內(nèi)容各方面都不兼容protobuf-java2.0版本。這種情況無論如何調(diào)整依賴都無法解決沖突的問題，要解決這種沖突，請繼續(xù)往下看，第五第六章內(nèi)容。
2.排除jar包解決依賴沖突
上一章節(jié)中第二個例子，主要原因是容器啟動時加載到的類不是預期spring-beans-4.3.5.RELEASE.jar中的類，而是spring-2.5.6.SEC03.jar包中的類，如果spring-2.5.6.SEC03.jar排除對業(yè)務無影響，可以通過排除spring-2.5.6.SEC03.jar來解決沖突。與上一節(jié)例子類似，可以通過IDEA Maven Helper 插件確定spring-2.5.6.SEC03.jar是由哪個jar間接依賴進來的，判斷業(yè)務的影響范圍，此處不在贅述。與上一節(jié)一樣，類似的情況不一定都可以用排除jar解決。
五、通過pandora自定義插件解決依賴沖突
第四章中有講到，如果一個應用中要同時運行兩個不兼容版本的jar包，是無法通過Maven調(diào)整依賴關系解決的。第二章講解依賴沖突原理時有提到，Pandora通過類隔離機制實現(xiàn)了集團各個中間件之間的隔離，Pandroa同時也支持業(yè)務方按規(guī)范創(chuàng)建一個可以運行在Pandora容器中的插件，容器幫業(yè)務方實現(xiàn)加載隔離。
聯(lián)盟一淘團隊就將類似IC、卡券這種核武器級存在的二方包根據(jù)自己業(yè)務的需要進行裁剪包裝后，制作成Pandora插件來避免依賴沖突，取得了很好的效果。
用Pandora插件確實能在不對應用做很大調(diào)整，不影響性能的情況下完美解決依賴沖突問題。
但也有一些問題就不太適合用局部方法解決了，比如：
當維護的應用依賴過于復雜，每個應用依賴外部三四十個二方庫時。這種重量級應用就會嚴重影響生產(chǎn)效率。
如上圖所示，早期本人負責聯(lián)盟用戶平臺時，就遇到兩個巨無霸應用，adv(6w+代碼)、pub(12w+代碼)。
一方面因為依賴多，基本每周都會遇到集團各種升級，安全問題，各種小修小補，不斷的上線。一方面業(yè)務發(fā)布需求也較多。
導致需要頻繁發(fā)布，比如有一年個人就發(fā)布了566次。此時龐大的依賴導致部署效率，影響評估回歸都會很難，此時就不應該從局部解決沖突這種視角去看，應該考慮優(yōu)化應用架構，進行依賴治理，盡量避免沖突。
六、通過依賴架構治理解決依賴沖突
1.復雜依賴標準化、簡化治理
首先，依賴本身就是一種復雜的業(yè)務。大部分依賴背后都有較深的業(yè)務領域知識 或者 技術領域知識。
比如我們查詢搜索。
業(yè)務領域知識方面，光銷量就有交易成交筆數(shù)，成交件數(shù)，搜索銷量【有些訂單不計入搜索銷量】等。
技術領域知識方面，主搜索，聯(lián)盟廣告搜索引擎有時是配合使用的，比如商家未入駐廣告前給商家展示貨品信息就需要查主搜索，而入駐后投放下行時則需要用廣告引擎。不同引擎的調(diào)用方法，結果都不一樣。
如下圖所示，如果我們每個業(yè)務應用都各自實現(xiàn)，那么各應用開發(fā)同學就要消化大量搜索客戶端相關的業(yè)務、技術領域知識。成本是很高的。
面對這種情況，如果我們將這類復雜的依賴，由專人owner進行統(tǒng)一包裝標準化【專人干專事】，會大大提升組織協(xié)同效率。如下圖所示。
我們通過對主搜索，聯(lián)盟引擎的統(tǒng)一封裝。對檢索條件，返回結果的標準化封裝。大大降低了同學們的接入成本，以往要熟悉一個引擎的接入大概要2天，用標準化封裝后的wrapper，在專人，規(guī)范文檔的指導下僅0.5天就可以，大大提升效率。
2.重量級依賴代理服務化
第五節(jié)中有講到，應用依賴的jar包過多會導致應用啟動很慢，因此如果一個依賴引入jar包超過30個以上時，務必要警惕，這種依賴引入幾個，就會逐步導致你工作效率大大下降。比如IC，TP，優(yōu)惠中心的二方包就是典型的例子。
目前我們針對這類依賴，是直接封裝一個標準代理服務，避免應用被這種巨無霸二方包拖慢。
經(jīng)過以上綜合治理手段，取得了很好的效果。目前聯(lián)盟很少再需要大家去解決沖突問題。
參考鏈接
INode講解：http://www.cnblogs.com/itech/archive/2012/05/15/2502284.html
