Dubbox：來自當當網的SOA服務框架

Dubbo是一個來自阿里巴巴的開源分佈式服務框架，噹噹根據自身的需求，爲Dubbo實現了一些新的功能，包括REST風格遠程調用、Kryo/FST序列化等等。並將其命名爲Dubbox（即Dubbo eXtensions）。Dubbox主要的新功能包括：

1、支持REST風格遠程調用（HTTP + JSON/XML)

dubbo支持多種遠程調用方式，例如dubbo RPC（二進制序列化 + tcp協議）、http invoker（二進制序列化 + http協議，至少在開源版本沒發現對文本序列化的支持）、hessian（二進制序列化 + http協議）、WebServices （文本序列化 + http協議）等等，但缺少對當今特別流行的REST風格遠程調用（文本序列化 + http協議）的支持。

dubbox基於很是成熟的JBoss RestEasy框架，在dubbo中實現了REST風格（HTTP + JSON/XML）的遠程調用，以顯著簡化企業內部的跨語言交互，同時顯著簡化企業對外的Open API、無線API甚至AJAX服務端等等的開發。事實上，這個REST調用也使得Dubbo能夠對當今特別流行的「微服務」架構提供基礎性支持。 另外，REST調用也達到了比較高的性能，在基準測試下，HTTP + JSON與Dubbo 2.x默認的RPC協議（即TCP + Hessian2二進制序列化）之間只有1.5倍左右的差距。

REST的優勢（摘自維基百科）：

• 可更高效利用緩存來提升響應速度
• 通信自己的無狀態性可讓不一樣的服務器的處理一系列請求中的不一樣請求，提升服務器的擴展性
• 瀏覽器便可做爲客戶端，簡化軟件需求
• 相對於其餘疊加在HTTP協議之上的機制，REST的軟件依賴性更小
• 不須要額外的資源發現機制
• 在軟件技術演進中的長期的兼容性更好

基於簡單的文本格式消息和通用的HTTP協議，使REST具有極廣的適用性，幾乎全部語言和平臺都對它提供支持，同時其學習和使用的門檻也較低。在dubbo中支持REST，能夠爲當今多數主流的遠程調用場景都帶來好處：

1. 顯著簡化企業內部的異構系統之間的（跨語言）調用。此處主要針對這種場景：dubbo的系統作服務提供端，其餘語言的系統（也包括某些不基於 dubbo的java系統）作服務消費端，二者經過HTTP和文本消息進行通訊。即便相比Thrift、ProtoBuf等二進制跨語言調用方 案，REST也有本身獨特的優點（詳見後面討論）
2. 顯著簡化對外Open API（開放平臺）的開發。既能夠用dubbo來開發專門的Open API應用，也能夠將原內部使用的dubbo service直接「透明」發佈爲對外的Open REST API（固然dubbo自己將來最好能夠較透明的提供諸如權限控制、頻次控制、計費等諸多功能）
3. 顯著簡化手機（平板）APP或者PC桌面客戶端開發。相似於2，既能夠用dubbo來開發專門針對無線或者桌面的服務器端，也能夠將原內部使用的 dubbo service直接「透明」的暴露給手機APP或桌面程序。固然在有些項目中，手機或桌面程序也能夠直接訪問以上場景2中所述的Open API。
4. 顯著簡化瀏覽器AJAX應用的開發。相似於2，既能夠用dubbo來開發專門的AJAX服務器端，也能夠將原內部使用的dubbo service直接「透明」的暴露給瀏覽器中JavaScript。固然，不少AJAX應用更適合與web框架協同工做，因此直接訪問dubbo service在不少web項目中未必是一種很是優雅的架構。
5. 爲企業內部的dubbo系統之間（即服務提供端和消費端都是基於dubbo的系統）提供一種基於文本的、易讀的遠程調用方式。
6. 必定程度簡化dubbo系統對其它異構系統的調用。能夠用相似dubbo的簡便方式「透明」的調用非dubbo系統提供的REST服務（無論服務提供端是在企業內部仍是外部）

須要指出的是， 1～3是dubbo的REST調用最有價值的三種應用場景，而且爲dubbo添加REST調用，其最主要到目的也是面向服務的提供端，即開發REST服務來提供給非dubbo的（異構）消費端。概括起來，全部應用場景以下圖所示：

 

2、支持基於Kryo和FST的Java高效序列化實現

dubbo RPC是dubbo體系中最核心的一種高性能、高吞吐量的遠程調用方式，簡單的說：

• 長鏈接：避免了每次調用新建TCP鏈接，提升了調用的響應速度
• 多路複用：單個TCP鏈接可交替傳輸多個請求和響應的消息，下降了鏈接的等待閒置時間，從而減小了一樣併發數下的網絡鏈接數，提升了系統吞吐量。

dubbo RPC主要用於兩個dubbo系統之間做遠程調用，特別適合高併發、小數據的互聯網場景。而序列化對於遠程調用的響應速度、吞吐量、網絡帶寬消耗等一樣也 起着相當重要的做用，是咱們提高分佈式系統性能的最關鍵因素之一。在dubbo RPC中，同時支持多種序列化方式，例如：

• dubbo序列化：阿里還沒有開發成熟的高效java序列化實現，阿里不建議在生產環境使用它
• hessian2序列化：hessian是一種跨語言的高效二進制序列化方式。但這裏實際不是原生的hessian2序列化，而是阿里修改過的hessian lite，它是dubbo RPC默認啓用的序列化方式
• json序列化：目前有兩種實現，一種是採用的阿里的fastjson庫，另外一種是採用dubbo中本身實現的簡單json庫，但其實現都不是特別成熟，並且json這種文本序列化性能通常不如上面兩種二進制序列化。
• java序列化：主要是採用JDK自帶的Java序列化實現，性能很不理想。

在一般狀況下，這四種主要序列化方式的性能從上到下依次遞減。對於dubbo RPC這種追求高性能的遠程調用方式來講，實際上只有一、2兩種高效序列化方式比較般配，而第1個dubbo序列化因爲還不成熟，因此實際只剩下2可用， 因此dubbo RPC默認採用hessian2序列化。但hessian是一個比較老的序列化實現了，並且它是跨語言的，因此不是單獨針對java進行優化的。而 dubbo RPC實際上徹底是一種Java to Java的遠程調用，其實沒有必要採用跨語言的序列化方式（固然確定也不排斥跨語言的序列化）。

最近幾年，各類新的高效序列化方式層出不窮，不斷刷新序列化性能的上限，最典型的包括：

• 專門針對Java語言的：Kryo，FST等等
• 跨語言的：Protostuff，ProtoBuf，Thrift，Avro，MsgPack等等

這些序列化方式的性能多數都顯著優於hessian2（甚至包括還沒有成熟的dubbo序列化）。有鑑於此，咱們爲dubbo引入Kryo和FST這 兩種高效Java序列化實現，來逐步取代hessian2。其中，Kryo是一種很是成熟的序列化實現，已經在Twitter、Groupon、 Yahoo以及多個著名開源項目（如Hive、Storm）中普遍的使用。而FST是一種較新的序列化實現，目前還缺少足夠多的成熟使用案例，但它仍是非 常有前途的。

3、其餘新功特性

• 支持基於嵌入式Tomcat的HTTP remoting體系：基於嵌入式tomcat實現dubbo的 HTTP remoting體系（即dubbo-remoting-http），用以逐步取代Dubbo中舊版本的嵌入式Jetty，能夠顯著的提升REST等的遠 程調用性能，並將Servlet API的支持從5升級到3.1。（注：除了REST，dubbo中的WebServices、Hessian、HTTP Invoker等協議都基於這個HTTP remoting體系）。
• 升級Spring：將dubbo中Spring由x升級到目前最經常使用的3.x版本，減小項目中版本衝突帶來的麻煩。
• 升級ZooKeeper客戶端：將dubbo中的zookeeper客戶端升級到最新的版本，以修正老版本中包含的bug。

參考文檔：

• http://dangdangdotcom.github.io/dubbox/
• https://github.com/dangdangdotcom/dubbox

來自：http://www.biaodianfu.com/dubbox.html