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