Tars協(xié)議到底是指啥？
從Tars的這兩篇文檔的命名很具有迷惑性，看了半天不知道Tars和Tup啥關(guān)系？
其實就是tars賦予的內(nèi)容太多了導(dǎo)致的。
- 以.tars結(jié)尾的接口文件，里面的內(nèi)容用tars語言或語法來定義接口；
- 基于這個接口語言可以進行tars編碼；
- 網(wǎng)絡(luò)通信可以采用基于Tars協(xié)議的RPC通信。
做個類比就比較清楚了
- tars語言，定義了一些語法，類似于json，當(dāng)然和json不太一樣的是，tars語言既可以定義對象又可以定義方法。
- tars編碼，其實是對象序列化的方法，類似于fastjson對json文件進行序列化。
- tars協(xié)議，類似于http協(xié)議，也是Request/Response(請求響應(yīng))模型，定義了Request和Response消息的格式。
Tars協(xié)議和Tup協(xié)議又有什么區(qū)別？
tars通信協(xié)議有幾個版本，v1叫作tars，v3叫作tup，v2應(yīng)該廢棄不用了。
v1（tars協(xié)議），主要是用于服務(wù)間的接口調(diào)用，也就是rpc的主要協(xié)議。
v3（Tup協(xié)議），是用于其他客戶端訪問Tars服務(wù)
Response網(wǎng)絡(luò)包結(jié)構(gòu)
class TarsServantResponse1 {
0 int dataLength; // 整個數(shù)據(jù)包的長度，包含該字段 [4 Bytes]
1 short version; // 協(xié)議版本號 tag = 1 [2 Bytes]
2 byte packetType; // 包類型 tag = 2 [1 Bytes]
///////////////////////////////////////////////////
// version == 1，普通的Tars RPC調(diào)用
3 int requestId; // 請求id，未使用
4 int messageType; // 消息類型
5 int ret; // 返回值
6 byte[] result; // 結(jié)果值, Tars序列化后的byte數(shù)組，按照返回參數(shù)順序，組成對象。
7 Map<String, String> status;
8 String remark; // 若ret=0 成功才會填寫該字段
// version == 2 or version == 3， WupProxy調(diào)用
3 int messageType; // 消息類型
4 int ticketNum;
5 String servantName; // 服務(wù)名稱
6 String functionName; // 函數(shù)名稱
7 byte[] wupResult; // 結(jié)果值，Tars序列化后的byte數(shù)組
8 int timeout; // 超時時間
9 Map<String, String> context;
10 Map<String, String> status;
}
// 定義協(xié)議的版本號
const short TARSVERSION = 0x01; // tars協(xié)議
const short TARSVERSION = 0x01; // 老的tup協(xié)議，應(yīng)該已經(jīng)不用了
const short TUPVERSION = 0x03; // tup協(xié)議
Version 1的輸出參數(shù)結(jié)構(gòu)
/**
* 若functionName="tars_ping"，該結(jié)果字段為空
* 老的tup協(xié)議，應(yīng)該已經(jīng)不用了
* 直接對參數(shù)進行tars編碼，不包含參數(shù)的名稱和類型
*/
class TarsServantResponseResult {
0 Object paramter1;
1 Object paramter1;
}
Version 2的輸出參數(shù)結(jié)構(gòu)
/**
* TUPVERSION = 0x03; // tup協(xié)議
* 既包含類型名稱，也包含參數(shù)命名
* <ClassName, <ParameterName, ParameterValue>>
* 返回值作為一個參數(shù)加入進來，key 為 ""
*/
class TarsServantResponseWupResult {
0 HashMap<String, HashMap<String, byte[]>> _data;
}
Version 3的輸出參數(shù)結(jié)構(gòu)
/**
* TUPVERSION = 0x03; // tup協(xié)議
* 只包含參數(shù)名
* <ParameterName, ParameterValue>
* 返回值作為一個參數(shù)加入進來，key 為 ""
*/
class TarsServantResponseWupResult {
0 HashMap<String, byte[]> _newData
}
Request網(wǎng)絡(luò)包結(jié)構(gòu)
class TarsServantRequest1 {
int dataLength; // 整個數(shù)據(jù)包的長度，包含該字段 [4 Bytes]
1 short version; // 協(xié)議版本號 tag = 1 [2 Bytes]
2 byte packetType; // 包類型 tag = 2 [1 Bytes]
3 int messageType; // 消息類型
4 int ticketNum;
5 String servantName; // 服務(wù)名稱
6 String functionName; // 函數(shù)名稱
7 byte[] requestParams; // 請求參數(shù)的二進制編碼，Tars序列化后的byte數(shù)組
8 int timeout; // 超時時間
9 Map<String, String> context;
10 Map<String, String> status;
}
同樣當(dāng)version不同，參數(shù)序列化結(jié)構(gòu)不同，和Response類似
總結(jié)
從上面Tars和Tup的組包來看，最主要的區(qū)別是請求和返回參數(shù)的組包方式。Tars完全采用順序來區(qū)分參數(shù)，而Tup是通過參數(shù)名稱來區(qū)分參數(shù)的。
