面试造轮子:如何回答RPC实践操作题?
Posted 勾勾的Java宇宙
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了面试造轮子:如何回答RPC实践操作题?相关的知识,希望对你有一定的参考价值。
很多候选人对于 RPC 有关的面试问题存在一个误区,认为面试官只会问这样几个问题:
RPC 的一次调用过程是怎样的?
RPC 的服务发现是如何实现的?
RPC 的负载均衡有哪些?
……
其实这些问题看似专业,却很容易搜索到答案,如果作为面试题很难区分候选人的技术能力。
所以针对 RPC 的技术考察,目前大多数面试官会从实践操作+原理掌握两个角度出发,递进地考察候选人。
RPC 实践操作
举个例子:
在电商 App 商品详情页中,用户每次刷新页面时,App 都会请求业务网关系统,并由网关系统远程调用多个下游服务(比如商品服务、促销服务、广告服务等)。
对于整条 RPC 调用链路(从 App 到网关再到各个服务系统),怎么设置 RPC 的超时时间?要考虑哪些问题?
一些初中级研发会觉得问题很简单,不用想也知道:
App 远程调用网关系统的超时时间要大于网关系统调用后端各服务的超时时间之和。这样至少能保证在网关与下游服务的每个 PRC 调用执行完成之前不超时。
如果你这么回答,从“实践”的角度上看,基本是不合格的。
因为 PRC 接口的超时设置看似简单,但其中却涉及了很多技术层面的问题。比如——
RPC 都有超时重传的机制,如果后端服务触发超时重传,这时对 App 来说,也会存在请求等待超时的风险,就会出现后端服务还没来得及做降级处理,商品详情页就已经等待超时了。
并且在 RPC 调用的过程中也还会涉及其他的技术点,比如:
即使考虑到整个调用链的平均响应时长会受到所有依赖服务的耗时和重传次数影响,那么依据什么来设置 RPC 超时时间和重试次数呢?
如果发生超时重传,怎么区分哪些 RPC 服务可重传,哪些不可重传呢?
如果请求超过了 PRC 的重传次数,一般会触发服务降级,这又会对商品详情页造成什么影响?
总的来说,任何一个微服务出现性能问题,都会影响网关系统的平均响应时长,最终对 App 产生影响。所以从 RPC 接口的超时问题上,面试官会考察候选人很多深层次的开发实践能力。
那具体要怎么回答呢?我建议你参考以下解题思路。
结合 TP99 请求耗时:首先如果你要回答“超时时间设置和重传次数问题”,需要根据每一个微服务 TP99 的请求耗时,以及业务场景进行综合衡量。
RPC 调用方式:你要站在业务场景下,讲清楚网关调用各下游服务的串并行方式,服务之间是否存在上下服务依赖。
分析核心服务:分析出哪些是核心服务,哪些是非核心服务,核心服务是否有备用方案,非核心服务是否有降级策略。
总的来讲,解答实践操作类面试题,一定要结合理论和落地实践,要做到既有理也有据,有理表示要有分析问题的能力,有据表示具备落地实战的经验。很多同学的通病是:回答问题只有方案,没有落地细节,这会让面试官认为你技术不扎实。
进一步,如果面试官觉得你“实践问题”答得不错,会深入考察你对 RPC 的原理性知识的掌握情况。
RPC 原理掌握
以刚刚的“电商 App”场景为例:
商品详情页的 QPS 已达到了 2 万次/s,在做了服务化拆分之后,此时完成一次请求需要调用 3 次 RPC 服务,计算下来,RPC 服务需要承载大概 6 万次/s 的请求。那么你怎么设计 RPC 框架才能承载 6 万次/s 请求量呢?
能否答好这个问题,很考验候选人对 RPC 原理掌握的深度,我建议你从两个角度分析。
优化 RPC 的网络通信性能:高并发下选择高性能的网络编程 I/O 模型。
选型合适的 RPC 序列化方式:选择合适的序列化方式,进而提升封包和解包的性能。
然而我在面试候选人时发现,一些同学虽然做了准备,但只能说出个别 RPC 框架的大致流程,不能深刻理解每个环节的工作原理,所以整体给我的感觉就是:应用层面通过,原理深度不够。
而我对你的要求是:对于中间件等技术工具和框架,虽然在实际工作中不推荐重复“造轮子”,但在面试中要证明自己具备“造轮子”的能力,因为要评价一个程序员是否对技术栈有全面的认识,考察其“造轮子”的能力是一个不错的切入点。
那么,在 RPC 的面试题目中,要如何证明你很会“造轮子”呢?明天我们再好好说一说。
阅读推荐:
以上是关于面试造轮子:如何回答RPC实践操作题?的主要内容,如果未能解决你的问题,请参考以下文章
「从零开始造 RPC 轮子系列」01 我为什么要去造一个轮子?
「从零开始造 RPC 轮子系列」01 我为什么要去造一个轮子?