分析分佈式服務框架

技術是爲需求而服務的，分佈式服務框架也同樣如此，它不是憑空誕生的，也是因爲有這樣的需求纔會有分佈式服務框架這麼樣的東西誕生，在這篇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仍然是個很好的選擇。