技術(shù)是為需求而服務的，分布式服務框架也同樣如此，它不是憑空誕生的，也是因為有這樣的需求才會有分布式服務框架這么樣的東西誕生，在這篇blog中來詳細的分析分布式服務框架誕生的原因(其實也是需要用分布式服務框架的應用場景，這里隱含的意思就是并不是什么應用都需要分布式服務框架的)、分布式服務框架需要提供的feature以及實現(xiàn)這些feature可選的技術(shù)方案。
其實這篇blog應該寫在實現(xiàn)分布式服務框架系列blog之前，:)，不廢話了，來看為什么會需要分布式服務框架，在一個不斷發(fā)展的大型應用中，系統(tǒng)的業(yè)務和功能不斷的增加，同時技術(shù)在不斷的發(fā)展、團隊在不斷的變化，很容易造成的現(xiàn)象就是：各個子系統(tǒng)、模塊實現(xiàn)的技術(shù)五花八門，部署時各子系統(tǒng)的方式和要求不同，各個子系統(tǒng)之間的交互方式和方法不統(tǒng)一。這種現(xiàn)象帶來的問題就是整個系統(tǒng)感覺很混亂，不過技術(shù)畢竟是不斷的發(fā)展，因此各子系統(tǒng)、模塊的具體實現(xiàn)技術(shù)要完全限制應該是不太可能的，也沒必要，但會希望系統(tǒng)對外提供的功能能采用統(tǒng)一的部署以及交互方法，這樣的話每個子系統(tǒng)能保持其黑盒的實現(xiàn)方式，其他子系統(tǒng)不想也不需要關心它的實現(xiàn)方式，只需要能夠統(tǒng)一的方式調(diào)用到它們提供的功能就可以了，這是出現(xiàn)的第一個需求。
起初整個應用部署在一臺機器上，但隨著系統(tǒng)的功能越來越多，不得不不斷的增加機器以減輕服務器的壓力，但很快就出現(xiàn)瓶頸，不得不把應用分層部署，這樣可以撐一段時間，在撐過一段時間后發(fā)現(xiàn)再度出現(xiàn)瓶頸，于是希望能夠再度的把系統(tǒng)進行劃分，這個時候就變成了希望能夠以非常細的粒度來部署了，而不是把一堆的功能都部署在同一臺機器上，這樣帶來的好處是系統(tǒng)的重用性能夠再度的增強，服務器的壓力能夠有效的降低，使得系統(tǒng)可以以較低的成本繼續(xù)保持Scable（就像google），其實這也是ebay的演變過程，大家可以去看看那個著名的
ebay架構(gòu)演變的PPT，還有一篇中文的
ebay是怎樣煉成的。
從上面的需求場景描述中可以看出，需要分布式服務框架的場景并不是很多，這里還有一種場景沒去提及，那就是對于一個大型企業(yè)而言，由于需要用到的軟件多種多樣，其實也是有分布式服務框架的需求的，但還是有些不同，因為要去滿足那種場景的方法可以更為簡單。
分析下分布式服務框架的應用場景，可以得知，分布式服務框架的誕生目的主要有兩個：
1、約束需要對外提供的功能，保證其以一個統(tǒng)一的方式來對外提供和獲取；
2、分布式的部署細粒度的功能。
在確定了這兩個目的后，來詳細的分析下為了達到這兩個目的，需要提供些什么feature。
要約束對外提供的功能，保證以統(tǒng)一的方式來對外提供和獲取，首先需要制定的標準是功能到底以什么方式來對外提供，這里首先誕生了服務這個很好很形象的名詞，對外提供的功能其實也就是為別人提供的服務了，那么服務里到底有些什么呢，面向接口自然是首選，所以服務都以接口方式來提供，另外可能就是會有一些服務的元信息了，如服務的名稱、描述、依賴、所在機器等等；接著要完成的就是如何把各子系統(tǒng)對外提供的功能定義成服務呢，這里要求分布式服務框架能提供強大的集成能力，例如子系統(tǒng)是采用spring來實現(xiàn)，那么就需要支持能把spring的bean直接定義成服務；定義服務完成了，這個時候要解決的問題就是其他的子系統(tǒng)怎么知道有這些服務的存在呢，因此需要提供一個統(tǒng)一的服務的注冊中心，同時相應的帶來的問題就是各個服務應用端怎么來查找這些服務，怎么調(diào)用這些服務，這也是分布式服務框架需要解決的，在提供了上面的這些feature后，第一個需求就可以基本實現(xiàn)了。
分布式的部署細粒度的功能，這個在第一個需求達成的情況下，直接就可以實現(xiàn)了，因為分布式服務框架對服務應用端的粒度并沒有要求，可粗可細，只是分布式的部署細粒度的功能其實潛在的帶來了另外的需求，那就是怎么樣把這些細粒度的服務直接組裝來滿足業(yè)務的需求，這也是分布式服務框架應該提供的功能；同時，還要注意的一點是，當變成細粒度的分布式部署的場景時，系統(tǒng)的穩(wěn)定性和性能是會受到影響的，對于大型應用來講這兩點偏偏又是非常重要的，分布式服務框架需要對此進行考慮。
.......................................................咖啡一杯，休息一下.......................................................
繼續(xù)，上面分析完畢后產(chǎn)生了分布式服務框架的基本Feature，來總結(jié)看看，并同時對其進行可選的實現(xiàn)技術(shù)的分析：
1、服務模型
在服務模型中需要詳細定義服務模型包含了哪些信息，而這些信息也就決定了服務在發(fā)布時需要提供的信息，同時也是為服務查找和調(diào)用提供的信息。
2、服務的注冊中心
服務的注冊中心在分布式服務框架中充當?shù)木褪欠招畔⒌拇鎯鏊淖饔茫瑫r它還需要提供的一個重要的功能就是查找服務，這兩個最重要功能最重要的就是穩(wěn)定、高效以及支持Cluster。
存儲服務信息上可采用數(shù)據(jù)庫存儲、分布式文件系統(tǒng)存儲等，查找服務需要的就是支持高效的查找，這個要根據(jù)服務的查找方法等來建立相應的緩存和索引，這里需要注意的是在cluster情況下的處理，選用數(shù)據(jù)庫存儲或分布式文件系統(tǒng)存儲自然是不會有cluster的問題的。
另外一個需要確定的就是服務應用端怎么調(diào)用服務注冊中心提供的管理接口，可采用的技術(shù)有JNDI、JMS、WebService等等N多種實現(xiàn)方式，可以根據(jù)具體的性能要求、實現(xiàn)方法、需求等來進行選擇。
從擴展方面去看，服務的注冊中心應該提供多種服務應用端和注冊中心的交互協(xié)議的選擇、擴展。
3、發(fā)布服務的方式，支持Spring、EJB3等等
支持直接的把服務應用端的功能發(fā)布為服務，發(fā)布的方式更多的是xml、annotation等方式，就是一種很不錯的設計，所以要根據(jù)服務應用端采用的技術(shù)而定，常見的如spring、EJB，這個完全根據(jù)分布式服務框架所面對的應用場景而定，如果你的服務應用端都是基于Spring的，那么就可以暫時只提供Spring的方式了。
注冊服務方面的技術(shù)基本也不用選擇，因為它其實是根據(jù)服務應用端采用的技術(shù)而決定的，相當于提供一個集成的接口而已，由此接口去完成和服務中心的交互。
但這里有個關鍵的實現(xiàn)技術(shù)需要選擇，就是把服務以什么方式對外提供，例如有JNDI、Webservice、JMS等等，就像Spring中的HessianServiceExporter，這里需要的是服務框架本身支持好這些協(xié)議，至于到底要實現(xiàn)多少種也是根據(jù)需求來看了，而各種協(xié)議的實現(xiàn)可以選用協(xié)議對應的成熟產(chǎn)品，如jndi有jboss jnp，也可以自己根據(jù)需求實現(xiàn)。
也許在spring中我們可以這么來發(fā)布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、查找服務和調(diào)用服務的方式，支持Spring、EJB3等等
查找服務和調(diào)用服務方面，需要做到的就是能夠讓服務應用端透明的使用遠程的服務，所以其實也是和服務應用端采用的技術(shù)相關的。
當然，它本身需要提供以各種協(xié)議和服務中心通訊，以各種協(xié)議調(diào)用遠端服務的支持，另外就是同步、異步的支持等，還需要從高效性去考慮。
對于使用者來說則比較簡單，也許在Spring中我們可以這么來調(diào)用遠端的service：
<bean id="loginService" class="HSFObjectFactoryBean">
<hsf:service>
<import:jndi server="" interface="">
<!--可用于過濾查找的服務-->
<property name=""></property>
</import:jndi>
</hsf:service>
</bean>
5、服務的組裝
服務的組裝需要提供的就是將服務中心的服務進行組裝，以實現(xiàn)復雜的業(yè)務需求，這里面需要包括容錯等等的支持，同樣，高效性也是這里面的重點。
可選用的技術(shù)有采用事件框架、jbpm等。
6、穩(wěn)定性和性能
通常來講，需要用到分布式服務框架的應用在穩(wěn)定性和性能方面都會有很高的要求，當然，穩(wěn)定性更多的是通過避免Single Point的方式來提供，但同時軟件層面也應該盡量避免無謂的錯誤，從技術(shù)角度上來講可以采取fail-fast的思想來實現(xiàn)。
性能方面，需要根據(jù)使用時的壓力情況來決定，如查找服務時太慢，需要考慮提升服務中心查找服務的效率，增加索引，使用分布式存儲等等都是可采用的方式，提升性能的方面其實可采用的方案是非常多的，但每種技術(shù)幾乎都是需要非常專業(yè)的人才去實現(xiàn)的。
上面分析的feature只是分布式服務框架的基本feature了，一個強大的分布式服務框架的話實現(xiàn)的東西會比這個多很多(例如提供服務管理端、監(jiān)控端、IDE等)，不過主要會是細節(jié)上，在具備了這些基礎feature的情況下，細節(jié)就決定了高低了，:)。
分布式服務框架的引入也許會降低些性能，但應用的適當?shù)脑挘瑒t能充分發(fā)揮服務器性能，并且很大程度的降低系統(tǒng)Scable的成本，至于開發(fā)效率的話我不覺得是分布式服務框架需要解決的問題。
服務框架其實對于所有應用而言幾乎都是需要的，而且非分布式的服務框架可選的是有很多的，但分布式服務框架可選的目前基本是沒有，所以如果不是應用真的需要，沒有必要去實現(xiàn)分布式服務框架（就像在企業(yè)應用模式里Martin Fowler講的一樣，盡量不要分布式，:)），因為分布式服務框架對于技術(shù)層面還是有挺高的要求的，說簡單點呢，就是高效的存儲、查找策略+高效的通訊策略+滿足需求的服務模型+強大的集成能力構(gòu)成了分布式服務框架的核心技術(shù)實現(xiàn)。
ps：在寫完這篇blog后，發(fā)現(xiàn)自己在基于OSGi實現(xiàn)分布式服務框架（四）里面寫OSGi不適合其實是個不準確的詞，因為在服務的應用端其實是可以采用OSGi的，不過以分布式服務框架而言，OSGi是沒有什么適用的場景，除了服務模型可參考外，但在服務應用端而言，OSGi仍然是個很好的選擇。