1.多个物理分离的子系统，需要建立物理联系的方法：RPC，分布式消息队列，HTTP请求调用，数据库，分布式缓存。
（这里，我最常用的是，HTTP调用，就是调用接口。数据库，应该是两个项目调一个数据库，直接从源头解决数据问题。这俩分布式的，不是很理解）
2.nginx和后端服务之间也可以理解为RPC数据交互
（比如uwsgi，nginx代理uwsgi启动的项目 uwsgi协议就是走的二级制协议）
3.大数据里边，也是常用RPC。比如，hadhoop的文件系统，hdfs，一般包括一个namenode和多个datanode，namenode和datanode之间就是用hadhoop rpc的二进制协议进行通讯。
（这里有待后边学习）
4.tensorfiow cluster的RPC通讯框架使用了grpc，谷歌的
5.开源rpc协议中，最广的两个是 protobuf和thrift
6.没有在网络上进行分离，是运行在同一个操作系统实例上的两个进程，他们之间的通信手段更多：共享内存，信号量，文件系统，内核消息队列，管道，都是基于操作系统内核机制来进行数据和消息的交互
（一个都不了解）
7.套接字，socket。反应过来了，websocket。
（这个有待仔细了解一下)
8.消息分隔方式常用的有两种：特殊分隔符法和长度前缀发
（特殊分隔符发就是在每条消息末尾追加一个特殊的分隔符，比如 \r\n 。这种方式适合消息体是文本信息。因为二进制消息里好多 \r\n ，所以二进制的消息，会先进行base64编码，转成普通文字再发）
（长度前缀发悔在每条消息开头增加一个4字节长度的整数值，标记消息体的长度。这种的适合二进制的消息。http歇息的content-length头部信息用来标记消息体的长度，这个也可以看成是长度前缀发的一种应用）
（科普，http协议称之为超文本传输协议的原因：HTTP 协议是一种基于特殊分割符和长度前缀法的混合型协议。比如 HTTP 的消息头采用的是纯文本外加 \r\n 分割符，而消息体则是通过消息头中的 Content-Type 的值来决定长度。HTTP 协议虽然被称之为文本传输协议，但是也可以在消息体中传输二进制数据数据的，例如音视频图像）
以上的一些概念，后边还没有看完，先记录到这里。
简单写一下我对rpc服务器的理解，就是自己写一套协议，让数据更快的传输。有许多涉及到数据压缩的地方。原本的json格式，阅读起来很简单，但是太占空间了，一个引号都要占一行。所以，服务器端对客户端，可以用json这种格式。但是服务间，可以更快的调用数据。比如把参数转成二进制，然后快速的请求另外一个服务，另外一个服务就把参数再转成普通文本。这样，服务之间的调用速度就很快。
还有写了rpc的简单服务器代码后，大概理解怎么处理了。提供服务的，把服务1启动起来后，在代码里写好自己要启动的端口，程序启动后，就一直处于监听的状态。这个时候，有另外一个服务2的请求过来了，服务1会立刻响应服务2的请求，然后处理，然后服务二的收到了数据，就关闭这个链接，到此，一次请求到此结束。看起来和http请求没有问么不同。下边就是区别。
假如服务一写的是单线程的，而服务二一直不关闭这次请求，服务一就会一直处于被占用的状态，要是有个服务三想进来，就只能等着了，这就是阻塞。所以，单线程的肯定是不行的。这个时候，就要用到python的异步多进程编程了。
具体的异步多进程怎么写，就不放代码了。
再简单写一下，怎么把这个rpc放到业务中，用接口实现。（以下是个人的理解，有待验证。上边的都是socket，下边的就是websocket）
假设是一个服务1的接口1，然后服务二来请求了。假设接口1的代码是在一个视图函数里，这个时候，服务二开始请求这个接口，给一些参数。服务一是不是可以直接用if来弄，if服务二sock.sendall()了一个参数，服务一开始执行一串代码，然后给服务二sock.sendall()返回一个结果，然后服务二收到结果，再展示出来或者给别的请求方。然后服务二接着请求别的东西...... 直到服务二传了某个关闭的参数，这个时候，服务一关闭这次连接，服务二也关闭这次连接。
大概就是这么回事，还需要再研究一下
以上就是基本的rpc的原理，可以找找python有没有成熟的rpc框架，有的话，就可以直接拿来用了，不用自己纯手写了