目录
一、RPC的概念
二、使用分布式架构
三、进一步改进
四、最终框架
一、RPC的概念
RPC（Remote Procedure Call，远程过程调用）是一种通信机制，使得客户端能够像调用本地函数一样调用远程服务器上的函数。本质上是客户端需要完成一个任务，但无需在本地执行，而是将请求发送给服务器。服务器在接收到请求后，根据调用的方法和参数进行处理，并将结果返回给客户端。
在实际应用中，RPC 通过隐藏底层网络通信的复杂性，实现了这种透明的远程调用。它的工作流程包括：
- 请求发送与处理：客户端发送调用请求，服务器接收并解析请求，执行相应的任务。
- 序列化与反序列化：为了让数据能够在网络上传输，RPC 需要将方法名、参数等信息序列化为适合传输的格式（如 JSON、Protobuf），并在接收时反序列化为可处理的对象。
- 结果返回：服务器处理完任务后，将结果序列化为响应数据，并返回给客户端，客户端接收到后再进行反序列化处理。
RPC 的优势在于它能够让客户端远程调用的过程像调用本地函数一样自然，屏蔽了底层的网络传输和协议细节。有些异步 RPC 实现可能还涉及回调机制，但通常情况下，客户端直接等待服务器的返回结果即可。
二、使用分布式架构
然而上图的模型中，是⼀种客户端与服务端多对⼀或⼀对⼀的关系，一旦服务端掉线，则客户端无法进行远端调用，且其服务端的负载也会较⾼，因此在rpc实现中，我们不仅要实现其基本功能，还要再进一步，实现分布式架构的rpc。
分布式架构：简单理解就是由多个节点组成的⼀个系统，这些节点通常指的是服务器，将不同的业务或者同⼀个业务拆分分布在不同的节点上，通过协同工作解决高并发的问题，提高系统扩展性和可用性。
这里可以采用多加入一个注册中心，注册中心的职责是维护每个服务器的状态和提供的服务列表。注册中心对各个服务器所提供的功能进行注册，当用户使用某个功能时，注册中心可以根据注册发现找到该功能对应的服务器，从而建立服务端与客户端的链接。
三、进一步改进
而其次的发布订阅功能，则是依托于多个客户端围绕服务端进行消息的转发。不过单纯的消息转发功能，并不能满足于大部分场景的需要，因此会在其基础上实现基于主题订阅的转发。
四、最终框架
将上述功能合并，我们就可以得到项目的最终框架：
在这里解释一下上图的各个部分，其中左上方的RPCClient只需要订阅主题，当主题有新消息时就会收到消息，它们并不关心去哪个服务器找哪个操作；最下方的RPCClient负责使用发现订阅，找到负责的服务器地址然后完成rpc调用，随后会把结果发送给主题模块；主题模块通过发布订阅将消息发布给各个RPCClient。
在上图的结构中，我们甚⾄可以让每⼀个Server作为备用注册中⼼形成分布式架构，⼀旦⼀个注册中心下线，可以向备用中心进行注册以及请求，且在此基础上客⼾端在请求Rpc服务的时候，因为可以有多个rpc-provider可选，因此可以实现简单的负载均衡策略，且基于注册中⼼可以更简便实现发布订阅的功能。
