手动实现简易版RPC(一)

时间:2024-04-11 09:24:36

手动实现简易版RPC(一)

前言

什么是RPC?它的原理是什么?它有什么特点?如果让你实现一个RPC框架,你会如何是实现?带着这些问题,开始今天的学习。

本文主要介绍RPC概述以及一些关于RPC的知识,为后面实现做充足的准备。


1. RPC简述

1.1 什么是RPC

专业定义: RPC是远程过程调用(Remote Procedure Call)。 RPC 的主要功能目标是让构建分布式计算(应用)更容易,在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标,RPC 框架需提供一种透明调用机制,让使用者不必显式的区分本地调用和远程调用。

举个????:

假设你住在一个大社区里,社区里有很多居民,每个人都有自己的专长。比如,有的擅长修理电器,有的擅长烹饪美食,还有的擅长园艺。有一天,你突然发现家里的水龙头坏了,你并不会修理,于是你想到社区里那位擅长修理电器的居民。

在这个场景下,你可以将自己想象成客户端(Client),那位擅长修理的居民则是服务端(Server)。你想要调用服务端的“修理水龙头”这个“方法”。但是,你和服务端并不在同一个地方,不能直接交流,于是你需要通过一些方式(比如电话,发短信,或者社区的信息平台)来发起这个调用请求。

而达成的效果呢:就像你自己修理水龙头一样的丝滑,你不需要知道整个修理的过程,你只需要知道,修理好了这个结果就行

1.2 为什么要用RPC

回到 RPC 的概念,RPC 允许一个程序(称为服务消费者)像调用自己程序的方法一样,调用另一个程序(称为服务提供者)的接口,而不需要了解数据的传输处理过程、底层网络通信的细节等。这些都会由 RPC 框架帮你完成,使得开发者可以轻松调用远程服务,快速开发分布式系统。

举个????:

现在有项目A和项目B两个单独的项目,项目A提供一系列的关于宠物的服务,然后项目B也想使用项目A 的一些服务,完成宠物信息的查询。

项目A的查询猫咪信息的服务接口伪代码如下:

interface CatService {
    /***
     * 获取猫咪信息
     * @return
     */
    Cat getCat(参数1,参数2...);


    /***
     * 按照id获取猫咪信息
     * @param id
     * @return
     */
    Cat getCatById(int id);
    
    //....other
}

如果没有RPC,项目B会如何调用项目A的服务呢?

首先,由于项目A和项目 B都是独立的系统,不能像 SDK一样作为依赖包引入。

那么就需要项目 A提供 web 服务,并且编写一个点餐接口暴露服务,比如访问http:localhost:8088/api/cat 就能调用服务A的猫咪查询服务;然后项目B作为服务消费者,需要自己构造请求,并通过 HttpClient 请求上述地址,拿到相关信息。

如果项目B需要调用更多第三方服务,每个服务和方法的调用都编写一个 HTTP 请求,那么会非常麻烦

示例伪代码如下:

url="http:localhost:8088/api/cat"
req=new Req(参数1,参数2,参数3)
res=httpClient.post(url).body(reg).execute()
cat =res.data

那么如果使用RPC框架,对于项目B来说,要实现上述调用,可能只需要一行代码

cat=CatService.getCat(参数1,参数2,参数3)

看起来是不是和调用自己的方法一样,十分简洁。

2.RPC设计实现思路

基本设计

RPC框架为什么能够简化调用?该如何实现一个RPC框架呢?带着这两个问题,一起往下看

首先呢,我们将上述服务A抽象为服务提供者(producer),服务B抽象为服务消费者(consumer)

请添加图片描述

消费者想要调用提供者,就需要提供者启动一个 web 服务 ,然后通过 请求客户端 发送 HTTP 或者其他协议的请求来调用。
比如请求 http:localhost:8088/api/cat 地址后,提供者会调用 CatService的 getCat方法:

请添加图片描述

但如果提供者提供了多个服务和方法,每个接口和方法是不是都要单独写一个接口?消费者需不需要针对每个接口写一段 HTTP 调用的逻辑么?

其实可以提供一个统一的服务调用接口,通过请求处理器,根据客户端的请求参数来进行不同的处理、调用不同的服务和方法。

可以在服务提供者程序维护一个本地服务注册器,记录服务和对应实现类的映射。

举个????:

消费者要调用 CatService服务的 getCat 方法,可以发送请求,参数为 service=CatService,method=getCat 然后请求处理器会根据 service 从服务注册器中找到对应的服务实现类,并且通过 Java 的反射机制调用 method 指定的方法。

请添加图片描述

但是在数据传输过程中是不支持java实体类进行传输的,所以为了达成网络传输,需要对传输的参数等实现序列化和反序列化

请添加图片描述

为了简化消费者发请求的代码,实现类似本地调用的体验。可以基于代理模式,为消费者要调用的接口生成一个代理对象,由代理对象完成请求和响应的过程。所谓代理,就是有人帮你做一些事情,不用自己操心。
至此,一个最简易的 RPC 框架架构图诞生了,下图中的虚线部分:

请添加图片描述

整个简单的调用过程客以参考下图

请添加图片描述

拓展设计

虽然上述设计已经跑通了基本调用流程,但离一个完备的 RPC 框架还有很大的差距,让我们带着问题来进一步完善一下架构设计。

1、服务注册发现
问题 1:消费者如何知道提供者的调用地址呢?

继续我们上述的第一个例子,社区中有人会修理水龙头,那么要想让他帮你来修,你们双方得知道双方的地址,而这个地址,是不是由物业进行保管。因此,我们需要一个 注册中心,来保存服务提供者的地址。消费者要调用服务时,只需从注册中心获取对应服务的提供者地址即可。

架构图如下:

请添加图片描述

主流的注册中心组件:Redis、Zookeeper、Consul、Etcd。Dubbo采用的是ZooKeeper提供服务注册与发现功能。

2、负载均衡
问题 2:如果有多个服务提供者,消费者应该调用哪个服务提供者呢?

我们可以给服务调用方增加负载均衝能力,通过指定不同的算法来决定调用哪一个服务提供者,比如轮询、随机、根据性能动态调用等,在高并发的场景下,需要多个节点或集群来提升整体吞吐能力。。
架构图如下:

请添加图片描述

3、容错机制
问题 3:如果服务调用失败,应该如何处理呢?

为了保证分布式系统的高可用,我们通常会给服务的调用增加一定的容错机制,比如失败重试、降级调用其他接口等等。
架构图如下:

请添加图片描述

4、其他

除了上面几个经典设计外,如果想要做一个优秀的 RPC 框架,还要考虑很多问题。

比如:

  • 服务提供者下线了怎么办?需要一个失效节点剔除机制。
  • 服务消费者每次都从注册中心拉取信息,性能会不会很差?可以使用缓存来优化性能。
  • 如何优化 RPC 框架的传输通讯性能?比如选择合适的网络框架、自定义协议头、节约传输体积等
  • 如何让整个框架更利于扩展?比如使用 Java 的 SPI 机制、配置化等等。

所以,完成 RPC 项目并不难,但做一个完美的 RPC 项目却是难于上青天啊!

总结一下,我们可以通过做一个 RPC 项目学习到网络、序列化、代理、服务注册发现、负载均衡、容错、可扩展设计等知识,相信完成后会收获满满。