开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀
1、前言
隨著云IM的發展，已吸引越來越多有IM需求的APP接入。但考慮到云IM無論從商業模式還是運營模式上，還需經過多年的沉淀，才可能真正實現客戶與服務商的運營和服務良性循環的雙贏局面。在此之前，加上有些場景下（比如為了信息安全而不允許接入第3方云IM的應用、IM作為公司核心技術發展而不考慮用云的情況等）也確實不適合采用云IM，所以目前開發完全自主IM的需求和動力依然很旺盛。
但要想做好全功能、全平臺的IM，沒一定的技術積累，顯然是很難駕馭的了。正如TeamTalk的服務端設計者所說“IM的開發，從功能抽象的角度看可能非常簡單，可以認為是管理大量的客戶端連接和在不同的客戶端之間傳遞消息，但具體到實現細節就比較復雜了。打個不恰當的比喻，OS的功能抽象也非常簡單，無非是進程間的調度和硬件資源的管理，但要是自己去實現一個，一般人也就只能呵呵了”。
有鑒于此，很多團隊開發自主IM時，都會首先想到在開源IM的基礎上修改后，作為已用。但話雖如此，靠譜的支持全平臺的開源IM，少之又少，這其中，蘑菇街開源的TeamTalk勉強算是一個。但正如國內大多數的開源工程一樣，對已無利的事，很少會有人真心堅持的下去。
本文將簡要介紹TeamTalk開源的過去和現在，為打算研究和采用TeamTalk的同行提供一定程度的參考。文中所涉及內容如有不妥，還請各位看官見諒。
(本文同步發布于：http://www.52im.net/thread-447-1-1.html)
2、即時通訊技術交流
- 即時通訊開發交流群：215891622[推薦]
- 更多即時通訊技術資料：http://www.52im.net/forum.php?mod=collection&op=all
3、TeamTalk相關資源
官方網站：http://mogu.io/
官方Blog：http://tt.mogu.io/
曾今的管理者的Blog：http://www.bluefoxah.org/
Github地址1：https://github.com/mogujie/TeamTalk（2015年5月后）
Github地址2：https://github.com/mogutt（2015年5月前）
4、版權糾紛：源碼存在版權糾紛，使用有風險
4.1 到底發生了什么？
源碼被Github下架后TeamTalk的網站給出的申明，截圖如下：
4.2 來自官方的訪談和回應
作為蘑菇街官方對TeamTalk源碼與網易泡泡版權糾紛的回應,以下是對蘑菇街研發部架構師月明的訪談全文，現摘錄如下：
2014年10月底，蘑菇街開源了其內部即時通訊軟件TeamTalk，TeamTalk是一款企業辦公即時通訊軟件，目前支持所有的主流平臺。正當開發者大贊蘑菇街的開源舉措時，TeamTalk于11月4日晚被GitHub下架，原因是TeamTalk牽涉網易POPO版權。這一系列事件不禁讓我們想到開源的底線還應該是尊重，目前具體情況還在調查中。本次訪談了蘑菇街的研發部架構師月明，以深入剖析TeamTalk背后的細節。
Q：請先介紹一下TeamTalk這款產品以及蘑菇街開源TeamTalk的初衷。
A：TeamTalk是一款企業辦公即時通訊軟件，由蘑菇街技術團隊幾位工程師利用業余時間開發完成。在開源之前，主要用于蘑菇街內部的在線溝通。蘑菇街在創業前期擁抱開源社區并使用了很多開源軟件，這些開源軟件幫助我們能夠在技術資源有限的情況下很好的支撐了公司業務的快速發展，在技術團隊發展壯大的過程中，我們逐步有一些的技術沉淀和積累，抱著感恩社區回饋開源的心態，我們希望能夠把一些優秀的軟件回饋給開源社區，不止TeamTalk，后續我們還會陸續推出服務化框架等更多的開源項目。
Q：請介紹一下TeamTalk的架構，這么一個支持多平臺的產品，開發需要投入很多人力吧？
A：TeamTalk的架構設計主要是參考借鑒了蘑菇街自身線上IM的架構，考慮到消息類業務應用的特性，設計上優先考慮安全性、可用性、可伸縮性。設計的定量指標是平均單機10W并發用戶以及千萬級并發在線。
從前往后看的話， 前端有支持多平臺的客戶端，包括Android、iPhone/Mac、Windows、Web，后端是負責登錄和負載均衡的LoginService，負責消息通信的MsgService，負責調度管理和集群擴展的RouterService，負責業務邏輯的BizService，負責存儲服務的StorageService，以及其他系統類服務（監控服務，配置服務，日志服務，文件傳輸服務）。 具體詳細的架構設計圖，大家可以通過我們的GitHub查看細節。
TeamTalk最早的代碼是從蘑菇街線上IM的一個分支拉出來的，現在主要是有5位工程師在貢獻代碼，他們大部分都是身兼多職的全棧式開發工程師，毫無疑問，現有的人員投入是遠遠不夠的，所以希望能有更多的人加入TeamTalk開源，一起開發和維護TeamTalk。
Q：在開發過程中，是否有借鑒其它IM軟件？相比來講，TeamTalk有何優點？還有哪些方面需要改善？
A：剛才已經提到在架構和代碼方面最大的借鑒是我們自己線上的IM，這個線上IM主要是服務于蘑菇街自己的商家和用戶之間的閉環交流，在產品體驗操作上，我們參考了QQ、微信等一些產品的做法，這也是讓用戶的操作習慣能夠保持一致。
同比其他IM軟件，個人覺得TeamTalk的優點主要有以下幾點：
開源：開源意味著免費和自定義開發，從客戶端端到后端，每一部分都開源，社區的力量能夠幫助它走得更快更好，也能夠幫助一些企業和開發者快速搭建自己的IM應用和服務。
跨平臺：多平臺客戶端支持，PC下的Windows和Web頁面，移動化方面的Android和iOS都能夠很好的支持，符合當前應用全端的趨勢。
高安全性：通過對協議和數據的抽象分層設計，支持自定義協議傳輸和數據包加解密處理，支持消息閱后即焚功能，支持數據自定義加解密存儲。
彈性伸縮：通過對后端服務的高度分層和應用功能單一化處理，隔離消息通信處理和消息業務處理，使得運維成本，硬件成本降到最低，保證彈性伸縮。
高可用行：通過LoginService的排隊機制和負載策略，MsgSerivce/BizService的多實例配置，RouterService的調度和集群管理避免單點，保證了系統的高可用性。
TeamTalk的不足還是很明顯的，存在以下幾點：
缺人：團隊在軟件開源管理方面經驗比較少，缺少社區開源這塊經驗豐富的運作人員，也缺少能夠貢獻代碼的開發者。
功能不夠完善：TeamTalk作為全新的IM開源軟件，目前只具備了語音、文本、表情、傳圖等基礎IM業務功能，功能還不夠強大，框架層面，我們也只是做了比較基礎的部分。
文檔和注釋不夠規范：之前開發得比較急，很多代碼的注釋不夠詳盡，文檔也比較粗糙。
Q：TeamTalk是如何保證消息的安全性以及可靠性的？
A：剛說到TeamTalk優點的時候也提到了安全性，我們通過對消息數據的在系統中6個生命周期：數據錄入、數據封包、數據傳輸、數據解包、數據存儲、數據展現進行了細致劃分，從協議和數據兩個維度出發做了高度抽象分層設計，采用了自定義協議和自定義數據封解包處理。
為了節省網絡流量，TeamTalk的協議是建立在TCP上的自定義二進制協議，TCP協議棧保證了數據的可靠傳輸。但是由于移動設備的網絡不是很穩定，經常會出現一些連接超時斷開的問題，我們對消息的傳輸又做了應用層方面的Ack機制，這樣當客戶端沒有收到服務器的Ack，會提醒用戶消息發送失敗。以后還會考慮加入send-wait這種機制來確保消息的可靠傳輸，即在發送下一條消息前，已經確保收到了前一條消息的Ack。同時考慮到有些內網只支持HTTP穿透，我們后繼會考慮支持HTTP長輪詢接入，蘑菇街線上的服務器已經支持這兩種模式。
Q：TeamTalk未來的發展計劃是什么？會增加哪些新功能？是否會搭建云IM服務器為大家所用？會推出付費服務么？
A：從長遠角度，我們的目標是希望TeamTalk能夠成為企業和開發者搭建自己IM的首選軟件，這個是理想。回到現實的話，半年之內，我們希望能夠完成以下幾個里程碑：
社區：有一個相對穩定活躍的社區，有一幫志同道合熱愛IM熱愛開源的小伙伴很重要。
文檔：GitHub上的文檔和注釋能夠相對規范完善。
服務：對外提供公有云服務，切實的幫助中小企業和開發者快速以最小時間最小人力成本搭建自己的全端IM服務。
對于TeamTalk的新功能，由于TeamTalk支持插件式功能開發，所以我認為在開源的背景下，這個不是第一要位的事情，我想每個開發者都會很想給自己的女神開發一個搖一搖插件，發揮大家的能動性就好。TeamTalk付費服務暫時不在我們考慮中。
Q：11月4日，TeamTalk相關的倉庫都已經被GitHub禁用，GitHub官方解釋是TeamTalk的架構、通訊協議以及部分代碼都有抄襲網易POPO之嫌。能解釋下這件事情么？目前準備怎么處理？
A：TeamTalk做出開源決定的初衷，是因為我們在創業初期也使用了很多優秀的開源軟件，所以想把一些優秀的軟件也回饋給開源社區。4號11點多我們突然發現被下架的情況，之后收到GitHub的下架通知，大家也非常重視，畢竟TT凝聚了工程師們的大量心血。但恰逢雙十一，而且這個雙十一是蘑菇街上線自己的電商交易平臺以來的第一個雙十一，我們主營業務的開發壓力非常大，為了盡快排查TT被下架的細節情況，澄清事實，解決問題，我們已經安排了專人在仔細地檢查代碼，并和GitHub以及POPO團隊進行積極的溝通。但從現在的情形看來，還需要多一點時間。
我們已經向GitHub提出了申訴，同時，如果排查的結果確實存在版權問題，我們會做出公開道歉并制定懲戒方案。
5、源碼割裂：混亂的源碼管理
5.1、2015年5月前的TeamTalk
筆者清楚的記得，TeamTalk開源之初的github托管地址是：https://github.com/mogutt，源碼和文檔都是很齊全的，比如下面的截圖：
文檔和說明還算齊全，你還能在Github上找到當初的fork版本，比如下面這個：https://github.com/lizj3624/https-github.com-mogutt-TTServer
5.2、2015年5月后的TeamTalk
現在的TeamTalk托管在Github上的地址是：https://github.com/mogujie/TeamTalk，大致翻了下，源碼和文檔跟當初https://github.com/mogutt相比，源碼先不說，至少文檔上來看，比原先要簡陋了很多：
5.3、此源碼可能已非彼源碼！
鑒于發布之初與網易泡泡的源碼存在很大的糾紛（說白了很可能是網易泡泡的離職人員直接使用了POPO的代碼），2015年5月后的源碼（就是現在的官方托管地址：https://github.com/mogujie/TeamTalk）可能已非當初的源碼，具體能不能用，還有多少借鑒價值，就不得而之了。
6、管理之爭：TeamTalk開源管理者的離去
原先的管理者“藍狐”于2015年7月31日發布的博文（地址是：http://www.bluefoxah.org/teamtalk/another_tt_roadmap.html）中稱：
自從離開蘑菇街之后，蘑菇街收回了我的github代碼提交權限，這讓我非常詫異，TeamTalk是一款開源的產品，為什么所有的控制權一定要把控在某個公司手里？我心里知道這是誰的主意，也可以想象出來當時的場景。不過后面還是冷靜下來思考良久。也許是他們擔心TeamTalk的“榮譽”被我給“占領”了。我想說的是，既然是開源產品，就該本著自由，開放，共享，貢獻，合作的精神來把TeamTalk發展起來，而不是在背后瞎BB。
雖然由于個人原因，離開了蘑菇街，但是一直關注著TT的發展，也一直努力去維護TT群的氛圍，期間也在提交代碼，但是卻不明白“官方”為什么要收回我提交，審核代碼的權限。
以上文字不多，但作為技術同行的你，應該能想見TeamTalk這背后的“人”和“事”了，各位自行猜測吧。
7、沒有未來：已1年無更新的TeamTalk談何未來
先不說現在的TeamTalk源碼（地址是：https://github.com/mogujie/TeamTalk）跟發布之初的代碼有多少淵源（當初涉及網易POPO的源碼去哪了？），官方的Github倉庫顯示至少已超過11個月無人去管了：
8、即時通訊開發資料分享
[1] 網絡編程基礎資料：
《TCP/IP詳解-第11章·UDP：用戶數據報協議》
《TCP/IP詳解-第17章·TCP：傳輸控制協議》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《計算機網絡通訊協議關系圖（中文珍藏版）》
《NAT詳解：基本原理、穿越技術(P2P打洞)、端口老化等》
《UDP中一個包的大小最大能多大？》
《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》
《NIO框架入門(三)：iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰》
《NIO框架入門(四)：Android與MINA2、Netty4的跨平臺UDP雙向通信實戰》
>>更多同類文章 ……
[2] 有關IM/推送的通信格式、協議的選擇：
《為什么QQ用的是UDP協議而不是TCP協議？》
《移動端即時通訊協議選擇：UDP還是TCP？》
《如何選擇即時通訊應用的數據傳輸格式》
《強列建議將Protobuf作為你的即時通訊應用數據傳輸格式》
《移動端IM開發需要面對的技術問題（含通信協議選擇）》
《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
《理論聯系實際：一套典型的IM通信協議設計詳解》
《58到家實時消息系統的協議設計等技術實踐分享》
>>更多同類文章 ……
[3] 有關IM/推送的心跳保活處理：
《Android進程保活詳解：一篇文章解決你的所有疑問》
《為何基于TCP協議的移動端IM仍然需要心跳保活機制？》
《微信團隊原創分享：Android版微信后臺保活實戰分享(進程保活篇)》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
>>更多同類文章 ……
[4] 有關WEB端即時通訊開發：
《新手入門貼：史上最全Web端即時通訊技術原理詳解》
《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》
《SSE技術詳解：一種全新的HTML5服務器推送事件技術》
《Comet技術詳解：基于HTTP長連接的Web端實時通信技術》
《WebSocket詳解（一）：初步認識WebSocket技術》
《socket.io實現消息推送的一點實踐及思路》
>>更多同類文章 ……
[5] 有關IM架構設計：
《淺談IM系統的架構設計》
《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
《一套原創分布式即時通訊(IM)系統理論架構方案》
《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》
《蘑菇街即時通訊/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產品的技術方法論》
>>更多同類文章 ……
[6] 有關IM安全的文章：
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（二）：探討組合加密算法在IM中的應用》
《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯系實際：一套典型的IM通信協議設計詳解（含安全層設計）》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
>>更多同類文章 ……
[7] 有關實時音視頻開發：
《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》
《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》
《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》
《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》
《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》
《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通訊音視頻開發（十七）：視頻編碼H.264、V8的前世今生》
《簡述開源實時音視頻技術WebRTC的優缺點》
《良心分享：WebRTC 零基礎開發者教程（中文）》
>>更多同類文章 ……
[8] IM開發綜合文章：
《移動端IM開發需要面對的技術問題》
《開發IM是自己設計協議用字節流好還是字符流好？》
《請問有人知道語音留言聊天的主流實現方式嗎？》
《IM系統中如何保證消息的可靠投遞（即QoS機制）》
《談談移動端 IM 開發中登錄請求的優化》
《完全自已開發的IM該如何設計“失敗重試”機制？》
《微信對網絡影響的技術試驗及分析（論文全文）》
《即時通訊系統的原理、技術和應用（技術論文）》
《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》
>>更多同類文章 ……
[9] 開源移動端IM技術框架資料：
《開源移動端IM技術框架MobileIMSDK：快速入門》
《開源移動端IM技術框架MobileIMSDK：常見問題解答》
《開源移動端IM技術框架MobileIMSDK：壓力測試報告》
>>更多同類文章 ……
[10] 有關推送技術的文章：
《iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《掃盲貼：認識MQTT通信協議》
《一個基于MQTT通信協議的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三種方案的優劣》
《移動端實時消息推送技術淺析》
《掃盲貼：淺談iOS和Android后臺實時消息推送的原理和區別》
《絕對干貨：基于Netty實現海量接入的推送服務技術要點》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《為何微信、QQ這樣的IM工具不使用GCM服務推送消息？》
>>更多同類文章 ……
[11] 更多即時通訊技術文章分類：
http://www.52im.net/forum.php?mod=collection&op=all
總結
以上是生活随笔為你收集整理的开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： css制作按钮按下去效果
- 下一篇： vue.config.js多页配置