一種在線多人多事務(wù)即時通訊系統(tǒng)的設(shè)計與實現(xiàn)

吳 迪

(黎明職業(yè)大學(xué) 信息與電子工程學(xué)院，福建 泉州 362000)

0 引言

在移動互聯(lián)時代到來后，即時通訊軟件從PC端向移動端發(fā)展，現(xiàn)有常見的即時通訊APP有微信、QQ等.微信或QQ如果需要多人共同討論一個話題，一般需創(chuàng)建一個群組，如果要討論另一個話題，即同時要處理多項事務(wù)，即使這個新話題跟前一個話題存在邏輯上的聯(lián)系，也無法在用戶體驗中體現(xiàn)出二者之間的關(guān)聯(lián)，用戶不得不通過搜索查找在不同群組之間切換.本文介紹的方案是讓多人可以加入不同的群組，這里稱之為話題組，話題組之間具有密切的邏輯關(guān)系.系統(tǒng)架構(gòu)上采用話題組的邏輯關(guān)聯(lián)和通訊服務(wù)相分離的設(shè)計，從而滿足本方案的多人多事務(wù)的設(shè)計需求.

1 存在問題

即時通訊類APP如微信、QQ，可以很方便的將相關(guān)幾個人拉進(jìn)一個群組，就某個話題獨自進(jìn)行討論.如果要討論另一個相關(guān)話題，而群組成員需要做些調(diào)整，則不能在原有群組中討論，就得另外創(chuàng)建一個話題，再重新拉人進(jìn)去.如果有多個話題而成員不同，就需要重復(fù)創(chuàng)建多個群組，在管理上變得十分繁瑣，不易使用.

2 解決思路

本方案的設(shè)計不僅要解決上述問題，還要考慮到APP受手機屏幕尺寸較小的限制，從用戶體驗出發(fā)，考慮設(shè)計如何讓話題能按邏輯和時間合理的組織起來，適合手機端小屏幕展示[1].已知的設(shè)計方案為：討論消息展示包括主題的內(nèi)容界面中，將所有討論消息信息或討論消息的內(nèi)容進(jìn)行排序顯示，形成討論消息列表；或僅自動顯示用戶進(jìn)入該界面后創(chuàng)建的新討論消息信息或討論消息的內(nèi)容；或包括在多人即時聊天界面中，顯示最新的討論消息信息或討論消息的內(nèi)容；上述討論消息信息包括討論消息的內(nèi)容和討論消息相關(guān)信息，所述討論消息的相關(guān)信息包括討論消息的創(chuàng)建者、創(chuàng)建時間和回復(fù)的對象.該方案雖然可以通過主題找到討論消息，但是其討論消息不包含主題內(nèi)容，無法通過討論消息倒推出主題內(nèi)容，導(dǎo)致用戶難以直觀的從即時聊天界面上區(qū)分不同主題的討論消息內(nèi)容.另外，由于手機的屏幕尺寸較小，將包括主題的內(nèi)容界面中將所有討論消息信息或討論消息的內(nèi)容進(jìn)行排序顯示，形成討論消息列表，顯然不適合手機使用[2].

3 解決方案

3.1 交互方式

為了解決上述問題，設(shè)計了如下這樣一種交互方式：用戶在聊天界面中根據(jù)需求，插入話題消息，為了跟普通消息相區(qū)別，并能表達(dá)出話題的主要含義，把話題關(guān)鍵詞及表達(dá)話題的特殊字符串組合在一起，假設(shè)以#為表達(dá)話題的特殊字符，則話題消息的格式可舉例為：#今天上午開會#.服務(wù)器在接受約定格式的字符串后，進(jìn)行解析，生成一個新的話題，該話題包含主題、創(chuàng)建者等信息.用戶在點擊該特殊字符串時，會跳轉(zhuǎn)到所指向的話題.接下來在該話題中展開新的討論時，每次發(fā)表的信息都攜帶該話題關(guān)鍵詞，用于跟蹤和綁定話題[3].

圖1 消息列表

不同話題產(chǎn)生的消息都將放在消息提示頁面中，按產(chǎn)生的時間順序排序，在每條消息記錄上顯示所在話題名稱及最新一條消息內(nèi)容，如圖1所示.

由于要處理多事務(wù)的情況，當(dāng)話題較多時，需提供多種查詢功能，方便用戶使用：1.在消息列表上方提供話題搜索框，輸入話題關(guān)鍵詞，進(jìn)行查找.2.新增話題列表頁，列表中的話題按年、月、日分類排序顯示，同時還可進(jìn)一步分為“我參與的話題”、“我發(fā)起的話題”和“全部話題”.在話題顯示時，要加入權(quán)限控制，避免不必要的信息泄露.

在上述方案基礎(chǔ)上可以做進(jìn)一步擴(kuò)展和完善，如話題的發(fā)布、瀏覽、回復(fù)等操作均加入權(quán)限控制，來保護(hù)用戶的隱私，即由話題創(chuàng)建者來指定參與話題的成員，限定只能由某些特定成員才能查看和參與該話題的討論.其次，話題中同樣可以嵌入話題，話題的嵌套就構(gòu)成了一棵話題樹.用戶在主話題中可以看到討論的主線索，還可以在每個子話題中看到所展開的詳細(xì)信息，從而實現(xiàn)用戶對主話題和子話題的跟蹤.在處理比較復(fù)雜的事務(wù)時，相較以往的解決方案，可以比較輕松的實現(xiàn)事務(wù)跟蹤.

3.2 消息收發(fā)

消息的收發(fā)是一個獨立模塊，每個用戶在系統(tǒng)中都有一個唯一標(biāo)識的uid，由通訊服務(wù)器來對消息進(jìn)行中轉(zhuǎn)，由可靠的通信機制確保將消息發(fā)送給目標(biāo)用戶.在具體實現(xiàn)上有多種選擇，如果是iOS系統(tǒng)，可以將消息發(fā)到蘋果推送服務(wù)器(APNs)[4]，蘋果推送服務(wù)器會根據(jù) deviceToken 查找相應(yīng)的設(shè)備，并根據(jù)推送證書中的 BundleID 和 App 打包時使用的 Provisioning Profile 查找 App，從而確定唯一的設(shè)備上的唯一App，進(jìn)行消息推送.另外一個主流系統(tǒng)Android，由于 Android FCM(Firebase Cloud Messaging)在國內(nèi)不能使用[5]，所以 Android APP需要實現(xiàn)自己的消息服務(wù)，因此針對這部分的消息流量，要增設(shè)服務(wù)器來處理.消息類型根據(jù)通訊需求，預(yù)先設(shè)置幾種類型，消息字段的含義見表1.

表1 消息類型及字段含義

3.3 接口設(shè)計

本方案的軟件架構(gòu)的后端接口可分為API接口和通訊接口兩類.為防止用戶隨意訪問通訊接口，接口需要引入認(rèn)證機制.通訊接口的認(rèn)證方式設(shè)計為基于Token的認(rèn)證.Token認(rèn)證有許多優(yōu)勢：①可解決跨域取值問題；②避免利用cookie受到CSRF攻擊；③避免session占用服務(wù)器內(nèi)存空間；④符合RESTful規(guī)范[6].本方案設(shè)計為在用戶每次的請求中，HTTP Request Header都攜帶Token信息，實現(xiàn)無狀態(tài)HTTP請求.在訪問API接口時，需要提供必要參數(shù)，放在HTTP Request Header中，從返回結(jié)果中獲取所需Token，參數(shù)的名稱、類型和含義見表2.

表2 API接口參數(shù)

訪問API接口的代碼示例如下[7]：

srand((double)microtime()*1000000);// // 重置隨機數(shù)種子

$appSecret = 'Y1W2MeFwwwRxa0'; // 系統(tǒng)分配的App Secret

$nonce = rand(); //產(chǎn)生隨機數(shù)

$timestamp = time()*1000; //得到時間戳

$signature = sha1($appSecret.$nonce.$timestamp);// 得到數(shù)據(jù)簽名

APP訪問API接口和通訊接口獲取Token的時序圖如圖2所示.

圖2 APP獲取Token時序圖

在實現(xiàn)Token驗證的方式上，現(xiàn)在有一些規(guī)范的方法，方案中采用JWT，JWT的意思是：JSON Web Tokens[8]，包含三個部分的字符串：header,payload,signature，中間用∵分隔，再用Base64編碼.header 部分主要是兩部分內(nèi)容，一個是 Token 的類型，另一個是使用的算法，例如{ "typ":"JWT","alg":"HS256"}表示的意思是類型為JWT，算法是 HS256.用Base64編碼后轉(zhuǎn)換為：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.Payload 部分是 Token 的具體內(nèi)容，里面包含一些標(biāo)準(zhǔn)字段，也可以添加自定義字段.標(biāo)準(zhǔn)字段見表3.

表3 JWT Token標(biāo)準(zhǔn)字段

4 結(jié)語

本方案的設(shè)計思路跟現(xiàn)有的即時通訊APP有所不同，主要區(qū)別在于主話題中可嵌入子話題，多層嵌套形成一棵話題樹.每個子話題樹都有獨立的權(quán)限控制，可以保護(hù)話題內(nèi)用戶的隱私，每個子話題產(chǎn)生的共享資源也獨立于其他話題.話題內(nèi)的對話列表可保持邏輯上的延續(xù)性，在組成結(jié)構(gòu)上維持一個樹狀結(jié)構(gòu).用戶可通過瀏覽這棵樹，來對話題進(jìn)行跟蹤和追溯，在面對復(fù)雜事務(wù)時，有助于問題的分工解決.本方案設(shè)計了API接口和通訊服務(wù)接口，用于實現(xiàn)業(yè)務(wù)需求.通訊是基礎(chǔ)服務(wù)，針對目前主流的Android和iOS系統(tǒng)如何解決消息收發(fā)給出一個解決思路，并定義了不同消息類型的格式.雖然安全不是本方案要重點討論的方面，但對于一個完整的設(shè)計方案來說，也是一個不能忽視的問題，文中分析了如何使用JWT Token對通訊接口進(jìn)行保護(hù)的設(shè)計思路.

在帶來新的用戶體驗時，本設(shè)計方案中對象和資源之間的關(guān)系變得比較復(fù)雜，已經(jīng)超出了基于群組的簡單的通訊架構(gòu).隨著用戶數(shù)和請求量的不斷增加，對系統(tǒng)的響應(yīng)性能要求越來越高，需要不斷優(yōu)化底層架構(gòu).