2017年我們一直在做分布式服務(wù)跟蹤系統(tǒng)的升級改造，為了更好的服務(wù)于廣大的開發(fā)和運維人員，能夠在數(shù)以千萬計的微服務(wù)系統(tǒng)中快速的發(fā)現(xiàn)問題、定位問題。一年下來，接入了上千個系統(tǒng)，快的幾分鐘，慢的不到10分鐘，最多就是處理一下jar包依賴沖突問題，所以能這么迅速的推廣。不過前幾天遇到一個客戶，他們的系統(tǒng)采用的是OSGI的框架。OSGI這個詞相信大部分人是聽過沒用過的。

當我們的監(jiān)控系統(tǒng)遇到了OSGI架構(gòu)系統(tǒng)也是碰撞出了激烈的火花，足足用了兩天的時間，才搞定了各種水土不服。我把期間的各種酸甜苦辣記錄下來，希望為奮斗在APM一線的同行們提供一點點幫助。

在整個過程中，我們遇到了四個技術(shù)關(guān)鍵點：

• 把一個普通的jar包Bundle化。
• OSGI的類加載機制。
• 引入第三方非Bundle化的jar包。
• 通過Activator在Bundle的啟動和停止實現(xiàn)回調(diào)。

項目背景

首先我簡單介紹下兩個項目的背景：

監(jiān)控系統(tǒng)：這是一個利用動態(tài)字節(jié)碼技術(shù)，自動的無侵入的對目標系統(tǒng)實行秒級實時監(jiān)控，監(jiān)控內(nèi)容包括但不限于容量、性能、成功率、調(diào)用鏈、應(yīng)用拓撲等，詳細內(nèi)容請參考：http://os.51cto.com/art/201709/552641.htm。

目標系統(tǒng)：分為兩部分，第一部分以war包形式發(fā)布，部署到Web容器內(nèi)，接收http請求；第二部分采用OSGI架構(gòu)，每一個Bundle是一個業(yè)務(wù)服務(wù)(可以理解為Bundle就是微服務(wù))。這兩部分通過servlet的橋接方式連接，其中一些公用Bundle(如slf4j)會放在war包的指定目錄中，每個業(yè)務(wù)Bundle不需要再單獨引入。這個架構(gòu)是我在解決了所有問題之后才總結(jié)出來的，在這里提前拋出是為了方便理解后邊的內(nèi)容。

剛開始的時候，我們就把它當做一個普通的系統(tǒng)來接入，把我們的jar包放到了目標系統(tǒng)war包的WEB-INF/lib下，加入啟動腳本，再啟動系統(tǒng)，可以看到我們的jar打印出的啟動日志，然后就沒有然后了，除了那一行日志，沒有任何效果。這個時候，我就意識到了OSGI系統(tǒng)不是這么玩的，于是開始OSGI的漫漫探索之路......

當看到OSGI的每一個Bundle包都是用單獨ClassLoader負責加載時，我仿佛找到了解決方案。

我們把監(jiān)控jar包打到了每一個業(yè)務(wù)的Bundle里邊，然后重啟，結(jié)果監(jiān)控成功了，問題解決了。

從純技術(shù)角度來看貌似是沒什么問題，然而噩夢才剛剛開始。由于監(jiān)控jar包打入了業(yè)務(wù)Bundle內(nèi)，帶來了兩個比較棘手的問題：第一，技術(shù)上每個業(yè)務(wù)Bundle都需要這么去引入，加大了開發(fā)工作量，這個和我們極致的設(shè)計理念是不符的；第二，業(yè)務(wù)上每一個業(yè)務(wù)Bundle就成為了一個單獨應(yīng)用，客戶方表示我們這個是一個應(yīng)用，而不是多個應(yīng)用。

所以還是要解決之前的問題，把整個目標系統(tǒng)所有的Bundle當做一個應(yīng)用去接入監(jiān)控。

我不熟悉目標系統(tǒng)和OSGI架構(gòu)，客戶開發(fā)方又不了解監(jiān)控系統(tǒng)的原理和實現(xiàn)過程，經(jīng)過了長時間的各種嘗試和交流，仍沒有絲毫進展。于是我們決定采用一個最原始，最簡單，最笨，也是最有效的方法，從“hello world”開始。

當一個系統(tǒng)出現(xiàn)問題，你又不知道問題出在哪部分的時候，要么把這些“部分”一個一個去掉，直到發(fā)現(xiàn)沒有“問題”為止；要么從“零”開始，然后一個一個的加入，直到出現(xiàn)“問題”為止，我們采取了后者。

首先，針對我們的監(jiān)控jar包去掉基于動態(tài)字節(jié)碼的自動監(jiān)控，采用編程式的直接API調(diào)用，并且將API接口做了Mock，去掉了所有的第三方依賴。修改目標系統(tǒng)的代碼，在希望被監(jiān)控的方法中直接調(diào)用監(jiān)控API。打包，部署，啟動，被監(jiān)控Bundle不能啟動，報錯......

Missing Constraint: Import-Package: com..................sgm...... 

經(jīng)過和對方開發(fā)人員的溝通和網(wǎng)上查閱OSGI相關(guān)資料，了解到這是一個OSGI打包的規(guī)范問題。

之前我們的監(jiān)控jar包是沒有按照OSGI的規(guī)范去打包的，打的只是一個普通的jar包，所以在OSGI框架下，其他的Bundle是無法訪問到我們的jar包中的類，造成啟動報錯的問題。這里遇到了我們第一個要解決的主要問題：

1. 普通jar包Bundle化

先看下邊的兩張圖：

上邊的兩張圖是jar包中META-INF/MANIFEST.MF文件，第一張圖是普通jar包，第二圖是具有OSGI規(guī)范的jar包。既然知道了，那這樣的OSGI的包怎么打？我們用maven來編譯，順理成章的就找到了maven-Bundle-plugin的這個插件，使用很簡單，代碼如下：

<plugin> 
<groupId>org.apache.felix</groupId> 
<artifactId>maven-Bundle-plugin</artifactId> 
<version>3.3.0</version> 
<extensions>true</extensions> 
<executions> 
<execution> 
<id>Bundle-manifest</id> 
<phase>process-classes</phase> 
<goals> 
<goal>manifest</goal> 
</goals> 
</execution> 
</executions> 
<configuration> 
<instructions> 
<Import-Package>org.slf4j</Import-Package> 
<Export-Package>com.wangyin.sgm.client</Export-Package> 
<Bundle-RequiredExecutionEnvironment>JavaSE-1.6</Bundle-RequiredExecutionEnvironment> 
</instructions> 
</configuration> 
</plugin> 

在這么多屬性中， Import-Package和Export-Package尤其重要，一個jar包就是一個Bundle，Bundle和Bundle之間的訪問全靠這兩個屬性來控制。

Import-Package：說明了這個Bundle jar需要調(diào)用外部其他Bundle的哪些包(package)。

Export-Package: 說明了這個Bundle jar可以提供哪些包(package)供其他Bundle去調(diào)用。

當一個Bundle啟動的時候，會分為Resolved(解析)，Installed(安裝)，Started(激活)等幾個步驟，解析就是檢查jar是不是正常，安裝的時候會把Export-Package中的指定的包進行注冊，這就知道哪些包由哪些Bundle來提供，激活的時候會檢查當前這個Bundle的Import-Package依賴的包是不是都有對應(yīng)的Bundle來提供，否則激活失敗。

修改監(jiān)控客戶端，把父項目，子項目，子子項目全部按照OSGI規(guī)范打包，又是一遍部署重啟，這次被監(jiān)控的業(yè)務(wù)Bundle沒有報錯，而是監(jiān)控客戶端啟動報錯：

Missing Constraint: Import-Package: org.slf4j 

有了剛才的經(jīng)驗，一看就知道是沒有slf4j，可是對方開發(fā)人員反饋slf4j是有的，他們自己也在用，這就奇怪了。

這時我發(fā)現(xiàn)還有在監(jiān)控客戶端里MANIFEST.MF的一句話org.slf4j;version="[1.7,2)"，version這個詞引起了我的注意。

原來在目標系統(tǒng)里的slf4j是1.5版本，而監(jiān)控客戶端要求1.7版本，slf4j降級再試，這次目標系統(tǒng)成功調(diào)用到了監(jiān)控客戶端的API，打印出了日志，萬里長征終于邁出了第一步。但這只是一個Mock的版本，真正的監(jiān)控程序還沒有加入。

先小結(jié)一下：首先在OSGI的框架下，所有jar必須按照OSGI的規(guī)范去打包，否則不能使用；其次要對Import-Package和Export-Package配置好，需要依賴外部哪些包，自己又可以提供哪些包供外部使用，同時注意版本，依賴時一般都是要高于哪個版本。

接下來，就要加入真正的代碼跑一跑，根據(jù)前面的經(jīng)驗還是要慢慢來，我們分兩步加入代碼，第一次先加入監(jiān)控代碼，待成功后加入網(wǎng)絡(luò)傳輸部分的代碼，后邊遇到的坑讓我們發(fā)現(xiàn)這個決定是正確的。

打包部署啟動調(diào)用這個流程已經(jīng)很熟練了，報錯還是如期出現(xiàn)了，這次報錯的是com.lmax的disruptor這個第三方開源jar包：

Missing Constraint: Import-Package: sun.misc 

納尼？sun.misc沒有？這不是jdk里的嗎，為什么會沒有呢？于是，又是一番資料查找，終于明白了其中的道理。

這里就要講到OSGI的類加載機制了，它并不是我們常說的雙親委托機制。關(guān)于這個問題，網(wǎng)上已經(jīng)有很多文章介紹了，但這里我還是結(jié)合這個例子簡單的說一下。

2. OSGI的類加載機制

首先每一個Bundle(jar)都會被一個單獨的ClassLoader去加載，當一個Bundle的ClassLoader嘗試去加載一個類的時候：

1. 如果這個類的包名是java.*開頭的，那么直接交給bootstrap ClassLoader去加載。
2. 查看這個類是否在OSGI的配置文件中有org.osgi.framework.bootdelegation屬性定義，如果定義了，交給bootstrap ClassLoader去加載這個類。
3. 查看這個類是否在OSGI的配置文件中有org.osgi.framework.system.packages屬性定義，如果定義了，交給父類加載器去加載，一般就是AppClassLoader。
4. 查看這個類是否在本Bundle的MANIFEST.MF文件的Import-Package中定義，如果定義了，交給Export-Package這個類的Bundle去加載。
5. 在上邊條件都不滿足的時候，那這個類就是自己的Bundle的內(nèi)部類，由自己的ClassLoader去加載。

現(xiàn)在我們來看一下，下邊這張圖是disruptor的MANIFEST.MF文件：

在disruptor里使用了sun.misc.Unsafe類，在啟動disruptor的時候，需要加載sun.misc.Safe，那么1,2,3點都不滿足，命中了第4點，就開始尋找?guī)в蠩xport-Package的Bundle，那肯定找不到。

遵循上邊的原則，在配置文件中加入了org.osgi.framework.bootdelegation=javax.*,sun.*，同時又把disruptor中的Import-Package刪掉了，問題成功解決了，又向勝利邁進了一步。

接下來，就要把網(wǎng)絡(luò)傳輸這部分加入進來了，系統(tǒng)就可以監(jiān)控了，數(shù)據(jù)需要發(fā)送出來才可以真正的使用。有了之前的經(jīng)驗，感覺應(yīng)該問題不大，然而現(xiàn)實情況并不是這樣……

當把這部分代碼和依賴加入后，各種的Missing Constraint: Import-Package: xxx。我發(fā)現(xiàn)所有的依賴的第三方j(luò)ar都在里邊，為什么還會報錯，我開始懷疑是這些第三方j(luò)ar本身的問題。

打開這些jar文件的MANIFEST.MF文件查看，果然如此，我們依賴的這些jar有多一半都不是Bundle化的jar包，這里就涉及到了本文第三個要解決的核心問題。

3. OSGI如何加載第三方非Bundle化的jar包

OSGI如何加載第三方非Bundle化的jar包，有如下幾種方式：

• 通過父類加載器加載，也就是配置org.osgi.framework.system.packages。
• 將jar轉(zhuǎn)換成Bundle，然后Export-Package。
• 把jar打包進引用方的Bundle。

第一種方式需要目標系統(tǒng)配置，同樣不符合我們的設(shè)計理念，顯然不合適，于是我們首先嘗試了第二種方式，重新打包那些非Bundle的第三方j(luò)ar。

在這個過程中，我們發(fā)現(xiàn)這絕對是個苦逼的活，需要找到源碼，下載源碼，修改pom，有的找源碼很費勁，有的還是ant編譯的，有的雖然是maven管理，但又依賴了父項目……

總之想順利的重新打包是個很費勁的事?？磥碇皇Ｏ碌谌龡l路了，這又要退回到之前第一個問題，如何打一個Bundle jar。

之前我們是把maven工程的每一個子項目分別Bundle化，如果要把第三方j(luò)ar打入Bundle，那就有可能一個第三方j(luò)ar被多次打入不同的子項目Bundle，造成浪費。

所以決定放棄對原有項目的每個子項目單獨Bundle化的方案，而是新建一個子項目，由這個子項目引入所有的其他子項目和第三方依賴jar，把他們所有打成一個大的Bundle jar。

<Import-Package>org.osgi.framework,org.slf4j</Import-Package> 
<Export-Package>com.wangyin.sgm.client</Export-Package> 
<Private-Package>com.wangyin.*,com.lmax.disruptor.*,…… 
</Private-Package> 

看一下上邊的配置，比之前多了一個Private-Package，就是說哪些Package是這個Bundle的內(nèi)部包，也就是要打入最后Bundle jar的東西。

現(xiàn)在通過編程式API直接調(diào)用的方式已經(jīng)可以監(jiān)控到目標系統(tǒng)了，最后要做的就是引入運行時字節(jié)碼增強技術(shù)。

還是按照常規(guī)的方式，把我們的Agent通過javaagent方式啟動，有了之前的經(jīng)驗，我知道這個是被bootstrap ClassLoader加載的，于是就直接在org.osgi.framework.bootdelegation中加入了監(jiān)控Agent的包名。

結(jié)果啟動正常，但是無法自動監(jiān)控，看了日志后發(fā)現(xiàn)是監(jiān)控客戶端沒有啟動。監(jiān)控客戶端的啟動是通過在每個類加載的時候，嘗試性的使用它的類加載去加載監(jiān)控客戶端的啟動類。

如果可以加載上，那么就啟動成功了，因為啟動程序是放在了啟動類的static塊中，且啟動類是一個單例模式，記錄著被監(jiān)控應(yīng)用的信息。

從這個啟動日志來分析，被監(jiān)控系統(tǒng)有200多個Bundle，每個Bundle啟動都去加載監(jiān)控客戶端，然后我們希望監(jiān)控客戶端被它自己的類加載器去加載。這里就是本文第四個核心問題。

4. 如何在Bundle啟動的時候去做一些初始化操作

在OSGI的規(guī)范里提供了一個叫BundleActivator的接口，里邊有start和stop兩個方法，顧名思義，在Bundle啟動和停止的時候會回調(diào)這兩個方法，這就好辦了，我們可以在start方法中實現(xiàn)啟動監(jiān)控客戶端的代碼。

<instructions> 
<Bundle-Activator>com.wangyin.sgm.client.Activator</Bundle-Activator> 
<Import-Package>org.osgi.framework,org.slf4j</Import-Package> 
<Export-Package>com.wangyin.sgm.client</Export-Package> 
<Private-Package>com.wangyin.*,com.lmax.disruptor.*,org.apache.flume.* 
        ,org.apache.avro.*,com.thoughtworks.*, 
        ,org.apache.commons.compress.*,org.apache.commons.lang.* 
        ,org.codehaus.jackson.*,org.jboss.netty.*,org.apache.velocity.* 
        ,org.xerial.snappy,org.tukaani.xz.* 
</Private-Package> 
<Bundle-RequiredExecutionEnvironment>JavaSE-1.6</Bundle-RequiredExecutionEnvironment> 
</instructions> 

上邊的Bundle-Activator這個標簽，指定這個Bundle的Activator是哪個類。

至此所有的問題都得到了解決，這次OSGI應(yīng)用接入APM監(jiān)控足足花掉了兩天的時間。

由于負責監(jiān)控系統(tǒng)的人員并沒有使用過OSGI，被監(jiān)控目標系統(tǒng)的開發(fā)人員也不知道監(jiān)控的原理是什么，一開始我們都以兩個產(chǎn)品整體去接入，做了許多的無用功，耽誤了很多時間。

從這個案例可以看出，當你所做的東西需要應(yīng)用到一個你不熟悉的技術(shù)領(lǐng)域的時候，又不可能有足夠的時間去學(xué)習(xí)這個領(lǐng)域的知識，有一個最好的辦法就是改造你所做的系統(tǒng)，從零開始，逐漸加碼，去適應(yīng)那個不熟悉的領(lǐng)域。

千萬不要想著能整體一下解決所有問題，因為可能要解決所有問題有100個技術(shù)點需要去修改，這100個問題同時暴露，你只有把它們同時都修改了，才能看到你的成果，這是根本不可能的事情。

而這100個問題一個個暴露出來，把一個不可能完成的大任務(wù)拆分成若干個可完成的小任務(wù)，修改一個，看到一步成功的效果，問題就得到了解決。

作者簡介：

[[215901]]

張晨， 資深研發(fā)工程師，目前任職京東金融，曾任職于搜狐等互聯(lián)網(wǎng)公司，擅長Java底層技術(shù)的研發(fā)及疑難問題的定位。從2015年開始從事智能運維監(jiān)控平臺的研發(fā)與實踐，參與并主導(dǎo)了APM等產(chǎn)品的研發(fā)與應(yīng)用，經(jīng)歷了多次618和雙11的千萬級TPS的運維保障，支撐了京東金融的大量業(yè)務(wù)應(yīng)用。

[[215902]]

沈建林，曾在多家知名第三方支付公司任職系統(tǒng)架構(gòu)師，致力于基礎(chǔ)中間件與支付核心平臺的研發(fā)，主導(dǎo)過 RPC 服務(wù)框架、數(shù)據(jù)庫分庫分表、統(tǒng)一日志平臺，分布式服務(wù)跟蹤、流程編排等一系列中間件的設(shè)計與研發(fā)，參與過多家支付公司支付核心系統(tǒng)的建設(shè)。現(xiàn)任京東金融集團資深架構(gòu)師，負責基礎(chǔ)開發(fā)部基礎(chǔ)中間件的設(shè)計和研發(fā)工作。擅長基礎(chǔ)中間件設(shè)計與開發(fā)，關(guān)注大型分布式系統(tǒng)、JVM 原理及調(diào)優(yōu)、服務(wù)治理與監(jiān)控等領(lǐng)域。