聊天服務的設計隨想

聊天系統

Contents

• 聊天系統
  • 敘
  • 聊天的類型
  • 現有的幾個開源方案
  • Jabber/XMPP的弊端
  • 輕巧的MQTT
  • 架構設計實現

敘

對於互聯的多用戶在線遊戲，聊天是不可少的。

聊天的類型

這裏分類是按用戶的多少來分類。

單點類型

很簡單如Skype（QQ）那樣，你能夠和好友，一對一的在線聊天。

多點類型

如Skype，能夠自由組織羣聊。

現有的幾個開源方案

ejabberd

ejabberd(基於Jabber/XMPP協議的即時通信服務器)是Gameloft如今很是廢柴的聊天系統。從開源角度，ejabberd彷佛是一款不錯的聊天替代品。

優勢

1. 跨平臺，容錯，集羣和模塊化.
2. 容易拓展（輕鬆的50行用戶認證插件代碼就集成到現有平臺）。
3. 分佈式, 容錯, 並基於開放標準的實時通信系統.
4. 功能服豐富的XMPP服務器.
5. 同時適合小規模佈署和超大規模佈署, 不管它們是否須要可伸縮性.

缺點

1. 對於移動互聯網來講，Jabber/XMPP很是臃腫。（之前公司的分佈式聊天平臺中當羣聊到50人時就很是吃力了）
2. 部署麻煩。
3. 維護性差，維護難度大。

openfire

Openfire 採用Java開發，開源的實時協做（RTC）服務器基於XMPP（Jabber）協議。優勢是易用安裝使用，還提供WEB管理工具。

Jabber/XMPP的弊端

對於移動互聯網環境來講，XMPP是臃腫的，實踐中表現並不是盡人意，延遲，羣聊用戶支持的用戶很少。 從客戶端來說，更爲耗電，消息處理延遲，併發量不大。

輕巧的MQTT

MQTT（Message Queuing Telemetry Transport） 是IBM開發的一個即時通信協議。

優勢

1. 對移動端友好，省電，每秒請求量更爲客觀。
2. 協議輕巧，通訊的內容協議自由組織。

缺點

1. 現有的開源實現很少，須要花費些時間實現。

架構設計實現

HTTP協議

JOIN group

POST group/<group-name>/join

group-name:	這是須要加入聊天的組名
username:	用戶名
token:	用戶令牌

若是用戶成功加入，將會返回http狀態200及內容:

{
    "chat_host": 1234
    "port" : "",
    "name": "",
    "id" : ,
    "users" : {
        ""
    }

}

爲鏈接聊天室的域名和端口

若是加入失敗返回500狀態碼和內容:

Room full

CHAT MESSAGE Protocal

client向server發送的命令協議比較簡單，使用行指令。空格分隔，第一個單詞爲指令。

GET group datetime

group:	是訂閱組消息
datetime:	是用戶上次獲取消息的時間，若是超過服務的限制會返回過去五分鐘的消息。

獲得到回覆:

ok:1034\r\n
[{'msg': 'hello group' 'from' : 'user_id', datetime: '2014-08-11 12:12:123'， ...},
{'msg': 'hello group' 'from' : 'user_id3', datetime: '2014-08-11 12:12:123', ...},
...
]

協議頭行爲狀態和內容長度，以英文冒號分隔。

若是失敗,將返回錯誤信息文本:

error:100\r\n
Unknow error