本文链接：https://blog.csdn.net/m0_37482190/article/details/101225286

温馨提示：下述内容多为个人理解，如有错误请指正！感谢

什么是RPC？

RPC(Remote Procedure Call Protocol)远程过程调用：
- 我们有生产者服务器和消费者服务器，分别部署着不同的应用a、b。当我们想通过消费者服务器来调用生产者服务器的应用上提供的函数或方法时，由于这些应用不在同一个内存空间，不能够直接调用，这就需要通过借助网络来传输数据请求。就比如我们在自己的机器上写一个程序，别人是无法直接调用的，这个时候就需要通过远程服务调用，RPC应运而生了！
  微服务架构是一种将单应用程序作为一套小型服务开发的方法。（因此我们可以知道，一般的小型企业是用不到微服务的）
- 百科官方解答
  
  RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
  RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

RPC解决了什么问题？

偏技术的问题：
1.通讯问题 : 客户端和服务器端通过TCP协议进行数据的传输。
2.寻址问题：服务器之间的应用如何调用，如何查找到对应应用所在的IP和端口。

优点：
1.解耦：把每个系统拆分开部署在不同的服务器上。
2.避免重复开发：避免对一个系统的重复开发，当有需要的时候可以直接调用
3.方便维护

RPC具体工作流程是怎么样的？（纯个人理解，待大佬指正）

RPC需要有三方：生产者、消费者和中央管理中心。 生产者即服务提供方，消费者即服务请求方，中央管理中心（下面简称中央）是充当一个中间人的身份，可以理解为我们的房屋中介。
当生产者想要使用微服务的时候， 需要先去中央注册身份，包括IP、端口号、包括哪些类或方法等信息都需要提供给中央做记录；同时，中央会根据自己的加密规则，生成一个密钥来唯一标志该生产者。
同理，当消费者想要使用微服务的时候， 也需要先去中央注册身份，包括IP、端口号、想要访问的方法等信息都需要提供给中央做记录；同时中央根据消费者提供的信息会给消费者提供一定的权限，并根据权限来判断该消费者可以去调用哪些生产者，也会对应生成密钥。
当消费者完成注册后，通过拿到的权限，来获取对应生产者的IP、端口号和密钥等信息，并将这些信息存放在本地缓存。
当消费者发送请求时，消费者会从本地缓存读取有效数据信息，如携带着对应生产者的密钥，通过HTTP、TCP等协议进行数据传输（这里传输用到了流操作、序列化和反序列化技术，暂时不做讲解，可出门右拐进入百度），生产者接收到请求后，进行反射代理， 首先来比对密钥是否正确，正确则进行真正的请求处理工作。
到这里，一个正常简易的RPC流程算是走完了。

但是就怕意外啊，RPC还有一些保障性的工作

心跳机制： 为防止生产者服务器突发心脏病宕机，或者某天心情不好闹小情绪导致发生异常而无法使用，我们强制规定生产者需要每隔几秒（可根据具体业务自行设计）向中央发送一次心跳，来证明生产者一切健康。如果说生产者一次没有发送心跳，中央可以原谅它的小调皮，但是如果连续三次都未发送心跳，中央就会主动标记该生产者有异常，同步到消费者缓存中进行信息的更新，并对该生产者服务器进行普通生病检查，同时触发报警机制来提醒正在改bug的程序猿来为其医治。
同步机制： 当生产者服务器有新增服务器、生产者服务器减少或更换服务器的情况，中央会将生产者的信息同步到消费者缓存。
反馈与检查机制： 由于心跳机制和同步机制没有即时性，那么很多时候，生产者服务器发生问题，往往是消费者先发现，当消费者连接生产者时，一次连接不成功，尝试重连，多次连接不成功后，会从本地缓存寻找其他可用生产者服务器信息进行数据的请求，同时会把连接失败的生产者服务器信息反馈上报给中央，说明该生产者服务器偷懒不工作；中央收到反馈后，立刻去检查该生产者服务器的异常原因并尝试触发报警机制。

这样一个大体上的RPC思想算是出来了，文字不易理解，可参考下图：
在这里插入图片描述

RPC中有哪些方面可以提升性能优化？

1.缓存： 缓存技术有很多种，进程缓存有jdk自带的ConcurrentHashMap缓存、功能比较丰富的Ehcache缓存等；分布式缓存有Redis和Tair等。依据我们业务需要来选择合适的缓存可以很好的提升性能。

2.数据传输流的操作： Netty作为高性能的NIO通信框架，在很多RPC框架中都有它的身影。我们也采用它当做通信服务器。
3.序列化和反序列化：
百科介绍：

序列化
(Serialization)是将对象的状态信息转换为可以存储或传输的形式的过程。在序列化期间，对象将其当前状态写入到临时或持久性存储区。以后，可以通过从存储区中读取或反序列化对象的状态，重新创建该对象。

目前互联网公司广泛使用Protobuf、Thrift、Avro等成熟的序列化解决方案来搭建RPC框架，这些都是久经考验的解决方案。当然具体使用哪种序列化还是要结合我们的业务来开展的。
4.通讯协议： 不同的通讯协议的在不同的数据结构和不同数据量时的传输性能都有所不同，也要我们看实际情况来定。我有一个想法是设计一个仿Tomcat的通讯协议，或许可以在某方面提升性能，还没实现过。

推荐几篇不错的博客：

稍后会针对RPC实操一波Dubbo+Zookeeper搭建的博客，敬请关注！