阿龙的学习笔记---RPC总结_阿龙框架-CSDN博客

本文链接：https://blog.csdn.net/weixin_39596127/article/details/114846684

RPC学习总结

实习项目中用到了gRPC和自研RPC，做一个总结吧。
参考：https://www.zhihu.com/question/25536695 里面2、3、4号回答都不错。
主要是先找了点通俗易懂大方向的知识了解一下~

番外

看到个这，感觉还挺有意思的，梳理了后台架构一步一步发展的趋势，SOA。

作者：得闲野鹤
链接：https://www.zhihu.com/question/25536695/answer/154614906
- 我们在做一个访问量不大的项目的时候,一台服务器部署一个应用+数据库也就够了.
- 那么访问量稍微大一点之后呢,为了解决用户反馈的卡，反应慢的情况，我们就上集群。架设nginx，部署多个服务，由nginx负责把请求转发到其他服务上，这样就解决了用户说的卡慢问题。
- 过了一段时间之后呢,我们发现数据库已经扛不住了，应用服务完好，数据库有时候宕机。那这个时候呢,我们就上数据库读写分离，再架设几台数据库服务器，做主从、做分库分表。然后数据库也不宕机了，服务又恢复了流畅。
- 又过了一段时间，公司事业增增日上，服务访问量越来越高，且大部分都是查询，吸取之前宕机且为了办证数据库的健壮性，我们这个时候又加上了缓存，把用户高频次访问的数据放到缓存里。
- 后来,项目功能越来越多,整个项目也愈发庞大,修改一个类就需要全盘上传，切换nginx重启，这样的发布流程越来越长，越来越繁杂。然后我们开始把模块拆分，用户信息分个项目，订单系统分一个项目。这样就达到了，用户模块代码修改的时候，只需要更新用户信息服务就好了。
- 但是还是需要切换顶层的nginx，把要重启的服务的流量切到可用服务上，这个时候我们就想到了RPC。那么RPC解决了什么呢? 所有的服务在启动的时候注册到一个注册机里面，然后顶层处理在接收到nginx的请求时，去注册机找一个可用的服务，并调用接口。这样子呢，在不加新功能的时候，顶层处理服务我们就不需要动了？那修改了用户信息项目的时候，我们只需要一个个更新用户信息项目的服务群就好了。

RPC概述

RPC是远程过程调用，就是要像调用本地的函数一样去调远程函数。
本地的调用我们大致知道流程，远程的调用需要哪些必备的条件和环节呢？
- Call ID映射：我们怎么告诉远程机器我们要调用Multiply，而不是Add或者FooBar呢？在本地调用中，函数体是直接通过函数指针来指定的，我们调用Multiply，编译器就自动帮我们调用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以，在RPC中，所有的函数都必须有自己的一个ID，这个ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，必须附上这个ID。
- 序列化和反序列化：客户端怎么把参数值传给远程的函数呢？在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（比如服务端用C++，客户端用Java或者Python）。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。
- 网络传输：远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也可以，而gRPC干脆就用了HTTP2。Java的Netty也属于这层的东西。

具体过程

大致过程如下：

// Client端 
//    int l_times_r = Call(ServerAddr, Multiply, lvalue, rvalue)
1. 将这个调用映射为Call ID。这里假设用最简单的字符串当Call ID的方法
2. 将Call ID，lvalue和rvalue序列化。可以直接将它们的值以二进制形式打包
3. 把2中得到的数据包发送给ServerAddr，这需要使用网络传输层
4. 等待服务器返回结果
5. 如果服务器调用成功，那么就将结果反序列化，并赋给l_times_r

// Server端
1. 在本地维护一个Call ID到函数指针的映射call_id_map，可以用std::map<std::string, std::function<>>
2. 等待请求
3. 得到一个请求后，将其数据包反序列化，得到Call ID
4. 通过在call_id_map中查找，得到相应的函数指针
5. 将lvalue和rvalue反序列化后，在本地调用Multiply函数，得到结果
6. 将结果序列化后通过网络返回给Client

优缺点

为啥子有了HTTP还要使用RPC呢？
- RPC在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标，RPC框架需提供一种透明调用机制，让使用者不必显式的区分本地调用和远程调用。
- 再者，效率上来说，RPC可以设计的效率更高，比起HTTP1.1请求报文体积更小。
- 负载均衡：RPC框架会有带分布式负载均衡的功能，HTTP服务需要额外配置分布式框架。
- RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。HTTP主要用于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用

gRPC： Google RPC

Google 开源了一个建立在 HTTP2.0 协议之上的通信框架直接取名为 gRPC，也就是 Google RPC，这时 HTTP 和 RPC 之间已经没有非常明显的界限了。所以在后文我们不再明确强调 RPC 和 HTTP 请求调用之间的细微区别了，直接统一称之为 RPC。
基于HTTP/2，protobuf来进行序列化，并且提供多语言支持。
优点：protobuf二进制消息，性能好/效率高（空间和时间效率都很不错），proto文件生成目标代码，简单易用
缺点：但GRPC尚未提供连接池，需要自行实现；尚未提供“服务发现”、“负载均衡”机制。

ProtoBuf

Protobuf是一种平台无关、语言无关、可扩展且轻便高效的序列化数据结构的协议，可以用于网络通信和数据存储。
Protobuf 的有如 XML，不过它更小、更快、也更简单。无需类似 XML 解析器的东西（因为 Protobuf 编译器会将 .proto 文件编译生成对应的数据访问类以对 Protobuf 数据进行序列化、反序列化操作）。
Protobuf 与 XML 相比也有不足之处。它功能简单，无法用来表示复杂的概念。