首页天道酬勤rpc属于哪个层的协议,rpc框架有哪些

rpc属于哪个层的协议,rpc框架有哪些

张世龙 05-13 11:59 15次浏览

别吵,我们直接开始!

前言以前,制作规模小的系统时,使用的是单体体系结构。 在一台服务器上部署上一个APP应用程序和数据库就足够了。

但是现代化互联网公司的业务逐渐扩大,服务逐渐细分,许多服务之间需要通过远程分布式接口调用通信。 也就是说,不同的服务没有部署在同一服务上。 例如,订购服务是a服务,支付服务是另一服务,有同步呼叫和异步呼叫。 此时,我们需要远程调用不同的服务,使用时调用远程服务就像调用本地服务一样,只要部署一个jar包就可以通过this .

重点:RPC 技术一定是今后工作必备基础,熟练掌握其中一种,知道原理,阅读源码,甚至自己手写一个。

1、面试官:公司用的是什么样的RPC框架? 能给我介绍一下RPC的工作原理吗?问题分析:面试官想知道基础设施是否与我们项目中使用的相同。 同样是最好的。 可以直接得到。 就算不一样,知道另外一个也应该没什么问题。 毕竟,原理技术很相似,说是你最熟悉的之一。

答:RPC是分布式计算的CS模型,其中客户端始终向服务器发出执行某些进程的请求。 服务器接受请求,使用客户端提供的参数,并在计算完成后将结果返回给客户端。

使用最广泛的Spring Cloud,基于Spring Boot特性集成开源行业中的优秀组件,总体上在微服务体系结构中对外提供了服务治理解决方案。

在国内开源框架中,应用比较广泛的阿里Dubbo后来捐赠给了Apache。 既有腾讯的Tars框架,也有Thrift框架,还有基于Thrift二次开发的RPC框架。 例如,美团的Mtthrift。

这些RPC的大致原理基本相同。 这个时候,从面试官那里得到纸和笔,画画说明RPC的原理)

这张图太复杂了,看起来不像在给自己挖洞,也不容易看起来很复杂。

1-5 逐行解释:

当服务集成到RPC中时,当服务(这里的服务是图中的提供商,服务提供商)启动时,通过注册模块,RPC框架注册服务的唯一ID和IP地址、端口信息等调用方(Consumer )想要调用服务时,使用提供商注册时的服务特定ID前往注册中心,查找可以在线调用的服务,并返回IP列表(3.notify部分) 步骤Consumer基于某些策略,如随机or循环从Registry返回的可用IP列表中实际调用服务(4.invoke )。 最后是统计功能。 RPC框架均提供监控功能,监控服务健康状况,控制服务在线扩展和上线(5.count ),有清晰的流程图,有步骤说明,面试人员满意,继续提问其他问题

2、面试官:服务开始时服务基本信息在注册中心注册。 如果服务提供商锁定,注册中心如何知道服务不再可用? 3358www.Sina.com/服务中断为答:主动下线

例如,当服务发布时,在重新启动之前主动通知注册中心。 我会重新启动。 流量进来的话,先不要分我。 请让我为另一台机器服务。 重新启动成功后,放入流量进来。 或者,在管理后台手动直接断开机器。 这是心跳检测

主动下线处理停电等服务未正常脱机的情况。 此时,如果注册中心不知道服务已脱机,则调用该服务时会出现问题。 为了避免这种情况,在注册中心添加心跳检测功能。 它将向服务提供者(Provider )进行心跳检测。 例如,每30s发送一次心跳,如果三次心跳的结果没有返回值,则认为服务已脱机,并立即更新消费者的服务列表,告知消费者调用另一台计算机。

心跳检测关于服务端如何挂注册中心感知的问题,你在这个问题上已经结束了吗? 还有,你给自己挖了个洞成功了。 面试官可能会继续深挖。 服务提供商(提供商)挂注册中心就可以解决,注册中心会不会自己阻止? 一连三个问题。

3、面试官:注册中心锁定的情况下,比如使用Zookeeper。 如果Zookeeper锁定,是否可以在服务之间进行交互调用?问题分析:首先,注册中心锁定也分为两种情况。 即使数据库锁定,ZK也可以使用。 因为ZK会将注册器列表缓存在缓存中。

其次,ZK本身就是集群。 当一台计算机锁定时,ZK将继续选择群集中的其他计算机作为主计算机提供服务。 整个集群挂起也没有问题。 因为调用方本地缓存从注册中心获取的服务列表。 省略与注册中心的交互,Consumer和Provider采用直接连接方式,这些策略是可配置的。

答:面试是一个自由交流的时间,每一点都有可能被释放出来继续挖掘,刨根问底

总有你覆盖不到的知识盲区,目的不是为难你,是想了解你的技术沉淀深度。

4、面试官:你对 RPC 了解的很透彻,那你能否自己写一个 RPC 框架?可以简答描述下思路也行。

答:这个问题,虽然没有自己动手写过,但是我阅读过源码,大致实现思路是这样的。(画图给面试官)

客户端 invoke 方法编写,使用 JDK 的动态代理技术,客户端调用远程服务方法时调用的是 InvocationHandler 的 invoke 方法。客户端 Filter 方法编写,完善的 RPC 框架少不了监控、路由、降级、鉴权等功能。创建 Socket,在 Filter 方法中实现 Client.write 方法,其逻辑为从连接池(ChannelPool)中获取连接,然后将数据写进 Channel。实现数据序列化、压缩,目的减少网络传输的数据量,向服务端发送 request 数据,这里可以使用 Netty 异步通讯框架。服务端收到客户端发过的消息后,从 Channel 中将消息读出来之前,也会先经反序列化解压。请求就到了服务端 Filter 中。请求依次经过监控、鉴权方法。根据客户端传递来的服务信息和参数,通过反射调用相应的业务服务并拿到业务处理结果。然后在 ResponseFilter 中将返回结果写入 Channel。服务端序列化、压缩等,发送给客户端。客户端收到消息后,经过客户端反序列化、解压缩,后交给 ResponseThreadPoolProcessor 线程池处理。ResponseThreadPoolProcessor 收到消息后,就将结果返回给之前的方法调用,整个调用请求就结束了。

 面试官: 可以可以,确实是看了,这个问题就到这。(面试官心理:虽然目前项目里不会让你真正去写一个 RPC 框架,知其然知其所以然,遇到这类 RPC 相关问题一定能搞定了,项目组正好缺一个这样的人)

深入分析 已经有 http 协议接口,或者说 RestFul 接口,为什么还要使用 RPC 技术?

在接⼝不多的情况下,使用 http 确实是一个明智的选择,比如在初创企业,我们不确定业务能顺利开展下去,可能面临随时倒闭,开发人员也不足,这个时候使用简洁高效的技术,先把东西做出来是最明智的选择,无需一步登天。

系统与系统交互较少的情况下,使用 http 协议优点显而易见:开发简单、测试也比较直接、部署方便,利用现成的 http 协议进行系统间通讯,如果业务真的慢慢做大,系统也慢慢扩大,RPC 框架的好处就显示出来 了,⾸先 RPC 支持长链接,通信不必每次都要像 http 一样去重复 3 次握⼿,减少了网络开销。

其次就是 RPC 框架一般都有注册中心模块,有完善的监控管理功能,服务注册发现、服务下线、服务动态扩展等都方便操作,服务化治理效率大大提高。

基于 TCP 协议实现的 RPC,能更灵活地对协议字段进行定制,相比 http 能减少网络传输字节数,降低网络开销(握手)提高性能。实现更大的吞吐量和并发数,但是需要更多的关注底层复杂的细节, 对开发人员的要求也高,增加开发成本。

总结

在面试官夺命三连问的攻击下,前三个题目一定要掌握,最后一个加分项徒手写 RPC 深入分析,可以大大拉升面试官对你的好感,只要有亮点,即使其他问题答得不好,那么问题也不大。

RPC 工作原理总结:

Provider:服务提供方,CS 模型中的 Server。Consumer: 调用远程服务服务消费方,CS 模型中的 Client。Registry:服务注册与发现的服务管理中心。Monitor:统计服务的调用次数和调用时间的监控中心。Container:服务运行容器,如 jetty。

RPC 执行过程总结:

服务容器负责启动,加载,运行服务提供者。服务提供者在启动时,向注册中心注册自己提供的服务,暴露自己的 IP 和端口信息。服务消费者在启动时,向注册中心订阅自己所需的服务。注册中心返回服务提供者列表给消费者,如果有变更,注册中心将基于长连接推送给数据消费者。服务消费者,从提供这地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另外一台服务调用。服务消费者和提供者,在内存中累计调用次数和调用时间,定时发送一次统计数据到监控中心。

不啰嗦,文章结束,期待三连!

通俗易懂的书籍有哪些,简洁明了通俗易懂 java rpc框架,thrift rpc框架