RPC的介绍和架构发展

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就可以根据需求进行针对性的优化和功能拓展。