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 + JSON	7.806	1280
REST: Jetty + JSON + GZIP	TODO	TODO
REST: Jetty + XML	TODO	TODO
REST: Jetty + XML + GZIP	TODO	TODO
REST: Tomcat + JSON	2.082	4796
REST: Netty + JSON	2.182	4576
Dubbo: FST	1.211	8244
Dubbo: kyro	1.182	8444
Dubbo: dubbo serialization	1.43	6982
Dubbo: hessian2	1.49	6701
Dubbo: fastjson	1.572	6352

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

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对企业内网中的小数据量复杂对象帮助不大，性能反而有下降（数据暂未在以上列出）。