dubbo的协议（什么是dubbo）

本文目录

• 什么是dubbo
• Dubbo——HTTP 协议 + JSON-RPC
• Dubbo协议长连接
• Dubbo 协议
• dubbo和zookeeper
• dubbo协议
• dubbo内部通信用的什么协议
• dubborpc支持事务吗_dubborpc协议
• dubbo协议层 jsonrpc协议迁移到http协议

什么是dubbo

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）。

Dubbo的核心部分包括：

1、远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

2、集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

3、服务自动注册与发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo的作用

1、透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

2、软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

3、服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo——HTTP 协议 + JSON-RPC

Protocol 还有一个实现分支是 AbstractProxyProtocol，如下图所示：

从图中我们可以看到：gRPC、HTTP、WebService、Hessian、Thrift 等协议对应的 Protocol 实现，都是继承自 AbstractProxyProtocol 抽象类。

目前互联网的技术栈百花齐放，很多公司会使用 Node.js、Python、Rails、Go 等语言来开发 一些 Web 端应用，同时又有很多服务会使用 Java 技术栈实现，这就出现了大量的跨语言调用的需求。Dubbo 作为一个 RPC 框架，自然也希望能实现这种跨语言的调用，目前 Dubbo 中使用“HTTP 协议 + JSON-RPC”的方式来达到这一目的，其中 HTTP 协议和 JSON 都是天然跨语言的标准，在各种语言中都有成熟的类库。

下面就重点来分析 Dubbo 对 HTTP 协议的支持。首先，会介绍 JSON-RPC 的基础，并通过一个示例，快速入门，然后介绍 Dubbo 中 HttpProtocol 的具体实现，也就是如何将 HTTP 协议与 JSON-RPC 结合使用，实现跨语言调用的效果。

Dubbo 中支持的 HTTP 协议实际上使用的是 JSON-RPC 协议。

JSON-RPC 是基于 JSON 的跨语言远程调用协议。Dubbo 中的 dubbo-rpc-xml、dubbo-rpc-webservice 等模块支持的 XML-RPC、WebService 等协议与 JSON-RPC 一样，都是基于文本的协议，只不过 JSON 的格式比 XML、WebService 等格式更加简洁、紧凑。与 Dubbo 协议、Hessian 协议等二进制协议相比，JSON-RPC 更便于调试和实现，可见 JSON-RPC 协议还是一款非常优秀的远程调用协议。

在 Java 体系中，有很多成熟的 JSON-RPC 框架，例如 jsonrpc4j、jpoxy 等，其中，jsonrpc4j 本身体积小巧，使用方便，既可以独立使用，也可以与 Spring 无缝集合，非常适合基于 Spring 的项目。

下面先来看看 JSON-RPC 协议中请求的基本格式：

JSON-RPC请求中各个字段的含义如下：

在 JSON-RPC 的服务端收到调用请求之后，会查找到相应的方法并进行调用，然后将方法的返回值整理成如下格式，返回给客户端：

JSON-RPC响应中各个字段的含义如下：

Dubbo 使用 jsonrpc4j 库来实现 JSON-RPC 协议，下面使用 jsonrpc4j 编写一个简单的 JSON-RPC 服务端示例程序和客户端示例程序，并通过这两个示例程序说明 jsonrpc4j 最基本的使用方式。

首先，需要创建服务端和客户端都需要的 domain 类以及服务接口。先来创建一个 User 类，作为最基础的数据对象：

接下来创建一个 UserService 接口作为服务接口，其中定义了 5 个方法，分别用来创建 User、查询 User 以及相关信息、删除 User：

UserServiceImpl 是 UserService 接口的实现类，其中使用一个 ArrayList 集合管理 User 对象，具体实现如下：

整个用户管理业务的核心大致如此。下面我们来看服务端如何将 UserService 与 JSON-RPC 关联起来。

首先，创建 RpcServlet 类，它是 HttpServlet 的子类，并覆盖了 HttpServlet 的 service() 方法。我们知道，HttpServlet 在收到 GET 和 POST 请求的时候，最终会调用其 service() 方法进行处理；HttpServlet 还会将 HTTP 请求和响应封装成 HttpServletRequest 和 HttpServletResponse 传入 service() 方法之中。这里的 RpcServlet 实现之中会创建一个 JsonRpcServer，并在 service() 方法中将 HTTP 请求委托给 JsonRpcServer 进行处理：

最后，创建一个 JsonRpcServer 作为服务端的入口类，在其 main() 方法中会启动 Jetty 作为 Web 容器，具体实现如下：

这里使用到的 web.xml 配置文件如下：

完成服务端的编写之后，下面再继续编写 JSON-RPC 的客户端。在 JsonRpcClient 中会创建 JsonRpcHttpClient，并通过 JsonRpcHttpClient 请求服务端：

在 AbstractProxyProtocol 的 export() 方法中，首先会根据 URL 检查 exporterMap 缓存，如果查询失败，则会调用 ProxyFactory.getProxy() 方法将 Invoker 封装成业务接口的代理类，然后通过子类实现的 doExport() 方法启动底层的 ProxyProtocolServer，并初始化 serverMap 集合。具体实现如下：

在 HttpProtocol 的 doExport() 方法中，与前面介绍的 DubboProtocol 的实现类似，也要启动一个 RemotingServer。为了适配各种 HTTP 服务器，例如，Tomcat、Jetty 等，Dubbo 在 Transporter 层抽象出了一个 HttpServer 的接口。

***隐藏网址***

HttpBinder 接口中的 bind() 方法被 @Adaptive 注解修饰，会根据 URL 的 server 参数选择相应的 HttpBinder 扩展实现，不同 HttpBinder 实现返回相应的 HttpServer 实现。HttpServer 的继承关系如下图所示：

这里以 JettyHttpServer 为例简单介绍 HttpServer 的实现，在 JettyHttpServer 中会初始化 Jetty Server，其中会配置 Jetty Server 使用到的线程池以及处理请求 Handler：

可以看到 JettyHttpServer 收到的全部请求将委托给 DispatcherServlet 这个 HttpServlet 实现，而 DispatcherServlet 的 service() 方法会把请求委托给对应接端口的 HttpHandler 处理：

了解了 Dubbo 对 HttpServer 的抽象以及 JettyHttpServer 的核心之后，回到 HttpProtocol 中的 doExport() 方法继续分析。

在 HttpProtocol.doExport() 方法中会通过 HttpBinder 创建前面介绍的 HttpServer 对象，并记录到 serverMap 中用来接收 HTTP 请求。这里初始化 HttpServer 以及处理请求用到的 HttpHandler 是 HttpProtocol 中的内部类，在其他使用 HTTP 协议作为基础的 RPC 协议实现中也有类似的 HttpHandler 实现类，如下图所示：

在 HttpProtocol.InternalHandler 中的 handle() 实现中，会将请求委托给 skeletonMap 集合中记录的 JsonRpcServer 对象进行处理：

skeletonMap 集合中的 JsonRpcServer 是与 HttpServer 对象一同在 doExport() 方法中初始化的。最后，我们来看 HttpProtocol.doExport() 方法的实现：

介绍完 HttpProtocol 暴露服务的相关实现之后，下面再来看 HttpProtocol 中引用服务相关的方法实现，即 protocolBindinRefer() 方法实现。该方法首先通过 doRefer() 方法创建业务接口的代理，这里会使用到 jsonrpc4j 库中的 JsonProxyFactoryBean 与 Spring 进行集成，在其 afterPropertiesSet() 方法中会创建 JsonRpcHttpClient 对象：

下面来看 doRefer() 方法的具体实现：

在 AbstractProxyProtocol.protocolBindingRefer() 方法中，会通过 ProxyFactory.getInvoker() 方法将 doRefer() 方法返回的代理对象转换成 Invoker 对象，并记录到 Invokers 集合中，具体实现如下：

本文重点介绍了在 Dubbo 中如何通过“HTTP 协议 + JSON-RPC”的方案实现跨语言调用。首先介绍了 JSON-RPC 中请求和响应的基本格式，以及其实现库 jsonrpc4j 的基本使用；接下来我们还详细介绍了 Dubbo 中 AbstractProxyProtocol、HttpProtocol 等核心类，剖析了 Dubbo 中“HTTP 协议 + JSON-RPC”方案的落地实现。

Dubbo协议长连接

连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
适用场景：常规远程服务方法调用
优点：采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（官方推荐使用）
缺点：在大文件传输时，单一连接会成为瓶颈

NIO单一长连接案例
业务线程在发出请求之前，需要存储一个请求对象，同时挂起相应的业务线程（挂起不会被任务调度，所以不存在线程切换消耗），这个请求对象包含了此次请求的id，然后在获取服务端返回的数据的时候，解析出这个id，通过这个id取出请求对象，并唤醒对应的线程。

Dubbo 协议

Dubbo是 Alibaba 开源的分布式服务框架远程调用框架，在网络间传输数据，就需要通信协议和序列化。

***隐藏网址***

先介绍几种常见的协议：

缺省协议，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。
连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
适用场景：常规远程服务方法调用

1、dubbo默认采用dubbo协议，dubbo协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
2、他不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
配置如下：

《dubbo:protocol name="dubbo" port="20880" /》
《dubbo:protocol name=“dubbo” port=“9090” server=“netty” client=“netty” codec=“dubbo”
serialization=“hessian2” charset=“UTF-8” threadpool=“fixed” threads=“100” queues=“0” iothreads=“9”
buffer=“8192” accepts=“1000” payload=“8388608” /》
3、Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接。

《dubbo:protocol name="dubbo" connections="2" /》
4、为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护

《dubbo:protocol name="dubbo" accepts="1000" /》

Java标准的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：TCP
传输方式：同步传输
序列化：Java标准二进制序列化
适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。
适用场景：常规远程服务方法调用，与原生RMI服务互操作

RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式 。

基于Hessian的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：表单序列化
适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。
适用场景：需同时给应用程序和浏览器JS使用的服务。

1、Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现。
***隐藏网址***

***隐藏网址***
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：表单序列化
适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。
适用场景：需同时给应用程序和浏览器JS使用的服务。

基于WebService的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：SOAP文本序列化
适用场景：系统集成，跨语言调用

序列化是将一个对象变成一个二进制流就是序列化， 反序列化是将二进制流转换成对象
为什么要序列化？

Dubbo序列化支持java、compactedjava、nativejava、fastjson、dubbo、fst、hessian2、kryo，其中默认hessian2。其中java、compactedjava、nativejava属于原生java的序列化。

hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化，而是阿里修改过的，它是dubbo RPC默认启用的序列化方式。
json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。
java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。

dubbo和zookeeper

dubbo 是一个远程调用服务的分布式框架，可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务，使得远程调用的协议可以使用dobbo协议( dubbo://x.x.x.x )或者其它协议，可以配置zookeeper集群地址，实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候，它也是可以实现服务端和调用端的通信的，这种方式是点对点通信的，所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候，就会暴露许多的问题：增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心，来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。

Dubbo实现服务调用是通过RPC的方式，即客户端和服务端共用一个接口(将接口打成一个jar包，在客户端和服务端引入这个jar包)，客户端面向接口写调用，服务端面向接口写实现，中间的网络通信交给框架去实现。

咱们来看下Spring 配置声明暴露服务，provider.xml文件

再来看服务消费者，consumer.xml文件

这就是典型的点对点的服务调用。当然我们为了高可用，可以在consumer.xml中配置多个服务提供者，并配置响应的负载均衡策略。

配置多个服务调用者在comsumer.xml的dubbo:reference标签的url属性中加入多个地址，中间用分号隔开即可；配置负载均衡策略在comsumer.xml的dubbo:reference标签中增加loadbalance属性即可，值可以为如下四种类型：

那么目前的架构有什么问题呢？
1.当服务提供者增加节点时，需要修改配置文件。
2.当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求。

这个时候就需要引入注册中心了，Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心，要使用注册中心，只需要将provider.xml和consumer.xml更改为如下：

如果zookeeper是一个集群，则多个地址之间用逗号分隔即可

把consumer.xml中配置的直连的方式去掉

注册信息在zookeeper中如何保存？
启动上面服务后，我们观察zookeeper的根节点多了一个dubbo节点及其他，图示如下

最后一个节点中服务的地址，为什么把最后一个节点标成绿色？因为最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址。
其实一个zookeeper集群能被多个应用公用，因为不同的框架会在zookeeper上建不同的节点，互不影响。如dubbo会创建一个/dubbo节点，storm会创建一个/storm节点。

zookeeper 介绍：
zookeeper是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。

流程说明：

支持以下功能：

补充：
dubbo的协议使用什么序列化框架？
***隐藏网址***

dubbo的通信方式？
采用单一长连接和NIO异步通信，基于Hessian2作为序列化协议。适合于小数据量（每次请求在100kb以内）大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。具体实现是消费者使用 NettyClient，提供者使用 NettyServer，Provider 启动的时候，会开启端口监听，使用我们平时启动 Netty 一样的方式。而 Client 在 Spring getBean 的时候，会创建 Client，调用远程方法的时候，将数据通过DubboCodec编码发送到 NettyServer，然后 NettServer 收到数据后解码，并调用本地方法，并返回数据，完成一次完美的 RPC 调用。

zookeeper选举机制？
zookeeper选举算法默认的是FastLeaderElection，选举机制的概念：
1.服务器ID：比如有三台服务器，编号分别是1、2、3，编号越大在选择算法中的权重越大。
2.事务ID：服务器中存放的最大数据ID(致使ZooKeeper节点状态改变的每一个操作都将更新事务id，即时间戳)，值越大说明数据越新，在选举算法中数据越新权重越大。
3.逻辑时钟，或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。
选举状态：LOOKING：竞选状态；FOLLOWING：随从状态，同步leader状态，参与投票；OBSERVING：观察状态,同步leader状态，不参与投票；LEADING：领导者状态。
初次选举简述：
目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：
1.服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
2.服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
3.服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数为3正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
4.服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
5.服务器5启动，后面的逻辑同服务器4成为小弟。
如果中间有节点挂掉，只要有半数以上节点存活，就可以正常服务，如果leader挂掉，则所有节点处于Looking状态 ，各自依次发起投票，投票包含自己的服务器ID和最新事务ID，如果发现别人的事务id比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的事务id所属节点(事务id一样，则数据id大的胜出)。每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。

引用：
***隐藏网址***

dubbo协议

dubbo协议是dubbo默认的协议，它的特点如下：

Dubbo 协议采用经典定长包头+变长包体的协议设计，包头记录了数据的序列化方式，请求状态，数据长度等信息，包体是请求/响应对象序列化后的二进制数据。格式见下图

字段说明： 2字节short类型的Magic 1字节的消息标志位 5位序列化id 1位心跳还是正常请求 1位双向还是单向 1位请求还是响应 1字节的状态位 8字节的消息id 4字节数据长度

网络传输层传输的就是这种二进制数据，基本流程如下

关于更多dubbo支持的RPC协议大家可以参考这篇文章

dubbo内部通信用的什么协议

dubbo内部通信用的什么协议
***隐藏网址***
　　有鉴于此，我们基于标准的Java REST API——JAX-RS 2.0（Java API for RESTful Web Services的简写），为dubbo提供了接近透明的REST调用支持。由于完全兼容Java标准API，所以为dubbo开发的所有REST服务，未来脱离dubbo或者任何特定的REST底层实现一般也可以正常运行。

dubborpc支持事务吗_dubborpc协议

目前比较多的解决方案有几个：

一、结合MQ消息中间件实现的可靠消息最终一致性

二、TCC补偿性事务解决方案

三、最大努力通知型方案

第一种方案：可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态

第二种方案：TCC补偿性，分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。

dubbo协议层 jsonrpc协议迁移到http协议

周末看到社区的协议迁移开始被提交了pr，还没merge,打算拜读一下

***隐藏网址***

HTTP 请求本身也可以看做是 RPC 的一种具体形式。HTTP 请求也一样是可以从本地发一个信号到服务器，服务器上执行某个函数，然后返回一些信息给客户端。

***隐藏网址***

根据dubbo的类机构继承图，是沿用SPI机制实现的 AbstractProxyProtocol
这里比较重要的是 protocolBindingRefer 方法。,构建一个DubboInvoker对象,根据dubbo的动态代理不断找到调用方的目标对象，添加到invoke当中，但这里没有指定要传输的格式，所以在dubbo序列化的时候还是会走默认的hessian协议，需要对协议中传入的格式进行校验

基本思路：将参数中的service(传输格式传入)设置到dubbo的代理，拿到代理之后添加到invoke的责任链当中，返回一个dubbo的代理对象给调用方