Tars協(xié)議到底是指啥湃交？
從Tars的這兩篇文檔的命名很具有迷惑性，看了半天不知道Tars和Tup啥關(guān)系昏名？
其實(shí)就是tars賦予的內(nèi)容太多了導(dǎo)致的蝎土。
- 以.tars結(jié)尾的接口文件视哑，里面的內(nèi)容用tars語言或語法來定義接口；
- 基于這個接口語言可以進(jìn)行tars編碼誊涯；
- 網(wǎng)絡(luò)通信可以采用基于Tars協(xié)議的RPC通信挡毅。
做個類比就比較清楚了
- tars語言，定義了一些語法暴构，類似于json跪呈，當(dāng)然和json不太一樣的是段磨，tars語言既可以定義對象又可以定義方法。
- tars編碼耗绿，其實(shí)是對象序列化的方法苹支，類似于fastjson對json文件進(jìn)行序列化。
- 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ù)進(jìn)行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ù)加入進(jìn)來蟆盐，key 為 ""
*/
class TarsServantResponseWupResult {
0 HashMap<String, HashMap<String, byte[]>> _data;
}
Version 3的輸出參數(shù)結(jié)構(gòu)
/**
* TUPVERSION = 0x03; // tup協(xié)議
* 只包含參數(shù)名
* <ParameterName, ParameterValue>
* 返回值作為一個參數(shù)加入進(jìn)來承边，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ù)的二進(jìn)制編碼石挂，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ù)的。
