基於Spring-DM實現分布式服務架構(DSF)(一)

經過上篇分析分布式服務架構的blog後，正式對之前的基於OSGi實現分布式服務架構的系列改名(順便把分布式服務架構改為使用DSF縮寫)，因為已經決定基於Spring-DM來實現，為什麼呢，而且為什麼一定要是Spring-DM，而不直接說Spring呢？

今天是Spring-DM 1.0 release的大好日子，，不容易呀，做了這麼久，具體怎麼樣還沒來得及細看，不過之前有用過1.0 m2，已經覺得很不錯了，相信1.0 release更不會失望。

在我眼裡看來，Spring是個很大的東西，其實DSF需要的基礎的東西並不多，但又希望保持微核性和擴充性，外掛程式化、具備良好擴充支援的架構無疑是最佳的選擇，OSGi無疑是個好的選擇，但基於OSGi要自己去實現的東西實在是太多了，Spring-DM則是能滿足我以上兩點需求的最佳選擇，既有了外掛程式化的架構，又有了很多可用而且是很強大的東西，尤其是Spring在本地調用和遠程調用的透明化提供了優秀的設計支援和指導，例如Spring提供的HessianServiceExporter、JNDIObjectFactoryBean等等，而且Spring和OSGi結合後，就可以根據需求來選擇自己所需的Spring的那些增強功能了，不用每次都抱著整個巨大的Spring，當然，目前Spring還沒完全剝離好，等Spring-DM 1.1後會好很多。

在之前的分析分布式服務架構的blog中，已經說到其實實現DSF簡明扼要的說就是：高效的儲存、尋找策略+高效的通訊策略+滿足需求的服務模型+強大的整合能力，其實這裡面最重要的呢，又是強大的整合能力，為什麼呢，因為呢，前兩個關鍵點都是有挺多的可選方案的，需要根據系統啟動並執行情況來做出不同的選擇，這個時候就要求DSF具備很好的整合能力，使得可以很方便的進行不同實現方案的切換，這點Spring已經向世人證明了很多次了，鑒於這些原因Spring-DM榮幸的入選成為DSF的選擇。　

來看看基於之前的那篇分析分布式服務架構的blog以及選擇了Spring-DM後，DSF變成什麼樣了：

是不是覺得和之前的DSF的圖有很多的不同的地方，至於為什麼會變成這樣，可以去看看分析分布式服務架構的blog，不在此細說，在此會詳細的介紹下目前DSF第一個版本V 0.7，也就是上圖中的每個部分：

先全域的說下，仍然是分為服務應用端和服務中心，但是從圖中可以看出，服務尋找和調用的機制和以前的有所不同，在DSF中服務僅把其元資訊直接在服務中心進行註冊，此元資訊會由服務中心寫入分布式的緩衝DB：MemcacheDB中，當服務應用端進行服務調用時，它將直接存取MemcacheDB來尋找到目標服務的訪問機制，然後直接和目標服務應用端進行通訊，而不經過服務中心路由，這裡要稍微說下為什麼採用MemcacheDB，其實就是解決DSF中所說的高效的儲存、尋找機制，當然，裡面其實還有個細節，就是cluster的考慮，可以想想，如果目標服務的元資訊是直接緩衝在服務應用端的話，那麼當目標服務元資訊發生改變時，那通知起來是件非常麻煩的事，所以乾脆找個支援cluster持久和高效緩衝的東西，還好有了MemcacheDB，當然，其實你也可以根據你所面對的應用的實際需求來定，例如，你的目標服務壓根就不可能存在元資訊變化的現象，那完全可以直接把目標服務的元資訊緩衝到服務應用端(甚至這步可以在部署期直接完成)，這些等DSF做到後期版本後，可以考慮機制調整的支援，但在V 0.7中將會採用圖示的方案。

經過機制的改變後，服務中心就變得非常簡單了，而且壓力是非常的小，它將來更多的需要承擔服務的管理和監控的職責，逐步的會壓力增大，這裡就不去過多的講它了，還是來看看服務應用端，其實也就是V 0.7需要乾的活了：

1、服務尋找

這個服務尋找就是負責和MemcacheDB通訊的了，根據服務模型進行服務的過濾尋找，只是要考慮以後切換為其他尋找方式(如基於Distributed File System、服務尋找後本機快取等)的支援，由於是基於Spring-DM的，不會有什麼問題。

2、發布服務

參考Spring的ServiceExporter來實現，在V 0.7中，暫時只提供jndi的方式，jndi server採用jboss jnp，而以Hessian、Webservice的方式發布，都是Spring直接就支援的，:)，只是當服務應用端不是採用Spring實現時，需要做個整合策略的實現。

3、調用服務

參考Spring的ObjectFactoryBean實現，由於V 0.7隻有JNDI、Hessian方式，Spring已經分別提供了JNDIObjectFactoryBean和HessianProxyFactoryBean，所以這塊暫時不用去考慮了。

在後續版本中這塊需要在緩衝等方面多加考慮。

4、和服務應用端的整合

在V 0.7中暫時假設服務應用端也是基於Spring的，所以就暫時不考慮整合的問題了。

OK，到此為止，剩下的兩個工作就是：

1、服務元資訊模型

服務元資訊模型完全參考OSGi Service。

在V 0.7中將只支援xml方式描述服務元資訊模型的註冊，這裡需要完成的就是將xml解析為元資訊模型。

2、服務管理端

V 0.7僅提供服務列表的查看、服務註冊、元資訊修改以及卸載。

V 0.7需要做的就是把DSF的架子搭好，保證好基於DSF的Scable的可行性，當然，其實service本身也是要考慮Scable的(如service操作的資源等)才行，在後續0.7-->1.0的過程中將會從細節加以改進，如支援更多的通訊協議、支援更多種服務應用端的整合、提高效能等。