网上讲的不明不白的居多，我来试试，争取让做过后端开发项目的学生能看明白，基础再往下我就没办法了。
如果有大佬，可以帮我看看我理解的是不是有错。
最基本的 CS 框架先说一下是怎么交流业务的吧，不画图，画图麻烦，几句话的事情而已。
1、客户端把请求打个包，发给服务端。
2、服务端收到请求包，解包，判断业务类型。
3、根据业务类型，调用相应方法，有数据返回则返回，没有则结束。
4、若有数据返回，服务端再打个包，发回给客户端。
熟悉吧。
写个简单架构设计哈：
客户端 网络层 业务转发层 业务层 model层 持久层
这个难道不是RPC吗？有点迷
RPC，远程过程调用协议，Remote Procedure Call Protocol。网上有一部分人把 RPC 和 什么传入服务端类、函数名及参数，然后直接调用服务端方法扯在一起，以去掉上面的业务转发层。不晓得，云里雾里的，就看那一层业务转发层那么讨厌吗，曾经我也有点喜欢这种直接传函数名的方式，感觉真直接。但是去思考如何实现的时候有点想不明白。
来张 RPC 调用的图吧：
其实吧，把 ORM 和 RPC 放在一起理解我觉得会比较好一些，初学的时候，我们调用数据库，是在业务层面直接拿数据库句柄，传SQL语句进去，获取结果。
后来使用 ORM 框架，将数据库和业务层解耦，我们在业务层只需要将参数传入数据库映射层，由映射层去构造SQL语言，执数据库句柄，和数据库交互，如果有结果就把结果返回给业务层。
从此我们在业务层再也不用关心数据库选型、数据表、SQL语句等具体实现。
那 RPC 呢，我是不是可以这样理解。我们在业务层要向服务端发送请求包的时候，我们要拿着通信套接字，然后构造数据包，往里面 send。（别说数据包模块是分离出来的，分离出来了不要调用数据包模块接口吗？）当服务端返回结果时，又要拿着通信套接字，从里面 recv 数据包，然后分包，解包，获取数据。
这一切细节都要放在业务层，亲力亲为。如果是长连接还稍微好点，短链接像HTTP，我还交流一次连一次啊？
所以，我们就把和网络交流的这些流程都抽象到一个层，上面是写个 RPCruntime 哈，咱也叫它 model 层呗，网络映射层。
ORM 框架使得业务层调用数据库就像调用本地方法一样，RPC 则使得调用网络通信接口如同调用本地方法一样。
这样讲，明白吗？流程还是我们最开始的那个C/S流程，只是加了个网络通信映射层。
