欢迎关注WX公众号：“程序猿补课班”，分享Java相关技术知识，学习经验，面试经验等。小伙伴快来补课吧！
正文开始
1、Dubbo 和 Spring Cloud 有什么区别？
两个没关联，如果硬要说区别，有以下⼏点。
1）通信⽅式不同
1、Dubbo 使⽤的是 RPC 通信，⽽ Spring Cloud 使⽤的是 HTTP RESTFul ⽅式。
2、dubbo由于是⼆进制的传输，占⽤带宽会更少（基于netty等）；springCloud是http协议传输，带宽会⽐较多，同时
使⽤http协议（http+restful api）⼀般会使⽤JSON报⽂，消耗会更⼤。
3、dubbo的开发难度较⼤，原因是dubbo的jar包依赖（存在代码级别的强依赖）问题很多⼤型⼯程⽆法解决；
springcloud的接⼝协议约定⽐较⾃由且松散，需要有强有⼒的⾏政措施来限制接⼝⽆序升级。
4、dubbo的改进是通过dubbofilter，很多东⻄没有，需要⾃⼰继承，如监控，如⽇志，如限流，如追踪。
springcloud具有配置管理、服务发现、断路器、智能路由、微代理、控制总线、⼀次性token、全局锁、选主、分布式会话和集群状态等，满⾜了构建微服务所需的所有解决⽅案。
最大的区别：Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于
TCP 协议传输的，配合以 Hession 序列化完成 RPC 通信。而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信，相对来说，Http 请求会有更大的报文，占的带宽也会更多。但是REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。
2、Dubbo有哪⼏种配置⽅式？
1）Spring 配置⽅式
2）Java API 配置⽅式
3、Dubbo启动时如果依赖的服务不可⽤会怎样？
Dubbo 缺省会在启动时检查依赖的服务是否可⽤，不可⽤时会抛出异常，阻⽌ Spring 初始化完成，默认 check="true"，可以通过 check="false" 关闭检查。
4、Dubbo推荐使⽤什么序列化框架，你知道的还有哪些？
推荐使⽤Hessian序列化，还有Duddo、FastJson、Java⾃带序列化
5、Dubbo默认使⽤的是什么通信框架，还有别的选择吗？
Dubbo 默认使⽤ Netty 框架，也是推荐的选择，另外内容还集成有Mina、Grizzly。
6、注册了多个同⼀样的服务，如果测试指定的某⼀个服务呢？
可以配置环境点对点直连，绕过注册中⼼，将以服务接⼝为单位，忽略注册中⼼的提供者列表。
7、Dubbo⽀持服务多协议吗？
Dubbo 允许配置多协议，在不同服务上⽀持不同协议或者同⼀服务上同时⽀持多种协议。
8、当⼀个服务接⼝有多种实现时怎么做？
当⼀个接⼝有多种实现时，可以⽤ group 属性来分组，服务提供⽅和消费⽅都指定同⼀个 group 即可。
9、服务上线怎么兼容旧版本？
可以⽤版本号（version）过渡，多个不同版本的服务注册到注册中⼼，版本号不同的服务相互间不引⽤。这个和服务分组的概念有⼀点类似。
10、Dubbo可以对结果进⾏缓存吗？
可以，Dubbo 提供了声明式缓存，⽤于加速热⻔数据的访问速度，以减少⽤户加缓存的⼯作量。
11、Dubbo服务之间的调⽤是阻塞的吗？
默认是同步等待结果阻塞的，⽀持异步调⽤。
Dubbo 是基于 NIO 的⾮阻塞实现并⾏调⽤，客户端不需要启动多线程即可完成并⾏调⽤多个远程服务，相对多线程开销较⼩，异步调⽤会返回⼀个 Future 对象。
12、在使⽤过程中都遇到了些什么问题？
单⼀⻓连接和NIO异步通讯，适合⼤并发⼩数据量的服务调⽤，以及消费者远⼤于提供者。Dubbo 的设计⽬的是为了满⾜⾼并发⼩数据量的 rpc 调⽤，在⼤数据量下的性能表现并不好，建议使⽤ rmi 或 http 协议。
13、注册中⼼挂了，消费者还能调⽤服务者吗？
-
注册中⼼对等集群，任意⼀台宕掉后，会⾃动切换到另⼀台
-
注册中⼼全部宕掉，服务提供者和消费者仍可以通过本地缓存通讯
-
服务提供者⽆状态，任⼀台 宕机后，不影响使⽤
-
服务提供者全部宕机，服务消费者会⽆法使⽤，并⽆限次重连等待服务者恢复
14、Dubbo 在安全机制方面是如何解决的
Dubbo 通过 Token 令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo 还提供服务黑白名单，来控制服务所允许的调用方
15、dubbo 通信协议 dubbo 协议为什么要消费者比提供者个数多
dubbo 协议采用单一长连接，假设网络为千兆网卡(1024Mbit=128MByte)，根据测试经验数据每条连接最多只能压满 7MByte(不同的环境可能不一样，供参考)，理论上 1 个服务提供者需要 20个服务消费者才能压满网卡。
16、dubbo 通信协议 dubbo 协议为什么采用异步单一长连接
因为服务的现状大都是服务提供者少，通常只有几台机器，而服务的消费者多，可能整个网站都在访问该服务，比如 Morgan 的提供者只有 6 台提供者，却有上百台消费者，每天有 1.5 亿次调用，如果采用常规的 hessian 服务，服务提供者很容易就被压跨，通过单一连接，保证单一消费者不会压死提供者，长连接，减少连接握手验证等，并使用异步 IO，复用线程池，防止 C10K 问题。
如有错漏之处,敬请指正
