Go微服务实践 - Rpc核心概念理解
概述
从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框架，其实只需要按以上流程实现就基本完成了。
其中：
- Call ID映射可以直接使用函数字符串，也可以使用整数ID，映射表一般就是一个哈希表。
- 序列化和反序列化可以自己写，也可以使用Protobuf或者FlatBuffers之类的。
- 网络传输库可以自己写socket，或者用asio,ZeroMQ,Netty之类。