<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    基于OSGi實現分布式服務框架歷程(四)

    在這個篇幅中將來分析下這個分布式服務框架的服務的生命周期的管理的問題,在分布式服務框架中,支持服務的動態部署、卸載、升級是很關鍵的,至于服務的生命周期是否需要做到像OSGi那樣的動態通知,在這個篇幅中會進行分析,并最終形成這個分布式服務框架的生命周期模型以及到目前為止的服務架構模型。
    先來分析下服務的生命周期是否需要做到像OSGi DS的動態通知,這里以服務組件安裝為例稍微的說下OSGi DS服務的生命周期模型,在OSGi DS中,當有新的Service Component安裝時,首先會檢查其是否lazy,如是lazy或此Service Component對外提供服務則完成安裝,生成ServiceRegistration對象放入其服務中心;如不是lazy或此Service Component不對外提供服務,則首先檢查其引用的服務是否可用,如不可用則嘗試激活引用的服務,如所有引用的服務均可用,那么激活此Component,對外提供此Service,并發布Service Active的事件;服務生命周期事件管理器在接收到Service Active的事件后,將會查找所有引用此Service的Component,如Component未激活,則嘗試激活,如已激活,則根據配置的bind-method注入此Active的Service Instance。
    根據上面的分析,到分布式的服務應用的環境下,來看看,下圖為一個典型的分布式服務應用的圖示:

    根據OSGi DS服務的生命周期模型,那么當我們在服務應用端部署了一個分布式服務時,此服務首先需要到服務中心進行注冊,在注冊時,需檢查去所引用的服務是否可用,如可用,得激活此服務,同時需要將此消息發送給所有引用了此服務的服務應用端,這整個過程說起來是相當的順暢的,但我們可以想想,如果這個服務是個基礎服務,被N多服務應用端引用了,那這個時候會是個什么狀況,那要通知到多少的服務器呢(可以想象100+的服務群),盡管可以cluster+同步,:),更復雜的情況,當此服務引用了其他N個服務,首先需要發消息嘗試激活這些服務,然后那些服務激活后又帶來了N個服務的激活,這個就把整個過程變得極度繁瑣了,整個的實現難度和邏輯復雜度大大提升了,動態的處理生命周期的變化將會帶來很大的技術難度以及不可控因素,例如在高并發的場景時某服務突然不可用了,但它的通知的消息還在傳遞,那結果會怎么樣呢?既然這么難控制,那就干脆不去控制這種動態的變化了,簡化整個生命周期模型,保證實現的簡便性和系統的高穩定性,這也是實現所有系統必須遵循的原則:“簡單(但不是簡陋)到可控、滿足需求為止”。
    鑒于以上的分析,在這個分布式服務框架中將采取一種適合大型分布式應用使用的服務生命周期模型:
    1、服務安裝時
          當服務在應用端被安裝時,首先注冊其Service元信息到本地服務中心,接著判斷如服務需要注冊到遠程服務中心,則進行注冊,注冊完畢后,根據服務引用的服務的信息生成相應的服務Proxy對象,注入到此服務中,同時激活服務。
    2、服務卸載時
          當服務在應用端被卸載時,首先從本地服務中心中刪除相應的Service元信息,如此服務注冊到了遠程服務中心,那么同時刪除遠程服務中心的Service元信息。
    3、服務升級
          服務升級需要做的其實就是替換Service元信息,同時刷新classloader中的服務實例。
    通過這個容易實現的服務生命周期模型可以看出,實現出來的這個分布式服務框架將會很好的支持服務的動態部署、卸載和升級,但并沒有支持到服務的狀態的通知等,其實也不是很必要,不過在目前的這種情況下需要解決的是調用的高效的問題,因為在不知道引用的服務的狀態的情況下,最復雜的就是每次都得發起調用,這里需要有一個高效的緩存機制,以避免無謂的調用(如服務壓根就不可用呀,或者服務沒改變,參數也沒改變的情況),:),這個具體怎么實現大家可以先想想,在后續的章節中會詳細的介紹。
    經歷到目前這步后,大家會發現,OSGi在整個的分布式服務框架中開始逐步消失,確實,OSGi在分布式領域的不足(最強的DS在分布式領域非常不適合)已經讓它不是很適合作為實現這種大型分布式場景應用的框架了,但這并不意味著OSGi就沒什么用了,OSGi在很多應用領域仍然是王者型的框架,只有最適合的,沒有最好的,:),而且OSGi的很多思想(例如服務的模型,所以其中還是有很多DS的影子)其實也在指導著這個分布式服務框架的思想,所以即使最后這個實現的分布式服務框架和OSGi沒有多大關系,也還是暫且叫著這個名字吧,來看下經歷到目前這步后的分布式服務框架是個什么樣子了:

    從上圖中可見,此框架中幾乎所有的部分都是可換的,這和OSGi的microKernel思想是非常吻合的,當然,也是為了此框架能更加靈活的滿足分布式應用領域的需求。

    << 基于OSGi實現分布式服務框架歷程(三)

    >> 基于Spring-DM實現分布式服務框架(DSF)(一)

    posted on 2008-01-22 11:19 BlueDavy 閱讀(4490) 評論(4)  編輯  收藏 所屬分類: OSGi、SOA、SCA

    評論

    # re: 基于OSGi實現分布式服務框架歷程(四)[未登錄] 2008-01-22 13:05

    收藏了。目前正在用osgi開發項目,感覺這個技術很不錯,每個人可以開發自己的模塊。很爽!!  回復  更多評論   

    # re: 基于OSGi實現分布式服務框架歷程(四) 2008-01-22 13:26 windspy

    對這個topic很有興趣,期待下文。  回復  更多評論   

    # re: 基于OSGi實現分布式服務框架歷程(四) 2008-02-22 17:11 jenny

    基于OSGi實現分布式框架,R-OSGi不錯的呀  回復  更多評論   

    # re: 基于OSGi實現分布式服務框架歷程(四)[未登錄] 2008-02-23 17:56 BlueDavy

    @jenny
    恩,差點忘了這東西。  回復  更多評論   

    公告

     









    feedsky
    抓蝦
    google reader
    鮮果

    導航

    <2008年1月>
    303112345
    6789101112
    13141516171819
    20212223242526
    272829303112
    3456789

    統計

    隨筆分類

    隨筆檔案

    文章檔案

    Blogger's

    搜索

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 亚洲影院天堂中文av色| xxxxx做受大片视频免费| 免费国产a国产片高清网站| 久久最新免费视频| 亚洲AV无码国产精品色| 亚洲国产精品综合久久网络| 久久精品成人免费看| 亚洲色大成网站www| 亚洲宅男天堂在线观看无病毒| 免费下载成人电影| eeuss免费影院| 亚洲国产精品美女| 亚洲国产成人五月综合网| 99精品国产成人a∨免费看| jizzjizz亚洲日本少妇| 亚洲欧洲在线观看| 亚洲精品乱码久久久久久不卡| **aaaaa毛片免费| ssswww日本免费网站片| 亚洲va在线va天堂成人| 亚洲精品无码乱码成人| 日本不卡高清中文字幕免费| 色欲色香天天天综合网站免费| 特黄特色大片免费| 亚洲一级免费视频| 亚洲AV无码久久精品狠狠爱浪潮| 日韩成全视频观看免费观看高清| 亚洲免费视频网站| 国产vA免费精品高清在线观看| tom影院亚洲国产一区二区| 亚洲成a人片在线观看日本| 国产免费直播在线观看视频| 中文毛片无遮挡高潮免费| 成人无码区免费A∨直播| 在线精品自拍亚洲第一区| 亚洲噜噜噜噜噜影院在线播放| 亚洲人成网站在线播放vr| 亚洲av无码成人精品区在线播放| 毛片a级三毛片免费播放| 亚洲视频在线观看免费视频| a毛片免费全部在线播放**|