聊聊t-io和netty的差異

引言

t-io和netty的差異，這是個被大量問及的問題，在此，作為t-io作者，列一些差異化的東西

t-io的最大優勢

API設計易懂，儘量避免引入自創概念——最大限度降低學習成本

接管了大量業務資源的繫結與自動解綁，開發人員只需要無腦地呼叫 API即可完成繫結與解綁功能，這個處理如果丟給業務開發人員是 極其複雜易錯的 ：

• 多執行緒環境下的集合管理都是要同步安全的，同步的設計既要安全又要高效

• 一是容易忘記釋放資源從而導致 OOM，二是容易忘記加鎖或是加了死鎖從而導致系統假死

• 其它同類框架為何以各種理由逃避實現這些功能？

1.        和業務掛鉤的都不好抽象

2.        會消耗框架效能

3.        複雜易錯

內建了豐富的易用的 API，開發人員一個方法就能搞定很多業務事情

提供了生產級別的 showcase示範工程

• 有經驗的開發人員稍事修改即可用在生產環境

• 沒經驗的開發人員可以當作入門的示範程式碼

文件集中在官網，使用者不需要到處學習無用的、錯誤的文件 ——進一步降低學習成本和試錯成本

netty的最大優勢

大量公有協議的實現

大量基於 netty的高層框架

其它對比

netty有大量公有協議的實現，t-io官方目前提供的僅有http和websocket

netty用到了零複製，這一點t-io在均衡再三之後，放棄了零複製，原因如下 :

• 零複製只是改善效能的手段（或叫演算法），對使用者而言，框架採用什麼演算法並不重要，重要的是最終的目的是否達成 —— netty用零複製來改善效能，t-io自創同步安全執行緒池來改善效能，都是手段，殊途同歸。

• 零複製在減少複製過程的同時，也消耗了計算機其它資源

• 堆外資源的管理勢必增加 t-io程式碼的複雜度，使t-io使用者難以在原始碼層駕馭t-io

• 部分同類框架引入堆外資源管理後，在某些場景的確是提升了效能，但這個過程也增加了很多嚴重 BUG

• t-io的效能已經足夠好，把精力花在服務業務上，而不是效能PK場上

t-io自創了同步執行緒池， 正是有了這個， t-io內部排程執行緒時就顯得尤為簡單，與netty的零複製一樣，這也是改善效能與簡化程式設計的手段，而不是最終目的。

t-io內建了業務資料管理能力 ， 這是個非常重要的能力，網路程式設計資料繫結和釋放是件極其考驗開發人員水平的功能，哪怕是經驗豐富的資深開發工程師也極容易死鎖和 OOM，甚至因此導致整個專案的失敗 。

• 舉例一：你做 im，你要做群組與群員關係對映吧？在t-io中，您只需要Tio.bindGroup()即可完成tcp連線和這個群組關係的繫結

• 舉例二：點對點訊息，你要針對使用者 id發訊息吧？在t-io中，您只需要Tio.bindUser()即可完成tcp連線和user的關係繫結

• 透過 Tio.bindXxx()繫結的業務資源，不用擔心TCP連線斷開後資源釋放不掉，t-io擁有嚴格的演算法保證這些資源得到快速有序地釋放（不得不提醒：釋放資源涉及到多執行緒操作，極易出錯）！

netty有大量書籍可供查閱；t-io提供了擁有即戰力的showcase工程（ 付費文件使用者可下載最新版 ），使用者並不需要太多時間即可完成可用於生產專案的網路程式設計腳手架

t-io和netty的程式設計模型和API差異極大

• t-io的API設計更多的是讓工程師用起來舒服，所以特意增加了一個Tio.java，專門放置常用的API，這樣使用者找起來就非常方便，不用滿大街找方法呼叫

• netty的部分API是把設計模式暴露出來了，讓內行人一看就知道這是個什麼設計模式做的

在效能測試上的差異

• 在 TFB平臺上，netty的效能遠超t-io，當然t-io的效能排名依然十分靠前，排在t-io後面的大有人在（t-io現在的效能比剛出來時的t-io差了很多，因為業務資料管理能力、阻塞傳送能力、同步傳送能力、流量監控與回撥，是比較消耗效能的），請參考：TFB效能PK平臺

• 帶上業務進行 PK時，t-io效能經常優於netty， 這其中的原因大概就是：用 netty需要自己寫程式碼完成業務資料的管理、流量監控等工作，而這些工作拖了裸netty的後腿，而這些工作已經被t-io內建了，所以給t-io帶來的效能損耗就很有限，請參考 netty和t-io對比測試結果

t-io提供了極其便捷的 阻塞傳送、同步傳送 ，這些能力在 netty中貌似沒有，需要使用者寫較多的程式碼才能實現

• 阻塞傳送： 訊息傳送到對方後，才往下執行程式碼

• 同步傳送： 對方收到訊息，並回了同樣的 synSeq訊息，才往下執行程式碼

易學程度： 從市場反饋來看， t-io設計的概念似乎更容易被工程師們所理解與接受，2014年老闆想讓我用netty，所以簡單地看過《netty權威指南》，這本書是我放棄netty的最後一根稻草，真的看不太懂，提供的示例我很難將其用在生產專案中（真實感受，當然也許是我太菜，我另一個非常優秀且年輕的同事也看過這本書，同樣表示雲裡霧裡）

不少使用者在抉擇時，覺得 t-io文件沒有netty多，轉而投netty，實際上，一個好框架，並不需要太多的文件，t-io在剛出來時，只有幾個showcase工程，第一批t-io使用者用這些showcase就完成了自己的專案，並且口碑迅速散開。現在t-io官方已經提供了相對完整的文件，再配上含金量十足的showcase工程，使用t-io已經很容易了

如果曾經使用過 netty或mina，再來使用t-io，也許你會感覺到前所未有的爽！

 

具體請參考：