dubbo是一个远程调用服务的分布式框架，可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务，使得远程调用的协议可以使用dobbo协议(dubbo://x.x.x.x)或者其它协议，可以配置zookeeper集群地址，实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候，它也是可以实现服务端和调用端的通信的，这种方式是点对点通信的，所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候，就会暴露许多的问题：增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心，来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。
Dubbo实现服务调用是通过RPC的方式，即客户端和服务端共用一个接口(将接口打成一个jar包，在客户端和服务端引入这个jar包)，客户端面向接口写调用，服务端面向接口写实现，中间的网络通信交给框架去实现。
咱们来看下Spring 配置声明暴露服务，provider.xml文件
<?xml version="1.0" encoding="UTF-8"?>
<beans>
<!-- 当前项目在整个分布式架构里面的唯一名称，用于计算依赖关系 -->
<dubbo:application name="helloworld-app" />
<!--dubbo这个服务所要暴露的服务地址所对应的注册中心，N/A为不使用注册中心-->
<dubbo:registry address="N/A"/>
<!--当前服务发布所依赖的协议；dubbo、webservice、Thrift、Hessain、http、rmi、redis、rest、memcached等九种-->
<dubbo:protocol name="dubbo" port="20880"/>
<!--服务发布的配置，需要暴露的服务接口-->
<dubbo:service interface="com.st.DemoService"
ref="demoService"/>
<!--bean的定义-->
<bean id="demoService" class="com.st.DemoServiceImpl"/>
</beans>
再来看服务消费者，consumer.xml文件
<?xml version="1.0" encoding="UTF-8"?>
<beans>
<!-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 -->
<dubbo:application name="consumer-of-helloworld-app"/>
<dubbo:registry address="N/A"/>
<!-- 生成远程服务代理，可以和本地bean一样使用demoService -->
<dubbo:reference id="demoService" interface="com.st.DemoService"
url="dubbo://localhost:20880/com.st.DemoService"/>
</beans>
这就是典型的点对点的服务调用。当然我们为了高可用，可以在consumer.xml中配置多个服务提供者，并配置响应的负载均衡策略。
配置多个服务调用者在comsumer.xml的dubbo:reference标签的url属性中加入多个地址，中间用分号隔开即可；配置负载均衡策略在comsumer.xml的dubbo:reference标签中增加loadbalance属性即可，值可以为如下四种类型：
- Random LoadBalance，随机，按权重设置随机概率，具体实现是将所有的invoker的权重都加起来，在这个总权重范围内随机生成一个数字，用这个数字依次减去没个invoker的权重，当结果变为<0时,即是这个invoker来执行。随机策略是默认策略。
- ConsistentHash LoadBalance，一致性 Hash，相同参数的请求总是发到同一提供者。
- LeastActive LoadBalance，最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。活跃数计算是每次调用该invoker时会将数字+1，调用完成后-1，这样执行慢的invoker在同一时间节点上的活跃数字就会比较大，快的就会比较小。
- RoundRobin LoadBalance，根据权重进轮询，轮询的缺点就是无法顾及invoker的执行效率，有可能将请求积压在某一处理较慢的provider上。
看完负载均衡策略，我们再来看下容错策略，容错策略有六种：
- Failover 故障转移策略。当消费者调用提供者集群中的某个服务器失败时，其会自动尝试着调用其它服务器。该策略通常用于读操作
- Failfast 快速失败策略。消费者端只发起一次调用，若失败则立即报错。通常用于非性的写操作，比如新增记录。
- Failsafe 失败安全策略。当消费者调用提供者出现异常时，直接忽略本次消费操作。该策略通常用于执行相对不太重要的服务
- Failback 失败自动恢复策略。消费者调用提供者失败后，Dubbo会记录下该失败请求，然后定时自动重新发送该请求。该策略通常用于实时性要求不太高的服务
- Forking 并行策略。消费者对于同一服务并行调用多个提供者服务器，只要一个成功即调用结束并返回结果。通常用于实时性要求较高的读操作
- Broakcast 广播策略。广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息
//示例 负载均衡使用LeastActive，容错使用Failover
@DubboReference(cluster = "failover", loadbalance = "leastactive")
private ExampleService exampleService;
那么目前的架构有什么问题呢？
1.当服务提供者增加节点时，需要修改配置文件。
2.当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求。
这个时候就需要引入注册中心了，Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心，要使用注册中心，只需要将provider.xml和consumer.xml更改为如下：
<!--<dubbo:registry address="N/A"/>-->
<dubbo:registry protocol="zookeeper" address="192.168.11.129:2181"/>
如果zookeeper是一个集群，则多个地址之间用逗号分隔即可
<dubbo:registry protocol="zookeeper" address="192.168.11.129:2181,192.168.11.137:2181,192.168.11.138:2181"/>
把consumer.xml中配置的直连的方式去掉
<!-- 生成远程服务代理，可以和本地bean一样使用demoService -->
<!--<dubbo:reference id="demoService" interface="com.st.DemoService"-->
<!--url="dubbo://localhost:20880/com.st.DemoService"/>-->
<dubbo:reference id="demoService" interface="com.st.DemoService"/>
注册信息在zookeeper中如何保存？
启动上面服务后，我们观察zookeeper的根节点多了一个dubbo节点及其他，图示如下
图1.png
最后一个节点中服务的地址，为什么把最后一个节点标成绿色？因为最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址。
其实一个zookeeper集群能被多个应用公用，因为不同的框架会在zookeeper上建不同的节点，互不影响。如dubbo会创建一个/dubbo节点，storm会创建一个/storm节点。
zookeeper介绍：
zookeeper是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。
流程说明：
- 服务提供者启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址
- 服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址
- 监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。
支持以下功能：
- 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
- 当注册中心重启时，能自动恢复注册数据，以及订阅请求
- 当会话过期时，能自动恢复注册数据，以及订阅请求
- 当设置 <dubbo:registry check="false" /> 时，记录失败注册和订阅请求，后台定时重试
- 可通过 <dubbo:registry username="admin" password="1234" /> 设置 zookeeper 登录信息
- 可通过 <dubbo:registry group="dubbo" /> 设置 zookeeper 的根节点，不设置将使用无根树
- 支持 * 号通配符 <dubbo:reference group="" version="" />，可订阅服务的所有分组和所有版本的提供者
其中，dubbo与zk的连接方式为长链接，这样的好处是在服务启动后可以持续地与 ZooKeeper 进行通信，实时地感知服务的注册和变化情况。
补充：
dubbo的协议使用什么序列化框架？
dubbo有多种协议(Dubbo协议、RMI协议、HTTP协议、Hessian协议、Thrift协议、Webservice协议等)，不同的协议默认使用不同的序列化框架。比如dubbo协议默认使用 Hessian2 序列化(说明：Hessian2 是阿里在 Hessian 基础上进行的二次开发，起名为Hessian2)。rmi协议默认为 java 原生序列化，http协议默认为为 json。
dubbo的通信方式？
使用dubbo协议时采用单一长连接(即每个消费者和服务提供者建立一个tcp长连接)和NIO异步通信(一个线程可以同时处理大量的连接请求，使用Future)，基于Hessian2作为序列化协议。适合于小数据量（每次请求在100kb以内）大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。具体实现是消费者使用 NettyClient，提供者使用 NettyServer，Provider 启动的时候，会开启端口监听，使用我们平时启动 Netty 一样的方式。而 Client 在 Spring getBean 的时候，会创建 Client，调用远程方法的时候，将数据通过序列化方式发送到 NettyServer，然后 NettServer 收到数据后反序列化，并调用本地方法，返回数据，完成一次完美的 RPC 调用。
服务提供者暴露过程？
先读取配置信息，通过 Proxy 封装服务接口， 通过 Proxy 封装成 Invoker，它是真实服务调用的实例。然后将 Invoker 转化成Exporter，Exporter 只是把 Invoker 包装了一层，是为了在注册中心中暴露自己，之后会向注册中心注册服务信息，再创建 NettyServer 监听端口，并保存服务实例。
dubbo如何处理粘包拆包？
TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。dubbo中处理逻辑是如果出现粘包，就会根据它的请求长度(请求header长度为16字节，里面包含了魔数、序列化标志、消息类型 、状态码 、序列化后的消息body的长度、请求id)进行截取；如果出现了拆包，数据不完整，就进入循环重新读取，直到取到完整数据。调用业务逻辑响应时，会根据请求id(每个请求会生成一个id)找到对应的请求，响应给对应的调用方。
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。
需要注意的是，zookeeper选主期间会产生短暂的不可用状态，但是这个时间一般很短，对于小型的zookeeper集群，这个时间通常是几百毫秒。
网友评论