微服务核心理论 - 通信之RPC_使用rpc通信方式的-CSDN博客

内容项	RPC调用	本地调用
函数寻址	IP端口路由（NamingService+LoadBalancer）+函数路由	内存指针
传递数据	序列化后的数据流	内存对象
调用方异常处理	timeout、retry、curcuitbreaker	抛出Exception/函数返回固定异常标识的数据
被调用方异常处理	认证鉴权、过载保护	入参检查/执行异常捕获和处理
问题定位	分布式Trace、监控、日志中心	日志记录/断点调试跟踪
性能优化	连接池、多路复用、线程池、轻量级线程、non-blockIO等	编译器优化（inline等）

这里可以看出rpc比函数调用复杂的多，比如：

函数寻址：你怎样调到你想要的哪个函数？在本地调用中其实就是一个函数指针，但是在RPC场景下，你要找到这个函数其实非常复杂，一个服务一般有多个下游实例，首先要选择一个下游实例，一般这个是由NamingService+LB来实现，到达对应的实例后，服务端还要解析请求体，找到函数名，然后做函数路由。
数据传递：在本地调用过程中其实就是传递一个指针或者值，在RPC场景下其实是通过网络传递的，网络上需要传递一个内存对象序列化之后的一个二进制网络数据流，response回来的时候也需要经过一个反序列化的过程。
异常处理：本地调用的情况下，无非就是判断下这个函数的返回值或者有没有抛一些异常，但是在RPC场景下就很复杂，比如网络拥塞了，服务端处理慢了或者超时，还有很多异常的情况，所以我们要做很多系统容错的事情，比如：超时、重试等策略来解决这些问题。本地调用的时候我只需要检查参数是否合法，但是在RPC的场景下我们要做一些类似认证鉴权，过载保护等策略，避免流量过大将server打挂。
问题定位：本地调用方法很多，比如：断点调试，打本地日志。但是在RPC场景下，这些方法其实是行不通的，我们需要分布式tracing、监控和分布式日志中心来帮助我们定位问题。
性能优化：本地调用其实我们不用关心太多，因为编译器会帮我们做一些列的优化，但是在RPC的场景下，就需要我们自己优化通信效率，常用的优化手段比如：连接池、多路复用、线程池等等很多方法，这些方法实现起来都非常的复杂。现在大家应该能理解RPC场景是非常复杂的

正因为有如此的复杂性，所以我们需要一个RPC框架来处理这些复杂的事情，让RPC看起来就像本地调用一样简单。

2.6 RPC 框架调用流分析

2.6.1 RPC框架功能（简单版本）

实现的过程：

client初始化一个channel，监听NamingService，从服务名字中解析出来服务真正的上游实例地址
客户端将请求的的数据进行序列化
上游可能多个实例，需要LB去选择一个下游的IP+Port，选出来之后需要和上游实例建立连接和发送请求
建立连接之后发送请求
服务端接着接受连接和接受数据，收到数据之后将二进制数据反序列化为一个内存对象request
然后再调用server的响应方法进行处理
服务端通过sockets将消息发送到客户端；
客户端接收到结果消息，并进行解码（将结果消息反序列化）

2.6.2 RPC框架功能（复杂版本）

有些RPC框架不只是处理通信相关的工作（如数据的序列化和反序列化，协议的解析/打包，数据的压缩解压缩，数据的加密和解密），还可以做很多微服务治理的工作。

比如Dubbo支持对服务的治理，包括服务注册与发现、故障注入、超时重试、负载均衡、连接管理和健康检查等。除此之外，服务端还有认证鉴权、并发流量限制、函数路由、协议适配和参数校验等等复杂的策略。

所以一个成熟的RPC框架也可以是一个非常复杂全面的分布式系统，在一定程度上协助工程进行微服务建设。

2.7 主流RPC 框架对比

对比项	Dubbo	gRPC	brpc	Thrift
公司	Ali	Google	Baidu	FaceBook
通讯协议	tcp/http	http2	多种协议	tcp/http
序列化协议	可扩展	protobuf	protobuf/json/mcpack	可扩展
开发语言	Java	跨语言	C++/Java	跨语言
主要特点	服务治理、扩展性	跨语言、性能	高性能、扩展性	跨语言
githubstar	36.9K	33.5K	12.9K	8.9K