Protocol协议篇设计思路

一、概述

协议即约定,最简单理解就是服务端按照什么样的规则来解析TCP通道传输来的二进制数据。

框架中协议提供了HTTP/HTTPS/MOJITO三种。其中HTTP/HTTPS准确来说其实就是一种,标准的HTTP协议。如果采用HTTP协议的话，不仅可以使用框架生成的Client同时也可以使用 市面上任何的HttpClient框架。

eg:

• OkHttp
• HttpClient
• Unirest

二、设计

框架中协议的接口类是 Protocol<R extends RpcProtocolHeader, V extends RpcProtocolHeader> 。

• 泛型 R 为请求数据模型
• 泛型 V 为响应数据模型

Protocol 是一个比较核心的类贯穿始终。因为核心的组件都放在了 Protocol 类中，这样的设计目的是为了让框架看起来简单。主要的思想借鉴与 Mybatis 中的 Configuration 所有的核心配置都放在其中，让人一看便懂,快速了解架构,进行二次开发。

1. 通道编码器

面向TCP编程,网络中数据都是二进制数据。客户端会将Java数据模型,按照一定的格式转换成二进制数据经过TCP协议传输给服务端。

2. 通道解码器

服务端根据约定的格式(可以理解这个约定就是协议),通过通道解码器将二进制数据重新转换成Java数据模型。

3. API交换器

框架底层是基于 Netty 进行开发, ExchangeChannelHandler 负责将 Netty 的 API 转换成框架 API ,目的是对原生 Netty 的网络通道 Channel 进行增强。同时降低学习成本。

4. 服务端处理器

服务端是对客户端传来的数据进行处理的, 这里是由开发者来编程的业务处理器。

5. 客户端处理器

通信的连接默认都是长连接，如何处理长连接中数据交互所对应的关系，主要就是在这里实现的,框架内置处理器。在发送数据时候会在本地保存一个发送的唯一码，服务端响应时候会告诉我们 对应的唯一码，从而完成异步通知。

长连接通道中会有很多数据包在其中传输,如果不给每个数据包一个唯一的标志，那么客户端在接受到服务端的响应时候就不知道对应的是那个发送请求。

解决办法: 给每个数据包加上唯一的标识头，当客户端收到服务端响应时候就知道是对应的那个请求了

这个标志头在框架中就是 RpcProtocolHeader。 其组成部分: 协议类型(byte) + 序列化类型(byte) + 请求类型(byte) + id(String)