RPC概念：
RPC是远程过程调用协议，是一种不需要了解底层网络技术，调用远程计算机服务。
RPC框架的组成：
图1
当总项目的数据量、访问量不断提高，就把他分成多个服务，减轻单体机器的压力。分开的ABC服务之间要相互依赖，要数据，要数据的过程就是rpc。
如果使用常见的http协议，会带上很多不需要的数据，会降低传递数据的效率，我们只想要调用B服务的数据，因此，我们可以自定义一种传递格式。
RPC和http的区别？（面试）
1、RPC服务基于TCP/IP协议；HTTP服务基于HTTP协议。由于HTTP协议是位于TCP协议之上的，所以相比之下，RPC效率更高。
2、虽然RPC效率更高，但HTTP服务开发迭代会更快。
3、HTTP服务的缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，*灵活，更符合微服务理念。
RPC架构的演变
最开始的调用：
图2
在调用方直接把提供方写死，然后只能调用这一个提供方。
也就是说，如果提供方出现问题，那么调用方也就找不到调用数据了。
出现的问题就是：调用方不知道自己在调用什么
+注册中心：
图3
这样就可以灵活的去找提供方了。
服务方找注册中心注册，调用方发现注册的提供方，然后调用方就可以调用提供方了。
出现的问题：如果提供方太多了怎么办，如何选择提供方？
+路由层（负载均衡）：
图4
负载均衡可以把请求分布到多个提供方，以此提高系统的处理性能。
故障转移和负载均衡是解决服务器高可用性和性能问题的关键。
如果提供方A出现了问题，那么，就通过路由层调用提供方B，实现提供方的高可用性。
如果路由层出现问题了怎么办呢：
可以调用默认的提供方。
问题：请求中的数据应该怎么去表现呢，如何进行序列化和定义数据格式。
增加编码、序列化
图5
这样通过自己写的序列化和编码，可以使数据统一。
但是数据的调用肯定不是人人都能调用的，所以他还需要一个拦截器。这里使用token作为拦截器。调用方写一个token，提供方写一个token，双方的token一致就放行，不一致就不给过。
图6
但是像图6这种注册中心，负载均衡算法都是写好的，如果在开发过程中我想添加一个新的负载均衡算法或者注册中心，该怎么办呢？
图7
我们可以通过一个SPI来动态的加载注册中心，路由层，编码和拦截器，并且进行统一管理。像springboot的自动装配也是使用SPI。SPI像spring里的IOC的注入。
如果出现了问题，不能直接抛出异常吧，所以如果A挂了，那就调用其他服务，但是如果都挂了，就只能抛出异常了。
图8
这里出现异常之后，展示给调用方看，调用方根据情况，选择对应的容错机制，是故障转移还是忽略。
但是如果调用方发送多个数据，总不能全让提供方A接受了，然后让其他提供方同步等待，这样不行。可以弄一个线程池，接收之后调用合适的方法。
图9
这样可以提高程序的吞吐情况。
常见的RPC（Remote Procedure Call）框架包括：
- Spring Cloud。由Pivotal公司开源，支持Java语言，提供了一套构建分布式系统的开源框架。
- RMI。Java原生的RPC框架，限于Java语言，适用于Java跨版本或防火墙受限的环境。
- Dubbo。由阿里巴巴开发，适用于Java语言，是一款高性能、轻量级的RPC框架，适用于大规模分布式系统。
- Motan。微博内部使用的RPC框架，开源于2016年，仅支持Java语言。
- gRPC。由Google开发，支持多种语言，使用Protocol Buffers（protobuf）作为接口定义语言（IDL），基于HTTP/2协议。
- Tars。腾讯内部使用的RPC框架，开源于2017年，仅支持C++语言。
- gRPC over HTTP/2。Google开发的RPC框架，支持多种传输协议和负载均衡策略。
RPC架构能经久不衰的原因：
1、分布式系统的需求
随着时代的发展，单体无法满足业务需求，RPC作为一种重要的通信协议，能够满足分布式系统的需求
2、RPC相关技术的演进
3、多语言的支持
RPC框架支持多种语言，是不同语言编写的程序能进行跨语言远程调用
4、不同场景的需求
不同的应用场景对RPC架构提出了各种需求，如：高并发，低延迟，可拓展性，安全性等，RPC就可以根据需求进行针对性的优化和功能拓展。