Dubbo知识点说明

最新推荐文章于 2024-04-27 17:33:21 发布

栗超

最新推荐文章于 2024-04-27 17:33:21 发布

阅读量261

点赞数

分类专栏： Dubbo 文章标签： Dubbo 学习说明知识点

本文链接：https://blog.csdn.net/lichao_3013/article/details/121351119

版权

Dubbo 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Dubbo是什么

Dubbo是一款高性能、轻量级的开源RPC框架，提供服务自动注册、自动发现等高效服务治理方案。可以和Spring框架无缝集成。

Dubbo的使用场景

1、透明化的远程方法调用

2、软负载均衡及容错机制

3、服务自动注册与发现

Dubbo的整体架构设计

服务层（Service）：改成主要是处理业务逻辑，根据provider和consumer的业务设计对应的接口和实现类。

配置层（Config）：对外配置的接口，以ServiceConfig和ReferenceConfig为中心。

代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务的Skeleten，以ServiceProxy为中心，扩展接口为ProxyFactory。

注册层（Registry）：封装服务地址的注册和发现，以服务URL为中心，扩展接口为RegistryFactory、Registry、RegistryService

路由层（Cluster）：封装多个提供者的路由和负载均衡，并桥接注册中，以Invoker为中心，扩展接口为Cluster、Dirdectory、Router和LoadBalance

监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService

调用层（Protocal）：封装RPC调用，以Invocation和Result为中心，扩展接口为Protocal、Invoker和Exporter

交换层（Exchange）：封装请求响应模式，同步转异步。以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer

传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec

序列化层（Serialize）：可以复用的一些工具。扩展接口为Serialization、ObjectInput、ObjectOutput和ThreadPool

Dubbo核心配置

Dubbo使用到的设计模式

1、工厂模式

Provider在export服务时，会调用ServiceConfig的export方法。ServiceConfig中有：

private static fianl Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

Dubbo里面有很多这个样子的代码，这也是一种工厂模式，只是实现类的获取才用了JDK SPI的机制、这么实现的优点是可扩展性强，想要扩展实现，只需要在classpath下增加一个文件就可以了，代码零侵入。另外，像上面的Adaptive实现，可以做到调用是动态决定调用哪个实现，但是由于这种实现才用了动态代理，会造成代码调试比较麻烦，需要分析出实际调用的实现类。

2、装饰器模式

Dubbo在启动和调用阶段都大量使用了装饰器模式。以Provider提供的调用链为例，具体的调用链代码是在ProtocolFilterWrapper的buildInvokerChain完成的，具体是将注解中的group=provider的Filter实现，按照order排序，最后的调用顺序是：

EchoFilter --> ClassLoaderFilter --> GenericFilter --> ContextFilter --> 
ExecuteLimitFilter --> TraceFilter --> TimeoutFileter --> MonitorFilter -->
ExceptionFilter

更确切的说，这里是装饰器和责任链模式的混合使用，例如：EchoFilter的作用是判断是否是回声测试请求，是的话就直接返回内容，这是一种责任链的提现。而想ClassLoaderFilter则只是在主功能上添加了功能，更改当前线程的ClassLoader，这是典型的装饰器模式。

3、观察者模式

Dubbo的Provider启动时，需要与注册中心交互，先注册自己的服务，再订阅自己的服务，订阅时，才用了观察者模式，开启了一个Listener，注册中心会每5秒定时检查是否有服务更新，如果有更新，向该服务的提供者发送一个notify消息，provider接收到notity消息后，即运行NotifyListener的notify方法，执行监听器方法。

4、动态代理模式

Dubbo扩展JDK SPI的类ExtensionLoader的Adaptive实现是典型的动态代理实现，Dubbo需要灵活地控制实现类，即在调用阶段动态的根据参数决定调用哪个实现类，所以采用先生成代理类的方法，能够做到灵活的调用，生成代理类的代码是ExtensionLoader的CreateAdaptiveExtensionClassCode方法，代理类的主要逻辑是：获取URL参数中置顶参数的值作为获取实现类的Key。

Dubbo 支持的协议

1、 dubbo：单一长连接和 NIO 异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步， Hessian 序列化；

2、 rmi：采用 JDK 标准的 rmi 协议实现，传输参数和返回参数对象需要实现Serializable 接口，使用 java 标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和提供者个数差不多，可传文件，传输协议 TCP。多个短连接， TCP 协议传输，同步传输，适用常规的远程服务调用和 rmi 互操作。在依赖低版本的 Common-Collections 包， java 序列化存在安全漏洞；

3、 http：基于 Http 表单提交的远程调用协议，使用 Spring 的 HttpInvoke 实现。多个短连接，传输协议 HTTP，传入参数大小混合，提供者个数多于消费者，需要给应用程序和浏览器 JS 调用；

4、 webservice：基于 WebService 的远程调用协议，集成 CXF 实现，提供和原生 WebService 的互操作。多个短连接，基于 HTTP 传输，同步传输，适用系统集成和跨语言调用；

5、 hessian：集成 Hessian 服务，基于 HTTP 通讯，采用 Servlet 暴露服务，Dubbo 内嵌 Jetty 作为服务器时默认实现，提供与 Hession 服务互操作。多个短连接，同步 HTTP 传输， Hessian 序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件；

6、 Redis：基于 Redis 实现的 RPC 协议

PRC架构组件

一个基本的RPC架构里面应该至少包含以下4个组件：
1、客户端（Client）:服务调用方（服务消费者）
2、客户端存根（Client Stub）:存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端
3、服务端存根（Server Stub）:接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理
4、服务端（Server）:服务的真正提供者

RPC框架的实现目标则是将上面的第2-10步完好地封装起来，也就是把调用、编码/解码的过程给封装起来，让用户感觉上像调用本地服务一样的调用远程服务。

Dubbo 服务集群配置（集群容错模式）

在集群调用失败时， Dubbo 提供了多种容错方案，缺省为 failover 重试。可以自行扩展集群容错策略

Failover Cluster(默认)

失败自动切换，当出现失败，重试其它服务器。(缺省)通常用于读操作，

但重试会带来更长延迟。可通过 retries="2"来设置重试次数(不含第一次)。

<dubbo:service retries="2" cluster="failover"/>
或：
<dubbo:reference retries="2" cluster="failover"/>
cluster="failover"可以不用写,因为默认就是 failover

Failfast Cluster

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

比如新增记录。

<dubbo:service cluster="failfast" />
或：
<dubbo:reference cluster="failfast" />
cluster="failfast"和 把 cluster="failover"、 retries="0"是一样的效果,retries="0"就是不重

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

<dubbo:service cluster="failsafe" />
或：
<dubbo:reference cluster="failsafe" />

Failback Cluster

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

<dubbo:service cluster="failback" />
或：
<dubbo:reference cluster="failback" />

Forking Cluster并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读

操作，但需要浪费更多服务资源。可通过 forks="2"来设置最大并行数。

<dubbo:service cluster=“forking" forks="2"/>
或：
<dubbo:reference cluster=“forking" forks="2"/>

Dubbo的核心功能

1、 Remoting：网络通信框架，提供对多种NIO框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。

2、 Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

3、 Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo的核心组件

1、Provider：暴露服务的服务提供方

2、Consumer：调用远程服务消费方

3、Registry：服务注册与发现注册中心

4、Monitor：监控中心和访问调用统计

5、Container：服务运行容器

Dubbo集群提供的负载均衡策略

1、Random LoadBalance：随机选择提供者策略。有利于动态调整提供者权重。界面碰撞率高，调用次数越多，分布会越均匀。

2、RoundRobin LoadBalance：轮询选择提供者策略。平均分布，但是存在请求积压问题。

3、LeastActive LoadBalance：最少活跃调用策略。解决复杂操作处理流程长问题，可以使提供者接收更少的请求。

4、ConstantHash LoadBalance：一致性Hash策略，可以让相同参数请求总是发送到同一个提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动。

默认使用的是Random随机调用。

Dubbo服务调用超时如何解决

dubbo在调用服务不成功时，默认是会重试两次的。这样在服务端的处理时间超过了设定的超时时间时，就会有重复请求，比如在发邮件时，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据，那么怎么解决超时问题呢？
对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理全局配置实例

<dubbo:provider delay="-1" timeout="6000" retries="0"/>

当然Dubbo的重试机制其实是非常好的QOS保证，它的路由机制，是会帮你把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。但是请一定要综合线上的访问情况，给出综合的评估。

栗超

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
Dubbo知识点说明

Dubbo是什么Dubbo是一款高性能、轻量级的开源RPC框架，提供服务自动注册、自动发现等高效服务治理方案。可以和Spring框架无缝集成。Dubbo的使用场景1、透明化的远程方法调用2、软负载均衡及容错机制3、服务自动注册与发现Dubbo核心配置[dubbo:service/] | 服务配置 | 用于服务的暴露使用，定义了服务的元信息，一个服务可以使用多个协议暴露，一个服务也可以注册到多个注册中心[dubbo:reference/] | 引用配置 | 用于创建一个远程服务.
复制链接

扫一扫