撸码的人都应该知道，现代编程中最常用的系统之间通信方式是：http调用和rpc调用。对于同一个网络或者说是互通的网络环境中，rpc调用方式是系统间通信交互最常用的方式，比基于http协议的通信方式性能高出数倍甚至数个量级。我司的平台rpc通信，每秒在几万甚至更高，每次调用的通信时间在一定程度上几乎可以忽略不计，再加上我们首席架构师深厚的系统设计功力，采用进程内缓存等等优化措施，一次rpc调用的整体平均时间也在一毫秒之下。这是http协议无法达到的速度，如果你在浏览器的F12的窗口观察过，一个http协议调用如果整体花费的时间在5毫秒甚至10毫秒，那么其实就可以认为这个http请求响应时间是很短的了。

RPC调用虽然简化了撸码的难度，但是想要实现一套rpc框架，何止容易，一套优秀的rpc框架，更是难如登天。

多数rpc框架的服务端以service的方式来运行，为了避免和其他进程发生监听端口的冲突，一般会随机选择一个端口来进行监听。虽然这看上去很好，但是却给client端带来了麻烦，如果服务端监听固定端口，client连接服务端的时候，最少可以在代码中固定写死服务端的IP和端口。但是现在服务端监听的端口是随机的，而且更可怕的是服务器有可能会更换或者切换IP，那client怎么才能正确的去和服务端建立连接呢？

服务端之所以会采用这种随机方式来监听端口，其中很大一个原因是为了以后扩容。client如何正确的去连接服务器则采用了一个集中式的方案，服务端引入了一个服务注册中心的概念，有的系统可能会以别的名称来体现，但是作用是类似的。这个注册中心存储着所有的服务端信息，其中包括每个服务端的IP和端口，有的甚至还有版本信息，每个服务端进程启动的时候，都是采用主动连接注册中心，主动注册的方式。client端在发起连接服务的时候，首先去注册中心查找已经注册的服务端信息，然后进行连接。这样rpc调用在某种程度上在连接步骤就实现了“自动化”。

当client和服务端建立tcp连接之后（有的rpc框架会采用udp协议），下一个问题就是client和服务端怎么相认的问题了。举个栗子：客户端想要实现一个获取用户姓名的方法，方法名怎么定义才能让服务端正确识别出来呢？是传一个字符串“GetName”,还是传一个整数1来代表呢？服务端的返回结果，如果发生异常改如何返回呢？

当我们在本地调用一个函数，语法，语义，以及语法语义的分析，编译器已经帮我们做好了这些，但是rpc是远程过程调用，虽然表面上和本地类似，但是已经出现了跨网络的情况，语法语义等等这些分析需要client和服务端协商一致。

其实现代几乎大部分rpc通信都遵循一个标准：

当client发起一个远程调用的时候，它首先会先调用本地的Stub，它负责将调用的接口，函数以及参数按照约定好的协议格式进行编码，然后通过本地的Runtime进行传输，最后通过网卡将数据包发送到指定的服务器。

服务器Runtime接收到请求之后，会首先调用本地的Stub按照约定好的协议格式进行解码，最后调用服务端具体的函数。函数执行完毕，把结果利用本地的Stub编码之后通过runtime发送给客户端。客户端Runtime接收到消息利用本地Stub进行解码，然后进行其他处理。

由此可见，现代的rpc框架其实是把协议的封装和数据的发送分别抽象成了单独的层。Stub负责协议部分，Runtime处理数据发送以及网络相关部分。

数据通过网络传输过程中，每个数据包的完整性如何来识别，如果是一个简单int型数据很简单，但是如果是一个类或者一个数组，甚至是其他变长的类型，rpc的通信协议如何约束这些，如果能正确识别出来数据是协议部分最难处理的部分。更何况还有大头小头编码的问题。

凡是基于网络传输的形式，任何通信都是不可靠的，网络本质是不可靠的。包括网络抖动，错误等造成的丢包，粘包现象，如何正确的处理也是一个rpc通信中很重要的部分。一个rpc请求失败，是直接丢弃还是重试，这些策略都需要去规定。

1.一个rpc调用如果采用同步的方式，性能会大大打折扣，如何实现rpc的异步调用，这是一个rpc是否优秀的重要指标。

2.无论rpc的网络传输多么优秀，都会有性能损耗，能否把某些结果数据设置缓存？

3.无论是client还是服务端，处理请求的线程能否重用（线程池）？

4.能否支持多语言呢？