Dubbo分布式服务框架

作为微服务里面的另外一大派系 Dubbo ，使用也是蛮多的，很多时候面试也会考到。

前言

平常我们在构建分布式系统的时候，一般都是基于 Dubbo 技术栈或者是 SpringCloud 技术栈来做。

早期其实最先比较流行的是 Dubbo，dubbo是目前事实上大部分公司的分布式系统的rpc框架标准，基于dubbo也可以构建一整套的微服务架构。但是需要自己大量开发。

当然去年开始spring cloud非常火，现在大量的公司开始转向spring cloud了，spring cloud人家毕竟是微服务架构的全家桶式的这么一个东西。但是因为很多公司还在用dubbo，所以dubbo肯定会是目前面试的重点，何况人家dubbo现在重启开源社区维护了，未来应该也还是有一定市场和地位的。

1.Dubbo是什么？

那我们先来聊聊Dubbo到底什么？？？

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，**说白了就是个远程服务调用的分布式框架（**告别Web Service模式中的WSdl（webservice并不是分布式的服务框架，他需要结合F5实现负载均衡。），以服务者与消费者的方式在dubbo上注册）

2.dubbo架构图(工作原理)

节点角色说明：

​ Provider: 暴露服务的服务提供方。

​ Consumer: 调用远程服务的服务消费方。

​ Registry: 服务注册与发现的注册中心。

​ Monitor: 统计服务的调用次调和调用时间的监控中心。

​ Container: 服务运行容器。

这点我觉得非常好，角色分明，可以根据每个节点角色的状态来确定该服务是否正常。

调用关系说明：

0 服务容器(container)负责启动，加载，运行服务提供者。

1 服务提供者（privider)在启动时，向注册中心注册自己提供的服务。

2 服务消费者(consumer)在启动时，向注册中心订阅自己所需的服务。

3 注册中心(Registry)返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心(Monitor)。

把以上简化的工作流程：

1）第一步，服务容器启动provider，provider向注册中心去注册
2）第二步，consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务
3）第三步，consumer调用provider
4）第四步，consumer和provider都异步的通知监控中心

（2）注册中心挂了可以继续通信吗？

可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信。

（3）例子法理解dubbo为啥存在？

（当你有一个服务A，部署在A机器上，服务B部署在B机器上，现在你有个需求是，调用A服务上现有的接口查询数据，并在B服务（消费者）中做一些处理，然后显示出来，你不能访问A服务（提供者）的数据库，这个时候你就需要远程调用了。）

（4）.Dubbo的执行流程

项目一启动，加载配置文件的时候，就会初始化，服务的提供方ServiceProvider就会向注册中心注册自己提供的服务，当消费者在启动时，就会向注册中心订阅自己所需要的服务，如果服务提供方有数据变更等，注册中心将基于长连接的形式推送变更数据给消费者。

默认使用Dubbo协议：
连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要使用dubbo协议传输大文件或超大字符串
使用场景：常规远程服务方法调用
从上面的适用范围总结，dubbo适合小数据量大并发的服务调用，以及消费者机器远大于生产者机器数的情况，不适合传输大数据量的服务比如文件、视频等，除非请求量很低。

（5）Dubbo的安全性如何得到保障：
a.在有注册中心的情况下,可以通过dubbbo admin中的路由规则，来指定固定ip的消费方来访问
b.在直连的情况下，通过在服务的提供方中设置密码(令牌)token，消费方需要在消费时也输入这 个密码，才能够正确使用。
Dubbo添加服务ip白名单，防止不法调用

（5）Duubo中如何保证分布式事务？
一般情况下，我们尽量将需要事务的方法放在一个service中，从而避开分步式事务。
Dubbo底层是基于socket： Socket通信是一个全双工的方式，如果有多个线程同时进行远程方法调用，这时建立在client server之间的socket连接上会有很多双方发送的消息传递，前后顺序也可能是乱七八糟的，server处理完结果后，将结果消息发送给client，client收到很多消息，怎么知道哪个消息结果是原先哪个线程调用的？
答：使用一个ID，让其唯一，然后传递给服务端，再服务端又回传回来，这样就知道结果是原先哪个线程的了。

（6）Dubbo的心跳机制：
目的：
维持provider和consumer之间的长连接
实现：
dubbo心跳时间heartbeat默认是1s，超过heartbeat时间没有收到消息，就发送心跳消 息(provider，consumer一样),如果连着3次(heartbeatTimeout为heartbeat*3)没有收到心跳响应，provider会关闭channel，而consumer会进行重连;不论是provider还是consumer的心跳检测都是通过启动定时任务的方式实现；

Dubbo的zookeeper做注册中心，如果注册中心全部挂掉，发布者和订阅者还能通信吗？
可以通信的，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用；

注册中心对等集群，任意一台宕机后，将会切换到另一台；注册中心全部宕机后，服务的提供者和消费者仍能通过本地缓存通讯。服务提供者无状态，任一台 宕机后，不影响使用；服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复；挂掉是不要紧的，但前提是你没有增加新的服务，如果你要调用新的服务，则是不能办到的。