把分布式当成微服务，把所有框架当成库，嗯，就这样，分布式中间件其实也是微服务的一个应用，微服务可以部署在单机，也可以多机器，分布式肯定是多机器。微服务是一种架构风格。

而开发微服务风格的系统，可以使用现成的微服务框架-嗯，框架也是一种库，就是写好的让你用的代码。

在我的脑子里，只有设计风格，和拿来主义用的代码库，没别的概念了。什么框架啦，分布式啦，统统木有。

比如ice 比如micro在我看来都是拿来就用的库。

通信协议 VS 数据传输协议：通信协议就是相互沟通的方式，比如http,rpc，zinx的通信协议，mysql也算通信协议，都是对通信方式的约定，数据传输协议就是json，xml,protobuf等等，指的是通信的数据部分的传输协议。

协议的本质就是约定，不论是对沟通方式的约定，还是数据格式的约定，都是约定。分清楚是对沟通方式的约定-通信协议，还是数据格式的约定-数据传输协议，就可以了。

实现协议的框架：比如，rest是协议，restful是实现，rpc是协议，grpc框架是其中干的一个实现。

经常的搭配是：http+json;http+protobuf;rpc+protobuf

上图我感觉画的不太好，命名框架实现了rpc协议，而框架可以使用protobuf数据格式。gRPC我觉得也是rpc的一种实现。

中间件的分类：事务处理中间件；MOM-（MQ/publish-subscribe）;分布式中间件-协议们.. 下层基础都为远程过程调用

RPC协议：会话层协议

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

协议结构

远程过程调用（RPC）信息协议由两个不同结构组成：调用信息和答复信息。信息流程如下所示：

RPC：远程过程调用流程

RPC 调用信息：每条远程过程调用信息包括以下无符号整数字段，以独立识别远程过程：

程序号（Program number）

程序版本号（Program version number）

过程号（Procedure number）

RPC 调用信息主体形式如下：

struct call_body {

unsigned int rpcvers;

unsigned int prog;

unsigned int vers;

unsigned int proc;

opaque_auth cred;

opaque_auth verf;

1 parameter

2 parameter . . . }；

RPC 答复信息：RPC 协议的答复信息的改变取决于网络服务器对调用信息是接收还是拒绝。答复信息请求包括区别以下情形的各种信息：

RPC 成功执行调用信息。.

RPC 的远程实现不是协议第二版，返回 RPC 支持的最低和最高版本号。

在远程系统中，远程程序不可用。

远程程序不支持被请求的版本号。返回远程程序所支持的最低和最高版本号。

请求的过程号不存在。通常是呼叫方协议或程序差错。

RPC答复信息形式如下：

enum reply_stat stat {MSG_ACCEPTED = 0, MSG_DENIED = 1 }