区块链技术博客
www.b2bchain.cn

Dubbo 常见问题总结求职学习资料

本文介绍了Dubbo 常见问题总结求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

    • RPC基础
      • 何为 RPC?
      • RPC 的原理是什么?
    • Dubbo基础
      • 什么是 Dubbo?
      • 为什么要用 Dubbo?
    • 分布式基础
      • 什么是分布式?
      • 为什么要分布式?
    • Dubbo 架构
      • Dubbo 架构中的核心角色有哪些?
      • Dubbo 中的 Invoker 概念了解么?
      • Dubbo 的工作原理了解么?
      • Dubbo 的 SPI 机制了解么? 如何扩展 Dubbo 中的默认实现?
      • Dubbo 的微内核架构了解吗?
      • 关于Dubbo架构的一些自测小问题
        • 注册中心的作用了解么?
        • 服务提供者宕机后,注册中心会做什么?
        • 监控中心的作用呢?
        • 注册中心和监控中心都宕机的话,服务都会挂掉吗?

这篇文章是我根据官方文档以及自己平时的使用情况,对 Dubbo 所做的一个总结。欢迎补充!

RPC基础

何为 RPC?

RPC(Remote Procedure Call) 即远程过程调用,通过名字我们就能看出 RPC 关注的是远程调用而非本地调用。

为什么要 RPC ? 因为,两个不同的服务器上的服务提供的方法不在一个内存空间,所以,需要通过网络编程才能传递方法调用所需要的参数。并且,方法调用的结果也需要通过网络编程来接收。但是,如果我们自己手动网络编程来实现这个调用过程的话工作量是非常大的,因为,我们需要考虑底层传输方式(TCP还是UDP)、序列化方式等等方面。

**RPC 能帮助我们做什么呢? ** 简单来说,通过 RPC 可以帮助我们调用远程计算机上某个服务的方法,这个过程就像调用本地方法一样简单。并且!我们不需要了解底层网络编程的具体细节。

举个例子:两个不同的服务 A、B 部署在两台不同的机器上,服务 A 如果想要调用服务 B 中的某个方法的话就可以通过 RPC 来做。

一言蔽之:RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单。

RPC 的原理是什么?

为了能够帮助小伙伴们理解 RPC 原理,我们可以将整个 RPC的 核心功能看作是下面👇 6 个部分实现的:

  1. 客户端(服务消费端) :调用远程方法的一端。
  2. 客户端 Stub(桩) : 这其实就是一代理类。代理类主要做的事情很简单,就是把你调用方法、类、方法参数等信息传递到服务端。
  3. 网络传输 : 网络传输就是你要把你调用的方法的信息比如说参数啊这些东西传输到服务端,然后服务端执行完之后再把返回结果通过网络传输给你传输回来。网络传输的实现方式有很多种比如最近基本的 Socket或者性能以及封装更加优秀的 Netty(推荐)。
  4. 服务端 Stub(桩) :这个桩就不是代理类了。我觉得理解为桩实际不太好,大家注意一下就好。这里的服务端 Stub 实际指的就是接收到客户端执行方法的请求后,去指定对应的方法然后返回结果给客户端的类。
  5. 服务端(服务提供端) :提供远程方法的一端。

具体原理图如下,后面我会串起来将整个RPC的过程给大家说一下。

Dubbo 常见问题总结

RPC原理图

  1. 服务消费端(client)以本地调用的方式调用远程服务;
  2. 客户端 Stub(client stub) 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体(序列化):RpcRequest
  3. 客户端 Stub(client stub) 找到远程服务的地址,并将消息发送到服务提供端;
  4. 服务端 Stub(桩)收到消息将消息反序列化为Java对象: RpcRequest
  5. 服务端 Stub(桩)根据RpcRequest中的类、方法、方法参数等信息调用本地的方法;
  6. 服务端 Stub(桩)得到方法执行结果并将组装成能够进行网络传输的消息体:RpcResponse(序列化)发送至消费方;
  7. 客户端 Stub(client stub)接收到消息并将消息反序列化为Java对象:RpcResponse ,这样也就得到了最终结果。over!

相信小伙伴们看完上面的讲解之后,已经了解了 RPC 的原理。

虽然篇幅不多,但是基本把 RPC 框架的核心原理讲清楚了!另外,对于上面的技术细节,我会在后面的章节介绍到。

最后,对于 RPC 的原理,希望小伙伴不单单要理解,还要能够自己画出来并且能够给别人讲出来。因为,在面试中这个问题在面试官问到 RPC 相关内容的时候基本都会碰到。

Dubbo基础

什么是 Dubbo?

Dubbo 常见问题总结

Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架。

根据 Dubbo 官方文档的介绍,Dubbo 提供了六大核心能力

  1. 面向接口代理的高性能RPC调用。
  2. 智能容错和负载均衡。
  3. 服务自动注册和发现。
  4. 高度可扩展能力。
  5. 运行期流量调度。
  6. 可视化的服务治理与运维。

Dubbo 常见问题总结

Dubbo提供的六大核心能力

简单来说就是: Dubbo 不光可以帮助我们调用远程服务,还提供了一些其他开箱即用的功能比如智能负载均衡。

Dubbo 目前已经有接近 34.4 k 的 Star 。

2020 年度 OSC 中国开源项目 评选活动中,Dubbo 位列开发框架和基础组件类项目的第7名。想比几年前来说,热度和排名有所下降。

Dubbo 常见问题总结

Dubbo 是由阿里开源,后来加入了 Apache 。正式由于 Dubbo 的出现,才使得越来越多的公司开始使用以及接受分布式架构。

为什么要用 Dubbo?

随着互联网的发展,网站的规模越来越大,用户数量越来越多。单一应用架构 、垂直应用架构无法满足我们的需求,这个时候分布式服务架构就诞生了。

分布式服务架构下,系统被拆分成不同的服务比如短信服务、安全服务,每个服务独立提供系统的某个核心服务。

我们可以使用 Java RMI(Java Remote Method Invocation)、Hessian这种支持远程调用的框架来简单地暴露和引用远程服务。但是!当服务越来越多之后,服务调用关系越来越复杂。当应用访问压力越来越大后,负载均衡以及服务监控的需求也迫在眉睫。我们可以用 F5 这类硬件来做负载均衡,但这样增加了成本,并且存在单点故障的风险。

不过,Dubbo 的出现让上述问题得到了解决。Dubbo 帮助我们解决了什么问题呢?

  1. 负载均衡 : 同一个服务部署在不同的机器时该调用那一台机器上的服务。
  2. 服务调用链路生成 : 随着系统的发展,服务越来越多,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。Dubbo 可以为我们解决服务之间互相是如何调用的。
  3. 服务访问压力以及时长统计、资源调度和治理 :基于访问压力实时管理集群容量,提高集群利用率。
  4. ……

Dubbo 常见问题总结

另外,Dubbo 除了能够应用在分布式系统中,也可以应用在现在比较火的微服务系统中。不过,由于 Spring Cloud 在微服务中应用更加广泛,所以,我觉得一般我们提 Dubbo 的话,大部分是分布式系统的情况。

我们刚刚提到了分布式这个概念,下面再给大家介绍一下什么是分布式?为什么要分布式?

分布式基础

什么是分布式?

分布式或者说 SOA 分布式重要的就是面向服务,说简单的分布式就是我们把整个系统拆分成不同的服务然后将这些服务放在不同的服务器上减轻单体服务的压力提高并发量和性能。比如电商系统可以简单地拆分成订单系统、商品系统、登录系统等等,拆分之后的每个服务可以部署在不同的机器上,如果某一个服务的访问量比较大的话也可以将这个服务同时部署在多台机器上。

Dubbo 常见问题总结

分布式事务示意图

为什么要分布式?

从开发角度来讲单体应用的代码都集中在一起,而分布式系统的代码根据业务被拆分。所以,每个团队可以负责一个服务的开发,这样提升了开发效率。另外,代码根据业务拆分之后更加便于维护和扩展。

另外,我觉得将系统拆分成分布式之后不光便于系统扩展和维护,更能提高整个系统的性能。你想一想嘛?把整个系统拆分成不同的服务/系统,然后每个服务/系统 单独部署在一台服务器上,是不是很大程度上提高了系统性能呢?

Dubbo 架构

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

官方文档中的框架设计章节 已经介绍的非常详细了,我这里把一些比较重要的点再提一下。

Dubbo 常见问题总结

dubbo-relation

上述节点简单介绍以及他们之间的关系:

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

Dubbo 中的 Invoker 概念了解么?

Invoker 是 Dubbo 领域模型中非常重要的一个概念,你如果阅读过 Dubbo 源码的话,你会无数次看到这玩意。就比如下面我要说的负载均衡这块的源码中就有大量 Invoker 的身影。

简单来说,Invoker 就是 Dubbo 对远程调用的抽象。

Dubbo 常见问题总结

dubbo_rpc_invoke.jpg

按照 Dubbo 官方的话来说,Invoker 分为

  • 服务提供 Invoker
  • 服务消费 Invoker

假如我们需要调用一个远程方法,我们需要动态代理来屏蔽远程调用的细节吧!我们屏蔽掉的这些细节就依赖对应的 Invoker 实现, Invoker 实现了真正的远程服务调用。

Dubbo 的工作原理了解么?

下图是 Dubbo 的整体设计,从下至上分为十层,各层均为单向依赖。

左边淡蓝背景的为服务消费方使用的接口,右边淡绿色背景的为服务提供方使用的接口,位于中轴线上的为双方都用到的接口。

Dubbo 常见问题总结

dubbo-framework

  • 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 数据序列化层 :对需要在网络传输的数据进行序列化。

Dubbo 的 SPI 机制了解么? 如何扩展 Dubbo 中的默认实现?

SPI(Service Provider Interface) 机制被大量用在开源项目中,它可以帮助我们动态寻找服务/功能(比如负载均衡策略)的实现。

SPI 的具体原理是这样的:我们将接口的实现类放在配置文件中,我们在程序运行过程中读取配置文件,通过反射加载实现类。这样,我们可以在运行的时候,动态替换接口的实现类。和 IoC 的解耦思想是类似的。

Java 本身就提供了 SPI 机制的实现。不过,Dubbo 没有直接用,而是对 Java原生的 SPI机制进行了增强,以便更好满足自己的需求。

那我们如何扩展 Dubbo 中的默认实现呢?

比如说我们想要实现自己的负载均衡策略,我们创建对应的实现类 XxxLoadBalance 实现 LoadBalance 接口或者 AbstractLoadBalance 类。

package com.xxx;  import org.apache.dubbo.rpc.cluster.LoadBalance; import org.apache.dubbo.rpc.Invoker; import org.apache.dubbo.rpc.Invocation; import org.apache.dubbo.rpc.RpcException;   public class XxxLoadBalance implements LoadBalance {     public <T> Invoker<T> select(List<Invoker<T>> invokers, Invocation invocation) throws RpcException {         // ...     } }

我们将这个是实现类的路径写入到resources 目录下的 META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance文件中即可。

src  |-main     |-java         |-com             |-xxx                 |-XxxLoadBalance.java (实现LoadBalance接口)     |-resources         |-META-INF             |-dubbo                 |-org.apache.dubbo.rpc.cluster.LoadBalance (纯文本文件,内容为:xxx=com.xxx.XxxLoadBalance)

org.apache.dubbo.rpc.cluster.LoadBalance

xxx=com.xxx.XxxLoadBalance

其他还有很多可供扩展的选择,你可以在官方文档@SPI扩展实现这里找到。

Dubbo 常见问题总结

Dubbo 的微内核架构了解吗?

Dubbo 采用 微内核(Microkernel) + 插件(Plugin) 模式,简单来说就是微内核架构。微内核只负责组装插件。

何为微内核架构呢? 《软件架构模式》 这本书是这样介绍的:

微内核架构模式(有时被称为插件架构模式)是实现基于产品应用程序的一种自然模式。基于产品的应用程序是已经打包好并且拥有不同版本,可作为第三方插件下载的。然后,很多公司也在开发、发布自己内部商业应用像有版本号、说明及可加载插件式的应用软件(这也是这种模式的特征)。微内核系统可让用户添加额外的应用如插件,到核心应用,继而提供了可扩展性和功能分离的用法。

微内核架构包含两类组件:核心系统(core system)插件模块(plug-in modules)

Dubbo 常见问题总结

核心系统提供系统所需核心能力,插件模块可以扩展系统的功能。因此, 基于微内核架构的系统,非常易于扩展功能。

我们常见的一些IDE,都可以看作是基于微内核架构设计的。绝大多数 IDE比如IDEA、VSCode都提供了插件来丰富自己的功能。

正是因为Dubbo基于微内核架构,才使得我们可以随心所欲替换Dubbo的功能点。比如你觉得Dubbo 的序列化模块实现的不满足自己要求,没关系啊!你自己实现一个序列化模块就好了啊!

通常情况下,微核心都会采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依赖 Spring 等 IoC 容器,也不想自已造一个小的 IoC 容器(过度设计),因此采用了一种最简单的 Factory 方式管理插件 :JDK 标准的 SPI 扩展机制java.util.ServiceLoader)。

关于Dubbo架构的一些自测小问题

注册中心的作用了解么?

注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互。

服务提供者宕机后,注册中心会做什么?

注册中心会立即推送事件通知消费者。

监控中心的作用呢?

监控中心负责统计各服务调用次数,调用时间等。

注册中心和监控中心都宕机的话,服务都会挂掉吗?

不会。两者都宕机也不影响已运行的提供者和消费者,消费者在本地缓存了提供者列表。注册中心和监控中心都是可选的,服务消费者可以直连服务提供者。

    • RPC基础
      • 何为 RPC?
      • RPC 的原理是什么?
    • Dubbo基础
      • 什么是 Dubbo?
      • 为什么要用 Dubbo?
    • 分布式基础
      • 什么是分布式?
      • 为什么要分布式?
    • Dubbo 架构
      • Dubbo 架构中的核心角色有哪些?
      • Dubbo 中的 Invoker 概念了解么?
      • Dubbo 的工作原理了解么?
      • Dubbo 的 SPI 机制了解么? 如何扩展 Dubbo 中的默认实现?
      • Dubbo 的微内核架构了解吗?
      • 关于Dubbo架构的一些自测小问题
        • 注册中心的作用了解么?
        • 服务提供者宕机后,注册中心会做什么?
        • 监控中心的作用呢?
        • 注册中心和监控中心都宕机的话,服务都会挂掉吗?

这篇文章是我根据官方文档以及自己平时的使用情况,对 Dubbo 所做的一个总结。欢迎补充!

RPC基础

何为 RPC?

RPC(Remote Procedure Call) 即远程过程调用,通过名字我们就能看出 RPC 关注的是远程调用而非本地调用。

为什么要 RPC ? 因为,两个不同的服务器上的服务提供的方法不在一个内存空间,所以,需要通过网络编程才能传递方法调用所需要的参数。并且,方法调用的结果也需要通过网络编程来接收。但是,如果我们自己手动网络编程来实现这个调用过程的话工作量是非常大的,因为,我们需要考虑底层传输方式(TCP还是UDP)、序列化方式等等方面。

**RPC 能帮助我们做什么呢? ** 简单来说,通过 RPC 可以帮助我们调用远程计算机上某个服务的方法,这个过程就像调用本地方法一样简单。并且!我们不需要了解底层网络编程的具体细节。

举个例子:两个不同的服务 A、B 部署在两台不同的机器上,服务 A 如果想要调用服务 B 中的某个方法的话就可以通过 RPC 来做。

一言蔽之:RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单。

RPC 的原理是什么?

为了能够帮助小伙伴们理解 RPC 原理,我们可以将整个 RPC的 核心功能看作是下面👇 6 个部分实现的:

  1. 客户端(服务消费端) :调用远程方法的一端。
  2. 客户端 Stub(桩) : 这其实就是一代理类。代理类主要做的事情很简单,就是把你调用方法、类、方法参数等信息传递到服务端。
  3. 网络传输 : 网络传输就是你要把你调用的方法的信息比如说参数啊这些东西传输到服务端,然后服务端执行完之后再把返回结果通过网络传输给你传输回来。网络传输的实现方式有很多种比如最近基本的 Socket或者性能以及封装更加优秀的 Netty(推荐)。
  4. 服务端 Stub(桩) :这个桩就不是代理类了。我觉得理解为桩实际不太好,大家注意一下就好。这里的服务端 Stub 实际指的就是接收到客户端执行方法的请求后,去指定对应的方法然后返回结果给客户端的类。
  5. 服务端(服务提供端) :提供远程方法的一端。

具体原理图如下,后面我会串起来将整个RPC的过程给大家说一下。

Dubbo 常见问题总结

RPC原理图

  1. 服务消费端(client)以本地调用的方式调用远程服务;
  2. 客户端 Stub(client stub) 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体(序列化):RpcRequest
  3. 客户端 Stub(client stub) 找到远程服务的地址,并将消息发送到服务提供端;
  4. 服务端 Stub(桩)收到消息将消息反序列化为Java对象: RpcRequest
  5. 服务端 Stub(桩)根据RpcRequest中的类、方法、方法参数等信息调用本地的方法;
  6. 服务端 Stub(桩)得到方法执行结果并将组装成能够进行网络传输的消息体:RpcResponse(序列化)发送至消费方;
  7. 客户端 Stub(client stub)接收到消息并将消息反序列化为Java对象:RpcResponse ,这样也就得到了最终结果。over!

相信小伙伴们看完上面的讲解之后,已经了解了 RPC 的原理。

虽然篇幅不多,但是基本把 RPC 框架的核心原理讲清楚了!另外,对于上面的技术细节,我会在后面的章节介绍到。

最后,对于 RPC 的原理,希望小伙伴不单单要理解,还要能够自己画出来并且能够给别人讲出来。因为,在面试中这个问题在面试官问到 RPC 相关内容的时候基本都会碰到。

Dubbo基础

什么是 Dubbo?

Dubbo 常见问题总结

Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架。

根据 Dubbo 官方文档的介绍,Dubbo 提供了六大核心能力

  1. 面向接口代理的高性能RPC调用。
  2. 智能容错和负载均衡。
  3. 服务自动注册和发现。
  4. 高度可扩展能力。
  5. 运行期流量调度。
  6. 可视化的服务治理与运维。

Dubbo 常见问题总结

Dubbo提供的六大核心能力

简单来说就是: Dubbo 不光可以帮助我们调用远程服务,还提供了一些其他开箱即用的功能比如智能负载均衡。

Dubbo 目前已经有接近 34.4 k 的 Star 。

2020 年度 OSC 中国开源项目 评选活动中,Dubbo 位列开发框架和基础组件类项目的第7名。想比几年前来说,热度和排名有所下降。

Dubbo 常见问题总结

Dubbo 是由阿里开源,后来加入了 Apache 。正式由于 Dubbo 的出现,才使得越来越多的公司开始使用以及接受分布式架构。

为什么要用 Dubbo?

随着互联网的发展,网站的规模越来越大,用户数量越来越多。单一应用架构 、垂直应用架构无法满足我们的需求,这个时候分布式服务架构就诞生了。

分布式服务架构下,系统被拆分成不同的服务比如短信服务、安全服务,每个服务独立提供系统的某个核心服务。

我们可以使用 Java RMI(Java Remote Method Invocation)、Hessian这种支持远程调用的框架来简单地暴露和引用远程服务。但是!当服务越来越多之后,服务调用关系越来越复杂。当应用访问压力越来越大后,负载均衡以及服务监控的需求也迫在眉睫。我们可以用 F5 这类硬件来做负载均衡,但这样增加了成本,并且存在单点故障的风险。

不过,Dubbo 的出现让上述问题得到了解决。Dubbo 帮助我们解决了什么问题呢?

  1. 负载均衡 : 同一个服务部署在不同的机器时该调用那一台机器上的服务。
  2. 服务调用链路生成 : 随着系统的发展,服务越来越多,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。Dubbo 可以为我们解决服务之间互相是如何调用的。
  3. 服务访问压力以及时长统计、资源调度和治理 :基于访问压力实时管理集群容量,提高集群利用率。
  4. ……

Dubbo 常见问题总结

另外,Dubbo 除了能够应用在分布式系统中,也可以应用在现在比较火的微服务系统中。不过,由于 Spring Cloud 在微服务中应用更加广泛,所以,我觉得一般我们提 Dubbo 的话,大部分是分布式系统的情况。

我们刚刚提到了分布式这个概念,下面再给大家介绍一下什么是分布式?为什么要分布式?

分布式基础

什么是分布式?

分布式或者说 SOA 分布式重要的就是面向服务,说简单的分布式就是我们把整个系统拆分成不同的服务然后将这些服务放在不同的服务器上减轻单体服务的压力提高并发量和性能。比如电商系统可以简单地拆分成订单系统、商品系统、登录系统等等,拆分之后的每个服务可以部署在不同的机器上,如果某一个服务的访问量比较大的话也可以将这个服务同时部署在多台机器上。

Dubbo 常见问题总结

分布式事务示意图

为什么要分布式?

从开发角度来讲单体应用的代码都集中在一起,而分布式系统的代码根据业务被拆分。所以,每个团队可以负责一个服务的开发,这样提升了开发效率。另外,代码根据业务拆分之后更加便于维护和扩展。

另外,我觉得将系统拆分成分布式之后不光便于系统扩展和维护,更能提高整个系统的性能。你想一想嘛?把整个系统拆分成不同的服务/系统,然后每个服务/系统 单独部署在一台服务器上,是不是很大程度上提高了系统性能呢?

Dubbo 架构

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

官方文档中的框架设计章节 已经介绍的非常详细了,我这里把一些比较重要的点再提一下。

Dubbo 常见问题总结

dubbo-relation

上述节点简单介绍以及他们之间的关系:

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

Dubbo 中的 Invoker 概念了解么?

Invoker 是 Dubbo 领域模型中非常重要的一个概念,你如果阅读过 Dubbo 源码的话,你会无数次看到这玩意。就比如下面我要说的负载均衡这块的源码中就有大量 Invoker 的身影。

简单来说,Invoker 就是 Dubbo 对远程调用的抽象。

Dubbo 常见问题总结

dubbo_rpc_invoke.jpg

按照 Dubbo 官方的话来说,Invoker 分为

  • 服务提供 Invoker
  • 服务消费 Invoker

假如我们需要调用一个远程方法,我们需要动态代理来屏蔽远程调用的细节吧!我们屏蔽掉的这些细节就依赖对应的 Invoker 实现, Invoker 实现了真正的远程服务调用。

Dubbo 的工作原理了解么?

下图是 Dubbo 的整体设计,从下至上分为十层,各层均为单向依赖。

左边淡蓝背景的为服务消费方使用的接口,右边淡绿色背景的为服务提供方使用的接口,位于中轴线上的为双方都用到的接口。

Dubbo 常见问题总结

dubbo-framework

  • 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 数据序列化层 :对需要在网络传输的数据进行序列化。

Dubbo 的 SPI 机制了解么? 如何扩展 Dubbo 中的默认实现?

SPI(Service Provider Interface) 机制被大量用在开源项目中,它可以帮助我们动态寻找服务/功能(比如负载均衡策略)的实现。

SPI 的具体原理是这样的:我们将接口的实现类放在配置文件中,我们在程序运行过程中读取配置文件,通过反射加载实现类。这样,我们可以在运行的时候,动态替换接口的实现类。和 IoC 的解耦思想是类似的。

Java 本身就提供了 SPI 机制的实现。不过,Dubbo 没有直接用,而是对 Java原生的 SPI机制进行了增强,以便更好满足自己的需求。

那我们如何扩展 Dubbo 中的默认实现呢?

比如说我们想要实现自己的负载均衡策略,我们创建对应的实现类 XxxLoadBalance 实现 LoadBalance 接口或者 AbstractLoadBalance 类。

package com.xxx;  import org.apache.dubbo.rpc.cluster.LoadBalance; import org.apache.dubbo.rpc.Invoker; import org.apache.dubbo.rpc.Invocation; import org.apache.dubbo.rpc.RpcException;   public class XxxLoadBalance implements LoadBalance {     public <T> Invoker<T> select(List<Invoker<T>> invokers, Invocation invocation) throws RpcException {         // ...     } }

我们将这个是实现类的路径写入到resources 目录下的 META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance文件中即可。

src  |-main     |-java         |-com             |-xxx                 |-XxxLoadBalance.java (实现LoadBalance接口)     |-resources         |-META-INF             |-dubbo                 |-org.apache.dubbo.rpc.cluster.LoadBalance (纯文本文件,内容为:xxx=com.xxx.XxxLoadBalance)

org.apache.dubbo.rpc.cluster.LoadBalance

xxx=com.xxx.XxxLoadBalance

其他还有很多可供扩展的选择,你可以在官方文档@SPI扩展实现这里找到。

Dubbo 常见问题总结

Dubbo 的微内核架构了解吗?

Dubbo 采用 微内核(Microkernel) + 插件(Plugin) 模式,简单来说就是微内核架构。微内核只负责组装插件。

何为微内核架构呢? 《软件架构模式》 这本书是这样介绍的:

微内核架构模式(有时被称为插件架构模式)是实现基于产品应用程序的一种自然模式。基于产品的应用程序是已经打包好并且拥有不同版本,可作为第三方插件下载的。然后,很多公司也在开发、发布自己内部商业应用像有版本号、说明及可加载插件式的应用软件(这也是这种模式的特征)。微内核系统可让用户添加额外的应用如插件,到核心应用,继而提供了可扩展性和功能分离的用法。

微内核架构包含两类组件:核心系统(core system)插件模块(plug-in modules)

Dubbo 常见问题总结

核心系统提供系统所需核心能力,插件模块可以扩展系统的功能。因此, 基于微内核架构的系统,非常易于扩展功能。

我们常见的一些IDE,都可以看作是基于微内核架构设计的。绝大多数 IDE比如IDEA、VSCode都提供了插件来丰富自己的功能。

正是因为Dubbo基于微内核架构,才使得我们可以随心所欲替换Dubbo的功能点。比如你觉得Dubbo 的序列化模块实现的不满足自己要求,没关系啊!你自己实现一个序列化模块就好了啊!

通常情况下,微核心都会采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依赖 Spring 等 IoC 容器,也不想自已造一个小的 IoC 容器(过度设计),因此采用了一种最简单的 Factory 方式管理插件 :JDK 标准的 SPI 扩展机制java.util.ServiceLoader)。

关于Dubbo架构的一些自测小问题

注册中心的作用了解么?

注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互。

服务提供者宕机后,注册中心会做什么?

注册中心会立即推送事件通知消费者。

监控中心的作用呢?

监控中心负责统计各服务调用次数,调用时间等。

注册中心和监控中心都宕机的话,服务都会挂掉吗?

不会。两者都宕机也不影响已运行的提供者和消费者,消费者在本地缓存了提供者列表。注册中心和监控中心都是可选的,服务消费者可以直连服务提供者。

    • RPC基础
      • 何为 RPC?
      • RPC 的原理是什么?
    • Dubbo基础
      • 什么是 Dubbo?
      • 为什么要用 Dubbo?
    • 分布式基础
      • 什么是分布式?
      • 为什么要分布式?
    • Dubbo 架构
      • Dubbo 架构中的核心角色有哪些?
      • Dubbo 中的 Invoker 概念了解么?
      • Dubbo 的工作原理了解么?
      • Dubbo 的 SPI 机制了解么? 如何扩展 Dubbo 中的默认实现?
      • Dubbo 的微内核架构了解吗?
      • 关于Dubbo架构的一些自测小问题
        • 注册中心的作用了解么?
        • 服务提供者宕机后,注册中心会做什么?
        • 监控中心的作用呢?
        • 注册中心和监控中心都宕机的话,服务都会挂掉吗?

这篇文章是我根据官方文档以及自己平时的使用情况,对 Dubbo 所做的一个总结。欢迎补充!

RPC基础

何为 RPC?

RPC(Remote Procedure Call) 即远程过程调用,通过名字我们就能看出 RPC 关注的是远程调用而非本地调用。

为什么要 RPC ? 因为,两个不同的服务器上的服务提供的方法不在一个内存空间,所以,需要通过网络编程才能传递方法调用所需要的参数。并且,方法调用的结果也需要通过网络编程来接收。但是,如果我们自己手动网络编程来实现这个调用过程的话工作量是非常大的,因为,我们需要考虑底层传输方式(TCP还是UDP)、序列化方式等等方面。

**RPC 能帮助我们做什么呢? ** 简单来说,通过 RPC 可以帮助我们调用远程计算机上某个服务的方法,这个过程就像调用本地方法一样简单。并且!我们不需要了解底层网络编程的具体细节。

举个例子:两个不同的服务 A、B 部署在两台不同的机器上,服务 A 如果想要调用服务 B 中的某个方法的话就可以通过 RPC 来做。

一言蔽之:RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单。

RPC 的原理是什么?

为了能够帮助小伙伴们理解 RPC 原理,我们可以将整个 RPC的 核心功能看作是下面👇 6 个部分实现的:

  1. 客户端(服务消费端) :调用远程方法的一端。
  2. 客户端 Stub(桩) : 这其实就是一代理类。代理类主要做的事情很简单,就是把你调用方法、类、方法参数等信息传递到服务端。
  3. 网络传输 : 网络传输就是你要把你调用的方法的信息比如说参数啊这些东西传输到服务端,然后服务端执行完之后再把返回结果通过网络传输给你传输回来。网络传输的实现方式有很多种比如最近基本的 Socket或者性能以及封装更加优秀的 Netty(推荐)。
  4. 服务端 Stub(桩) :这个桩就不是代理类了。我觉得理解为桩实际不太好,大家注意一下就好。这里的服务端 Stub 实际指的就是接收到客户端执行方法的请求后,去指定对应的方法然后返回结果给客户端的类。
  5. 服务端(服务提供端) :提供远程方法的一端。

具体原理图如下,后面我会串起来将整个RPC的过程给大家说一下。

Dubbo 常见问题总结

RPC原理图

  1. 服务消费端(client)以本地调用的方式调用远程服务;
  2. 客户端 Stub(client stub) 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体(序列化):RpcRequest
  3. 客户端 Stub(client stub) 找到远程服务的地址,并将消息发送到服务提供端;
  4. 服务端 Stub(桩)收到消息将消息反序列化为Java对象: RpcRequest
  5. 服务端 Stub(桩)根据RpcRequest中的类、方法、方法参数等信息调用本地的方法;
  6. 服务端 Stub(桩)得到方法执行结果并将组装成能够进行网络传输的消息体:RpcResponse(序列化)发送至消费方;
  7. 客户端 Stub(client stub)接收到消息并将消息反序列化为Java对象:RpcResponse ,这样也就得到了最终结果。over!

相信小伙伴们看完上面的讲解之后,已经了解了 RPC 的原理。

虽然篇幅不多,但是基本把 RPC 框架的核心原理讲清楚了!另外,对于上面的技术细节,我会在后面的章节介绍到。

最后,对于 RPC 的原理,希望小伙伴不单单要理解,还要能够自己画出来并且能够给别人讲出来。因为,在面试中这个问题在面试官问到 RPC 相关内容的时候基本都会碰到。

Dubbo基础

什么是 Dubbo?

Dubbo 常见问题总结

Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架。

根据 Dubbo 官方文档的介绍,Dubbo 提供了六大核心能力

  1. 面向接口代理的高性能RPC调用。
  2. 智能容错和负载均衡。
  3. 服务自动注册和发现。
  4. 高度可扩展能力。
  5. 运行期流量调度。
  6. 可视化的服务治理与运维。

Dubbo 常见问题总结

Dubbo提供的六大核心能力

简单来说就是: Dubbo 不光可以帮助我们调用远程服务,还提供了一些其他开箱即用的功能比如智能负载均衡。

Dubbo 目前已经有接近 34.4 k 的 Star 。

2020 年度 OSC 中国开源项目 评选活动中,Dubbo 位列开发框架和基础组件类项目的第7名。想比几年前来说,热度和排名有所下降。

Dubbo 常见问题总结

Dubbo 是由阿里开源,后来加入了 Apache 。正式由于 Dubbo 的出现,才使得越来越多的公司开始使用以及接受分布式架构。

为什么要用 Dubbo?

随着互联网的发展,网站的规模越来越大,用户数量越来越多。单一应用架构 、垂直应用架构无法满足我们的需求,这个时候分布式服务架构就诞生了。

分布式服务架构下,系统被拆分成不同的服务比如短信服务、安全服务,每个服务独立提供系统的某个核心服务。

我们可以使用 Java RMI(Java Remote Method Invocation)、Hessian这种支持远程调用的框架来简单地暴露和引用远程服务。但是!当服务越来越多之后,服务调用关系越来越复杂。当应用访问压力越来越大后,负载均衡以及服务监控的需求也迫在眉睫。我们可以用 F5 这类硬件来做负载均衡,但这样增加了成本,并且存在单点故障的风险。

不过,Dubbo 的出现让上述问题得到了解决。Dubbo 帮助我们解决了什么问题呢?

  1. 负载均衡 : 同一个服务部署在不同的机器时该调用那一台机器上的服务。
  2. 服务调用链路生成 : 随着系统的发展,服务越来越多,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。Dubbo 可以为我们解决服务之间互相是如何调用的。
  3. 服务访问压力以及时长统计、资源调度和治理 :基于访问压力实时管理集群容量,提高集群利用率。
  4. ……

Dubbo 常见问题总结

另外,Dubbo 除了能够应用在分布式系统中,也可以应用在现在比较火的微服务系统中。不过,由于 Spring Cloud 在微服务中应用更加广泛,所以,我觉得一般我们提 Dubbo 的话,大部分是分布式系统的情况。

我们刚刚提到了分布式这个概念,下面再给大家介绍一下什么是分布式?为什么要分布式?

分布式基础

什么是分布式?

分布式或者说 SOA 分布式重要的就是面向服务,说简单的分布式就是我们把整个系统拆分成不同的服务然后将这些服务放在不同的服务器上减轻单体服务的压力提高并发量和性能。比如电商系统可以简单地拆分成订单系统、商品系统、登录系统等等,拆分之后的每个服务可以部署在不同的机器上,如果某一个服务的访问量比较大的话也可以将这个服务同时部署在多台机器上。

Dubbo 常见问题总结

分布式事务示意图

为什么要分布式?

从开发角度来讲单体应用的代码都集中在一起,而分布式系统的代码根据业务被拆分。所以,每个团队可以负责一个服务的开发,这样提升了开发效率。另外,代码根据业务拆分之后更加便于维护和扩展。

另外,我觉得将系统拆分成分布式之后不光便于系统扩展和维护,更能提高整个系统的性能。你想一想嘛?把整个系统拆分成不同的服务/系统,然后每个服务/系统 单独部署在一台服务器上,是不是很大程度上提高了系统性能呢?

Dubbo 架构

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

官方文档中的框架设计章节 已经介绍的非常详细了,我这里把一些比较重要的点再提一下。

Dubbo 常见问题总结

dubbo-relation

上述节点简单介绍以及他们之间的关系:

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

Dubbo 中的 Invoker 概念了解么?

Invoker 是 Dubbo 领域模型中非常重要的一个概念,你如果阅读过 Dubbo 源码的话,你会无数次看到这玩意。就比如下面我要说的负载均衡这块的源码中就有大量 Invoker 的身影。

简单来说,Invoker 就是 Dubbo 对远程调用的抽象。

Dubbo 常见问题总结

dubbo_rpc_invoke.jpg

按照 Dubbo 官方的话来说,Invoker 分为

  • 服务提供 Invoker
  • 服务消费 Invoker

假如我们需要调用一个远程方法,我们需要动态代理来屏蔽远程调用的细节吧!我们屏蔽掉的这些细节就依赖对应的 Invoker 实现, Invoker 实现了真正的远程服务调用。

Dubbo 的工作原理了解么?

下图是 Dubbo 的整体设计,从下至上分为十层,各层均为单向依赖。

左边淡蓝背景的为服务消费方使用的接口,右边淡绿色背景的为服务提供方使用的接口,位于中轴线上的为双方都用到的接口。

Dubbo 常见问题总结

dubbo-framework

  • 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 数据序列化层 :对需要在网络传输的数据进行序列化。

Dubbo 的 SPI 机制了解么? 如何扩展 Dubbo 中的默认实现?

SPI(Service Provider Interface) 机制被大量用在开源项目中,它可以帮助我们动态寻找服务/功能(比如负载均衡策略)的实现。

SPI 的具体原理是这样的:我们将接口的实现类放在配置文件中,我们在程序运行过程中读取配置文件,通过反射加载实现类。这样,我们可以在运行的时候,动态替换接口的实现类。和 IoC 的解耦思想是类似的。

Java 本身就提供了 SPI 机制的实现。不过,Dubbo 没有直接用,而是对 Java原生的 SPI机制进行了增强,以便更好满足自己的需求。

那我们如何扩展 Dubbo 中的默认实现呢?

比如说我们想要实现自己的负载均衡策略,我们创建对应的实现类 XxxLoadBalance 实现 LoadBalance 接口或者 AbstractLoadBalance 类。

package com.xxx;  import org.apache.dubbo.rpc.cluster.LoadBalance; import org.apache.dubbo.rpc.Invoker; import org.apache.dubbo.rpc.Invocation; import org.apache.dubbo.rpc.RpcException;   public class XxxLoadBalance implements LoadBalance {     public <T> Invoker<T> select(List<Invoker<T>> invokers, Invocation invocation) throws RpcException {         // ...     } }

我们将这个是实现类的路径写入到resources 目录下的 META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance文件中即可。

src  |-main     |-java         |-com             |-xxx                 |-XxxLoadBalance.java (实现LoadBalance接口)     |-resources         |-META-INF             |-dubbo                 |-org.apache.dubbo.rpc.cluster.LoadBalance (纯文本文件,内容为:xxx=com.xxx.XxxLoadBalance)

org.apache.dubbo.rpc.cluster.LoadBalance

xxx=com.xxx.XxxLoadBalance

其他还有很多可供扩展的选择,你可以在官方文档@SPI扩展实现这里找到。

Dubbo 常见问题总结

Dubbo 的微内核架构了解吗?

Dubbo 采用 微内核(Microkernel) + 插件(Plugin) 模式,简单来说就是微内核架构。微内核只负责组装插件。

何为微内核架构呢? 《软件架构模式》 这本书是这样介绍的:

微内核架构模式(有时被称为插件架构模式)是实现基于产品应用程序的一种自然模式。基于产品的应用程序是已经打包好并且拥有不同版本,可作为第三方插件下载的。然后,很多公司也在开发、发布自己内部商业应用像有版本号、说明及可加载插件式的应用软件(这也是这种模式的特征)。微内核系统可让用户添加额外的应用如插件,到核心应用,继而提供了可扩展性和功能分离的用法。

微内核架构包含两类组件:核心系统(core system)插件模块(plug-in modules)

Dubbo 常见问题总结

核心系统提供系统所需核心能力,插件模块可以扩展系统的功能。因此, 基于微内核架构的系统,非常易于扩展功能。

我们常见的一些IDE,都可以看作是基于微内核架构设计的。绝大多数 IDE比如IDEA、VSCode都提供了插件来丰富自己的功能。

正是因为Dubbo基于微内核架构,才使得我们可以随心所欲替换Dubbo的功能点。比如你觉得Dubbo 的序列化模块实现的不满足自己要求,没关系啊!你自己实现一个序列化模块就好了啊!

通常情况下,微核心都会采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依赖 Spring 等 IoC 容器,也不想自已造一个小的 IoC 容器(过度设计),因此采用了一种最简单的 Factory 方式管理插件 :JDK 标准的 SPI 扩展机制java.util.ServiceLoader)。

关于Dubbo架构的一些自测小问题

注册中心的作用了解么?

注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互。

服务提供者宕机后,注册中心会做什么?

注册中心会立即推送事件通知消费者。

监控中心的作用呢?

监控中心负责统计各服务调用次数,调用时间等。

注册中心和监控中心都宕机的话,服务都会挂掉吗?

不会。两者都宕机也不影响已运行的提供者和消费者,消费者在本地缓存了提供者列表。注册中心和监控中心都是可选的,服务消费者可以直连服务提供者。

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » Dubbo 常见问题总结求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们