讲一下Dubbo框架的实现原理及与SpringCloud微服务之间的区别

一、简介
Dubbo是由阿里巴巴开源的透明的高性能分布式RPC框架，基于dubbo协议实现，底层通信方式是基于TCP长连接，传输方式是NIO实现，提高服务的性能。主要有三个核心特性：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

二、Dubbo工作原理：

第一层：service层，接口层，给服务提供者和消费者来实现的
第二层：config层，配置层，主要是对dubbo进行各种配置的
第三层：proxy层，服务代理层，透明生成客户端的stub和服务单的skeleton
第四层：registry层，服务注册层，负责服务的注册与发现
第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
第七层：protocol层，远程调用层，封装rpc调用
第八层：exchange层，信息交换层，封装请求响应模式，同步转异步
第九层：transport层，网络传输层，抽象mina和netty为统一接口
第十层：serialize层，数据序列化层

三、Dubbo执行流程：

首先，项目启动时，会加载配置文件进行初始化，服务提供方会向注册中心注册自己提供的服务；当消费者启动时，会向注册中心订阅自己所需要的服务，如果服务提供方有数据变更，注册中心会基于长连接形式推送变更数据至消费方（异步）。

默认采用dubbo协议：

连接个数：单连接；连接方式：长连接；传输方式：NIO异步传输；传输协议：TCP；序列化：默认采用Hessian二进制。

适用范围：传入传出参数数据包较小（100K以内），消费者个数大于提供者个数，尽量不要用dubbo协议去传输大文件、视频以及大的字符串数据。

dubbo特性：适用于数据量少大并发的场景。

四、Dubbo安全性能如何得到保障：

1、有注册中心的情况下，可通过dubbo提供的dubbo admin控制台去设置路由规则，来指定固定ip消费方访问。

2、在直连的情况下，可在服务提供方设置令牌（token），此时服务消费方需要提供对应的令牌进行访问。

3、Dubbo添加服务ip白名单，防止非法调用。

五、Dubbo中如何保证分布式事务：

我们尽量把需要事务的方法加在一个service层中，避免分步式事务。Dubbo底层是基于socket连接，如果多个线程同时远程调用提供者方法，这时会建立client server之间的socket连接上会有很多双方发的数据包传递，并不难保证前后顺序，容易造成乱七八糟，服务提供方处理完后，会将处理结果发送到client，client收到很多数据包，怎么保证哪个响应数据包对应的原先哪个线程调用的吗？

这时就要使用到分布式唯一RequestID，去保证其唯一性，消费端调用时，会将唯一ID传给服务提供者；然后，服务提供者处理完，会将该ID一起响应给client（这样就能保证其前后消费顺序）。

六、Dubbo心跳机制：

目的：维持provider和customer之间的通信

实现：dubbo默认心跳时间为1s，超过心跳时间没有收到消息，就发送心跳消息，如果超过3次心跳没有收到心跳消息，provider会关闭channel，而customer会进行重连；不管是provider还是customer的心跳机制检测都是通过启动定时任务方式实现的。

七、Dubbo使用zookeeper做注册中心，如果注册中心全部挂掉了，消费方还能够与提供方正常通信吗？

可以的，因为服务消费方启动时会订阅注册中心里面所需要的服务，此时会把服务订阅的相关信息写入到本地缓存（也就是磁盘），下次与服务提供方远程调用时，会直接从本地缓存获取提供方信息进行通信。若此时服务提供方有数据变动或有新的服务，消费方是无法获取的，对其他新的服务是不能够进行正常通信的。

八、Dubbo提供负载均衡策略有哪些，如何配置吗？

RandomLoadBalance（默认随机）：可按权重配置，随机分配策略；

RoundRobinLoadBalance（轮询）：按照顺序去访问每个节点，容易造成请求堆积过多，请求分布不均匀；

LeastActiveLoadBalance（最少活跃调用数）：是指各服务请求前后调用计数差，相同活跃数，随机分配；由于各服务里面都维护活跃数计数器，用来记录当前同时处理的并发请求数，若该值越小，说明该服务处理请求很快或者当前机器负载比较低，会优先选择分配到该服务。如果一个服务处理速度很慢，会堆积起来，同时处理请求数比较多，此时活跃调用数越大，该服务会接收到的请求比较少，因为请求数与活跃数成反比。

ConsistentHashLoadBalance（一致性hash）：相同参数总是发送到同一个提供者，如果这个提供者挂掉了，它会根据它的虚拟节点，平摊到其它服务者，不会引起巨大的变动

九、负载均衡策略服务端与客户端都可配置（优先配置在客户端）

服务端：

<-! 服务端服务级别配置>-!>
<dubbo:service interface="接口名" loadbalance="roundrobin"/>
<-! 服务端方法级别配置>-!>
<dubbo:service interface="接口名">
　　<dubbo:method name="方法名" loadbalance="均衡策略名"/>
dubbo:service>    

客户端：

<-! 客户端服务级别配置>-!>
<dubbo:reference interface="接口名" loadbalance="roundrobin"/>
<-! 客户端方法级别配置>-!>
<dubbo:reference interface="接口名">
    <dubbo:method name="方法名" loadbalance="均衡策略明"/>
dubbo:reference>

搭建集群注意点（2点）：

1、同一集群环境中应用名必须保持一致

2、端口必须要不同

十、Dubbo和SpringCloud有什么区别吗？

官方说明：

Dubbo官方文档指明，dubbo是一个基于java的高性能、轻量级的rpc框架。他只是对rpc进行了封装，使其更高效而已，再牛皮也只是一个通信协议。

SpringCloud官方文档是这样写的：SpringCloud专注于为典型的用例和扩展机制提供良好的开箱即用体验，以涵盖其他情况。重点在提供良好的开箱即用体验。所以不同于dubbo只是对通信协议的封装，springcloud的目标是快速搭建一个框架，并提供很多易用的组件，使服务能快速的运行起来，以使用户有一个很好的服务体验。所以Spring Cloud的定位是微服务架构下的一站式解决方案。

总结比较：

• Dubbo由于是二进制的传输，占用带宽会更少；
• SpringCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大；
• Dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决；
• SpringCloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级；
  传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大；
• Dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决；
• SpringCloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级；
• Dubbo的注册中心可以选择zookeeper、redis等，SpringCloud的注册中心用Eureka、Consul、Nacos等。