概述
从0研究一下Golang已经Golang的微服务生态体系,Golang的微服务首先要从Rpc开始,在升级到Grpc,详细介绍这些技术点都在解决什么技术问题。
Rpc
- Rpc (Remote Procedure Call) 远程过程调用,简单的理解是一个节点请求另一个节点提供的服务。
- 对应Rpc的是本地过程调用,函数调用时最常见的本地过程调用。
- 将本地过程调用变成远程过程调用会面临各种问题。
远程调用过程面临的问题?
1.Call ID映射。
我们怎么告诉远程机器我们要调用的函数ID呢?再本地调用中,函数体是直接通过指针来指定的,我们调用function,编译器就自动帮我们调用它相应的函数指针。
但是在远程调用中,函数指针是不行的,因为两个进程的地址空间是完全不一样的。所以,再RPC中,所有的函数都必须有自己的一个ID。这个ID在所有的进程中都是唯一确定的。客户端在做远程调用时,必须附上这个ID。然后还需要再客户端和服务端分别维护一个{函数 <–> Call ID}的对应表。两者的表不一定需要完全相同,但相同函数对应的Call ID必须相同。
当客户端需要进行远程调用时,它就查一下这个表,找出相应的Call ID,然后把它传给服务端,服务端也通过查表,来确定客户端需要调用的函数,然后执行相应的函数的代码。
2.序列化和反序列化
客户端怎么把参数值传给远程函数呢?在本地调用中,我们只需要把参数压到栈里,然后让函数自己去栈里读就行。但是在远程过程调用时,客户端跟服务端是不同的进程,不能通过内存来传递参数。甚至有时候客户端和服务端使用的不是同一种编程语言,这时候就需要客户端和服务端把参数先转成一个字节流,传给服务端后再把字节流转成自己能读懂的格式,这个过程叫做序列化和反序列化。
3.网络传输
远程调用往往用在网络上,客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输,因此就需要一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端,然后在把序列化后的调用结果返回客户端,只要能完成这两者的,都可以作为传输层使用。
因此,它所使用的协议其实是不限的,能完成传输就行。尽管大部分Rpc框架都使用Tcp协议,但其实Udp也可以,gRPC干脆使用了Http2。
Rpc框架需要解决哪些问题
Client端要解决的问题:
1.将这个调用映射为Call ID,这里假设用最简单的字符串当Call ID的方法
2.将Call ID a和b序列化,可以直接将他们的值以二进制形式打包
3.把2中得到的数据包发送给ServerAddr,这需要网络传输层
4.等待服务器返回结果
5.如果服务器调用成功,那么被结果反序列化,并献给total
Server端解决的问题:
1.在本地维护一个Call ID到函数指针的映射call_id_map,可以用dict完成
2.等待请求,包括多线程的并发处理能力
3.得到一个请求后,将其数据包反序列化,得到Call ID
4.通过在call_id_map中查找,得到相应的函数指针
5.将aherb反序列化后,本地调用add函数,得到结果
6.将结果序列化后通过网络返回给Client
在上面的整个流程中,估计有部分同学看到了熟悉的计算机网络的流程和web服务器的定义,所以要实现一个Rpc框架,其实只需要按以上流程实现就基本完成了。文章来源:https://www.toymoban.com/news/detail-632096.html
其中:文章来源地址https://www.toymoban.com/news/detail-632096.html
- Call ID映射可以直接使用函数字符串,也可以使用整数ID,映射表一般就是一个哈希表。
- 序列化和反序列化可以自己写,也可以使用Protobuf或者FlatBuffers之类的。
- 网络传输库可以自己写socket,或者用asio,ZeroMQ,Netty之类。
到了这里,关于Go微服务实践 - Rpc核心概念理解的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!