dubbox新特性介绍

云深处

dubbx是当当网对原阿里dubbo2.x的升级，并且兼容原有的dubbox。其中升级了zookeeper和spring版本，并且支持restfull风格的远程调用。
dubbox git地址:  https://github.com/dangdangdotcom/dubbox
dubbox 关于restfull的介绍：http://dangdangdotcom.github.io/dubbox/rest.html
--------------------------------------------------------------------------------------------------------------------------------------------
dubbox的新特性介绍：

• 　　支持REST风格远程调用（HTTP + JSON/XML)：基于非常成熟的JBoss RestEasy框 架，在dubbo中实现了REST风格（HTTP + JSON/XML）的远程调用，以显著简化企业内部的跨语言交互，同时显著简化企业对外的Open API、无线API甚至AJAX服务端等等的开发。事实上，这个REST调用也使得Dubbo可以对当今特别流行的“微服务”架构提供基础性支持。 另外，REST调用也达到了比较高的性能，在基准测试下，HTTP + JSON与Dubbo 2.x默认的RPC协议（即TCP + Hessian2二进制序列化）之间只有1.5倍左右的差距，详见文档中的基准测试报告。
  
• 　　支持基于Kryo和FST的Java高效序列化实现：基于当今比较知名的Kryo和FST高性能序列化库，为Dubbo默认的RPC协议添加新的序列化实现，并优化调整了其序列化体系，比较显著的提高了Dubbo RPC的性能，详见文档中的基准测试报告。
  
• 　　支持基于Jackson的JSON序列化：基于业界应用最广泛的Jackson序列化库，为Dubbo默认的RPC协议添加新的JSON序列化实现。
  
• 　　支持基于嵌入式Tomcat的HTTP remoting体系：基于嵌入式tomcat实现dubbo 的HTTP remoting体系（即dubbo-remoting-http），用以逐步取代Dubbo中旧版本的嵌入式Jetty，可以显著的提高REST等的远 程调用性能，并将Servlet API的支持从2.5升级到3.1。（注：除了REST，dubbo中的WebServices、Hessian、HTTP Invoker等协议都基于这个HTTP remoting体系）。
  
• 　　升级Spring：将dubbo中Spring由2.x升级到目前最常用的3.x版本，减少版本冲突带来的麻烦。
  
• 　　升级ZooKeeper客户端：将dubbo中的zookeeper客户端升级到最新的版本，以修正老版本中包含的bug。
  
• 　　支持完全基于Java代码的Dubbo配置：基于Spring的Java Config，实现完全无XML的纯Java代码方式来配置dubbo
  
• 　　调整Demo应用：暂时将dubbo的demo应用调整并改写以主要演示REST功能、Dubbo协议的新序列化方式、基于Java代码的Spring配置等等。
  
• 　　修正了dubbo的bug 包括配置、序列化、管理界面等等的bug。
  

　　注：dubbox和dubbo 2.x是兼容的，没有改变dubbo的任何已有的功能和配置方式（除了升级了spring之类的版本）

----------------------------------------------------------------------------------------------------------------------------------------------------
以下为restfull风格的性能报告：
REST最佳实践
　　TODO
性能基准测试
测试环境
　　粗略如下：

• 两台独立服务器
  
• 4核Intel(R) Xeon(R) CPU E5-2603 0 @ 1.80GHz
  
• 8G内存
  
• 服务器之间网络通过百兆交换机
  
• CentOS 5
  
• JDK 7
  
• Tomcat 7
  
• JVM参数-server -Xms1g -Xmx1g -XX:PermSize=64M -XX:+UseConcMarkSweepGC
  

测试脚本
　　和dubbo自身的基准测试保持接近：
　　10个并发客户端持续不断发出请求：

• 传入嵌套复杂对象（但单个数据量很小），不做任何处理，原样返回
  
• 传入50K字符串，不做任何处理，原样返回（TODO：结果尚未列出）
  

　　进行5分钟性能测试。（引用dubbo自身测试的考虑：“主要考察序列化和网络IO的性能，因此服务端无任何业务逻辑。取10并发是考虑到http协议在高并发下对CPU的使用率较高可能会先打到瓶颈。”）
测试结果
　　下面的结果主要对比的是REST和dubbo RPC两种远程调用方式，并对它们作不同的配置，例如：

• “REST: Jetty + XML + GZIP”的意思是：测试REST，并采用jetty server，XML数据格式，启用GZIP压缩。
  
• “Dubbo: hessian2”的意思是：测试dubbo RPC，并采用hessian2序列化方式。
  

　　针对复杂对象的结果如下（响应时间越小越好，TPS越大越好）：
远程调用方式平均响应时间平均TPS（每秒事务数）REST: Jetty + JSON7.8061280REST: Jetty + JSON + GZIPTODOTODOREST: Jetty + XMLTODOTODOREST: Jetty + XML + GZIPTODOTODOREST: Tomcat + JSON2.0824796REST: Netty + JSON2.1824576Dubbo: FST1.2118244Dubbo: kyro1.1828444Dubbo: dubbo serialization1.436982Dubbo: hessian21.496701Dubbo: fastjson1.5726352

　　仅就目前的结果，一点简单总结：

• dubbo RPC（特别是基于高效java序列化方式如kryo，fst）比REST的响应时间和吞吐量都有较显著优势，内网的dubbo系统之间优先选择dubbo RPC。
  
• 在 REST的实现选择上，仅就性能而言，目前tomcat7和netty最优（当然目前使用的jetty和netty版本都较低）。tjws和sun http server在性能测试中表现极差，平均响应时间超过200ms，平均tps只有50左右（为了避免影响图片效果，没在上面列出）。
  
• 在REST中JSON数据格式性能优于XML（数据暂未在以上列出）。
  
• 在REST中启用GZIP对企业内网中的小数据量复杂对象帮助不大，性能反而有下降（数据暂未在以上列出）。