一种多模融合技术的即时通讯解决方案

苏成武

摘要：本文针对网络即时通信IM（Instant Messenger）存在的多渠道（不同浏览器、不同客户端）、多协议（HTTP、Flash XMLSocekt、WebSocket）接入困难问题，设计了一个多模融合即时消息服务，使各业务系统以统一的接口接入各渠道及各协议，同时可以不在修改业务系统的前提下接入新的渠道及协议。实践运行表明，本系统具有良好的易用性和可扩展性，已在多个业务系统推广使用。

关键词：IM;网络即时通信;即时消息服务

中图分类号：TP393      文献标识码：A

文章编号：1009-3044（2022）12-0035-03

开放科学（资源服务）标识码（OSID）：

随着移动互联网的发展，用户利用手机、电脑上网的时间越来越多，以“社区（Community）” “内容（Contenet）”“商务（Commerce）”为主要特征的网络即时通信IM（Instant Messenger），越来越受到用户的重视。网络即时通信使得用户的沟通更加方便、快捷，使用户真正有了天涯若比邻的“地球村”的感觉。

用户可通过浏览器（IE、Chrome、Firefox、Safari、Edge）、Windows桌面软件、Linux桌面软件、MAC桌面软件、安卓App、苹果App等不同的渠道访问业务系统。由于历史原因，各渠道实现网络即时通讯的技术差异较大，如Chrome、Firefox、Safari、Edge等较新的浏览器支持HTML5标准中的WebSocket，可通过WebSocket实现网络即时通讯。较老版本的IE浏览器只能通过轮询方式或Flash XMLSocekt实现即时通讯。而Windows桌面软件、Linux桌面软件、MAC桌面软件、安卓App、苹果App等需要通过Socket实现网络即时通讯。如果业务系统负责每一个渠道的网络即时通讯接入，无疑会导致业务系统过于复杂，不利于不同业务系统之间代码共享，同时增加新的协议接入时，会破坏原有的业务系统。

基于以上的问题，本文提出了一种多模融合技术的即时通讯解决方案，建立一个多模融合即时消息服务，接收不同渠道的客户端连接，并从连接当中取出一定数量的字符，与各对应的协议报文头进行字符匹配，从而识别连接渠道客户端所使用的协议，并按协议格式解析报文数据。再通过统一的协议与业务系统进行通讯，并将解析出的数据传递给业务系统进行处理，并可将业务系统返回的结果推送给各渠道的客户端。通过多模融合即时消息服务可实现与业务系统的统一通讯，即使增加新的渠道客户端协议，只用修改多模融合即时消息服务，实现了业务与即时消息能力的解耦。当连接海量用户时，只需部署多套模融合即时消息服务即可。

1 主要内容

基于EPOLL技术实现高性能的多模融合即时消息服务，通过此服务，可以实现不同渠道不同协议的接入，并为后台业务系统提供统一的接口。可以降低业务系统代码的复杂度，并可实现不同业务系统即时消息的功能复用。

本解决方案的内容主要分为以下几个方面：

1）协议识别器：通过关键字符的匹配，识别出当前渠道客户端所采用的协议，为后续的数据处理和结果返回提供必要的信息，本设计可自动识别出HTTP、Flash XMLSocekt、WebSocket等协议。

2）协议解码器：实现HTTP、Flash XMLSocekt、WebSocket等协议的解码器，从传输协议里面解析出数据报文供下一步处理。

3）协议编码器：实现HTTP、Flash XMLSocekt、WebSocket等协议的编码器，将业务系统或心跳包等模块返回的结果数据按相应的协议封装并返回给渠道客户端。

4）多模融合框架：开发统一的多模融合框架，进行服务端口监听并处理网络事件（采用EPOLL实现高性能网络事件处理）。同时提供统一的接口，可支持不同的协议识别器、协议解码器、协议编码器接入多模融合框架。

5）心跳检测：通过定时向渠道客户端和业务系统发送心跳包，可剔除已经异常断开的连接，保证连接的有效性。

6）开放SDK：向业务系统和渠道客户端提供建立连接、获取数据、发送数据、断开连接等接口。

2 总体架构设计

渠道客户端集成开放SDK，向多模融合即时消息服务发起连接请求并携带报文数据。多模融合即时消息服务的多模融合框架收到报文后调用协议识别器，识别出渠道客户端所使用协议。将协议报文传给相应的解碼器进行解码，解码出的数据通过多模融合框架传输给业务系统并接收业务系统返回的数据，经过协议编码器编码后将数据返回给渠道客户端。同时多模融合即时消息服务通过心跳检测模块检测，定时向渠道客户端和业务系统发送心跳包以检测其是否存活。

3 各模块详细设计

3.1 多模融合框架设计

多模融合即时消息服务在启动时调用多模融合框架进行初始化。多模融合框架读取配置文件，并监听配置文件配置的网络端口，再通过EPOLL事件驱动机制实现与渠道客户端及业务系统的网络通讯。同时初始化一个哈希表，用于协议解码器和协议编码器的注册，以便识别出协议后可以快速查找到解码器和编码器并对网络报文进行编码和解码，编解码器需一一对应，一个解码器只对应且必须对应一个编码器。

3.1.1 EPOLL事件驱动机制

EPOLL是Linux提供的高性能网络事件驱动机制，可以使应用程序支持海量的用户接入。EPOLL是在SELECT事件驱动机制上发展而来，SELECT事件驱动机制需程序每次将所有待监听的SOCKET传入内核，内核在某一SOCKET出现读、写、关闭等事件时，再将事件返回给应用程序，应用程序再通过遍历所有SOCKET来判断是否发生相关的事件。应用程序每一轮处理，都要向内核传递所有SOCKET，同时发生事件时要遍历所有的SOCKET，性能较低。而EPOLL则当有新的SOCKET时才告知内核需监听此SOCKET，同时有读、写、关闭等事件时内核只会将发生事件的SOCKET通知应用程序，从而减少内核与应用程序的数据交换及SOCKET的遍历，支持海量用户接入[1]。

3.1.2 哈希表

哈希表是一种数据结构，存储KEY-VALUE值。通过哈希函数将KEY值映射成长整型的HASHCODE，将此HASHCODE作为VALUE值存储的位置（数组索引），当不同KEY值映射到同一个存储位置时，通过双向链表来存储VALUE值。只要哈希函数合理，在KEY值分布较稀疏的情况下，哈希表有较好的查询性能（O（1）的时间复杂度），通过哈希函数可以一次定位到对应的VALUE值[5]。

3.2 协议识别器设计

协议识别器是多模融合即时消息服务核心组件，只有准确识别出渠道客户端所使用的协议，才能进行下一步处理。协议识别器在有渠道客户端进行连接并接收第一个报文数据时，通过分析报文头部数据的关键字符并根据核心逻辑识别出对应的协议，并解析报文头的数据（如HTTP头部）与当前渠道客户端连接进行关联，为下一步处理做好充分准备。下表列出了识别HTTP、Flash XMLSocekt、WebSocket三种不同协议报文头部关键字符和核心逻辑。

3.3 解码器和编码器设计

解码器和编码器需一一对应，即一个解码器只对应且必须对应一个编码器，因此解码器和编码器应在一起设计。解码器其核心内容根据协议格式解码出实际传输的数据供业务系统使用，编码器的作用主要是将业务系统返回结果按协议格式进行封装并返回给渠道客户端。

3.3.1 HTTP解码器/编码器设计

HTTP解码器/编码器基于HTTP协议[3]进行了扩展，改变HTTP协议的一问一答形式，双方均可以随时通过HTTP请求或响应报文发送数据给对方。渠道客户端发送信息时使用HTTP请求报文（解码器），多模融合即时消息服务返回消息时使用HTTP响应报文（编码器）。

1）解码器报文

请求行：发送post请求并指明使用http1.1版本。

请求头部：第二行至第六行携带相应的头部，如标注报文长度等。

空行：请求头部和请求数据之间的间隙。

请求数据：即时通讯携带的报文数据。

2）编码器报文

状态行：指明HTTP协议版本号及状态码、状态消息，如上例中HTTP版本为1.1，状态码为200，状态消息为（ok）。

消息报头：携带客户端要使用的一些附加信息。

空行：消息报头与响应正文后面的空行是必须的。

响应正文：服务器返回给客户端的文本信息，空行后面的html部分为响应正文。

3.3.2 Flash XMLSocekt解码器/编码器设计

Flash XMLSocekt在建立连接后第一个数据报文发送前，需进行沙箱和安全策略认证。具体为Flash建立连接后发送一个字符串，内容为 ""（多模融合即时消息服务通过此字段识别Flash XMLSocekt协议），并等待返回安全策略XML。多模融合即时消息服务解析出此连接前几个字符是后返回 字符后，认证通过，即可进行正常的数据报文通讯[2]。

在通过沙箱和安全策略认证后，每一个请求报文首先发送两个字节的报文长度，接下来的字节即为报文数据，具体报文格式由各业务系统自行定义（解码器和编码器发送的数据报文格式完全一致，只是发送的方向不一样）。下图为有两个数据报文的示例：

3.3.3 WebSocekt解码器/编码器设计

按照RFC标准，WebSocket的建立需要借助于HTTP，其流程为：渠道客户端发一个HTTP GET请求（这个请求只包含一些头部）携带升级为WebSocket的头部[4]标识到服务端，服务端确认后，渠道客户端与服务端就可以按WebSocket消息帧（WebSocekt解码器和编码器均按此消息帧格式封装通信）进行通信。

3.4 心跳检测设计

多模融合即时消息服务定时向渠道客户端和业务系统发送心跳包报文，如果规定的时间内（可通过配置文件配置）收到渠道客户端或业务系统的回复报文，则认为连接正常，否则从连接信息清单里剔除无效的连接。具体做法为当渠道客户端或业务系统建立连接成功后，多模融合即时消息服务为每一个渠道客户端或业务系统建立连接信息，并初始化一个字段最后读写时间为当前时间，在后续收到或发送数据时均更新最后读写时间字段。同时多模融合即时消息服务建立系统定时任务，每隔5秒钟遍历一次连接信息，当某一个连接最后读写时间超过一定的时长后，则发送心跳包报文。

3.5 开放SDK设计

开放SDK主要功能是为渠道客户端和业务系统提供接入多模融合即时消息服务并进行相关接口功能API的调用。为渠道客户端主要提供C、JAVA、JavaScript、Flash等不同语言版本。为业务系统主要提供C、JAVA等不同语言版本。主要接口清单如下：

1）连接建立：与多模融合即时消息服务进行连接，需输入参数业务系统标识、渠道客户端ID、服务URL，输出结果为连接是否成功、当前连接TOKEN、连接结果描述。

2）发送数据：通过多模融合即时消息服务向业务系统或另一个渠道客户端发送数据，需要输入对端标识（业务系统标识或连接TOKEN）、数据（JSON字符串），输出结果为是否发送成功。

3）接收數据：通过回调方法的行式向渠道客户端返回接收到的JSON字符串，具体JSON里面的字段按业务需要进行定制。

4）断开连接：断开与多模融合即时消息服务的连接，需输入的参数为当前连接TOKEN，输出结果为空。断开连接后此连接将释放不可用。

4 结语

本文主要针对网络即时通信的多渠道（不同浏览器、不同客户端）、多协议（HTTP、Flash XMLSocekt、WebSocket）的统一接入进行分析和设计。采用EPOLL事件驱动机制实现高性能网络即时通信，同时基于哈希表的数据结构实现了不同协议的解码器及解码器的接入，保证平台的松耦合性、高可靠性和后期可维护性。本文针对目前网络即时通信的痛点（多渠道、多协议接入工作量大，耗时长）进行了分析，并且这些痛点在本设计的系统中得到了有效的解决与改善。现阶段基本上达到了设计目标，实现了多模融合即时消息服务的主要内容。同时本系统在实时性、可用性、易用性等方面都达到了良好的效果，在一定程度上解决了各业务系统接入即时通信的工作量大，耗时长，等诸多痛点。本系统可以较为明显地为各业务系统进行服务，节省开发人员的时间和精力，可以在一定程度上推动网络即时通信的变革。

参考文献：

[1] WarrenW Gay.实战Linux Socket 编程[M].詹俊鹄，译.西安：西安电子科技大学出版社，2002.

[2] [加拿大]班得逊.Adobe Flex 3高级编程[M].北京：清华大学出版社，2011.

[3] David Gourley，Brian Totty.HTTP权威指南[M].陈涓，赵振平，译.北京：人民邮电出版社，2012.

[4] 齐华，李佳，刘军.基于Websocket的消息实时推送设计与实现[J].微处理机，2016，37（3）：36-39，43.

[5] 严蔚敏，吴伟民.数据结构[M].北京：清华大学出版社，1997.

【通联编辑：张薇】