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、即時通訊開發資料分享

作者：Jack Jiang (點擊作者姓名進入Github)
出處：http://www.52im.net/space-uid-1.html
交流：

開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀

1、前言

2、即時通訊技術交流

3、TeamTalk相關資源

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

5、源碼割裂：混亂的源碼管理

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

7、沒有未來：已1年無更新的TeamTalk談何未來

8、即時通訊開發資料分享

ActionBar中，menu 一些細節！

NAT與NAT穿越學習總結

關於Java的File.separator

如何自動在Eclipse裏對指定類或接口生成要覆蓋的方法？

wireshark 實用過濾表達式（針對ip、協議、端口、長度和內容）

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結