基于微信好友的直播互动系统设计与实现文献综述

1. 文献综述（或调研报告）：
2. 研究现状

目前国内外主流的直播互动系统在数据传输协议上很多使用JSON来进行传输，如后端给前端返回的数据格式使用JSON、前端向后端发送get或者post请求里包含的数据格式也是用json。自json提出以来，因其采用完全独立于编程语言的文本格式来存储和表示数据，简洁和清晰的层次结构使得 JSON成为理想的数据交换语言，易于人阅读和编写，同时相对最初的XML来言也更易于机器解析和生成，从而相对于最初的数据传输协议XML能够有效地提升网络传输效率，开发人员在联调时只要事先约定好字段格式与字段含义，便能很快的理解数据并进行使用。JSON在数据传输方面得到广泛应用，本毕设课题调研过程中，参考文献提到系统交互数据所用的传输协议采用的都是json进行数据传输，如《社交领域的消息推送系统的设计与实现》^[3]、《56Baby 成长记录系统的设计与实现》^[4]、《基于 SOA 的直播互动平台的设计与实现》^[5]、《基于 Android 的在线教育直播互动系统设计与实现》^[6]。

由谷歌推出另一种数据传输协议是protocol buffer，不同于XML与JSON，其是一种二进制的格式。

关于消息同步机制的问题，首先两个基本概念是收到消息的收件箱（inbox）和发出消息的发件箱（outbox）。同步机制主要存在两种形式：读扩散（pull）和写扩散（push）^[7-10]。其中读扩散的模式下，用户每次到消息发送者的发件箱去拉取消息，优点是写优化，每次发送的消息只需要写到一个地方，写操作比较少，由收件者自己去拉取消息即可。缺点便是读操作很重，假设一个用户有一千个好友，重新登录时需要拉取这些好友所有的离线消息。写扩散就是经常说的push模式，即每个消息都直接发送到该用户的收件箱中。其优点是读优化，读的操作比较轻，用户每次只需要去读取自己收件箱中的消息即可。缺点则是写很重，如果这个消息是一条群消息，那么一个群成员发送出去的消息将拷贝到所有其余群成员的收件箱中。目前针对哪个模型更好这一点没有确定的定论，因为可以很明显的看到两个模型各有优缺点，需要根据具体的业务读写需求情况来综合决定，例如《社交领域的消息推送系统的设计与实现》^[3]采用的便是读写混合模式。

主流的系统架构都是采用分层架构，大体上都会分为展示层、逻辑业务层和数据存储层。这样的架构能够解耦系统的复杂度，每一层只关心自己内部的逻辑，从而减小了开发的难度，如文献《微信平台开发架构》提出了一种基于微信公众平台的通用快速开发框架，该框架包括了5层：表示层，业务层，数据库层，数据库和操作环境^[11]。

关于数据存储服务，目前主流关系型数据库是Oracle和MySQL，其中Oracle因为其高昂的价格导致其在学术项目中使用不多，更多的是被用在在企业级开发中，而参考文献中底层数据服务均采用MySQL。

1. 调研结果分析
   1. 功能调研结果

目前随着移动互联网和通信技术的发展，直播已经成为各大互联网厂商的必争之地，分析国内外主流互动直播平台后，调研总结出各大互动直播系统主要功能，并以此为参考作为本毕设课题《基于微信好友的直播互动系统》的系统需求，具体功能列出如下：

1. 观看直播功能：这是最基本也是最核心的功能性需求。
2. 登录功能：在大部分的直播互动系统中用户第一次进入直播间时是无法看到进入之前用户的评论或者各种操作记录的，不同于普通的系统或者大部分的直播互动系统，本系统希望能够在用户登录的时候能够展现部分历史评论、投票等，这可以类比“冷启动”问题。面对一个很火热的直播间时可能存在大量的历史数据，故登录操作对于本系统而言是一个很重的操作，可能开销较大，所以需要关注登录时第一次获取历史数据的性能问题。
3. 发送/删除评论功能（或者称之为弹幕功能，取决于前端展现形式）：这是直播系统互动性的直接体现，也是直播互动系统区别于普通流媒体播放的核心所在。
4. 投票功能：让用户进行站队能够更好的提升用户的参与感。
5. 一些无障碍的使用功能，或节省流量、节省系统运行开销等的优化使用体验的功能。
   1. 技术方案调研结果
6. 关于数据传输协议的选定：采用protocol buffer。虽然JSON有着很多优点，参考文献也都是选用JSON来进行数据传输。但JSON毕竟是使用文本格式来存储和表示数据的，一个字符就需要一个字节来存储，这会需要很大的空间来存储以及带来很大的网络开销；加之JSON的格式复杂多变，所以JSON的解析速度方面一直为人诟病。很多研究者提出XML、JSON、protocol buffer(简称Protobuf，下面均用这个简称)中，JSON并不是最优的数据传输方式，JSON虽然比XML在解析速度、存储大小方面都有所优化，但序列化/反序列化速度仍比Protobuf慢两倍甚至5倍^[12]、视频存储大小比Protobuf大出3倍^[12]。XML就表现更差，解析速度甚至能比Protobuf慢出50倍^[13]。解析速度与数据大小是影响性能的重要因素，本人认为Protobuf牺牲了传输数据的直接可读性换来了性能的大幅度提升是值得的，所以本毕设课题最终决定采用谷歌推出的Protobuf作为本系统的数据传输协议。
7. 关于消息同步机制的选定：采用写扩散模型。读扩散与写扩散模型各有优点，选用哪种方案需要针对系统的具体读写需求情况来决定。在直播互动系统中，一场直播的观看人数可能达到上千万甚至上亿（如春晚直播），但如此多的用户中会发送评论、弹幕的人相对于观看人数而言往往很少，也就是绝大部分用户都是在读取数据、只有很小一部分用户会写数据，总结起来就是“读多写少”。为了降低读操作的开销，本毕设课题最终选用了写扩散的消息同步机制。
8. 关于系统架构的选定：本毕设课题确定采用分层架构，除去常见的表示层（应用层）、逻辑业务层以及数据存储层外，额外增加网关层。之所以采用这样的架构是基于保护后台服务同时为了便于跟外部服务交互的目的：网关层上接前端，下接后台服务，可以在恶意请求到达后台服务前就拒绝请求，同时把与外部第三方服务交互的逻辑放到网关层可以便于系统设计。
9. 关于数据存储服务的选定：本毕设课题采用公司自研的分布式KV存储服务。本系统的性能问题是一个重难点，而对于系统最为底层的数据存储服务，如果采用MySQL可能存在单机的性能瓶颈，且其不是分布式的存储服务，可能会存在单点故障导致整个系统不可用，自行搭建分布式的MySQL环境又开销过大。

1. 方案（设计方案、或研究方案、研制方案）论证：

本毕设课题《基于微信好友的直播互动系统》总体上分为后端服务部分与前端用户使用部分。目前直播数据主要来源于腾讯视频的体育直播，如果需要加入多元化的直播数据可以随时更换直播源数据，核心功能与实现不受影响。

1. 功能、需求介绍

系统后端主要是需要满足在用户登录的前提下维护好友关系链（用户请求直播数据时能正确获得对应好友的数据）、直播数据维护、评论数据维护、投票数据维护、预约维护、当前观看好友人数统计等功能性的需求，以及还需要有性能监控、过载保护、备份容灾等非功能性需求。

系统前端主要的功能是面向用户开放的，包括预约直播、观看直播、发送评论、比赛投票、观看文字直播、查看比赛相关资讯等。

1. 用例图

图1.用例图

1. 架构图

图2.架构图

1. 模块图
   1. 前端功能模块图

图3.前端功能模块图

• 1. 后端功能模块图

图4.后端功能模块图

1. 功能模块的流程图
   1. 前端功能模块

前端功能模块都存在一些相同的流程，如最开始均是验证是否登录，未登录则跳转到登录流程，然后前端请求CGI、CGI验证请求是否合法（参数、用户认证等）,最后都是由CGI向前端返回请求、前端向用户返回结果。这些相同的流程在每个单独的模块中不再赘述。

1. 登录模块流程：在CGI验证请求合法后，后台服务会请求微信相关服务进行认证，然后后台服务向CGI返回结果
2. 数据统计模块流程：在CGI验证请求合法后，后台服务判断当前请求是否是要访问好友关系链，如果需要则请求微信相关服务获得好友关系链并以此过滤数据；不需要则直接统计数据并返回。
3. 观看直播流程：在CGI验证请求合法后，后台服务会请求外部门服务（腾讯视频）获取直播数据源，然后请求微信相关服务获得好友关系链，接着访问存储层获得评论、投票、比赛信息，再根据好友关系链过滤这些从存储层获得的数据，最后向CGI返回结果
4. 预约模块流程：在CGI验证请求合法后，后台服务直接将预约数据写入存储层并将结果返回CGI即可
5. 评论模块流程：在CGI验证请求合法后，后台服务需要处理评论请求验证评论是否合法，接着请求微信相关服务获得好友关系链，并根据获得的好友关系链写扩散修改评论数据到存储层。
6. 比赛投票模块流程：在CGI验证请求合法后，后台服务直接将投票数据写入存储层并将结果返回CGI即可。

文字直播模块流程：在CGI验证请求合法后，后台服务直接从存储层读取比赛文字直播数据并将结果返回CGI即可。

1. 比赛资讯模块流程：在CGI验证请求合法后，后台服务直接从存储层读取比赛资讯数据并将结果返回CGI即可。
   1. 后端功能模块

后端功能模块依赖于部门自由的监控体系、过载保护体系、token访问验证体系以及消息推送模块，主要就是把这些模块接入到CGI层、后台服务层即可。因此整体后端功能模块流程图如下：

图5.后端模块流程图

整个系统设计方案大致分为三层：应用层、网关层、逻辑业务层。其中第一层主要负责与用户交互，并将用户请求传递到网关层进行下一步的处理。第二层网关层负责分发、过滤、验证用户请求，同时负责与外部门的服务进行交互，便于后台访问第三方服务。第三层逻辑业务层为具体的业务处理代码，负责进行具体的业务操作，同时访问数据存储服务于微信相关服务完成业务请求。

1. 参考文献

[1] 中国中央网络安全和信息化委员办公室, 中华人民共和国国家互联网信息办公室. 第43次《中国互联网络发展状况统计报告》（全文）[EB/OL]. http://www.cac.gov.cn/2019-02/28/c_1124175677.htm，2019-02-28

[2] 罗子盈. 论网络直播的现状、问题及对策[J]. 记者摇篮，2019(11)：117-119

[3] 冯祥敏. 社交领域的消息推送系统的设计与实现[D]. 北京:北京交通大学软件学院,2015

[4] 李欢. 56Baby成长记录系统的设计与实现[D]. 北京:北京交通大学软件学院,2016

[5] 张晓勇. 基于SOA的直播互动平台的设计与实现[D]. 北京:北京交通大学软件学院,2018

[6] 马博林. 基于Android的在线教育直播互动系统设计与实现[D]. 广州:华南农业大学数学与信息学院,2016

[7] codedump.info. IM服务器设计-消息存储[EB/OL]. https://www.codedump.info/post/20190608-im-msg-storage/，2019-06-08

[8] 阿里云云栖社区木洛. 现代IM系统中的消息系统架构 - 模型篇[EB/OL]. https://yq.aliyun.com/articles/701593?spm=a2c4e.11153940.0.0.fd972d96lhXzHN，2019-05-08

[9] 阿里云云栖社区木洛. 现代IM系统中的消息系统架构 - 架构篇[EB/OL]. https://yq.aliyun.com/articles/698301?spm=a2c4e.11153940.0.0.bef956b7fgBV8U，2019-04-15

[10] 阿里云云栖社区木洛. 现代IM系统中消息推送和存储架构的实现[EB/OL]. https://yq.aliyun.com/articles/253242?spm=a2c4e.11153940.0.0.285555b2bF7BAY，2017-11-16

[11] Enguang Liang, Yu Liang, Sanxing Cao. Research on development architecture of WeChat platform[C]. In: 2017 3rd IEEE International Conference on Computer and Communications (ICCC). Chengdu: IEEE, 2017. 2512-2516

[12] Audie Sumaray, S. Kami Makki. A comparison of data serialization formats for optimal efficiency on a mobile platform[C]. In: Proceedings of the 6th International Conference on Ubiquitous Information Management and Communication. Kuala Lumpur: ACM. 1-6

[13] Nenad Gligorić, Igor Dejanović, Srđan Krčo. Performance evaluation of compact binary XML representation for constrained devices[C]. In: 2011 International Conference on Distributed Computing in Sensor Systems and Workshops (DCOSS). Barcelona: IEEE, 2011. 1-5

1. 进度安排：