RPC 面试题及详细答案（实战向）-1

RPC面试题及详细答案（实战向）一、基础概念类（入门必问）1.什么是RPC？核心作用是什么？答案：RPC全称远程过程调用，简单说就是允许一台机器的程序，直接调用另一台机器上的方法，使用体验和调用本地方法几乎一致。它的核心作用是屏蔽网络通信的底层细节，让开发者不用手动写Socket连接、数据收发、报文解析等逻辑，专注业务代码。在微服务架构中，RPC是服务与服务之间跨机器、跨进程通信的核心方案，解决了分布式系统的服务调用问题。简单区分：本地调用是同一进程内方法调用，RPC是跨进程、跨机器的远程方法调用。2.RPC和HTTP接口有什么区别？为什么服务内部通信优先用RPC？答案：两者最核心的差异是传输效率、协议设计、使用场景不同：1.协议层面：HTTP是应用层通用协议，报文头大、冗余信息多，基于文本传输；RPC大多基于自定义二进制协议，报文精简、无冗余，解析速度更快。2.调用体验：HTTP调用需要手动拼接URL、处理请求参数、解析响应数据；RPC直接封装成本地方法调用，支持接口注解、参数校验、自动序列化，开发更简洁。3.性能开销：HTTP头部信息量大，文本序列化反序列化耗时高；RPC二进制序列化体积小、速度快，网络传输开销极低。4.场景适配：HTTP适合对外网关、第三方对接、浏览器访问；RPC专注内网微服务之间的高频、低延迟调用，适配服务集群内部通信。所以微服务内部通信基本首选RPC，对外暴露接口才用HTTP。3.常见的RPC框架有哪些？各自的特点？答案：1.Dubbo：阿里开源，Java生态最主流RPC框架，轻量化、易于集成，服务治理能力极强，支持负载均衡、熔断、限流、重试、注册中心适配，主打稳定、高可用，是传统微服务首选。2.gRPC：谷歌开源，跨语言极强，基于HTTP2协议，使用Protobuf序列化，性能极致，适配多语言服务、云原生场景，适合跨语言服务调用，但服务治理原生能力较弱，需要额外配套组件。3.Thrift：字节开源，跨语言、高性能，序列化速度极快，协议极简，适合高性能内网通信，但生态和服务治理不如Dubbo完善。4.Motan：微博开源，轻量简洁，适配高并发场景，架构简单、上手容易，中小规模集群使用较多。二、核心原理类（高频重点）4.RPC的完整调用流程是什么？答案：一次完整的RPC调用分为7个核心步骤，以客户端调用服务端接口为例：1.客户端发起调用：业务代码调用本地的接口方法，实际上调用的是框架生成的代理类方法。2.代理拦截请求：客户端代理拦截方法调用，封装调用信息，包括服务名、方法名、请求参数、版本号、超时时间等。3.数据序列化：将内存中的对象、参数通过序列化器转为二进制字节流，方便网络传输。4.网络传输：通过TCP/HTTP2协议，将二进制数据发送到服务端。5.服务端解码反序列化：服务端接收字节流，解析报文，通过反序列化还原为业务参数对象。6.服务端执行业务逻辑：根据解析出的服务名、方法名，找到对应的实现类，执行目标方法，获取返回结果。7.结果回传：服务端将返回结果序列化后传回客户端，客户端反序列化得到结果，完成一次远程调用。5.RPC动态代理的作用是什么？没有代理会怎么样？答案：动态代理是RPC实现“像调用本地方法一样调用远程方法”的核心。它的核心作用：屏蔽所有网络通信、报文封装、序列化的底层逻辑，只对外暴露业务接口。开发者只需要调用接口方法，无需关心远程调用的底层细节。如果没有动态代理：每次远程调用都需要手动拼接请求报文、手动序列化、手动建立网络连接、手动接收解析响应，代码冗余极高，完全失去RPC简化开发的意义。Java中Dubbo默认使用JDK动态代理，也支持CGLIB代理。6.RPC序列化方式有哪些？各自优缺点？答案：主流序列化方案及对比：1.Protobuf：谷歌推出，二进制序列化，体积小、速度快、兼容性好、跨语言强，支持字段增删兼容，gRPC默认序列化方案；缺点是需要手写.proto文件，稍微繁琐。2.Hessian2：Dubbo默认序列化方案，跨语言、使用简单，无需定义模板，序列化结果紧凑；性能略低于Protobuf，高并发极致场景稍有劣势。3.JSON：文本序列化，可读性强、调试方便、通用性高；缺点是体积大、速度慢、冗余多，不适合高频RPC调用。4.Kryo：Java专属序列化，性能极高、速度快、体积小；缺点是不跨语言，版本兼容性差，字段增减容易序列化失败。企业选型原则：跨语言用Protobuf，Java单体微服务用Hessian2，极致性能内网场景可用Kryo。7.为什么RPC大多用TCP而不用UDP？答案：1.可靠性要求：RPC是业务调用，必须保证请求可靠到达、响应正常返回，不允许丢包、乱序。TCP面向连接、可靠传输、重传机制完备；UDP无连接、不可靠，丢包后不会重传，会直接导致调用失败。2.有序性要求：RPC调用有严格的时序和报文完整性要求，TCP保证数据包有序到达，UDP会出现乱序、重复报文问题。3.适配业务场景：UDP仅适合直播、音视频、日志上报等允许少量丢包的场景，完全不适合核心业务的远程调用。补充：gRPC基于HTTP2，底层依然是TCP协议。三、服务注册与发现（Dubbo核心）8.RPC服务注册和发现的原理是什么？答案：核心是通过注册中心统一管理服务提供者和消费者，实现解耦。1.服务注册：服务提供者启动后，主动将自己的服务名、IP、端口、版本、权重等信息上报到注册中心，注册中心存储服务节点列表。2.服务订阅：服务消费者启动后，向注册中心订阅需要调用的服务，注册中心将可用的服务节点列表推送或下发给消费者。3.本地缓存：消费者拿到节点列表后，会缓存到本地，后续调用直接从本地缓存选取节点，不每次请求注册中心，提升性能。4.动态感知：服务节点上下线、宕机时，注册中心会实时推送变更通知，消费者更新本地缓存，剔除无效节点。常用注册中心：Nacos、Zookeeper、Consul、Eureka。目前企业主流使用Nacos。9.注册中心宕机了，RPC服务还能调用吗？答案：可以正常调用。注册中心的核心职责是服务注册、节点推送、变更通知，不参与实际的业务调用过程。消费者本地会缓存服务节点列表，注册中心宕机后，缓存数据不会丢失，依然可以基于本地缓存和服务节点直接通信。唯一影响：新启动的服务无法注册、新消费者无法订阅服务，已存在的服务调用完全不受影响。这也是RPC架构的高可用设计，避免单点故障导致整体服务瘫痪。四、容错与高可用（面试高频难点）10.RPC调用常见的异常问题有哪些？答案：1.超时异常：网络卡顿、服务端阻塞、GC停顿导致响应超时。2.连接异常：服务节点宕机、端口占用、网络断开导致连接失败。3.序列化异常：参数类型不匹配、字段版本不一致、序列化器不兼容。4.服务端业务异常：服务端代码报错、参数校验失败、数据库异常。5.限流熔断触发：服务端压力过大，触发限流、熔断，直接拒绝请求。6.负载均衡失败：无可用服务节点、节点权重为0、节点被手动下线。11.Dubbo有哪些容错策略？各自适用场景？答案：Dubbo内置多种集群容错策略，适配不同业务场景：1.Failover（默认）失败重试：调用失败后，自动切换其他节点重试，适合读多写少、幂等的查询业务。2.Failfast快速失败：调用失败直接抛异常，不重试，适合非幂等的写操作，避免重复提交数据。3.Failsafe失败安全：调用失败直接忽略异常，返回空结果，适合日志、统计、埋点等非核心业务。4.Failback失败自动恢复：失败后异步记录请求，后台定时重试，适合消息通知、异步更新场景。5.Forking并行调用：同时调用多个节点，只要一个成功即返回，适合高可用、低延迟的核心查询业务，资源消耗较高。12.RPC超时重试会带来什么问题？怎么解决？答案：存在问题：1.非幂等接口重试会导致重复提交，比如下单、扣款、新增数据，重试会产生脏数据。2.服务端压力翻倍，一次超时触发多次重试，高并发下容易击穿服务，引发雪崩。3.接口响应延迟加剧，重试占用更多网络和线程资源。解决方案：1.区分幂等与非幂等接口：查询接口开启重试，新增、修改、扣款接口关闭重试，使用Failfast策略。2.全局唯一幂等号：写接口传入唯一流水号，服务端基于流水号去重，保证重复请求不生效。3.合理设置超时时间和重试次数：根据业务响应耗时配置，避免无效重试。4.增加重试间隔、熔断机制：连续失败直接熔断，不再重试，保护服务。13.什么是服务熔断、服务降级？两者区别是什么？答案：服务熔断：当目标服务频繁超时、报错率过高时，框架自动触发熔断，直接拦截请求，不再调用异常服务，避免消费者大量线程阻塞、等待超时，防止故障扩散。熔断是被动保护服务集群。服务降级：人为主动关闭非核心接口、返回兜底数据，在服务压力大、流量高峰、故障期间，优先保证核心业务可用。降级是主动舍弃非核心业务。核心区别：熔断是被动触发的故障保护，降级是主动的流量管控策略。五、负载均衡与性能优化14.RPC常见的负载均衡算法有哪些？答案：以Dubbo为例，内置5种负载均衡策略：1.随机Random：随机选取服务节点，实现简单，流量分布均匀，适合节点性能一致的集群。2.轮询RoundRobin：按顺序轮流调用每个节点，均匀分发流量，适合节点配置一致、无性能差异的场景。3.最少活跃调用LeastActive：优先选择当前活跃请求数最少、压力最小的节点，自动适配节点性能差异，是生产最常用策略。4.一致性哈希ConsistentHash：相同参数的请求固定路由到同一个节点，适合会话保持、缓存场景，减少缓存失效。5.加权轮询WeightRoundRobin：根据节点权重分配流量，配置高、性能好的节点权重更高，承担更多流量，适配节点配置不均的集群。15.如何优化RPC调用性能？答案：可以从协议、序列化、连接、容错、业务五个维度优化：1.序列化优化：替换JSON为Protobuf、Hessian2等高性能二进制序列化方案，减小报文体积。2.连接池复用：使用长连接池，避免每次调用新建连接、断开连接的开销，减少三次握手、四次挥手损耗。3.合理配置超时与重试：根据业务压测结果设置合理超时时间，禁止非幂等接口重试，减少无效请求。4.负载均衡优化：使用最少活跃调用、加权策略，避免流量集中到单点，防止节点过载。5.缓存优化：高频查询接口增加本地缓存、分布式缓存，减少远程调用次数。6.异步调用：非实时业务使用异步RPC调用，避免同步阻塞等待，提升吞吐量。7.服务拆分与隔离：核心、非核心服务拆分，线程池隔离，避免相互影响。六、实战踩坑与面试压轴题16.RPC长连接和短连接的区别？生产用哪种？答案：短连接：每次调用新建TCP连接，调用完成立即断开。优点是资源释放快、无需维护连接；缺点是每次请求都有握手挥手开销，高频调用性能极差。长连接：连接建立后长期复用，多次调用共用一个连接，定时心跳保活。优点是无重复连接开销、响应快、吞吐量高；缺点是需要维护连接状态，少量空闲连接占用少量资源。生产选型：微服务RPC全部使用长连接+连接池，适配高频、低延迟的内网调用场景。17.什么是RPC粘包拆包问题？怎么解决？答案：TCP是流式协议，无报文边界，底层只认字节流，不区分请求报文，因此会出现两个问题：粘包：多个请求报文合并成一个字节流被接收。拆包：一个完整的请求报文被拆分成多次接收。会直接导致服务端解析报文异常、参数错乱、调用失败。解决方案：统一报文边界，主流三种方式：1.长度字段定界（RPC主流）：报文头部固定位置存储报文总长度，服务端根据长度读取完整报文，Dubbo、gRPC均采用该方案。2.特殊分隔符：用固定字符作为报文结尾，适合文本协议。3.固定报文长度：所有请求报文长度统一，局限性大，极少使用。18.讲讲RPC异步调用和同步调用的区别与使用场景答案：同步调用：客户端发送请求后，阻塞等待服务端响应，拿到结果后再执行后续代码。优点是逻辑简单、可控性强；缺点是会阻塞线程，高并发下吞吐量受限。适合需要实时获取结果的核心业务，如查询数据、下单校验。异步调用：客户端发送请求后不阻塞，直接继续执行后续逻辑，通过回调、Future、CompletableFuture接收响应结果。优点是不阻塞线程、吞吐量极高；缺点是代码复杂度稍高，需要处理回调异常。适合日志上报、消息通知、异步更新、批量处理等无需实时响应的业务。19.微服务中RPC调用出现链路超时，如何排查问题？答案：我在生产中排查超时的完整思路：1.先定位超时位置：通过链路追踪日志（SkyWalking、Pinpoint）确定是客户端超时、网络超时，还是服务端处理超时。2.排查客户端问题：检查客户端线程池是否打满、连接池耗尽、重试次数过多、超时时间配置过小。3.排查网络问题：查看内网延迟、丢包、端口连通性，排查防火墙、网络策略限制。4.排查服务端问题：查看服务端GC情况、线程池阻塞、数据库慢查询、锁等待、接口逻辑耗时过长。5.排查流量与容错：是否流量突增触发限流熔断、节点负载过高