Dubbo总结

Dubbo总结

什么是Dubbo

Apache Dubbo 是一款微服务开发框架，它提供了 RPC通信 与 微服务治理 两大关键能力。这意味着，使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力， 同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

• 远程通讯：提供透明化的远程方法调用，提供多协议支持。
• 集群容错：软负载均衡，失败容错，动态配置等
• 自动发现：基于注册中心目录服务，使服务消费能动态的查找服务提供方，支持平滑或减少或增加机器。

什么是RPC

• RPC（Remote Procedure Call）远程过程调用，简单的理解是一个节点请求另一个节点提供的服务

由于HTTP在应用层中完成，整个通信的代价较高，远程过程调用中直接基于TCP进行远程调用，数据传输在传输层TCP层完成，更适合对效率要求比较高的场景，RPC主要依赖于客户端和服务端之间建立Socket链接进行，底层实现比REST更复杂。

那为什么要有 RPC，HTTP 不好么？

因为 RPC 和 HTTP 就不是一个层级的东西，所以严格意义上这两个没有可比性，也不应该来作比较，而题目问的就是把这两个作为比较了。

HTTP 只是传输协议，协议只是规范了一定的交流格式，而且 RPC 是早于 HTTP 的，所以真要问也是问有 RPC 为什么还要 HTTP。

RPC 是远程过程调用，是用来作为分布式系统之间的通信，它可以用 HTTP 来传输，也可以基于 TCP 自定义协议传输。

所以你要先提出这两个不是一个层级的东西，没有可比性，然后再表现一下，可以说 HTTP 协议比较冗余，所以 RPC 大多都是基于 TCP 自定义协议，定制化的才是最适合自己的。

Dubbo的应用场景

• RPC 分布式服务，拆分应用进行服务化，提高开发效率，调优性能，节省竞争资源
• 配置管理，解决服务的地址信息剧增，配置困难的问题
• 服务依赖，解决服务间依赖关系错踪复杂的问题
• 服务扩容，解决随着访问量的不断增大，动态扩展服务提供方的机器的问题

Dubbo服务注册发现流程

1. 服务容器负责加载、启动、运行服务
2. 服务提供者在启动时，向注册中心提供自己的服务
3. 服务消费者在启动时，向注册中心订阅自己所需的服务
4. 注册中心返回提供者的地址列表给消费者，如果有变更，注册中心将基于长连接推送变更后的数据给消费者
5. 服务消费者，从注册列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，在选另一台
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计到监控中心。

多协议

Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

不同服务不同协议

不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> 
    <dubbo:application name="world"  />
    <dubbo:registry id="registry" address="10.20.141.150:9090" username="admin" password="hello1234" />
    <!-- 多协议配置 -->
    <dubbo:protocol name="dubbo" port="20880" />
    <dubbo:protocol name="rmi" port="1099" />
    <!-- 使用dubbo协议暴露服务 -->
    <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" protocol="dubbo" />
    <!-- 使用rmi协议暴露服务 -->
    <dubbo:service interface="com.alibaba.hello.api.DemoService" version="1.0.0" ref="demoService" protocol="rmi" /> 
</beans>

多协议暴露服务

需要与 http 客户端相互操作

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
    <dubbo:application name="world"  />
    <dubbo:registry id="registry" address="10.20.141.150:9090" username="admin" password="hello1234" />
    <!-- 多协议配置 -->
    <dubbo:protocol name="dubbo" port="20880" />
    <dubbo:protocol name="hessian" port="8080" />
    <!-- 使用多个协议暴露服务 -->
    <dubbo:service id="helloService" interface="com.alibaba.hello.api.HelloService" version="1.0.0" protocol="dubbo,hessian" />
</beans>

dubbo协议

dubbo协议：duobbo缺省协议采用单一长连接和NIO异步通讯，适合小数据量大并发的服务调用，反之，dubbo缺省协议不适合传送大数据量的服务，比如文件、视频等。

特性

1. 连接个数：单连接

2. 连接方式：长连接

3. 传输协议：TCP

4. 传输方式：NIO异步传输

5. 序列化：Hession二进制序列化

6. 使用范围：传入传出参数数据包较小

为什么不能传大包？

因为dubbo协议采用长连接，如果每次传输的数据过大，网络将成为瓶颈，影响效率。

原理与http2的多路复用差不多，都是使用了一个唯一ID来表示请求与响应，通过这个ID来区分并发时的请求与响应数据包。

rmi协议

Rmi协议采用jdk标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式。

特性

1. 连接个数：多连接

2. 连接方式：短连接

3. 传输协议：TCP

4. 传输方式：同步传输

5. 序列化：java标准二进制序列化

6. 适用范围：传入传出参数数据包大小混合

hession协议

Hession协议用于集成Hession服务，底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现。

特性

1. 连接个数：多连接

2. 连接方式：短连接

3. 传输协议：HTTP

4. 传输方式：同步传输

5. 使用范围：传入传出参数数据包较大

http协议

基于http表单的远程调用协议，采用Spring的HttpInvoker实现。

特性

1. 连接个数：多连接

2. 连接方式：短连接

3. 传输协议：HTTP

4. 传输方式：同步传输

5. 序列化：表单序列化

6. 使用范围：传入传出参数数据包大小混合

webservice协议

基于webservice的远程调用协议

特性

1)连接个数：多连接

2)连接方式：短连接

3)传输协议：HTTP

4)传输方式：同步传输

5)序列化：SOAP文本序列化

6)使用范围：系统集成，跨语言调用

memcache

基于memcached实现的RPC协议

redis

基于redis实现的RPC协议

服务调用是阻塞的吗？

默认是阻塞的，可以异步调用，没有返回值的可以这么做。
Dubbo是基于NIO的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个Future对象。

Dubbo启动时如果依赖的服务不可用会怎样？

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check=“true”，可以通过 check=“false” 关闭检查。

Dubbo的注册中心集群挂掉，发布者和订阅者之间还能通信么？

可以的，启动dubbo时，消费者会从zookeeper拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用。

Dubbo使用的是什么通信框架?

默认使用NIO Netty框架

Dubbo集群提供了哪些负载均衡策略？

• Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀；
• RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题；
• LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求；
• ConstantHash LoadBalance: 一致性Hash策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动；
• 缺省时为Random随机调用

Dubbo的集群容错方案有哪些？

• Failover Cluster - 失败自动切换

  失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。

• Failfast Cluster- 快速失败

  快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

• Failsafe Cluster- 失败安全

  失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

• Failback Cluster- 失败自动恢复

  失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

• Forking Cluster - 并行调用多个服务提供者

  并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=”2″ 来设置最大并行数。

• Broadcast Cluster - 广播调用

  广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。

Dubbo的默认集群容错方案？

Failover Cluster

Dubbo支持哪些序列化方式？

默认使用Hessian序列化，还有Duddo、FastJson、Java自带序列化。

Dubbo怎么设置超时时间

Dubbo 可以在提供端(provider) 和 消费端(consumer) 设置超时间

provider：

• 系统向外提供的 facade 请求超时时间，默认1000 ms
• provider 接受到请求时，会把整个处理逻辑执行完，不管你是否设置了时间；dubbo 只会在方法执行完，判断是否超时，如果超时，记一个 warn 日志

<dubbo:provider timeout="" >

consumer：

• 调用外部系统接口的超时时间，默认1000 ms
• 请求发出后，线程处于阻塞状态，线程的唤醒条件是超时和收到 provider 返回

<dubbo:consumer timeout="" >

provider 和 consumer 都设置了超时时间，Dubbo 会默认优先使用 consumer 的配置

Dubbo有些哪些注册中心？

• Zookeeper 注册中心： 基于分布式协调系统 Zookeeper 实现，采用 Zookeeper 的 watch 机制实现数据变更(官方推荐)

• Multicast 注册中心： 基于网络中组播传输实现，不需要任何中心节点，只要广播地址，就能进行服务注册和发现

• Redis 注册中心： 基于 Redis 实现，采用 key/Map 数据结构存储，主 key 存储服务名和类型，Map 中 key 存储服务 URL，Map 中 value 存储服务过期时间，基于 Redis 的发布/订阅模式通知数据变更

• Simple 注册中心：一个普通的 Dubbo 服务，可以减少第三方依赖，使整体通讯方式一致，不支持集群

服务调用超时问题怎么解决？

dubbo在调用服务不成功时，默认是会重试两次的。

Dubbo在安全机制方面是如何解决？

Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。

除了Dubbo还有哪些分布式框架？

大家熟知的就是Spring cloud，当然国外也有类似的多个框架。

Dubbo和Spring Cloud的关系？

Dubbo是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。

dubbo和spring cloud的区别？

最大的区别：Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。而SpringCloud是基于Http协议+Rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。
t的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。