本文目录
- dubbo和zookeeper
- dubbo协议层 jsonrpc协议迁移到http协议
- Dubbo——HTTP 协议 + JSON-RPC
- Dubbo协议长连接
- Dubbo 协议
- dubbo 和activemq的区别
- 谈谈对Dubbo的理解
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协议层 jsonrpc协议迁移到http协议
周末看到社区的协议迁移开始被提交了pr，还没merge,打算拜读一下 ***隐藏网址*** HTTP 请求本身也可以看做是 RPC 的一种具体形式。HTTP 请求也一样是可以从本地发一个信号到服务器，服务器上执行某个函数，然后返回一些信息给客户端。 ***隐藏网址*** 根据dubbo的类机构继承图，是沿用SPI机制实现的 AbstractProxyProtocol 这里比较重要的是 protocolBindingRefer 方法。,构建一个DubboInvoker对象,根据dubbo的动态代理不断找到调用方的目标对象，添加到invoke当中，但这里没有指定要传输的格式，所以在dubbo序列化的时候还是会走默认的hessian协议，需要对协议中传入的格式进行校验 基本思路：将参数中的service(传输格式传入)设置到dubbo的代理，拿到代理之后添加到invoke的责任链当中，返回一个dubbo的代理对象给调用方
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 和activemq的区别
MQTT只是IBM推出的一个消息协议，基于TCP/IP的。两个App端发送和接收消息需要中间人，这个中间人就是消息服务器（比如ActiveMQ/RabbitMQ），三者通信协议就是MQTT。dubbo服务都是注册在注册中心的，然后调用端查询注册中心获取服务真实地。
MQTT只是IBM推出的一个消息协议，基于TCP/IP的。两个App端发送和接收消息需要中间人，这个中间人就是消息服务器（比如ActiveMQ/RabbitMQ），三者通信协议就是MQTT。dubbo服务都是注册在注册中心的，然后调用端查询注册中心获取服务真实地。
谈谈对Dubbo的理解
起初是阿里巴巴开源项目，中间有一段时间不维护了，后来被当当网给捡起来维护了，最后阿里把Dubbo捐给了Apache。 Dubbo是一款优秀的服务治理中间件，一款优秀RPC（远程调用）框架，类似于webservice。 1、容器 （spring容器） 2、服务生产者 3、注册中心 （zookeeper 、redis （发布订阅 -频道）） 4、服务消费者 5、监控中心（可以查看哪个方法的使用次数） 容器启动，服务生产者会把自己的服务的接口地址报告给注册中心。服务消费者订阅它需要的服务，他去查询注册中心，大哥有地址吗？有就返回服务地址。消费者拿到地址就可以去调用服务。监控中心：监控生产者和消费者的健康状况。 注册中心挂了会产生什么影响？答：对服务的调用没有任何影响，因为本地缓存了服务端的地址。 ***隐藏网址***
