深入探讨Dubbo面试题与知识点的全面总结：2025年最新版，助你轻松应对面试挑战

大家好，今天我将为大家提供一份关于Dubbo知识点与面试题的详细总结指南！

RPC 基础知识

RPC的定义

RPC（Remote Procedure Call），即远程过程调用，顾名思义，RPC的核心关注点在于实现远程调用，而非本地调用。

RPC的必要性：因为不同服务器上的服务在各自的内存空间中，必须通过网络编程来传递方法调用所需参数，同时获取调用结果也需要网络传输。如果手动实现网络编程来完成这套流程，工作量会非常庞大，我们需要考虑底层的传输方式（TCP或UDP）、序列化方式等多个方面。

RPC的优势：简而言之，RPC使得调用远程计算机的服务方法变得如同调用本地方法一样简单，并且用户无需关注底层网络编程的具体细节。

例如，服务A和B分别部署在两台不同的机器上，若服务A需要调用服务B的某个方法，可以通过RPC轻松实现。

简而言之：RPC的设计初衷是让远程方法调用变得像本地方法调用一样简单。

RPC的工作原理

为了帮助大家理解RPC的工作原理，可以将整个RPC过程视为以下六个核心部分的实现：

客户端（服务消费端）：负责发起远程方法调用。
客户端Stub（桩）：作为代理类，将调用方法、类及方法参数等信息传递给服务端。
网络传输：将调用方法的信息（如参数）传递到服务端，服务端执行完毕后，将返回结果通过网络发送回客户端。网络传输的实现方式多种多样，例如基本的Socket或更高效的Netty。
服务端Stub（桩）：接收客户端请求并将其反序列化为Java对象，随后根据请求信息调用相应的方法并返回结果。
服务端（服务提供端）：负责提供远程方法的实现。

具体的原理图如下所示，后续内容将为大家详细阐述RPC的完整过程。

RPC原理图

客户端以本地调用的方式请求远程服务；
客户端Stub接收到调用后，将方法及参数组装成可以进行网络传输的消息体（序列化为RpcRequest）；
客户端Stub找到远程服务的地址，并将消息发送到服务提供端；
服务端Stub接收到消息后将其反序列化为Java对象RpcRequest；
服务端Stub根据RpcRequest中的信息调用相应的方法；
服务端Stub获取方法执行结果后，组装成网络传输的消息体（序列化为RpcResponse）发送回客户端；
客户端Stub接收到消息并将其反序列化为Java对象RpcResponse，最终获得结果。

相信大家在阅读完以上内容后，对RPC的原理有了基本的了解。

虽然内容不多，但基本涵盖了RPC框架核心原理！后续章节中我将进一步介绍相关技术细节。

希望大家不仅能够理解RPC的原理，还能自己描绘出过程，并能够向他人讲解。在面试时，面试官通常会询问RPC相关内容。

Dubbo基础知识

Dubbo是什么？

Apache Dubbo (incubating) 是一款高性能、轻量级的开源Java RPC框架。

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

面向接口代理的高性能RPC调用。
智能容错及负载均衡。
服务的自动注册和发现。
高度的可扩展性。
运行时流量调度。
可视化的服务治理与运维。

Dubbo提供的六大核心能力

简而言之，Dubbo不仅能帮助我们调用远程服务，还提供了智能负载均衡等开箱即用的其他功能。

目前，Dubbo已经获得了接近34.4k的Star。

在 2020年度OSC中国开源项目评选活动中，Dubbo位列开发框架和基础组件类项目第七名。与几年前相比，其热度和排名有所下降。

Dubbo最初由阿里开源，后来加入Apache。正因为Dubbo的出现，越来越多的公司开始接受和使用分布式架构。

为什么选择Dubbo？

随着互联网的发展，网站规模的扩大和用户数量的增加，单一应用架构和垂直应用架构已经无法满足需求，分布式服务架构因此应运而生。

在分布式服务架构下，系统被拆分成不同的服务模块，例如短信服务和安全服务，每个服务独立提供系统的某个核心功能。

我们可以使用Java RMI（Java远程方法调用）、Hessian等框架简单暴露和引用远程服务。然而，随着服务数量的增加，服务调用关系愈发复杂，尤其是在高并发情况下，对负载均衡和服务监控的需求愈加迫切。虽然可以利用F5等硬件进行负载均衡，但这样会增加成本，并存在单点故障的风险。

Dubbo的出现有效解决了上述问题。Dubbo为我们解决了哪些问题呢？

负载均衡：当同一服务在不同机器上部署时，如何选择调用哪台机器上的服务。
服务调用链路生成：随着系统的发展，服务数量不断增加，服务间的依赖关系愈加复杂，甚至无法明确某个应用需在另一个应用之前启动。Dubbo可以帮助我们理解服务之间的调用关系。
服务访问压力及时长统计、资源调度和治理：根据访问压力实时管理集群容量，提高集群的利用率。
......

此外，除了在分布式系统中应用，Dubbo还可用于当前较为流行的微服务系统。不过，由于Spring Cloud在微服务中应用更为广泛，因此通常提到Dubbo的场景多是在分布式系统中。

接下来，我们将进一步探讨分布式的概念及其必要性。

分布式基础知识

分布式的定义

分布式系统，或称为SOA，核心在于面向服务。简单来说，分布式系统是将整个系统拆分为不同的服务，并将这些服务部署在不同的服务器上，以减轻单体服务的压力，提高并发量和性能。例如，一个电商系统可以拆分为订单系统、商品系统、登录系统等，拆分后的每个服务可以独立部署在多台服务器上，以应对高流量访问。

分布式事务示意图

为什么选择分布式？

从开发角度看，单体应用的代码集中在一起，而分布式系统的代码则根据业务拆分。这样，各个团队可以独立负责一个服务的开发，从而提升开发效率。此外，业务拆分后的代码更易于维护和扩展。

我认为，将系统拆分为分布式系统不仅便利扩展和维护，同时也能显著提高系统性能。想象一下，整个系统被拆分为不同的服务/系统，并分别部署在各自的服务器上，这样会大幅提升系统性能。

Dubbo架构

Dubbo架构中的核心角色

官方文档中关于框架设计的章节已经进行了详细介绍，这里我再强调一些关键点。

Dubbo关系图

上述节点及其关系简要介绍：

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

你了解Dubbo中的Invoker概念吗？

Invoker在Dubbo的领域模型中是一个非常重要的概念。如果你阅读过Dubbo源码，应该会频繁遇到这个术语。举例来说，在负载均衡的源码中，Invoker的身影随处可见。

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

dubbo_rpc_invoke.jpg

根据Dubbo官方的解释，Invoker可分为：

服务提供 Invoker
服务消费 Invoker

当我们需要调用远程方法时，需要通过动态代理来隐藏远程调用的细节，这部分细节是通过相应的Invoker实现来完成的。

了解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采用微内核（Microkernel）+插件（Plugin）模式，简单来说就是微内核架构。微内核负责插件的组装。

什么是微内核架构？ 《软件架构模式》一书中提到：

微内核架构模式（有时被称为插件架构模式）是实现基于产品应用程序的自然模式。基于产品的应用程序是已打包并拥有不同版本的，可以作为第三方插件下载。因此，许多公司也在开发、发布自己内部的商业应用，如有版本号、说明及可加载的插件式应用软件（这也是这种模式的特征）。微内核系统允许用户添加额外的插件到核心应用，从而提供可扩展性和功能分离。

微内核架构包含两种组件：核心系统（core system）和插件模块（plug-in modules）。

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

我们常用的一些IDE（集成开发环境），如IDEA和VSCode，都是基于微内核架构设计的，大多数IDE都提供插件以丰富其功能。

正因如此，Dubbo基于微内核架构，我们可以随意替换Dubbo的功能点。例如，若Dubbo的序列化模块的实现不满足需求，我们可以自行实现一个序列化模块。

通常情况下，微内核会采用Factory、IoC、OSGi等方式管理插件的生命周期。Dubbo选择了一种最简单的Factory方式管理插件，即JDK标准的SPI扩展机制（java.util.ServiceLoader）。

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

注册中心的作用是什么？

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

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

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

监控中心的作用是什么？

监控中心负责统计各服务的调用次数与调用时长。

注册中心和监控中心同时宕机，服务会停止运行吗？

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

Dubbo的负载均衡策略

什么是负载均衡？

我们先来看一下负载均衡的官方定义：

负载均衡改善了跨多个计算资源（如计算机、计算机集群、网络连接、中央处理单元或磁盘驱动）的工作负载分配。负载均衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载均衡的多个组件（而非单个组件）可以通过冗余提高可靠性和可用性。负载均衡通常涉及专用软件或硬件。

为便于理解，换个说法：

当系统中某个服务的访问量极大时，我们将该服务部署在多台服务器上。当客户端发起请求时，多个服务器均可处理该请求。因此，如何正确选择处理该请求的服务器变得至关重要。如果始终只用一台服务器处理该服务的请求，部署在多台服务器的意义将不复存在。负载均衡的目的正是为了避免单个服务器对同一请求的过载，以减少服务器宕机和崩溃的风险。

Dubbo提供的负载均衡策略有哪些？

在集群负载均衡中，Dubbo提供了多种负载均衡策略，默认为random随机调用。我们还可以自行扩展负载均衡策略（参考Dubbo的SPI机制）。

在Dubbo中，所有负载均衡的实现类均继承自AbstractLoadBalance，该类实现了LoadBalance接口，并封装了一些公共逻辑。

public abstract class AbstractLoadBalance implements LoadBalance {  
  
    static int calculateWarmupWeight(int uptime, int warmup, int weight) {  
    }  
  
    @Override  
    public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {  
    }  
  
    protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);  
  
    int getWeight(Invoker<?> invoker, Invocation invocation) {  
    }  
}

AbstractLoadBalance的实现类包括：

官方文档对负载均衡部分的介绍相当详细，推荐大家查阅，地址：Dubbo负载均衡文档。

RandomLoadBalance

根据权重随机选择（对加权随机算法的实现）。这是Dubbo默认采用的负载均衡策略。

RandomLoadBalance的实现原理十分简单，假设有两个提供相同服务的服务器S1和S2，S1的权重为7，S2的权重为3。

我们将这些权重值分布在坐标区间会得到：S1->[0, 7)，S2->(7, 10]。我们生成一个[0, 10)之间的随机数，若随机数落在指定区间，则选择对应的服务器来处理请求。

RandomLoadBalance

RandomLoadBalance的源码相当简单，花几分钟时间了解一下即可。

以下源码来自Dubbo主分支的最新版本2.7.9。

public class RandomLoadBalance extends AbstractLoadBalance {  
  
    public static final String NAME = "random";  
  
    @Override  
    protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {  
        int length = invokers.size();  
        boolean sameWeight = true;  
        int[] weights = new int[length];  
        int totalWeight = 0;  
        // 下面这个for循环的主要作用是计算所有该服务的提供者的权重之和  
        for (int i = 0; i < length; i++) {  
            int weight = getWeight(invokers.get(i), invocation);  
            totalWeight += weight;  
            weights[i] = totalWeight;  
            if (sameWeight && totalWeight != weight * (i + 1)) {  
                sameWeight = false;  
            }  
        }  
        if (totalWeight > 0 && !sameWeight) {  
            // 随机生成一个[0, totalWeight)区间内的数字  
            int offset = ThreadLocalRandom.current().nextInt(totalWeight);  
            // 判断会落在哪个服务提供者的区间  
            for (int i = 0; i < length; i++) {  
                if (offset < weights[i]) {  
                    return invokers.get(i);  
                }  
            }  
        }  
        return invokers.get(ThreadLocalRandom.current().nextInt(length));  
    }  
}

LeastActiveLoadBalance

LeastActiveLoadBalance，直译为最小活跃数负载均衡。

这个名字看似不直观，若不仔细看官方对活跃数的定义，可能无法理解其含义。

初始状态下，所有服务提供者的活跃数均为0（每个服务提供者中特定方法都有一个活跃数）。当收到请求后，对应的服务提供者活跃数+1，请求处理完成后，活跃数-1。

因此，Dubbo会认为活跃数越少的服务提供者，处理速度越快，性能也越好，从而优先将请求交给活跃数较少的服务提供者处理。

如果多个服务提供者活跃数相同怎么办？

很简单，使用RandomLoadBalance进行随机选择。

public class LeastActiveLoadBalance extends AbstractLoadBalance {  
  
    public static final String NAME = "leastactive";  
  
    @Override  
    protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {  
        int length = invokers.size();  
        int leastActive = -1;  
        int leastCount = 0;  
        int[] leastIndexes = new int[length];  
        int[] weights = new int[length];  
        int totalWeight = 0;  
        int firstWeight = 0;  
        boolean sameWeight = true;  
        // 这个for循环遍历invokers列表，找出活跃数最小的Invoker  
        for (int i = 0; i < length; i++) {  
            Invoker<T> invoker = invokers.get(i);  
            // 获取invoker对应的活跃数  
            int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();  
            int afterWarmup = getWeight(invoker, invocation);  
            weights[i] = afterWarmup;  
            if (leastActive == -1 || active < leastActive) {  
                leastActive = active;  
                leastCount = 1;  
                leastIndexes[0] = i;  
                totalWeight = afterWarmup;  
                firstWeight = afterWarmup;  
                sameWeight = true;  
            } else if (active == leastActive) {  
                leastIndexes[leastCount++] = i;  
                totalWeight += afterWarmup;  
                if (sameWeight && afterWarmup != firstWeight) {  
                    sameWeight = false;  
                }  
            }  
        }  
        // 如果只有一个Invoker具有最小的活跃数，直接返回该Invoker  
        if (leastCount == 1) {  
            return invokers.get(leastIndexes[0]);  
        }  
        // 如果有多个Invoker具有相同的最小活跃数，且它们之间的权重不同  
        if (!sameWeight && totalWeight > 0) {  
            int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);  
            for (int i = 0; i < leastCount; i++) {  
                int leastIndex = leastIndexes[i];  
                offsetWeight -= weights[leastIndex];  
                if (offsetWeight < 0) {  
                    return invokers.get(leastIndex);  
                }  
            }  
        }  
        return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]);  
    }  
}

活跃数通过RpcStatus中的ConcurrentMap保存，依据URL及服务提供者被调用的方法名，我们即可获取到对应的活跃数。换句话说，服务提供者中的每个方法的活跃数都是独立的。

public class RpcStatus {  
  
    private static final ConcurrentMap<String, ConcurrentMap<String, RpcStatus>> METHOD_STATISTICS =  
            new ConcurrentHashMap<String, ConcurrentMap<String, RpcStatus>>();  
  
    public static RpcStatus getStatus(URL url, String methodName) {  
        String uri = url.toIdentityString();  
        ConcurrentMap<String, RpcStatus> map = METHOD_STATISTICS.computeIfAbsent(uri, k -> new ConcurrentHashMap<>());  
        return map.computeIfAbsent(methodName, k -> new RpcStatus());  
    }  
  
    public int getActive() {  
        return active.get();  
    }  
}