@import url(http://m.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);
@import url(http://m.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);
如何選擇數(shù)據(jù)交換協(xié)議
選擇什么樣的協(xié)議跟我們的應(yīng)用場景有很大的關(guān)系。我們需要考慮我們開發(fā)是否方便、接口是否容易發(fā)布、是否需要考慮帶寬占用成本、序列化和反序列化的性能、接口協(xié)議的擴(kuò)展性等等。下面我們看下幾個(gè)比較常用的交換協(xié)議實(shí)現(xiàn)。
| 協(xié)議 |
實(shí)現(xiàn) |
跨語言 |
性能 |
傳輸量 |
RPC |
| xml |
廣泛 |
幾乎所有 |
低 |
很大 |
N（可實(shí)現(xiàn)） |
| json |
廣泛 |
大量 |
一般 |
一般 |
N（可實(shí)現(xiàn)） |
| php serialize |
PHPRPC |
大量 |
一般 |
一般 |
Y |
| hessian |
hessian |
大量 |
一般 |
小 |
Y |
| thrift |
thrift |
大量 |
高 |
小 |
Y |
| protobuf |
protobuf |
大量 |
高 |
小 |
N（可實(shí)現(xiàn)） |
| ice |
ice |
大量 |
高 |
小 |
Y |
| avro |
Apache Avro |
少量 |
高 |
小 |
Y |
| messagepack |
messagepack |
大量 |
高 |
小 |
Y |
上面表格列出了一些常用數(shù)據(jù)交換協(xié)議的一些特性的比較。這里并沒有比較好壞，只是想說明不同數(shù)據(jù)交換協(xié)議是有區(qū)別的，所以我們需要在我們的應(yīng)用場景中進(jìn)行選擇。
messagepack相關(guān)資料
http://pluto418.iteye.com/blog/1108457
優(yōu)勢：
1.序列化和反序列化所需要的時(shí)間少。通過30000條的記錄來測試，msgpack序列化的時(shí)間比使用jason來序列化JSON的時(shí)間要少三分之一；而反序列化的時(shí)間則要少一半。
2.生成的文件體積小。同樣也是基于30000條記錄來測試，msgpack序列化后生成的二進(jìn)制文件比用jason序列化出來的時(shí)間要少一半。
劣勢：
1.msgpack對復(fù)雜的數(shù)據(jù)類型（List、Map）支持的不夠，序列化沒有問題，但是反序列化回來就很麻煩，尤其是對于java開發(fā)人員。
2.在上面也提到過，msgpack是通過value的順序來定位屬性的，那么需要在不同的語言中都要維護(hù)同樣的模型以及模型中屬性的順序。這個(gè)會(huì)讓開發(fā)人員很困擾。
3.msgpack無法支持在模型中包含和嵌套其他自定義的模型（如weibo模型中包含comment的列表）。
@import url(http://m.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);