一种在线多人多事务即时通讯系统的设计与实现

吴 迪

(黎明职业大学 信息与电子工程学院，福建 泉州 362000)

0 引言

在移动互联时代到来后，即时通讯软件从PC端向移动端发展，现有常见的即时通讯APP有微信、QQ等.微信或QQ如果需要多人共同讨论一个话题，一般需创建一个群组，如果要讨论另一个话题，即同时要处理多项事务，即使这个新话题跟前一个话题存在逻辑上的联系，也无法在用户体验中体现出二者之间的关联，用户不得不通过搜索查找在不同群组之间切换.本文介绍的方案是让多人可以加入不同的群组，这里称之为话题组，话题组之间具有密切的逻辑关系.系统架构上采用话题组的逻辑关联和通讯服务相分离的设计，从而满足本方案的多人多事务的设计需求.

1 存在问题

即时通讯类APP如微信、QQ，可以很方便的将相关几个人拉进一个群组，就某个话题独自进行讨论.如果要讨论另一个相关话题，而群组成员需要做些调整，则不能在原有群组中讨论，就得另外创建一个话题，再重新拉人进去.如果有多个话题而成员不同，就需要重复创建多个群组，在管理上变得十分繁琐，不易使用.

2 解决思路

本方案的设计不仅要解决上述问题，还要考虑到APP受手机屏幕尺寸较小的限制，从用户体验出发，考虑设计如何让话题能按逻辑和时间合理的组织起来，适合手机端小屏幕展示[1].已知的设计方案为：讨论消息展示包括主题的内容界面中，将所有讨论消息信息或讨论消息的内容进行排序显示，形成讨论消息列表；或仅自动显示用户进入该界面后创建的新讨论消息信息或讨论消息的内容；或包括在多人即时聊天界面中，显示最新的讨论消息信息或讨论消息的内容；上述讨论消息信息包括讨论消息的内容和讨论消息相关信息，所述讨论消息的相关信息包括讨论消息的创建者、创建时间和回复的对象.该方案虽然可以通过主题找到讨论消息，但是其讨论消息不包含主题内容，无法通过讨论消息倒推出主题内容，导致用户难以直观的从即时聊天界面上区分不同主题的讨论消息内容.另外，由于手机的屏幕尺寸较小，将包括主题的内容界面中将所有讨论消息信息或讨论消息的内容进行排序显示，形成讨论消息列表，显然不适合手机使用[2].

3 解决方案

3.1 交互方式

为了解决上述问题，设计了如下这样一种交互方式：用户在聊天界面中根据需求，插入话题消息，为了跟普通消息相区别，并能表达出话题的主要含义，把话题关键词及表达话题的特殊字符串组合在一起，假设以#为表达话题的特殊字符，则话题消息的格式可举例为：#今天上午开会#.服务器在接受约定格式的字符串后，进行解析，生成一个新的话题，该话题包含主题、创建者等信息.用户在点击该特殊字符串时，会跳转到所指向的话题.接下来在该话题中展开新的讨论时，每次发表的信息都携带该话题关键词，用于跟踪和绑定话题[3].

图1 消息列表

不同话题产生的消息都将放在消息提示页面中，按产生的时间顺序排序，在每条消息记录上显示所在话题名称及最新一条消息内容，如图1所示.

由于要处理多事务的情况，当话题较多时，需提供多种查询功能，方便用户使用：1.在消息列表上方提供话题搜索框，输入话题关键词，进行查找.2.新增话题列表页，列表中的话题按年、月、日分类排序显示，同时还可进一步分为“我参与的话题”、“我发起的话题”和“全部话题”.在话题显示时，要加入权限控制，避免不必要的信息泄露.

在上述方案基础上可以做进一步扩展和完善，如话题的发布、浏览、回复等操作均加入权限控制，来保护用户的隐私，即由话题创建者来指定参与话题的成员，限定只能由某些特定成员才能查看和参与该话题的讨论.其次，话题中同样可以嵌入话题，话题的嵌套就构成了一棵话题树.用户在主话题中可以看到讨论的主线索，还可以在每个子话题中看到所展开的详细信息，从而实现用户对主话题和子话题的跟踪.在处理比较复杂的事务时，相较以往的解决方案，可以比较轻松的实现事务跟踪.

3.2 消息收发

消息的收发是一个独立模块，每个用户在系统中都有一个唯一标识的uid，由通讯服务器来对消息进行中转，由可靠的通信机制确保将消息发送给目标用户.在具体实现上有多种选择，如果是iOS系统，可以将消息发到苹果推送服务器(APNs)[4]，苹果推送服务器会根据 deviceToken 查找相应的设备，并根据推送证书中的 BundleID 和 App 打包时使用的 Provisioning Profile 查找 App，从而确定唯一的设备上的唯一App，进行消息推送.另外一个主流系统Android，由于 Android FCM(Firebase Cloud Messaging)在国内不能使用[5]，所以 Android APP需要实现自己的消息服务，因此针对这部分的消息流量，要增设服务器来处理.消息类型根据通讯需求，预先设置几种类型，消息字段的含义见表1.

表1 消息类型及字段含义

3.3 接口设计

本方案的软件架构的后端接口可分为API接口和通讯接口两类.为防止用户随意访问通讯接口，接口需要引入认证机制.通讯接口的认证方式设计为基于Token的认证.Token认证有许多优势：①可解决跨域取值问题；②避免利用cookie受到CSRF攻击；③避免session占用服务器内存空间；④符合RESTful规范[6].本方案设计为在用户每次的请求中，HTTP Request Header都携带Token信息，实现无状态HTTP请求.在访问API接口时，需要提供必要参数，放在HTTP Request Header中，从返回结果中获取所需Token，参数的名称、类型和含义见表2.

表2 API接口参数

访问API接口的代码示例如下[7]：

srand((double)microtime()*1000000);// // 重置随机数种子

$appSecret = 'Y1W2MeFwwwRxa0'; // 系统分配的App Secret

$nonce = rand(); //产生随机数

$timestamp = time()*1000; //得到时间戳

$signature = sha1($appSecret.$nonce.$timestamp);// 得到数据签名

APP访问API接口和通讯接口获取Token的时序图如图2所示.

图2 APP获取Token时序图

在实现Token验证的方式上，现在有一些规范的方法，方案中采用JWT，JWT的意思是：JSON Web Tokens[8]，包含三个部分的字符串：header,payload,signature，中间用∵分隔，再用Base64编码.header 部分主要是两部分内容，一个是 Token 的类型，另一个是使用的算法，例如{ "typ":"JWT","alg":"HS256"}表示的意思是类型为JWT，算法是 HS256.用Base64编码后转换为：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.Payload 部分是 Token 的具体内容，里面包含一些标准字段，也可以添加自定义字段.标准字段见表3.

表3 JWT Token标准字段

4 结语

本方案的设计思路跟现有的即时通讯APP有所不同，主要区别在于主话题中可嵌入子话题，多层嵌套形成一棵话题树.每个子话题树都有独立的权限控制，可以保护话题内用户的隐私，每个子话题产生的共享资源也独立于其他话题.话题内的对话列表可保持逻辑上的延续性，在组成结构上维持一个树状结构.用户可通过浏览这棵树，来对话题进行跟踪和追溯，在面对复杂事务时，有助于问题的分工解决.本方案设计了API接口和通讯服务接口，用于实现业务需求.通讯是基础服务，针对目前主流的Android和iOS系统如何解决消息收发给出一个解决思路，并定义了不同消息类型的格式.虽然安全不是本方案要重点讨论的方面，但对于一个完整的设计方案来说，也是一个不能忽视的问题，文中分析了如何使用JWT Token对通讯接口进行保护的设计思路.

在带来新的用户体验时，本设计方案中对象和资源之间的关系变得比较复杂，已经超出了基于群组的简单的通讯架构.随着用户数和请求量的不断增加，对系统的响应性能要求越来越高，需要不断优化底层架构.