吳 迪

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

0 引言

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

1 存在問(wèn)題

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

2 解決思路

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

3 解決方案

3.1 交互方式

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

圖1 消息列表

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

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

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

3.2 消息收發(fā)

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

表1 消息類型及字段含義

3.3 接口設(shè)計(jì)

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

表2 API接口參數(shù)

訪問(wèn)API接口的代碼示例如下[7]：

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

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

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

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

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

APP訪問(wèn)API接口和通訊接口獲取Token的時(shí)序圖如圖2所示.

圖2 APP獲取Token時(shí)序圖

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

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

4 結(jié)語(yǔ)

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

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