Thrift之TProtocol類體系原理及源碼詳細(xì)解析之其他協(xié)議類和總結(jié)

我的新浪微博：http://weibo.com/freshairbrucewoo。

歡迎大家相互交流，共同提高技術(shù)。

第六節(jié) 其他協(xié)議類

主要的協(xié)議類基本上已經(jīng)介紹完畢了，當(dāng)然如果你有更好的實(shí)現(xiàn)和思路也可以實(shí)現(xiàn)自己的協(xié)議類，只要按照我前面介紹的類層次結(jié)構(gòu)繼承就可以了。除了前面幾節(jié)介紹的協(xié)議類，Thrift還實(shí)現(xiàn)了一些自己內(nèi)部使用的協(xié)議類，例如TDebugProtocol類，采用開發(fā)人員可讀的文本協(xié)議，有助于調(diào)試，又例如TProtocolTap類，它可以使用兩種協(xié)議類進(jìn)行兩次協(xié)議轉(zhuǎn)換。放一個(gè)竊聽裝置在協(xié)議對象，任何讀取這個(gè)類都是通過一個(gè)封閉的協(xié)議對象的，但也反映為寫第二個(gè)協(xié)議對象，還有一個(gè)就是用于異常的協(xié)議類了。

到此為止，Thrift實(shí)現(xiàn)的協(xié)議類基本上介紹完畢了，從這些協(xié)議類的特征來看：

（1）都是實(shí)現(xiàn)了對外提供的統(tǒng)一接口，所以每一個(gè)協(xié)議類可以隨時(shí)的單獨(dú)使用，可以很方便的用一個(gè)協(xié)議類替換另一個(gè)協(xié)議類，對于實(shí)現(xiàn)都是完全獨(dú)立的，協(xié)議類直接沒有任何關(guān)系（繼承除外）；

（2）為了擴(kuò)展更多的協(xié)議類提供了良好的設(shè)計(jì)方式。

第七節(jié) 總結(jié)

(1)關(guān)于定義idl的一些總結(jié)，盡量避免定義過于復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。

從上面的協(xié)議分析來看，復(fù)合數(shù)據(jù)類型的存在著一個(gè)遞歸包含的關(guān)系。不過thrift在生成封/解包的代碼里，并沒有出現(xiàn)遞歸調(diào)用來封/解包,而是采用了循環(huán)嵌套循環(huán)的方式來生成代碼，這種做法避免了頻繁遞歸調(diào)用封/解包函數(shù)，可提高封/解包的效率。同時(shí)帶來的問題就是生成的代碼量的急劇膨脹。

雖然沒有遞歸調(diào)用來封/解包, 如果定義太過于復(fù)雜的數(shù)據(jù)結(jié)構(gòu)也會(huì)隨之產(chǎn)生多重循環(huán)，看下面的例子。假設(shè)定義以下一個(gè)數(shù)據(jù)結(jié)構(gòu)：

map< string, list< set<string> > >，thrift將會(huì)產(chǎn)生類似于以下的循環(huán)來進(jìn)行封/解包：

foreach (key in map)

{

foreach ( set in map[key] )

{

foreach (string in set )

encode()/decode();   

}

}

假設(shè)map,list,set的元素各有100個(gè)，這將是一個(gè)嚴(yán)重影響性能的地方，應(yīng)該避免。

(2)建議使用了unsigned long long的字段使用string類型，而不是u64類型，因?yàn)槟壳暗膖hrift不支持（不過好像最新版本是支持了的）。

(3)在網(wǎng)絡(luò)IO層一個(gè)潛在的瓶頸

由于thrift的binaryprotocol協(xié)議的包頭沒有任何的字節(jié)描述了整個(gè)網(wǎng)絡(luò)包的長度的信息。所以thrift的binaryprotocol協(xié)議在解包的時(shí)候是每次都只能采用從socket讀取一個(gè)變量的類型接著讀取變量的值出來這樣的解釋方式。

這種解包的方式可能引起的潛在問題：當(dāng)請求的client數(shù)量非常多，交互的數(shù)據(jù)量也非常多(這里可能是交互了很多字段，或者使用了太多復(fù)合數(shù)據(jù)類型)時(shí)，tcp/ip協(xié)議棧的緩沖區(qū)可能會(huì)被塞滿了還沒有被處理的數(shù)據(jù)，就會(huì)嚴(yán)重影響服務(wù)質(zhì)量。至于為何不提供某些字節(jié)來標(biāo)識整個(gè)數(shù)據(jù)包的長度，是因?yàn)閠hrift的binaryprotocol協(xié)議需要支持復(fù)雜數(shù)據(jù)類型，像set,list,map，而這些復(fù)合數(shù)據(jù)類型的大小是難以確定的。為了支持標(biāo)識整個(gè)數(shù)據(jù)包長度，封包前需要知道set,list,map的總體大小，那么就需要遍歷set,list,map的大小，這是相當(dāng)不劃算，會(huì)增加運(yùn)算邏輯，而且還會(huì)導(dǎo)致協(xié)議變得很復(fù)雜。

(4)如何做到兼容舊接口

當(dāng)我們的server更新接口的同時(shí)，還需要保證舊client能夠和新server交互，那么在定義IDL時(shí)就需要特別注意。假設(shè)，我們定義以下一個(gè)這個(gè)一個(gè)結(jié)構(gòu)體來交互用戶信息。

struct user

{

1:username string,

2:password string,

3:sex i16, 

}

當(dāng)我們需求變更時(shí)，假設(shè)以下兩種情況：

a)需要新增字段, age來表示年齡

struct user

{

1:username string,

2:password string,

3:sex i16, 

4:age i32,

}

注意，原來字段的序號標(biāo)識一定不能被改變，1:username string, 不能改成 5:username string。此時(shí)，如果server是新的，client是舊的，并不影響client的工作，client從server那邊收到的包里包含了age的信息，只是沒有decode出來而已。

b)刪除字段sex，新增字段age

struct user

{

1:username string,

2:password string,

//3:sex i16, 

4:age i32, (注意，為了保證a)所定義的client能夠和b)的server交互，這里的字段序號必須定義為4)

}

此時(shí)，如果server是新的，client是a)所生成的也并不影響和b)的server交互，因?yàn)閏lient從server那邊收到的包雖然沒有包含sex的信息，但是client并不會(huì)崩潰，只是缺少了sex的信息。因此，我們需求變更時(shí)，盡量保存舊的字段不要?jiǎng)h除，做到只增不減的方式來兼容舊接口。這里字段序號是唯一標(biāo)識字段的關(guān)鍵。