出處：http://www.cnblogs.com/zhangs1986/?

技術是為需求而服務的，分布式服務框架也同樣如此，它不是憑空誕生的，也是因為有這樣的需求才會有分布式服務框架這么樣的東西誕生，在這篇blog中來詳細的分析分布式服務框架誕生的原因(其實也是需要用分布式服務框架的應用場景，這里隱含的意思就是并不是什么應用都需要分布式服務框架的)、分布式服務框架需要提供的feature以及實現這些feature可選的技術方案。
其實這篇blog應該寫在實現分布式服務框架系列blog之前，:)，不廢話了，來看為什么會需要分布式服務框架，在一個不斷發展的大型應用中，系統的業務和功能不斷的增加，同時技術在不斷的發展、團隊在不斷的變化，很容易造成的現象就是：各個子系統、模塊實現的技術五花八門，部署時各子系統的方式和要求不同，各個子系統之間的交互方式和方法不統一。這種現象帶來的問題就是整個系統感覺很混亂，不過技術畢竟是不斷的發展，因此各子系統、模塊的具體實現技術要完全限制應該是不太可能的，也沒必要，但會希望系統對外提供的功能能采用統一的部署以及交互方法，這樣的話每個子系統能保持其黑盒的實現方式，其他子系統不想也不需要關心它的實現方式，只需要能夠統一的方式調用到它們提供的功能就可以了，這是出現的第一個需求。
起初整個應用部署在一臺機器上，但隨著系統的功能越來越多，不得不不斷的增加機器以減輕服務器的壓力，但很快就出現瓶頸，不得不把應用分層部署，這樣可以撐一段時間，在撐過一段時間后發現再度出現瓶頸，于是希望能夠再度的把系統進行劃分，這個時候就變成了希望能夠以非常細的粒度來部署了，而不是把一堆的功能都部署在同一臺機器上，這樣帶來的好處是系統的重用性能夠再度的增強，服務器的壓力能夠有效的降低，使得系統可以以較低的成本繼續保持Scable（就像google），其實這也是ebay的演變過程，大家可以去看看那個著名的ebay架構演變的PPT，還有一篇中文的ebay是怎樣煉成的。
從上面的需求場景描述中可以看出，需要分布式服務框架的場景并不是很多，這里還有一種場景沒去提及，那就是對于一個大型企業而言，由于需要用到的軟件多種多樣，其實也是有分布式服務框架的需求的，但還是有些不同，因為要去滿足那種場景的方法可以更為簡單。
分析下分布式服務框架的應用場景，可以得知，分布式服務框架的誕生目的主要有兩個：
1、約束需要對外提供的功能，保證其以一個統一的方式來對外提供和獲取；
2、分布式的部署細粒度的功能。
在確定了這兩個目的后，來詳細的分析下為了達到這兩個目的，需要提供些什么feature。
要約束對外提供的功能，保證以統一的方式來對外提供和獲取，首先需要制定的標準是功能到底以什么方式來對外提供，這里首先誕生了服務這個很好很形象的名詞，對外提供的功能其實也就是為別人提供的服務了，那么服務里到底有些什么呢，面向接口自然是首選，所以服務都以接口方式來提供，另外可能就是會有一些服務的元信息了，如服務的名稱、描述、依賴、所在機器等等；接著要完成的就是如何把各子系統對外提供的功能定義成服務呢，這里要求分布式服務框架能提供強大的集成能力，例如子系統是采用spring來實現，那么就需要支持能把spring的bean直接定義成服務；定義服務完成了，這個時候要解決的問題就是其他的子系統怎么知道有這些服務的存在呢，因此需要提供一個統一的服務的注冊中心，同時相應的帶來的問題就是各個服務應用端怎么來查找這些服務，怎么調用這些服務，這也是分布式服務框架需要解決的，在提供了上面的這些feature后，第一個需求就可以基本實現了。
分布式的部署細粒度的功能，這個在第一個需求達成的情況下，直接就可以實現了，因為分布式服務框架對服務應用端的粒度并沒有要求，可粗可細，只是分布式的部署細粒度的功能其實潛在的帶來了另外的需求，那就是怎么樣把這些細粒度的服務直接組裝來滿足業務的需求，這也是分布式服務框架應該提供的功能；同時，還要注意的一點是，當變成細粒度的分布式部署的場景時，系統的穩定性和性能是會受到影響的，對于大型應用來講這兩點偏偏又是非常重要的，分布式服務框架需要對此進行考慮。

.......................................................咖啡一杯，休息一下.......................................................

繼續，上面分析完畢后產生了分布式服務框架的基本Feature，來總結看看，并同時對其進行可選的實現技術的分析：
1、服務模型
????? 在服務模型中需要詳細定義服務模型包含了哪些信息，而這些信息也就決定了服務在發布時需要提供的信息，同時也是為服務查找和調用提供的信息。
2、服務的注冊中心
????? 服務的注冊中心在分布式服務框架中充當的就是服務信息的存儲場所的作用，同時它還需要提供的一個重要的功能就是查找服務，這兩個最重要功能最重要的就是穩定、高效以及支持Cluster。
????? 存儲服務信息上可采用數據庫存儲、分布式文件系統存儲等，查找服務需要的就是支持高效的查找，這個要根據服務的查找方法等來建立相應的緩存和索引，這里需要注意的是在cluster情況下的處理，選用數據庫存儲或分布式文件系統存儲自然是不會有cluster的問題的。
????? 另外一個需要確定的就是服務應用端怎么調用服務注冊中心提供的管理接口，可采用的技術有JNDI、JMS、WebService等等N多種實現方式，可以根據具體的性能要求、實現方法、需求等來進行選擇。
????? 從擴展方面去看，服務的注冊中心應該提供多種服務應用端和注冊中心的交互協議的選擇、擴展。
3、發布服務的方式，支持Spring、EJB3等等
????? 支持直接的把服務應用端的功能發布為服務，發布的方式更多的是xml、annotation等方式，就是一種很不錯的設計，所以要根據服務應用端采用的技術而定，常見的如spring、EJB，這個完全根據分布式服務框架所面對的應用場景而定，如果你的服務應用端都是基于Spring的，那么就可以暫時只提供Spring的方式了。
??????注冊服務方面的技術基本也不用選擇，因為它其實是根據服務應用端采用的技術而決定的，相當于提供一個集成的接口而已，由此接口去完成和服務中心的交互。
????? 但這里有個關鍵的實現技術需要選擇，就是把服務以什么方式對外提供，例如有JNDI、Webservice、JMS等等，就像Spring中的HessianServiceExporter，這里需要的是服務框架本身支持好這些協議，至于到底要實現多少種也是根據需求來看了，而各種協議的實現可以選用協議對應的成熟產品，如jndi有jboss jnp，也可以自己根據需求實現。
????? 也許在spring中我們可以這么來發布service：
??????<hsf:service>
??????????????<ref bean="Spring Bean"/>??????????????
????????????? <metainfo:jndi server=""?interface="服務接口名" name="簡要名稱" desc="服務功能描述"/>
????????????? <!--以jndi的方式對外提供-->
????????????? <publish:jndi server="">
??????????????????????? <property name=""></property>
????????????? </publish:jndi>
????????????? <!--以hessianservice的方式對外提供-->
????????????? <publish:hessian server=""/>
????????????? <!--以jms的方式對外提供-->
????????????? <publish:jms server="" queue=""/>
????? </hsf:export>
4、查找服務和調用服務的方式，支持Spring、EJB3等等
????? 查找服務和調用服務方面，需要做到的就是能夠讓服務應用端透明的使用遠程的服務，所以其實也是和服務應用端采用的技術相關的。
????? 當然，它本身需要提供以各種協議和服務中心通訊，以各種協議調用遠端服務的支持，另外就是同步、異步的支持等，還需要從高效性去考慮。
????? 對于使用者來說則比較簡單，也許在Spring中我們可以這么來調用遠端的service：
??????<bean id="loginService" class="HSFObjectFactoryBean">
????????????? <hsf:service>
????????????????????? <import:jndi?server="" interface="">
??????????????????????????????<!--可用于過濾查找的服務-->
????????????????????????????? <property name=""></property>
??????????????????????</import:jndi>
??????????????</hsf:service>
??????</bean>
5、服務的組裝
????? 服務的組裝需要提供的就是將服務中心的服務進行組裝，以實現復雜的業務需求，這里面需要包括容錯等等的支持，同樣，高效性也是這里面的重點。
????? 可選用的技術有采用事件框架、jbpm等。
6、穩定性和性能
??????通常來講，需要用到分布式服務框架的應用在穩定性和性能方面都會有很高的要求，當然，穩定性更多的是通過避免Single Point的方式來提供，但同時軟件層面也應該盡量避免無謂的錯誤，從技術角度上來講可以采取fail-fast的思想來實現。
????? 性能方面，需要根據使用時的壓力情況來決定，如查找服務時太慢，需要考慮提升服務中心查找服務的效率，增加索引，使用分布式存儲等等都是可采用的方式，提升性能的方面其實可采用的方案是非常多的，但每種技術幾乎都是需要非常專業的人才去實現的。

??? 上面分析的feature只是分布式服務框架的基本feature了，一個強大的分布式服務框架的話實現的東西會比這個多很多(例如提供服務管理端、監控端、IDE等)，不過主要會是細節上，在具備了這些基礎feature的情況下，細節就決定了高低了，:)。
分布式服務框架的引入也許會降低些性能，但應用的適當的話，則能充分發揮服務器性能，并且很大程度的降低系統Scable的成本，至于開發效率的話我不覺得是分布式服務框架需要解決的問題。
服務框架其實對于所有應用而言幾乎都是需要的，而且非分布式的服務框架可選的是有很多的，但分布式服務框架可選的目前基本是沒有，所以如果不是應用真的需要，沒有必要去實現分布式服務框架（就像在企業應用模式里Martin Fowler講的一樣，盡量不要分布式，:)），因為分布式服務框架對于技術層面還是有挺高的要求的，說簡單點呢，就是高效的存儲、查找策略+高效的通訊策略+滿足需求的服務模型+強大的集成能力構成了分布式服務框架的核心技術實現。

ps：在寫完這篇blog后，發現自己在基于OSGi實現分布式服務框架（四）里面寫OSGi不適合其實是個不準確的詞，因為在服務的應用端其實是可以采用OSGi的，不過以分布式服務框架而言，OSGi是沒有什么適用的場景，除了服務模型可參考外，但在服務應用端而言，OSGi仍然是個很好的選擇。

原文引自?http://www.blogjava.net/BlueDavy/archive/2008/01/24/177533.html

轉載于:https://www.cnblogs.com/firejava/p/6424494.html

總結

以上是生活随笔為你收集整理的分析分布式服务框架的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。