開源IM工程「蘑菇街TeamTalk」的現狀：一場虎頭蛇尾的開源秀

時間 2019-11-09

標籤開源工程蘑菇 teamtalk 現狀一場虎頭蛇尾简体版

原文原文鏈接

一、前言

隨着雲IM的發展，已吸引愈來愈多有IM需求的APP接入。但考慮到雲IM不管從商業模式仍是運營模式上，還需通過多年的沉澱，纔可能真正實現客戶與服務商的運營和服務良性循環的共贏局面。在此以前，加上有些場景下（好比爲了信息安全而不容許接入第3方雲IM的應用、IM做爲公司核心技術發展而不考慮用雲的狀況等）也確實不適合採用雲IM，因此目前開發徹底自主IM的需求和動力依然很旺盛。

但要想作好全功能、全平臺的IM，沒必定的技術積累，顯然是很難駕馭的了。正如TeamTalk的服務端設計者所說「IM的開發，從功能抽象的角度看可能很是簡單，能夠認爲是管理大量的客戶端鏈接和在不一樣的客戶端之間傳遞消息，但具體到實現細節就比較複雜了。打個不恰當的比喻，OS的功能抽象也很是簡單，無非是進程間的調度和硬件資源的管理，但要是本身去實現一個，通常人也就只能呵呵了」。

有鑑於此，不少團隊開發自主IM時，都會首先想到在開源IM的基礎上修改後，做爲已用。但話雖如此，靠譜的支持全平臺的開源IM，少之又少，這其中，蘑菇街開源的TeamTalk勉強算是一個。但正如國內大多數的開源工程同樣，對已無利的事，不多會有人真心堅持的下去。

本文將簡要介紹TeamTalk開源的過去和如今，爲打算研究和採用TeamTalk的同行提供必定程度的參考。文中所涉及內容若有不妥，還請各位看官見諒。php

(本文同步發佈於：http://www.52im.net/thread-447-1-1.html)html

二、即時通信技術交流

- 即時通信開發交流羣： 215891622 [推薦]前端

- 更多即時通信技術資料：http://www.52im.net/forum.php?mod=collection&op=allandroid

三、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月前）git

四、版權糾紛：源碼存在版權糾紛，使用有風險

4.1 到底發生了什麼？

源碼被Github下架後TeamTalk的網站給出的申明，截圖以下：

github

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.一、2015年5月前的TeamTalk

筆者清楚的記得，TeamTalk開源之初的github託管地址是：https://github.com/mogutt，源碼和文檔都是很齊全的，好比下面的截圖：

文檔和說明還算齊全，你還能在Github上找到當初的fork版本，好比下面這個：https://github.com/lizj3624/https-github.com-mogutt-TTServer

5.二、2015年5月後的TeamTalk

如今的TeamTalk託管在Github上的地址是：https://github.com/mogujie/TeamTalk，大體翻了下，源碼和文檔跟當初https://github.com/mogutt相比，源碼先不說，至少文檔上來看，比原先要簡陋了不少：

5.三、此源碼可能已非彼源碼！

鑑於發佈之初與網易泡泡的源碼存在很大的糾紛（說白了極可能是網易泡泡的離職人員直接使用了POPO的代碼），2015年5月後的源碼（就是如今的官方託管地址：https://github.com/mogujie/TeamTalk）可能已非當初的源碼，具體能不能用，還有多少借鑑價值，就不得而之了。

六、管理之爭：TeamTalk開源管理者的離去

原先的管理者「藍狐」於2015年7月31日發佈的博文（地址是：http://www.bluefoxah.org/teamtalk/another_tt_roadmap.html）中稱：

自從離開蘑菇街以後，蘑菇街收回了個人github代碼提交權限，這讓我很是詫異，TeamTalk是一款開源的產品，爲何全部的控制權必定要把控在某個公司手裏？我內心知道這是誰的主意，也能夠想象出來當時的場景。不事後面仍是冷靜下來思考良久。也許是他們擔憂TeamTalk的「榮譽」被我給「佔領」了。我想說的是，既然是開源產品，就該本着自由，開放，共享，貢獻，合做的精神來把TeamTalk發展起來，而不是在背後瞎BB。

雖然因爲我的緣由，離開了蘑菇街，可是一直關注着TT的發展，也一直努力去維護TT羣的氛圍，期間也在提交代碼，可是卻不明白「官方」爲何要收回我提交，審覈代碼的權限。

以上文字很少，但做爲技術同行的你，應該能想見TeamTalk這背後的「人」和「事」了，各位自行猜想吧。