没有合适的资源?快使用搜索试试~ 我知道了~
首页微服务架构,RPC细节
微服务架构,RPC细节
需积分: 33 228 浏览量
更新于2023-05-21
评论
收藏 513KB DOCX 举报
什么是RPC调用? 像调用本地函数一样,调用一个远端服务。 为什么需要RPC框架? RPC框架用于屏蔽RPC调用过程中的序列化,网络传输等技术细节。让调用方只专注于调用,服务方只专注于实现调用。 什么是序列化?为什么需要序列化? 把对象转化为连续二进制流的过程,叫做序列化。磁盘存储,缓存存储,网络传输只能操作于二进制流,所以必须序列化。 同步RPC-client的核心组件是什么? 同步RPC-client的核心组件是序列化组件、连接池组件。它通过连接池来实现负载均衡与故障转移,通过阻塞的收发来实现超时处理。 异步RPC-client的核心组件是什么? 异步RPC-client的核心组件是序列化组件、连接池组件、收发队列、收发线程、上下文管理器、超时管理器。它通过“请求id”来关联请求包-响应包-回调函数,用上下文管理器来管理上下文,用超时管理器中的timer触发超时回调,推进业务流程的超时处理。
资源详情
资源评论
资源推荐

服务化有什么好处?
服务化的一个好处就是,不限定服务的提供方使用什么技术选型,能够实现 大公司跨团队的技术解耦 ,如
下图所示:
服务 A:欧洲团队维护,技术背景是 Java
服务 B:美洲团队维护,用 C++实现
服务 C:中国团队维护,技术栈是 go
服务的上游调用方,按照接口、协议即可完成对远端服务的调用。
但实际上,大部分互联网公司,研发团队规模有限,大都使用同一套技术体系来实现服务:
这样的话,如果没有统一的服务框架,各个团队的服务提供方就需要各自实现一套 序列化、反序列化、网
络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动,造成整体的低效。
因此,统一服务框架把上述“业务之外”的工作统一实现,是服务化首要解决的问题。
什么是 RPC?
Remote Procedure Call Protocol ,远程过程调用。
什么是“远程”,为什么“远”?
先来看下什么是“近”,即“本地函数调用”。
当我们写下:
int result = Add(1, 2);
这行代码的时候,到底发生了什么?

传递两个入参
调用了本地代码段中的函数,执行运算逻辑
返回一个出参
这三个动作,都发生在同一个进程空间里,这是本地函数调用。
那有没有办法,调用一个跨进程的函数呢?
典型的,这个进程部署在另一台服务器上。
最容易想到的,两个进程约定一个协议格式,使用 Socket 通信,来传输:
入参
调用哪个函数
出参
如果能够实现,那这就是“远程”过程调用。
Socket 通信只能传递连续的字节流,如何将入参、函数都放到连续的字节流里呢?
假设,设计一个 11 字节的请求报文:
前 3 个字节填入函数名“add”
中间 4 个字节填入第一个参数“1”
末尾 4 个字节填入第二个参数“2”
同理,可以设计一个 4 字节响应报文:

4 个字节填入处理结果“3”
调用方的代码可能变为:
request = MakePacket(“add”, 1, 2);
SendRequest_ToService_B(request);
response = RecieveRespnse_FromService_B();
int result = unMakePacket(respnse);
这 4 个步骤是:
(1)将传入参数变为字节流;
(2)将字节流发给服务 B;
(3)从服务 B 接受返回字节流;
(4)将返回字节流变为传出参数;
服务方的代码可能变为:
request = RecieveRequest();
args/function = unMakePacket(request);
result = Add(1, 2);
response = MakePacket(result);
SendResponse(response);
这个 5 个步骤也很好理解:
(1)服务端收到字节流;
(2)将字节流转为函数名与参数;
(3)本地调用函数得到结果;
(4)将结果转变为字节流;
(5)将字节流发送给调用方;
这个过程用一张图描述如下:
剩余12页未读,继续阅读



















安全验证
文档复制为VIP权益,开通VIP直接复制

评论0