在這個篇幅中將來分析下這個分布式服務(wù)框架的服務(wù)的生命周期的管理的問題，在分布式服務(wù)框架中，支持服務(wù)的動態(tài)部署、卸載、升級是很關(guān)鍵的，至于服務(wù)的生命周期是否需要做到像OSGi那樣的動態(tài)通知，在這個篇幅中會進(jìn)行分析，并最終形成這個分布式服務(wù)框架的生命周期模型以及到目前為止的服務(wù)架構(gòu)模型。
先來分析下服務(wù)的生命周期是否需要做到像OSGi DS的動態(tài)通知，這里以服務(wù)組件安裝為例稍微的說下OSGi DS服務(wù)的生命周期模型，在OSGi DS中，當(dāng)有新的Service Component安裝時，首先會檢查其是否lazy，如是lazy或此Service Component對外提供服務(wù)則完成安裝，生成ServiceRegistration對象放入其服務(wù)中心；如不是lazy或此Service Component不對外提供服務(wù)，則首先檢查其引用的服務(wù)是否可用，如不可用則嘗試激活引用的服務(wù)，如所有引用的服務(wù)均可用，那么激活此Component，對外提供此Service，并發(fā)布Service Active的事件；服務(wù)生命周期事件管理器在接收到Service Active的事件后，將會查找所有引用此Service的Component，如Component未激活，則嘗試激活，如已激活，則根據(jù)配置的bind-method注入此Active的Service Instance。
根據(jù)上面的分析，到分布式的服務(wù)應(yīng)用的環(huán)境下，來看看，下圖為一個典型的分布式服務(wù)應(yīng)用的圖示：
根據(jù)OSGi DS服務(wù)的生命周期模型，那么當(dāng)我們在服務(wù)應(yīng)用端部署了一個分布式服務(wù)時，此服務(wù)首先需要到服務(wù)中心進(jìn)行注冊，在注冊時，需檢查去所引用的服務(wù)是否可用，如可用，得激活此服務(wù)，同時需要將此消息發(fā)送給所有引用了此服務(wù)的服務(wù)應(yīng)用端，這整個過程說起來是相當(dāng)?shù)捻槙车?，但我們可以想想，如果這個服務(wù)是個基礎(chǔ)服務(wù)，被N多服務(wù)應(yīng)用端引用了，那這個時候會是個什么狀況，那要通知到多少的服務(wù)器呢(可以想象100+的服務(wù)群)，盡管可以cluster+同步，:)，更復(fù)雜的情況，當(dāng)此服務(wù)引用了其他N個服務(wù)，首先需要發(fā)消息嘗試激活這些服務(wù)，然后那些服務(wù)激活后又帶來了N個服務(wù)的激活，這個就把整個過程變得極度繁瑣了，整個的實(shí)現(xiàn)難度和邏輯復(fù)雜度大大提升了，動態(tài)的處理生命周期的變化將會帶來很大的技術(shù)難度以及不可控因素，例如在高并發(fā)的場景時某服務(wù)突然不可用了，但它的通知的消息還在傳遞，那結(jié)果會怎么樣呢？既然這么難控制，那就干脆不去控制這種動態(tài)的變化了，簡化整個生命周期模型，保證實(shí)現(xiàn)的簡便性和系統(tǒng)的高穩(wěn)定性，這也是實(shí)現(xiàn)所有系統(tǒng)必須遵循的原則：“簡單(但不是簡陋)到可控、滿足需求為止”。
鑒于以上的分析，在這個分布式服務(wù)框架中將采取一種適合大型分布式應(yīng)用使用的服務(wù)生命周期模型：
1、服務(wù)安裝時
當(dāng)服務(wù)在應(yīng)用端被安裝時，首先注冊其Service元信息到本地服務(wù)中心，接著判斷如服務(wù)需要注冊到遠(yuǎn)程服務(wù)中心，則進(jìn)行注冊，注冊完畢后，根據(jù)服務(wù)引用的服務(wù)的信息生成相應(yīng)的服務(wù)Proxy對象，注入到此服務(wù)中，同時激活服務(wù)。
2、服務(wù)卸載時
當(dāng)服務(wù)在應(yīng)用端被卸載時，首先從本地服務(wù)中心中刪除相應(yīng)的Service元信息，如此服務(wù)注冊到了遠(yuǎn)程服務(wù)中心，那么同時刪除遠(yuǎn)程服務(wù)中心的Service元信息。
3、服務(wù)升級
服務(wù)升級需要做的其實(shí)就是替換Service元信息，同時刷新classloader中的服務(wù)實(shí)例。
通過這個容易實(shí)現(xiàn)的服務(wù)生命周期模型可以看出，實(shí)現(xiàn)出來的這個分布式服務(wù)框架將會很好的支持服務(wù)的動態(tài)部署、卸載和升級，但并沒有支持到服務(wù)的狀態(tài)的通知等，其實(shí)也不是很必要，不過在目前的這種情況下需要解決的是調(diào)用的高效的問題，因?yàn)樵诓恢酪玫姆?wù)的狀態(tài)的情況下，最復(fù)雜的就是每次都得發(fā)起調(diào)用，這里需要有一個高效的緩存機(jī)制，以避免無謂的調(diào)用(如服務(wù)壓根就不可用呀，或者服務(wù)沒改變，參數(shù)也沒改變的情況)，:)，這個具體怎么實(shí)現(xiàn)大家可以先想想，在后續(xù)的章節(jié)中會詳細(xì)的介紹。
經(jīng)歷到目前這步后，大家會發(fā)現(xiàn)，OSGi在整個的分布式服務(wù)框架中開始逐步消失，確實(shí)，OSGi在分布式領(lǐng)域的不足(最強(qiáng)的DS在分布式領(lǐng)域非常不適合)已經(jīng)讓它不是很適合作為實(shí)現(xiàn)這種大型分布式場景應(yīng)用的框架了，但這并不意味著OSGi就沒什么用了，OSGi在很多應(yīng)用領(lǐng)域仍然是王者型的框架，只有最適合的，沒有最好的，:)，而且OSGi的很多思想(例如服務(wù)的模型，所以其中還是有很多DS的影子)其實(shí)也在指導(dǎo)著這個分布式服務(wù)框架的思想，所以即使最后這個實(shí)現(xiàn)的分布式服務(wù)框架和OSGi沒有多大關(guān)系，也還是暫且叫著這個名字吧，來看下經(jīng)歷到目前這步后的分布式服務(wù)框架是個什么樣子了：
從上圖中可見，此框架中幾乎所有的部分都是可換的，這和OSGi的microKernel思想是非常吻合的，當(dāng)然，也是為了此框架能更加靈活的滿足分布式應(yīng)用領(lǐng)域的需求。
<<
基于OSGi實(shí)現(xiàn)分布式服務(wù)框架歷程(三)
>>
基于Spring-DM實(shí)現(xiàn)分布式服務(wù)框架(DSF)(一)