ToB企服应用市场:ToB评测及商务社交产业平台

标题: Dubbo原理解析(非常透彻) [打印本页]

---

作者: 灌篮少年    时间: 2022-6-25 07:32
标题: Dubbo原理解析(非常透彻)
一.概述 dubbo是一款经典的rpc框架，用来远程调用服务的。
dubbo的作用：

• 面向接口的远程方法调用
  
• 智能容错和负载均衡
  
• 服务自动注册和发现。
  
• 自定义序列化协议
  

---

Dubbo 架构中的核心角色有哪些？

• Container： 服务运行容器，负责加载、运行服务提供者。必须。
  
• Provider： 暴露服务的服务提供方，会向注册中心注册自己提供的服务。必须。
  
• Consumer： 调用远程服务的服务消费方，会向注册中心订阅自己所需的服务。必须。
  
• Registry： 服务注册与发现的注册中心。注册中心会返回服务提供者地址列表给消费者。非必须。
  
• Monitor： 统计服务的调用次数和调用时间的监控中心。服务消费者和提供者会定时发送统计数据到监控中心。非必须。
  

---

Dubbo 中的 Invoker 概念了解么？

• 
  
• 
  
  
  
  • 服务提供 Invoker
    
  • 服务消费 Invoker
    
  
  
• 我们需要调用一个远程方法，我们需要动态代理来屏蔽远程调用的细节吧！我们屏蔽掉的这些细节就依赖对应的 Invoker 实现， Invoker 实现了真正的远程服务调用
  

---

Dobbo的分层架构(工作原理)
 

• Service业务层：就是我们写代码的层，我们使用rpc只需要关注该层就行，主要是定义接口和实现类。
  
• config 配置层：Dubbo 相关的配置。支持代码配置，同时也支持基于 Spring 来做配置，以 ServiceConfig, ReferenceConfig 为中心
  
• proxy 服务代理层：调用远程方法像调用本地的方法一样简单的一个关键，真实调用过程依赖代理类，以 ServiceProxy 为中心。
  
• registry 注册中心层：封装服务地址的注册与发现。
  
• cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心。
  
• monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心。
  
• protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心。
  
• exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心。
  
• transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心。
  
• serialize 数据序列化层 ：对需要在网络传输的数据进行序列化。
  

 二.SPI Dubbo 的 SPI 机制了解么？

• SPI（Service Provider Interface） 机制被大量用在开源项目中(比如Dubbo，SpringBoot...)，它可以帮助我们进行功能扩展。
  
• SPI 的具体原理是这样的：我们将接口的实现类放在配置文件中，我们在程序运行过程中读取配置文件，通过反射加载实现类。这样，我们可以在运行的时候，动态替换接口的实现类。
  
• 一些配置类就可以使用SPI进行加载，如果我们需要进行扩展，就自定义类放在指定文件夹下。
  
• Java 本身就提供了 SPI 机制的实现。不过，Dubbo 没有直接用，而是对 Java 原生的 SPI 机制进行了增强，以便更好满足自己的需求。
  

---

为什么 Dubbo 不用 JDK 的 SPI，而是要自己实现?

• 因为 Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化，假设一个实现类初始化过程比较消耗资源且耗时，但是你的代码里面又用不上它，这就产生了资源的浪费。
  
• 因此 Dubbo 就自己实现了一个 SPI，给每个实现类配了个名字，通过名字去文件里面找到对应的实现类全限定名然后加载实例化，按需加载。
  

如果想深入研究Java SPI：请看一位大佬写的文章：SPI源码分析

---

如何扩展 Dubbo 中的默认实现？

•  比如说我们想要实现自己的负载均衡策略，我们创建对应的实现类 XxxLoadBalance 实现 LoadBalance 接口或者 AbstractLoadBalance 类。
  
• 我们将这个是实现类的路径写入到resources 目录下的 META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance文件中即可。
  

1. public class XxxLoadBalance implements LoadBalance {
2. public <T> Invoker<T> select(List<Invoker<T>> invokers, Invocation invocation) throws RpcException {
3.   // ...
4. }
5. }

复制代码

  

• RandomLoadBalance：随机。随机的选择一个。是Dubbo的默认负载均衡策略。(加权/不加权)
  
• RoundRobinLoadBalance：轮询。轮询选择一个。(加权/不加权)
  
• LeastActiveLoadBalance：最少活跃数。每个服务维护一个活跃数计数器。当A机器开始处理请求，该计数器加1，此时A还未处理完成。若处理完毕则计数器减1。而B机器接受到请求后很快处理完毕。那么A,B的活跃数分别是1，0。当又产生了一个新的请求，则选择B机器去执行(B活跃数最小)，这样使慢的机器A收到少的请求。
  
• ConsistentHashLoadBalance：一致性哈希。相同参数的请求总是落在同一台机器上。
  

服务暴露：生成代理类，将信息注册到ZK

• 组装URL：Spring IOC 容器刷新完毕之后，会根据配置参数组装成 URL， 然后根据 URL 的参数来进行代理类的生成。
  
• 生成代理类：会通过 proxyFactory.getInvoker，利用 javassist 来进行动态代理，封装真的实现类。
  
• 根据协议生成暴露对象(exporter)：通过 URL 参数选择对应的协议来进行 protocol.export，默认是 Dubbo 协议。
  
  
  
  • 自适应：代理类会根据 Invoker 里面的 URL 参数得知具体的协议，然后通过 Dubbo SPI 机制选择对应的实现类进行 export。
    
  
  
• 注册到ZK：将 export 得到的 exporter 存入一个 Map 中，供之后的远程调用查找，然后会向注册中心注册提供者的信息。
  

 想要深究源码的小伙伴可以看一位大佬写的文章：服务暴露源码分析。

---

 服务引用：获取远程调用的类，生成代理类。可以看作服务引用的逆过程。

• 组装URL：会根据配置参数组装成 URL， 然后根据 URL 的参数来进行代理类的生成。(2种时机)
  
  
  
  • 饿汉式：饿汉式是通过实现 Spring 的InitializingBean接口中的 afterPropertiesSet方法，容器通过调用 ReferenceBean的 afterPropertiesSet方法时引入服务。(在Spring启动时，给所有的属性注入实现类，包含远程和本地的实现类)
    
  • 懒汉式：只有当这个服务被注入到其他类中时启动引入流程，也就是说用到了才会开始服务引入。
    
    
    
    • 在应用的Spring Context初始化完成事件时触发，扫描所有的Bean，将Bean中带有@Reference注解的field获取到，然后创建field类型的代理对象，创建完成后，将代理对象set给此field。后续就通过该代理对象创建服务端连接，并发起调用。(dubbo默认)
      
    
    
  
  
• 从ZK中获取需要的服务提供者的信息：得到Map。
  
• 根据协议解析传过来的exporter：
  
  
  
  • 协议的不同，获取的路径也不同：本地，直接，从ZK。
    
  
  

• 生成代理类：供消费者使用Netty进行远程调用。invoker。
  

 想要深究源码的小伙伴可以看一位大佬写的文章：服务引用源码分析。

---

服务调用：

• 服务调用是在生成代理对象后，使用Netty，生成Netty Client进行远程调用。Netty Server通过反射返回调用结果。
  
• 在调用之前，就会进行智能容错和负载均衡。
  
  
  
  • 首先客户端调用接口的某个方法，实际调用的是代理类，代理类会通过 cluster 从 directory(invoker的集合) 中获取一堆 invokers(如果有一堆的话)，然后进行 router 的过滤（其中看配置也会添加 mockInvoker 用于服务降级），然后再通过 SPI 得到 loadBalance 进行一波负载均衡。
    
  
  

补充：cluster 是什么？

• 一个中间层，为消费者屏蔽了服务提供者的情况，简化了消费者的使用。
  
• 它可以负责选择哪个invoker返回给调用者，比如选择一个 invoker ，调用出错了可以换一个等等。
  

想要深究源码的小伙伴可以看一位大佬写的文章：服务调用源码分析。

---

容错机制：先容错，再负载均衡。

• 首先在服务引入的时候，将多个远程调用都塞入 Directory 中，然后通过 Cluster 来封装这个目录，封装的同时提供各种容错功能，比如 FailOver、FailFast 等等，最终暴露给消费者的就是一个 invoker。
  
• 然后消费者调用的时候会目录里面得到 invoker 列表，当然会经过路由的过滤，得到这些 invokers 之后再由 loadBalance 来进行负载均衡选择一个 invoker，最终发起调用。
  

dubbo常见的容错机制

• Failover Cluster(默认)
  
  
  
  • 失败自动切换，当出现失败，重试其它服务器。
    
  • 通常用于读操作，但重试会带来更长延迟。
    
  
  
• Failfast Cluster
  
  
  
  • 快速失败，只发起一次调用，失败立即报错。
    
  • 通常用于非幂等性的写操作，比如新增记录。
    
  
  
• Failsafe Cluster
  
  
  
  • 失败安全，出现异常时，直接忽略。
    
  • 通常用于写入审计日志等操作。
    
  
  
• Failback Cluster
  
  
  
  • 失败自动恢复，后台记录失败请求，定时重发。
    
  • 通常用于消息通知操作。
    
  
  
• Forking Cluster
  
  
  
  • 并行调用多个服务器，只要一个成功即返回。
    
  • 通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
    
  
  

 想要深究源码的小伙伴可以看一位大佬写的文章：dubbo智能容错源码分析
  五.其他小问题 Dubbo 为什么默认用 Javassist？

• 很简单，就是快，且字节码生成方便。
  
• 其他常见的动态代理： JDK 的动态代理、ASM、cglib。
  
  
  
  • ASM 比 Javassist 更快，但是没有快一个数量级，而Javassist 只需用字符串拼接就可以生成字节码，而 ASM 需要手工生成，成本较高，比较麻烦。
    
  
  

---

Dubbo 支持多种序列化方式?

• JDK 自带的序列化：不支持跨语言调用 ；性能差
  
• JSON：性能差
  
• ProtoBuf ：支持跨语言
  
• hessian2(默认)：支持跨语言
  
• Protostuff：支持跨语言
  
• Kryo：新引入的，只支持JAVA
  
• FST：新引入的，只支持JAVA
  

寄语：你所看到的惊艳，都曾被平庸历练 

小伙伴们有兴趣想了解内容和更多相关学习资料的请点赞收藏+评论转发+关注我，后面会有很多干货。
我有一些面试题、架构、设计类资料可以说是程序员面试必备！所有资料都整理到网盘了，需要的话欢迎下载！私信我回复【07】即可免费获取

 












原文出处：www.shaoqun.com/a/1514803.html

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4