dubbo学习三 dubbox概述

时间 2019-12-12

原文原文链接

当当网根据自身的需求，对dubbo进行了扩展就叫成了dubbox。具体的使用方法能够参照官网各类例子：http://dangdangdotcom.github.io/dubbox/

支持rest风格远程调用

以前了解过restful服务具体是什么，resteasy也了解过，因此看到就能够理解。

基于很是成熟的以前看过的rest实现jboss-resteasy框架，他把这个框架集成到了dubbo里面实现了rest风格的远程调用，这样就大大简化了服务的开发和更多类型的消费者系统。也使dubbo能够对当今特别流行的微服务架构提供支持。可是因为restful服务的消费端可能多种多样，若是消费端不是用dubbo的话，那么关于容错和负载均衡就得另想办法了，由于dubbo本身的容错和负载是在消费端调用的时候实现的。须要考虑其余手段对多个服务端作负载了，nginx，f5什么的。

支持基于Kryo和FST的Java高效序列化实现

关于序列化的一点东西，以前了解过，因此这里就能够看明白了。

下面的一些官网的摘抄

在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是一种较新的序列化实现，目前还缺少足够多的成熟使用案例，但我认为它仍是很是有前途的。

在面向生产环境的应用中，我建议目前更优先选择Kryo。

使用方法

还有一些其余扩展和优化

支持基于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配置等等。