im也去中心化？Startalk（星語）的去中心化設計之路

本文轉載自Startalk開發者，期待的搓搓小手，讓咱們來揭祕去中心化的im如何設計吧！！

Startalk目前全套代碼已全面開放至Github網站，地址：github.com/qunarcorp/q…

Startalk 官網地址：im.qunar.com/new/#/home

****************************************************************************************

本文的重點是Startalk的去中心化設計，然而和當前很火的區塊鏈並無什麼關聯。它的重點便是Startalk的架構演進史，也是IM系統發展的一個小縮影。

咱們會從如下這4個部份內容中瞭解Startalk去中心化主要解決的問題和方法:

• Startalk是什麼

• Startalk過去的設計

• Startalk的去中心化

• 有效案例

1、Startalk是什麼

Startalk是從2015年開始爲Qunar服務的自動化辦公軟件，到如今已經有4年多的時間了。最初的初創團隊只有4我的。

製做Startalk的初心是爲了解決當時咱們在用RTX時候遇到的不少性能和使用上的問題。並且在當時，RTX尚未移動版本。

4年說短也不短了。在這個過程當中，咱們人手一直沒能超過兩位數，然而通過這幾年的發展，咱們已經開始在知足於辦公自動化場景的基礎上，實現了商務客服場景，以及自行設計的客服轉接系統，固然，這部份內容因爲不是主要內容，會出如今之後的系列介紹中。

團隊從2017年後半年開始，工做重心逐步的轉向了開源、去中心化和智能機器人領域。

讀到這兒，可能不少讀者會說， 即時通訊咱們有微信了哈，已經很好用了，爲啥還要用其餘的，甚至要開發本身的im系統呢？

其實，微信是重社交的，咱們的辦公和商務場景並非那麼側重於社交。

咱們從如下兩個方面來闡述這個問題：

一、辦公

• 要給同事發送核心客戶名單，交易數據，身份證號，擔憂免費聊天工具不安全

你們知道，前陣子facebook剛出過安全事故，爲何會出現安全問題呢，固然並非說fb在安全領域作的不夠好，實際上他們的安全體系很健壯，比通常公司都要強大，

然而因爲他們(facebook)是一箇中心化的設計，所謂中心化的設計就是客戶使用業務提供商提供的客戶端登陸到提供商的後臺服務器，而後用戶的任何一個操做的數據都保存在他們公司的服務器上了

既然數據集中在一個點保存，那麼被攻克、被泄漏就並非什麼特別奇怪和偶然的事情。

• 出差沒有帶電腦，卻有一大堆流程亟待審批

每一個常常出差的人都清楚，若是OA只能在電腦上批，那將極大的影響辦公效率。集成到公網上？本身家的辦公系統放在公網貌似不是那麼的靠譜。

尤爲是再趕上某些多客戶端登陸，聊天記錄不能徹底同步的IM,將是一種災難。

• 公司內的提高生產效率的一些自定義應用沒法整合

如今咱們已經進入了移動互聯網時代，你們可能會發現，每新到一個公司就要裝一批app,這已是如今的通病了。反觀微信，它的集成能力很強，可是不多有公司會把企業辦公挪到微信上直接使用。

爲何呢？仍是安全性、隱私的問題。

二、 社交

• 微信是重社交的軟件，須要加好友才能夠繼續聊天。

由於微信是在廣域網上的，若是能隨便找到一個用戶就能夠聊天，那麼安全性，騷擾，都是問題。

因爲這些問題，當我須要馬上找到某個我不認識的人的時候，就會很麻煩。好比我如今須要聯繫某個部門的新來的團隊負責人，若是是微信的話，咱們須要加個好友才能夠；

若是用Startalk，只須要走到相應的組織結構的位置上，就能夠跟他進行溝通了，我不須要事先認識他，也不須要先跟他加個好友才能夠繼續。

與其同時的，不少人把工做和生活分得很開，微信就是平時生活上用的，若是裏頭有不少不是很熟悉的同事看本身的朋友圈，也是個挺奇怪的事情。

2、 Startalk過去的設計

不少人都以爲實現個IM很容易，其實有必定道理。作個能聊天的軟件很是簡單，不少前端用一下午時間就能coding出個徹底可用的聊天室來，作出這個並不複雜。

然而一個成熟的im系統是須要各類能力協同配合的，筆者十年前就在作全國排名前三的IM，當時我就認爲im的複雜性不亞於遊戲。如今看雖然十年時間過去了，結論仍舊適用。那麼因爲涉及的技術領域比較廣，標準化也就沒那麼容易，也就有了這篇文章和這個團隊。

 先來看看老版本的Startalk的架構圖:

• ejabberd經過用戶hash的方式來進行擴展
• 其餘部分的功能橫向擴展

客戶端有3種類型鏈接，分別是TCP、UDP、HTTPS。客戶端使用TCP鏈接保持雙工通訊。UDP主要用來搞音視頻。HTTPS執行一些狀態無關類操做。

最重要的一條鏈接來自於ejabberd，你們應該比較熟悉了，號稱單機負載100萬條鏈接沒啥問題哈。實際測試也確實是這樣，實測不須要怎麼調優就達到30～40萬在線仍是很輕鬆的。

而後咱們各類折騰，各類調優，發現和世界上其餘全部的系統同樣，該出問題還出問題。

接下來，咱們認爲咱們進入了一個怪圈，系統確實存在有這樣或者那樣的問題，然而咱們貌似是在爲了優化而優化，爲何呢？咱們來分享一下Startalk的業務數據:

Startalk日平均在線 6500人

	單人	羣內成員
消息數量	25萬	10萬
人數	6000	3000
平均	40	33

這裏只有Startalk某個時間點上的數據，僅供參考。Qunar商業版本數據涉及到商業數據的問題，就不能透露了，這裏咱們介紹下辦公版本，其中消息量不包括機器人的推送消息

看到圖以後咱們會發現兩個特色：

• 貌似天天有500我的不說話。。。
• 從使用頻率上來說呢，咱們跟微信基本是一個層次的，2017年微信的運營數據也是日人均40條消息

看完這個表格以後，你們也就明白了，因爲應用特性，咱們的IM不須要過多的考慮上億用戶在線的場景，目前的能力徹底足夠用了。

那怎麼辦呢？

3、Startalk的去中心化

在經歷了各類折騰發現根本用不上了以後，咱們參考了不少相似的app，發現你們多數都在往中心化的模式設計

而後仔細的思考了一陣以後，咱們發現其實去中心化是一條很是可行的路線。

在這裏，可能有些同窗認爲去中心化的目的是針對性能和容量的優化，其實去中心化的重點是安全性、易用性和可部署性，其次是根據現有客戶羣體，兼顧了性能和容量。

那麼咱們看看去中心化最關注的安全性是什麼呢？

若是您使用免費IM搞企業辦公，就像下面這個圖。。。

您的Idea，商業機密，客戶資源，團隊核心成員的聯繫方式以及組成， 都盡收眼底的展示給了您的潛在競爭對手。

在這裏，服務提供商多是無辜的，多是幫兇。正如上面所說，facebook本意並不但願信息外泄。可是他們不可能作到永遠不出安全問題。

那麼你們在使用各類門類的免費im作企業辦公的時候，這個問題是必需要考慮的。

看明白這個，你們也就明白了，爲何如今有幾個大型的移動互聯網公司都在搞本身的IM，不少公司寧肯養一個成本很高的團隊，也不會去用免費的版本。

看看新的架構圖：

在新架構中，之前的模塊被拆分，非狀態服務合併到了Public中，狀態服務進入了Domain中。Domain橫向擴展，相互之間隔離。

而後部署方式也跟着去中心化了：

圖很簡單，之前是你們連中央服務器；如今你們須要在本身家裏部署一套im服務。而後就能夠連本身家的機器了。

這樣一來呢，每一個節點都獨立運營了，數據也都只保存在節點中。一切都很美好，又回到了當前Startalk架構的基礎形態了。

客戶端上呢，因爲咱們的客戶端支持同時鏈接多個節點，用戶也不須要裝多個客戶端就能夠知足需求。

然而，這樣就引入了另一個話題：若是我企業比較大，我還想按部門、按照各轄區分公司爲單位進行去中心化部署，

這樣部門與部門之間數據確定是能夠不進行共享的哈，當我須要跨分公司跟其餘部門的人進行溝通，怎麼辦呢?

去中心化了之後的QTalk在節點間新增了一個Proxy作打通。打通的雙方都須要作一些配置纔可使得這個Proxy變得可用。

這樣一來的結果，domain間數據獨立。在proxy加持的狀況下，domain能夠與其餘domain進行互通。完全的解決了安全的問題

同時因爲每一個domain支持的人數並不會不少，還記得以前分享的表格吧，因此性能和容量上獲得了保證

4、有效案例

目前去哪兒網站、APP中的各類售前、客服，都是用Startalk的核心實現的。使用了最新的去中心化的設計和部署方式。效果見下圖：

• 某高校的校園管理系統

這裏爲了保護用戶隱私，隱去用戶的名稱。

這套系統有如下幾個特色：

• 學院間互相獨立，獨立部署

• 校園APP所有移植到IM上

• IM不只作app容器，也作統一登陸認證系統

• 用戶使用客戶端SDK作客戶端接入

以上是StarTalk的去中心化設計及部署理念。後續文章中還會繼續分享客服、智能AI機器人等相關內容，感謝各位的觀看，謝謝！

*****************************************************************************************

Startalk目前全套代碼已全面開放至Github網站，地址：github.com/qunarcorp/q…

Startalk 官網地址：im.qunar.com/new/#/home