手动实现简易版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 项目学习到网络、序列化、代理、服务注册发现、负载均衡、容错、可扩展设计等知识，相信完成后会收获满满。
