关于dubbo是用的什么协议？
在使用dubbo的时候会配置<dubbo:protocolname="dubbo"port="20880"/>所以在回答面试官的时候就随口说的是dubbo协议，其实面试官问的此协议非彼协议，而是问的是http协议还是Tcp协议，因为dubbo的核心就是用的单一长连接进行异步通信。
Tcp协议就是所谓的长连接，长连接的好处：
减少来回握手的频率，当操作频繁，点对点的通讯时，可以同时发送多个数据包，以不至于服务者被消费者压死
为什么要用dubbo进行数据传输？
一般服务端服务器比较少，消费端有可能会有很多项目或者工程会调用dubbo的接口，而且数据量传输较小且并发量比较高的情况下用dubbo效率会很高。
Dubbo中zookeeper做注册中心，如果注册中心集群都挂掉，发布者和订阅者之间还能通信么？ 可以
1.启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用。
2.注册中心对等集群，任意一台宕掉后，会自动切换到另一台 。
3.注册中心全部宕掉，服务提供者和消费者仍可以通过本地缓存通讯 。
4.服务提供者无状态，任一台 宕机后，不影响使用 。
5.服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复 。
dubbo连接注册中心和直连的区别 ？
在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连， 点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表，服务注册中心，动态的注册和发现服务，使服务的位置透明，并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover， 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外，注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者，注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表，注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
Dubbo在安全机制方面是如何解决的 ？
Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。
Dubbo常见的异常 ？
TimeoutException
RemotingException
RpcException
Dubbo启动时如果依赖的服务不可用会怎样？
Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check="true"，可以通过 check="false" 关闭检查。
当一个服务接口有多种实现时怎么做？
当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。
服务上线怎么兼容旧版本？
可以用版本号（version）过渡，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。
服务读写推荐的容错策略是怎样的？
读操作建议使用 Failover 失败自动切换，默认重试两次其他服务器。
写操作建议使用 Failfast 快速失败，发一次调用失败就立即报错。
Dubbo的管理控制台能做什么？
管理控制台主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。
服务提供者能实现失效踢出是什么原理？
基于zookeeper的临时节点原理
持久节点
所谓持久节点,是指在节点创建后,就一直存在,直到有删除操作来主动清除这个节点,也就是说不会因为创建该节点的客户端会话失效而消失
临时节点
临时节点的生命周期和客户端会话绑定,也就是说,如果客户端会话失效,那么这个节点就会自动被清除掉
创建的临时节点什么时候会被删除，是连接一断就删除吗？延时是多少？
连接断了之后，ZK不会马上移除临时数据，只有当SESSIONEXPIRED之后，才会把这个会话建立的临时数据移除。因此，用户需要谨慎设置Session_TimeOut
说说核心的配置有哪些？
dubbo:service/ 服务提供者暴露服务配置
dubbo:reference/ 服务消费者引用服务配置
dubbo:protocol/ 服务提供者协议配置
dubbo:registry/ 注册中心配置
dubbo:application/ 应用信息配置
dubbo:provider/ 服务提供者缺省值配置
dubbo:consumer/ 服务消费者缺省值配置
dubbo:method/ 方法级配置
集群容错
1.Failover Cluster
失败自动切换，当出现失败，重试其它服务器,通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
重试次数配置如下：
<dubbo:service retries="2" />
或
<dubbo:reference retries="2" />
或
<dubbo:reference>
<dubbo:method name="findFoo" retries="2" />
</dubbo:reference>
2.Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
3.Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
4.Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
5.Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
6.Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错,通常用于通知所有提供者更新缓存或日志等本地资源信息。
配置
服务提供方配置：
<!-- 提供方应用信息，用于计算依赖关系 -->
<dubbo:application name="hello-world-app" />
<!-- 使用zookeeper注册中心暴露服务地址 -->
<dubbo:registry address="zookeeper://224.5.6.7:1234" />
<!-- 用dubbo协议在20880端口暴露服务 这个端口可用于点对点调试-->
<dubbo:protocol name="dubbo" port="20880" />
<!-- 声明需要暴露的服务接口 -->
<dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" />
<!-- 和本地bean一样实现服务 -->
<bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" />
服务消费方配置：
<!-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 -->
<dubbo:application name="consumer-of-helloworld-app" />
<!-- 使用zookeeper注册中心暴露发现服务地址 -->
<dubbo:registry address="zookeeper://224.5.6.7:1234" />
<!-- 生成远程服务代理，可以和本地bean一样使用demoService -->
<dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" />
<!-- 服务启动关闭对该服务提供者的接口是否正常的监测，也就是BarService是否可以正常调用不影响本应用的启动，当为true的时候如果该接口挂了，本应用就起不起来了-->
<dubbo:reference interface="com.foo.BarService" check="false" />
<!-- 关闭所有服务的启动时检查 -->
<dubbo:consumer check="false" />
<!-- 配置重试次数，最好只用于读的重试，写操作可能会引起多次写入 下面三个任意一个配置就行 默认retries="0"-->
<dubbo:service retries="2" />
<dubbo:reference retries="2" />
<dubbo:reference>
<dubbo:method name="findFoo" retries="2" />
</dubbo:reference>
<!-- 扫描注解包路径，多个包用逗号分隔，不填pacakge表示扫描当前ApplicationContext中所有的类 -->
<dubbo:annotation package="com.foo.bar.service" />
dubbo调用服务的负载均衡，最后一种比较适合短时间内大量参数一样的请求
Random LoadBalance
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
算法参见：http://en.wikipedia.org/wiki/Consistent_hashing。
缺省只对第一个参数Hash，如果要修改，请配置<dubbo:parameter key="hash.arguments" value="0,1" />
缺省用160份虚拟节点，如果要修改，请配置<dubbo:parameter key="hash.nodes" value="320" />
配置如：
<dubbo:service interface="..." loadbalance="roundrobin" />
或：
<dubbo:reference interface="..." loadbalance="roundrobin" />
或：
<dubbo:service interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>
或：
<dubbo:reference interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>
当一个接口有多种实现时，可以用group区分。
<dubbo:service group="feedback" interface="com.xxx.IndexService" />
<dubbo:service group="member" interface="com.xxx.IndexService" />
<dubbo:reference id="feedbackIndexService" group="feedback" interface="com.xxx.IndexService" />
<dubbo:reference id="memberIndexService" group="member" interface="com.xxx.IndexService" />
任意组：(2.2.0以上版本支持，总是只调一个可用组的实现)
<dubbo:reference id="barService" interface="com.foo.BarService" group="*" />
当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。
在低压力时间段，先升级一半提供者为新版本
再将所有消费者升级为新版本
然后将剩下的一半提供者升级为新版本
<dubbo:service interface="com.foo.BarService" version="1.0.0" />
<dubbo:service interface="com.foo.BarService" version="2.0.0" />
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />
不区分版本：(2.2.0以上版本支持)
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />
按组合并返回结果，比如菜单服务，接口一样，但有多种实现，用group区分，现在消费方需从每种group中调用一次返回结果，合并结果返回，这样就可以实现聚合菜单项。比较鸡肋，小点的项目应该都用不到
配置如：(搜索所有分组)
<dubbo:reference interface="com.xxx.MenuService" group="*" merger="true" />
(合并指定分组)
<dubbo:reference interface="com.xxx.MenuService" group="aaa,bbb" merger="true" />
(指定方法合并结果，其它未指定的方法，将只调用一个Group)
<dubbo:reference interface="com.xxx.MenuService" group="*">
<dubbo:method name="getMenuItems" merger="true" />
</dubbo:service>
(某个方法不合并结果，其它都合并结果)
<dubbo:reference interface="com.xxx.MenuService" group="*" merger="true">
<dubbo:method name="getMenuItems" merger="false" />
</dubbo:service>
(指定合并策略，缺省根据返回值类型自动匹配，如果同一类型有两个合并器时，需指定合并器的名称)
<dubbo:reference interface="com.xxx.MenuService" group="*">
<dubbo:method name="getMenuItems" merger="mymerge" />
</dubbo:service>
(指定合并方法，将调用返回结果的指定方法进行合并，合并方法的参数类型必须是返回结果类型本身)
<dubbo:reference interface="com.xxx.MenuService" group="*">
<dubbo:method name="getMenuItems" merger=".addAll" />
</dubbo:service>
dubbo的令牌验证
防止消费者绕过注册中心访问提供者
在注册中心控制权限，以决定要不要下发令牌给消费者
注册中心可灵活改变授权方式，而不需修改或升级提供者
可以全局设置开启令牌验证：
<!--随机token令牌，使用UUID生成-->
<dubbo:provider interface="com.foo.BarService" token="true" />
<!--固定token令牌，相当于密码-->
<dubbo:provider interface="com.foo.BarService" token="123456" />
也可在服务级别设置：
<!--随机token令牌，使用UUID生成-->
<dubbo:service interface="com.foo.BarService" token="true" />
<!--固定token令牌，相当于密码-->
<dubbo:service interface="com.foo.BarService" token="123456" />
https://blog.csdn.net/abcde474524573/article/details/53026110
