不同RPC框架的服务端和客户端能相互通信使用吗？
当然可以，各种RPC框架的底层基本上都是对Java NIO 的 SocketChannel、ServerSocketChannel的封装，更直白地说，是针对网络Socket编程，端到端的通信模型基于OSI模型，或者TCP/IP协议簇。
在 Java NIO 主流的开源框架中，属Netty与Apache Ｍina比较出名，如果服务端是基于Mina开发的，那客户端使用Netty开发，这是完全可行的。
服务端、客户端能相互通信，其实最重要的是服务端与客户端约定好一个数据包的格式，这就是所谓的通信协议。
举一个通俗的例子，寄快递，发件人需要将快递先包裹起来，然后填写收件人信息，寄件人信息，至于传输过程是空运，还是汽运，船运，收件人无需强制，你用何种方式传输我不管，你只有遵循填写我们的约定（填收件人信息，寄件人信息）
这里的收件人信息，寄件人信息，我们就可以理解为协议。
回到计算机网络传输，是基于二进制流实现的，发送方需要将数据先转化成二进制流，而接受端需要从二进制流中识别出一个完整的请求，即一个请求从什么地方开始，什么地方结束。
所谓的通信协议就是通信双方共同遵循的一种“约定”，用于通信发送方将内容按照“通信协议”所规定的格式组装成“二进制流”，通信接收方按照“通信协议”所规定的格式正确的从二进制流中解码出一个个原始请求。
那通信协议如何设计呢？
在网络编程中，流行着一种经典的协议设计方法论：协议头 + 消息体。(图1)
其设计的关键点如下：
1、协议头的长度是固定的，通常为识别出一个业务的最小长度。
协议头中会包含一个长度字段，用来标识一个完整包的长度，用来表示长度字段的字节位数直接决定了一个包的最大长度，长度字段通常被设计为4个字节。
2、消息体中存储业务数据，例如如果是一个Dubbo协议，那消息体中可能会包含请求参数、调用的服务名等，而且字符串类的存储通常会采取字段长度、字段内容的组织方式。
为了有一个更直观的展示，我以一个简单的RPC通信场景为例，实现类似Dubbo服务的远程服务调用，其通信协议可以简单设置成下图所示：（图2）
基于 Header + Boby 的通信协议设计模式后，通信接收方就能很好的从二进制流中非常容易地解码出一条一条原始的请求数据包，解码的基本套路如下(在面试中面试官非常喜欢问的“粘包”问题的破解之道)
1、首先判断累积缓存区中是否存在一个完整的Head头部，例如上述示例中，一个包的Header的长度为6个字节，那首先判断累积缓存中可读字节数是否大于等于6，如果不足6个字节，跳过本次处理，等待更多数据到达累积缓存区。
2、尝试将头部6个字节读取，并且提取长度字段中存储的数值，即包长度，然后判断累积缓存区中可读字节数大于等于整个包的长度，如果累积缓存区不包含一个完整的数据包，则跳过本次处理，等待更多数据到达累积缓存区。
3、如果包含一个完整的包，则按照通信协议的格式按序读取相关的内容。
至于上面的实现过程是使用Netty还是Mina都可以。
如果觉得不错，希望大家点赞表示支持，您的点赞与转发是对我最大的鼓励。
晚上把编写了一个适用于STM32处理器+W5500框架的简单的MQTT客户端。
因为，整个TCP/IP通信的代码已经实现。
基于此增加MQTT协议的支持并不复杂，因为控制器只需要连接MQTT服务器、定时上报传感器数据并保护心跳。
因此，只需要与服务器建立TCP连接，并在该连接上将几个命令的数据封包发送给服务器。
在调试时，安装了apache-apollo的MQTT broker以及MQTTX客户端软件。
用该客户端和broker建立连接并发布某些topic的消息，采用wireshark抓包，对照抓包数据对处理器的MQTT消息封包。
只花了很短时间就完成了MQTT客户端的调试。
