建站
咨詢
售后
建站咨詢
新聞中心
對(duì)于OSGi，有人評(píng)論稱OSGi是“Spring之后的下一個(gè)big thing”。不過該文的作者后來又覺得，OSGi也有不少的問題，其中之一就是它在把技術(shù)變得復(fù)雜化。作者是這樣說的：
創(chuàng)新互聯(lián)溝通電話：18982081108，為您提供成都網(wǎng)站建設(shè)網(wǎng)頁設(shè)計(jì)及定制高端網(wǎng)站建設(shè)服務(wù)，創(chuàng)新互聯(lián)網(wǎng)頁制作領(lǐng)域10多年，包括木包裝箱等多個(gè)領(lǐng)域擁有豐富的網(wǎng)站運(yùn)維經(jīng)驗(yàn)，選擇創(chuàng)新互聯(lián)，為網(wǎng)站保駕護(hù)航！
編輯推薦：OSGi入門與實(shí)踐全攻略
我對(duì)OSGi不懷疑并承認(rèn)OSGi解決了許多問題，而且它支持一些出眾的結(jié)構(gòu)模型比如高模塊化（high modularization）以及微服務(wù)（micro services）。然而從另外一個(gè)角度來說，在使用了OSGi幾年之后，也體驗(yàn)了它在不同領(lǐng)域的表現(xiàn)（我是指開發(fā)領(lǐng)域）之后，我真的開始懷疑OSGi了。
這是我喜歡和討厭的OSGi的一些方面：
它從幾百個(gè)具有代表性的小bundle中創(chuàng)建出一個(gè)系統(tǒng)的概念非常棒。OSGi bundle很好的一點(diǎn)是它們定義了邊界：不僅從依賴關(guān)系的意義上，而且從運(yùn)行時(shí)間的意義上也是這樣。每個(gè)bundle可以充當(dāng)一個(gè)微應(yīng)用，有自己的lifecycle和用戶，每個(gè)bundle能夠仔細(xì)地?cái)喽ǔ瞿膫€(gè)對(duì)象對(duì)外暴露。好好地使用它們，會(huì)帶給系統(tǒng)以松耦合，并增加再使用的可能性。而與此同時(shí)，OSGi的lifecycle使life更加復(fù)雜。實(shí)際上，追蹤服務(wù)和管理服務(wù)所引發(fā)的各個(gè)問題很討厭（我曾看到過在它們的bundle activators使用大型的state machines來管理所有事情，這種樣板化代碼沒有人愿意寫）。幸運(yùn)的是有Spring DM來幫我們管理這些。坦白說，如果沒有Spring DM我絕不會(huì)動(dòng)手開始OSGi項(xiàng)目。盡管Spring DM大大降低了bundle啟動(dòng)的復(fù)雜度，但仍然很麻煩。我仍然需要啟動(dòng)OSGi的運(yùn)行時(shí)間、安裝啟動(dòng)bundles，我還需要確保所有其他我所需要的bundles已經(jīng)安裝和啟動(dòng)。
我個(gè)人覺得，作為開發(fā)者，我們應(yīng)當(dāng)迫使自己執(zhí)行系統(tǒng)的約束。我們不得不自動(dòng)核對(duì)定義的限制，比如說，如果我們讀取了一些我們并不想讀取的類，構(gòu)建程序就會(huì)失敗。OSGi的版本概念，通過定義輸入和輸出包，將架構(gòu)參數(shù)（architectural constraints）首次帶入開發(fā)者的日常生活，并引入了一系列新的問題。OSGi是這樣解決運(yùn)行時(shí)間的版本問題的：它給每個(gè)bundle自己的class loader，并讓class loader看起來像它所在的版本一樣。這也帶來一系列問題，因?yàn)樗淖兞四悱h(huán)境工作的方式。你的代碼在所有你的單元測(cè)試中都可以通過，但一旦執(zhí)行在OSGi的運(yùn)行時(shí)間上，就會(huì)崩潰；Libraries崩潰因?yàn)檫@提升了運(yùn)行時(shí)間中的類；Singletons被設(shè)計(jì)為靜態(tài)對(duì)象不止一次地被創(chuàng)建，周而復(fù)始。當(dāng)你在不斷地調(diào)整你的模塊構(gòu)建說明時(shí)你會(huì)經(jīng)常終止，而且絕對(duì)會(huì)在你的整個(gè)系統(tǒng)中傳播反直觀的依賴關(guān)系。Spring DM也是這個(gè)問題：通過在你的服務(wù)中添加一些指令并且不斷地調(diào)整你的class loaders，你仍然需要調(diào)整和傳送依賴關(guān)系。
尤其是類的導(dǎo)入更是帶來很麻煩的問題。你很快會(huì)注意到，沒有強(qiáng)大和自動(dòng)集成的測(cè)試組件來配合OSGi，你無法繼續(xù)下去。
現(xiàn)在說一下我的結(jié)論：
在考慮OSGi之前，我會(huì)切實(shí)核實(shí)是否在不關(guān)閉系統(tǒng)的情況下我能否在運(yùn)行時(shí)間中轉(zhuǎn)換bundles，即使在這種情況下，我也會(huì)再次查看這些需求，來看看是否我會(huì)把他們限制在一個(gè)角落里，在這里我可以使用其他技術(shù)在動(dòng)態(tài)時(shí)間上來動(dòng)態(tài)地加載模塊。還有其他選擇可以生成這種結(jié)構(gòu)條例（比如使用一個(gè)IOC container，使用獨(dú)立的container來執(zhí)行模塊依賴等等……）許多這些東西都很接近KISS原則，避免所有其他附件的樣板化代碼并構(gòu)建配置，這因此讓你更加敏捷。
回歸到我的題目上，還有一種技術(shù)擁有這樣的特點(diǎn)（我是指讓技術(shù)更加復(fù)雜），那就是EJB。Spring是最流行的實(shí)例：技術(shù)更加復(fù)雜，開發(fā)周期更加困難。也許我們會(huì)在未來的幾年內(nèi)在OSGi中看到同樣的境遇？我無法斷定，時(shí)間將驗(yàn)證一切。
當(dāng)前名稱：愛恨交加：OSGi的Spring和EJB之路？
網(wǎng)頁URL：http://m.5511xx.com/article/copeoop.html
