原文标注报告【个人文献版-本科论文】报告编号 PL-20220316-2DC27C39-BZ

9 -BZ 9 -BZ
7C3 7C3
送检文献信息
DC2 D C2
1 6-2 1 6-2
03
【题名】基于Golang的IM系统
2 2 03
作 者： 方炅昊
PL
-2 02
检测时间： 2022-03-16 13:34:20
PL
-2 02
0.44 总相似比
%

检测范围：  中国学术期刊数据库  优先出版论文数据库  国内外重要学术会议论文数据库

 中国博士学位论文全文数据库  中国优秀硕士学位论文全文数据库  中国优秀报纸全文数据库

 互联网学术资源数据库  学术网络文献数据库  中国专利文献全文数据库

 Z 
-BZ
特色英文文摘数据库 中国标准全文数据库
9-B 9
C3 C3
C 27 C 27
详细检测结果 -2D -2D
316 3 16
20 20
-2 02 -2 02
PL PL
原文总字符数 检测字符数 参考文献相似比 辅助排除参考文献相似比 可能自引相似比 辅助排除可能自引相似比
12835 12385 0.00% 0.44% 0.00% 0.44%

相似文献列表（仅列举前10条）

序号 相似比(相似字符) 9 -BZ 相似文献 类型 9

是否引用 -BZ
7C3 7C3
0.33%
DC2
什么是ORM?
D C2
6-2 6-2
1 mob604756f1e4c7；http://www.51cto.com/（网址 学术网文 否
41字符
1 ：https://blog.51cto.com/u_15127574/2724304）；2021-04-22 1
2 03 2 03
02
0.11% 散杂货港口汽车提货风险分析与预警研究
02
L-2 -2
2 学位 否
P14字符 毕辰雨（导师：黄磊）；北京交通大学，硕士（专业：电气工程)；2020
PL

原文标注

2018届本科毕业论文（设计）题目： 基于Golang的IM系统姓名： 方炅昊学院：计算机与网络空间安全学院专业： 软件工程

学号： 116072018005

9 -BZ 9 -BZ
C3 C3
指导教师：杜欣

C 27
[摘要]：本系统是采用的框架有名叫fiber的http框架，基于mysql的ORM框架gorm，react及react-hooks，vue,js设计的前端，以及自己设计的交流协议，能够完成已 C 27
-2D -2D
316
经在数据库中的用户在网页登录以后验证身份系统授予使用系统的权力。登录后用户可以在本系统的网页端查看实时在线用户，用户登录的消息也会推送给所有用户
3 16
20 20
02
，如果用户后来登录也会推送完整的在线列表。用户可以通过本系统实现即时通讯。在群组选项中可以进行多人聊天。聊天窗口推送最新的五条消息。
-2 -2 02
PL
[关键词]Golang；IM;通信协议设计；tcp;ES6 PL
目录

1. 引言 2

1.1. 课题背景 2

1.1.1. 研究意义 3

1.1.2. 国内外研究现状 3
9 -BZ 9 -BZ
7C3 7C3
C2 C2
2. 关键技术介绍与业务需求分析 3
D D
2.1.关键技术 3
1 6-2 1 6-2
2 03 2 03
02 02
2.1.1.协议技术 3
-2 -2
2.1.2事件驱动模型 3
PL PL
2.1.3前端技术介绍汇总 4

2.2业务需求分析 4

2.2.1综述 4

2.2.2可行性分析 5

2.2.3规格说明 5

3. 系统设计 11
3.1系统架构系统逻辑结构 11

9-BZ 9-BZ
C3 C3
3.2系统架构系统部署视图 13
7 7
3.3客户端设计 13
DC2 DC2
1.1.3. 多端登录 13 1 6-2 1 6-2
2 03 2 03
1.1.4. 会话聊天 14
-202 -2 02
3.4服务器设计 14 PL PL
3.4.1消息模块 14

3.4.2监控日志模块设计 14

3.4.3事务设计 14

3.4.4多端消息同步 14

4. 系统详细设计 15
9-BZ 9-BZ
C3 C3
4.1聊天系统设计 15
C 27 C 27
-2D -2D
16 16
4.1.1前端设计 15
3 3
4.1.2数据库设计 16 20 20
-2 02 -202
4.1.3结构体设计 16
PL PL
4.2云盘系统设计 18

4.2.1表单设计 18

5. 系统实现与验证 18

5.1本地后端实现 18

-BZ -BZ
5.2服务器端实现效果 19
9 9
5.3总体实现效果 19
7C3 7C3
6. 系统测试 27 DC2 DC2
1 6-2 1 6-2
6.1测试用例 27
2 03 2 03
7. 致谢 29 -202 -2 02
引言
PL PL
课题背景人民生活离不开信息传递，有效的沟通工具可以降低沟通的成本带来经济效益。一个简单易用的IM（Instant Messaging，简称IM）软件，就显得尤为重要。

在传统的jsp动态网页技术的基础上，优化了对DOM（Document Object Model，简称DOM）树的操作，引入了虚拟DOM[1]，每次渲染页面的时候对当前DOM与虚拟

DOM作对比并进行差量渲染。由于react是基于jsp开发的，所以jsp技术的优点，react也具备，且表现出更好的响应速度。

ORM（Object-relational mapping）技术，中文翻译为，对象关系映射，通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。

解决了持久层的难题，那就是持久层和业务耦合的难题。 9-BZ 9-BZ

C3 C3
C 27
基于以上两种技术可以开发出能够持久化和具有高响应的前端界面。核心业务逻辑需要用到一些通信技术。 C 27
6 -2D 6 -2D
31 31
研究意义由课题来源引出的这些问题其实就暴露了开发一个基于golang的IM系统有什么意义。
0 0
22 22
-20 -20
第一点就是对于用户来说，IM是很多系统的必备功能，一个企业或者是大众，往往都需要一个通信系统，如果在局域网内进行通信还需要其他工作群，无疑会让员工有

P L P L
一种工作侵入到生活的错觉。所以总结起来来说就是im模块是一个需求面很广的模块，无论是上线应用还是给客户定制都会用到该模块。

第二点也是第一点的延伸，由于im系统的受众广泛，所以模块的重用程度就很高，如果每次开发都要重构一次代码，重新组织系统，是对人力资源和时间成本的巨大浪

费，为了避免重复造轮子，有必要提高代码的内聚程度来提高代码的重用能力，再从一个产品的角度来看im系统，一个比较通用的模块意味这巨大的消费用户，用户会

为这个模块买单，使研究这个系统有了经济上的研究意义。

而从一个另类的角度来解读研究意义，那就是可以满足特殊通讯，这个意义的存在是为了回答既然市场上已经有了杀手级的im软件如主流的腾讯qq和微信等等以及在这

Z Z
9-B 9-B
之下的社交软件都能满足大众的通讯需求。但是在网络状况较差的特殊情况时，访问公网以寻求通信服务就不太现实。比如抗震救灾当中，大型信号站被破坏或损害

C 3 C 3
27
，这个时候的网络设备仅仅只够救援队临时组建一个局域网。这种特殊网络环境就对快速部署有着极高的需求，所以一款面向二次开发友好，用户开箱即用的im系统就
C C 27
有极大的意义。 -2D -2D
3 16 3 16
0 0
22 22
国内外研究现状国内商用主流IM系统有腾讯qq[2]，微信等等，这些商用产品主要用户是大众，为大众提供通讯服务。这类商用产品已经是非常成熟的通讯系统，在满

- 2 0 - 2 0
PL PL
足各种场景需求的同时拥有更及时的通讯体验。

企业往往也会有定制的IM系统，这些产品通常是找拥有相关业务的公司定制系统，这些系统通常会有一些特殊的需求，以满足公司业务中的某些流程。还有一个原因趋

势企业定制系统：企业不放心商用im系统的安全性，防止重要业务数据泄露。这时企业必须自己部署服务器和客户端。

国外常见的im系统有telegram，snapchat。这些用户是世界范围的大众，其系统也是相当成熟，用户体验流畅。

这类产品往往都是以c/s模型搭建的，一般需要用户安装在本地。

关键技术介绍与业务需求分析

2.1.关键技术

2.1.1.协议技术
RabbitMQ 是一款由rabbit公司开发的开源消息代理软件，是一款面向消息的中间件，由erlang语言编写，基于AMQP协议实现的软件。支持复合消息协议，消息队列

9-BZ 9-BZ
C3 C3
，弹性队列路由，复合交换机等等，不受平台限制，与业务完全解耦。[3]
7 7
2.1.2事件驱动模型
DC2 DC2
1 6-2
Event-driven architecture （EDA）[4]是一种软件编程范式，是一种设计架构。 1 6-2
203 2 03
02
传统的请求模型往往带着一问一答的设计思想，也就是事务往往被定义成一组事件，一组业务，事务是一些业务的组合。定义好了事务之后，传统请求模型会有专门的
-2 -202
PL
逻辑关注这些事务成功与否，并执行相应分支下的业务。这期间如果是异步的行为，则需要不断去轮询相关业务成功与否，进行忙等。 PL
而事件驱动模型则跳出了这样的设计理念，当一个事件发生的时候，触发对这个事件感兴趣的组件的回调函数也就是“激活”了另一个事件。这样事件的触发就从原本

的分步骤请求，变成了一条更通顺的流，流中阻塞的部分不会占用系统资源去忙等，而是等到相关的事件被触发的时候继续下去。

但是事件驱动模型并不是就更优于传统的请求模型，只不过在一些特定的应用场景事件驱动模型有很好的使用价值和施展空间。

2.1.3前端技术介绍汇总

-BZ
传统的MVC设计模式用户通过操作model向view发起指令进行操作，或者用户想controller发送请求进而让controller转发请求给view，这样设计的特点是非常肥大的
9 9-BZ
7 C3 C3
7
C2 C2
view层将承担沉重的业务负担，而controller只有薄薄的一层，没有起到应该有的作用。

-2 D -2 D
16 16
React采用的是MVVM[5]前端架构模式，这个模式的特点是view和ViewModel双向数据绑定：view的变动立刻反映在ViewModel上。这样做的好处是减轻了视图层的业

0 3 0 3
22 22
务负担，专注与渲染视图，而不是关注处理逻辑。同时为了更进一步改善视图层的性能瓶颈，react引入了虚拟dom[6]，让实际dom在渲染之前对比虚拟dom然后差量
0 0
- 2 - 2
渲染。
PL PL
传统的react有明确的父子关系，呈现一种数据单向传递的状态，子组件的状态改变并不会引起父组件的重新绘制。但是这样的关系决定了组件之间会有非常复杂的以来

关系。摈弃了继承的编写框架，react选择了函数式的设计加各种各样hook，在状态改变的时候触发钩子达到之前的传递数据效果。这样做的好处是更易复用代码，在

模块化过程中一路畅通无阻，但是也带来了依赖不清晰的风险。

Vue是一款前端框架，由国人个人开发者开发维护，相比于react的全新语法jsx，vue直接使用html的模板，从语法层面上更易兼容js,jq。

-BZ -BZ
通过路由改变并不跳转来改变当前前端的状态减少前端管理的状态。[7]
9 9
2.2业务需求分析
7C3 7C3
2.2.1综述 DC2 DC2
6-2 6-2
31 31
20 20
本系统为一个即时通讯系统，最主要的需求就是通信，通信的载体是文字，还带有多样的媒体，比如表情。所以系统需要能够正确传输这些载体。
0 2 0 2
L-2 L-2
再一个需要解决的问题就是通信的关系不是一个用户，是复数个用户之间的交互行为，所以系统需要能够统筹用户之间的关系。用户的通信关系还有一个特点就是，有
P
的时候消息是单独发送的，有的时候是多次单独发送，有的时候是在群体中发送。
P
用户需要能够在系统内编辑发送的信息。

需要一个用户友好的界面。

2.2.1.1.功能性需求分析[8]

消息编辑框：用户能够在系统内部编辑要发送的信息，包括文字和媒体。用户在敲打回车或者点击发送的时候应该能够将消息发送出去聊天信息展示框：用户应能够看

9-BZ
到自己发送的信息与对方或者该群组中产生的消息联系人关系：用户能观察到其他用户登录，并打开与该用户的聊天窗口进行通信单独会话：用户能够和自己的联系人 9-BZ
C3 C3
进行单独的通信，其他用户不能观察到两名用户之间的通信。 C 27 C 27
6 -2D -2D
31
群组关系：联系人可以选择建立群组，用户可以凭借系统生成的群组号加入群组。
316
0 20
22 02
-20
群体聊天：加入群聊之后用户可以在群聊中发送信息，任何加入群聊的用户都可以观察到发送在群聊会话当中的信息。
L -2
P
时间：用户要了解自己发送消息的时间。 PL
开发者模式：开发者模式允许用户进入开发者界面查看页面性能数据

2.2.1.2非功能性需求分析

用户的输入框需要集成文本框，表情按钮，按钮分别用来编辑文本，表情可以和文本镶嵌起来组合发送。

输入框输入过长的文本时能够下拉查看编辑区的文本聊天窗口需可以隐藏，并尽量在两次打开之间减少不必要的加载以提升用户体验。

网上云盘，上传和下载用户文件，包括图片，视频，文本等等[9]
9-BZ 9-BZ
2.2.2可行性分析 7C3 7C3
DC2 DC2
6-2 6-2
2.2.2.1经济可行性
1 1
203
首先分析这个系统需要的成本，该分析中硬件设备的设定是单核1G，价格是95.64元/年（阿里云为例），如果是甲骨文免费云机则成本为零，以后者为例，虽然有不稳 2 03
-2 02 -202
PL PL
定的风险但是如果多设置一个负载均衡和容灾机器就可以几乎避免关机风险，这样的话收益总是大于成本的。

目前正在流行的话题是元宇宙，这样的聊天系统解耦了业务和通信，很适合用于做元宇宙产品的雏形。

2.2.2.2技术可行性

技术可行性分析如下：

软件的部署极快，架构简单，适合轻量级聊天，性能上高吞吐高并发。

2.2.3规格说明

2.2.3.1用例设计

图2-1 系统总用例图
图2-2 聊天子系统用例图

9-BZ 9-BZ
C3 C3
用例编号 UC-01 用例名称 登录客户端用例描述 用户在登录界面输入账户名密码，若匹配则登录成功跳转到主页，前置条件 用户在数据库中录入自己的账户名和密码后
7 7
C2
置条件 若此时已经打开聊天页面，则提示该账户登录，在标签栏新增一个用户。并通知该系统所有用户，一个用户登录基本路径 在登录指定url后自动跳转到该页面
D DC2
，填写账户和密码，点击登录，登陆成功时跳转到主页。 1 6-2 1 6-2
203 203
02
备选路径 在登录指定url后自动跳转到该页面，填写账户和密码，点击登录，登陆未成功时弹窗提示未登录
-2 -2 02
表2-1 登录客户端用例表 PL PL
用例编号 UC-02 用例名称 单聊用例描述 用户登录以后能够和其他用户聊天前置条件 另外打开一个主页，点击登录，进行身份验证，身份验证成功后保证标签后的信号

标志为绿色，表示连接已打开后置条件 点击右下角展开聊天窗口，输入的文本可以发送给服务器，聊天区实时更新聊天信息。

基本路径 在前端页面点击friend选项，在选项中点击指定联系人，双击，在标签下的链接变成绿色信号图标时，点击右下角蓝色图标开始聊天，输入需要发送的文本

，单击回车或者点击发送图标发送消息。

备选路径
9-BZ 9-BZ
7 C3 7C3
C2 C2
表2-2 单聊用例表
D
-2 用户登录以后能够和其他用户聊天前置条件 另外打开一个主页，点击登录，进行身份验证，身份验证成功后保证标签后的信号-2 D
16 16
用例编号 UC-03 用例名称 群聊用例描述

0 3 0 3
标志为绿色，表示连接已打开后置条件
0 22 点击右下角展开聊天窗口，输入的文本可以发送给服务器，聊天区实时更新聊天信息。
0 22
- 2 - 2
PL PL
基本路径 在前端页面点击friend选项，在选项中点击指定群组，双击，在标签下的链接变成绿色信号图标时，点击右下角蓝色图标开始聊天，输入需要发送的文本，单

击回车或者点击发送图标发送消息。

备选路径

表2-3 群聊用例表

用例编号 UC-04 用例名称 刷新聊天信息用例描述 将当前聊天窗口的聊天信息更新到最新前置条件 用户需完成身份验证后置条件 刷新后需要点击右下角聊天窗口才能查

-BZ -BZ
看收到的聊天信息基本路径 在通讯人列表最上方有一个刷新键，点击刷新键时拉取最近的5条信息，并正序输出备选路径
9 9
表2-4 刷新聊天信息用例表
7C3 7C3
图2-3 云盘子系统用例图 DC2 DC2
6-2 6-2
31 31
20 20
用例编号 UC-05 用例名称 云盘上传/下载用例描述 上传或下载资源到服务器端前置条件 用户需完成身份验证后置条件 上传后文件会添加到服务器，本地的文件文件列
0 2 0 2
L2 L-2
表也会更新基本路径-点击左上角选择文件，选中一个要上传的文件，点击上传，文件就添加到了资源列表当中，本地的文件列表立即更新，翻阅最新一页可以查看新上

传的文件。
P P
点击文件列表中文件的序号可以下载文件备选路径 文件下载时已删除，则下载失败

表2-5 云盘上传/下载用例图

图2-4 浏览主页用例图

用例编号 UC-06 用例名称 浏览主页用例描述 用户浏览主页，选择需要的功能前置条件 用户需完成身份验证后置条件 点击选项卡路由到相应的功能页上基本路径 点击想

要前往的页面备选路径 9-BZ 9-BZ

C3 C3
表2-6 浏览主页用例表 C 27 C 27
6 -2D 6 -2D
31 31
图2-5 在线游戏用例图
2 0 0
用例编号 UC-07 用例名称2在线游戏用例描述 22
-20 -20
用户在系统上进行游戏前置条件后置条件 用户进行游戏基本路径 在该界面选择难度，对手，点击开始游戏进行五子棋游戏

备选路径 P L P L
表2-7 在线游戏用例表

图2-6 打开开发者模式用例图

用例编号 UC-08 用例名称 打开开发者模式用例描述 用户进行开发者视图，监控当前页面占用的内存空间以及响应时间前置条件 登录开发者账号后置条件 在开发者视图

中查看当前系统内存占用情况基本路径 点击登录，输入开发者账号，登录开发者视图并查看该视图备选路径

表2-8 打开开发者模式用例表
9-BZ 9-BZ
2.2.3.2协议说明 7C3 7C3
DC2 DC2
6-2 6-2
本系统在交换数据的时候遵守一定的应用协议。详见下表字节位置 序列方式 字段名 说明0-3 小端序 typ 规定本次消息通讯的类型，详见消息号表，最长支持消息号
1 1
203
4294967295，小规模通信时可以将本协议设置为仅读一字节，有特殊功能扩展需求的用户也可以在原本的消息头部拿出指定字节自定义消息号分支，对协议的加工的 203
-2 02 -2 02
PL PL
数据工厂已经包装好，用户只需要在此基础上写好对消息头的数据工厂即可完成业务扩展4-7 小端序 from 规定本次消息通讯的发送者，一般用户和二次开发者无需关心

发送者的id，这部分的数据不对外暴露，发送时和发送者本身的状态绑定，发送者的状态只有在登录的时候才改变，保证了用户只能通过自己发送消息。

8-11 小端序 sendTo 规定本次通讯的接收者，被接收端用于确定消息的接收者，以确定本地客户端的消息去向，也用于服务端确定拉取的数据对象。特殊情况有消息号

2用此字段填写响应结果。由于是稳定连接，所以消息也会发送给指定用户。

12-15 小端序 size 规定消息的长度，保证读写器每次读完头都知道往后读多少字节，避免出现沾包16-size-1 小端序 text 消息实际负载，可以为任意字节数，但是如果

数据量过大可能会把缓冲区占用满

表2-9 协议表

号码 说明接收101 刷新消息。拉取了数据库中指定对象的最新五条消息，发送到socket当中，由于每一个用户列表当中的用户都对应这一条连接，所以当这个连接有
101消息的时候就是指定给该用户的，下同不作过多赘述。

9-BZ 9-BZ
C3 C3
服务器会使用orm框架的接口向指定数据库查找相关的记录，并将记录中的信息推送到socket当中去。
7 7
C2
2 新用户登录请求，由客户端推送给服务端端说明其他地方有新用户登录，需要把数据推送给客户端。接受到该数据头的时候读取向数据库请求相关数据，如果确实有
D DC2
1 6-2
该用户的账户信息，将阻塞的管道打开，解封用户的系统功能，而后让该用户关注公共信道，以便下次有聊天信息也可以接收到111 群聊消息，接收后立刻入库并全量 1 6-2
203 2 03
推给关注该群组的用户。
-2 02 -2 02
PL
1 接受来自本地客户端的消息，该消息是私聊当中的即时消息，所以从客户端读取以后会由收发协程主动向消息队列推送消息，所有关注公共消息队列的用户都会响应 PL
该消息，如果没有及时响应，下次上线的时候也会推送。然后目标用户会在公共消息队列中找到发给自己的消息之后给数据库入库一份消息记录发送1 从ws中读取消息

，发送消息1给服务器端，消息1包括当前用户id，目标用户id，以及携带的文本信息。

2 发送信息2，信息2携带了从服务器端路验证过的用户名和密码

102 新用户登录，向所有用户推送新用户的登录消息111 拉取数据库中的群组消息，并将群组消息写入socket

表2-10 服务端协议表
9-BZ 9-BZ
C3 C3
号码 说明
C 27 C 27
6 -2D -2D
16
1 单聊消息，属性为：typ;receiver;text
31 3
20
2 群聊消息，属性为：typ;receiver,text
2 20
-20 -202
PL
表2-11 消息表（前端-本地客户端）
PL
号码 说明接收101 刷新消息。从服务器端拉去了数据库中指定对象的最新五条消息，发送到刷新信道refleshChan，由于app从路由friend/：id请求有意一直阻塞，直

到refleshChan有新消息，接下来将消息从中取出，与之前登录时做的标记进行对比，如果发现发送者是自己的消息，就可以认定在数据库里自己发送了该消息，标记

该消息，在前端表现为右边的气泡。否则都认为是对方发送的消息，表现为左边的气泡102 新用户登录消息，由服务端推送给客户端说明其他地方有新用户登录，需要

把数据推送给前端。接受到该数据头的时候读取携带的字符串作为用户名，封装成类型2的Msg结构体并通过ws主动发送给前端。

-BZ -BZ
111 群聊消息，从服务器接收群聊相关的消息，推送给前端1 原定主动推送新消息，后被废弃，每次有新消息的时候推送全部五条最近的消息。
9 9
C3
发送1 从ws中读取消息，发送消息1给服务器端，消息1包括当前用户id，目标用户id，以及携带的文本信息。
7 7C3
DC2
111 从ws中读取消息，发送消息1给服务器端，消息1包括当前用户id，目标群组id，以及携带的文本信息。 DC2
6-2 6-2
31 31
20 20
2 发送信息2，信息2携带了从前端路由携带的用户名和密码，五秒后超时并向前端发送407not registered信息表示用户未注册由102响应，如果成功响应则向前端发送
2 2
0 刷新消息请求，从路由中读取请求刷新的目标id，并集合当前用户的id向服务器发起刷新请求，期待服务器发送101响应，并携带该用户与
0
L-2 L-2
fiber.StatusOK（200）101
P
目标用户或目标群组最近五条消息
P
表2-12 消息表（本地客户端-服务器端）

路由表路由表路由 说明/ws/：type/：id 提供给前端的接口，前端通过该接口接入ws，并发送msg；

type 也会辅助验证是否为群聊，为防止有人恶意篡改路劲任然有本地客户端验证/login/：username/：pwd 客户端登录接口，只能另外从页面登录，发送用户名和密

码后可以向服务器发送查表请求，验证用户身份，用户身份验证后将提供系统的使用权限。

9-BZ
/group/：id 前端群聊刷新接口，当前端点击reflesh的时候发送刷新请求，本地后端向服务器请求该群组的最新五条消息，并推送给前端。 9-BZ
C3 C3
C 27
/friend/：id 前端单聊刷新接口，当前端点击reflesh的时候发送刷新请求，本地后端向服务器请求用户之间的最新五条消息，并推送给前端。 C 27
-2D
6 -2D 6
31 31
/cloud 静态资源注册/home 静态资源注册/game 静态资源注册/chat 静态资源注册/loginPage 静态资源注册/dashboard 开发者视图接口/personal 后端重定向
0 0
22 22
-20 -20
/homePage 后端重定向/chatPage 后端重定向/loginPage 后端重定向/gamePage 后端重定向/upload 上传文件接口，post方式，需要设置post表单中上传的文件名

P L
/aaa/：id 读取一个get请求并根据请求参数使用Fasthttp下载文件/list 获取资源目录下的文件列表 P L
表2-13 路由表

系统设计

3.1系统架构系统逻辑结构

本系统由5层架构组成，其中监控层不参与业务逻辑，但是在业务关键点记录日志。

Z Z
9-B 9-B
这五层分别是：表现层，控制层，ORM，和数据库。

C 3 C 3
27
用户从表现层对控件进行操作，触发控件，控件传递数据给控制层，控制层将控件传递的信息解析成事件，被关注该事件的模块捕捉到以后，事件流传递给数据层，并
C C 27
-2D
由ORM对数据库中相应的元数据进行拉去，并返回给控制层，控制层对拉取的数据进行加工并返回给事件的产生者。 -2D
3 16 3 16
0 0
22 22
图3-1 系统整体架构图

- 2 0 - 2 0
PL PL
表现层：表现层提供一系列可以被浏览器访问的资源，当浏览器打开这些资源的时候点击相应控件，访问指定的路径，浏览器后台就会根据逻辑组合用户提供的信息

，向更下层提供一些json字符串。

控制层：控制层负责从接收表现层传递的数据，发送到等待处理的队列当中，当队列为空的时候，处理的逻辑就阻塞，当队列产生新的数据的时候，立即消费队列中的

数据，并解析出头部含有的路由信息，根据路由信息选择如何处理这些数据。大部分情况下是收到的数据直接转发给服务器，不然就向浏览器推送一些状态改变信息

，令前端界面发生相应的变化。

ORM：ORM负责从数据库拉取数据，为了令业务逻辑和数据库解耦，选择使用orm层，这样面向orm的上层，只会有数据对象，而面对什么数据库，用什么指令则交给

ORM自行选择，技术选型是gorm，有自动迁移的功能，能用golang的结构体直接构造DTO。

DB：负责存储用户信息，包括以及注册的用户，后续有用户需要登录系统的时候也需要从数据库中查阅，当数据属实，账户密码正确，系统才会给与用户授权使用该系
统。

9-BZ 9-BZ
C3 C3
数据库还存储了用户聊天产生的消息，目前系统的私聊消息都在一个数据表当中，以unix时间戳作为id排序，这样可以保证系统拉取的五条聊天信息是最近才发送的。
7 7
C2
数据表项也标明了数据的发送者和接收者，方便用户针对不同的聊天对象拉取数据。
D D C2
图3-2 聊天模块详细架构图 1 6-2 16-2
203 2 03
3.2系统架构系统部署视图
-2 02 -202
图3-3 系统部署图 PL PL
3.3客户端设计

多端登录用户在多态设备登录的时候都会比较本地的消息时间戳和服务器消息时间戳，如果有更新的信息就会向服务器拉取最新消息，之后前端才渲染出基本界面，用

户才可以开始发送信息。

如果更新期间用户异常退出不会报错。

-BZ
会话聊天用户可以在左上角选择私聊还是群聊，如果是私聊点击friend链接，下方会弹出相应的在线用户列表，双击该用户的链接即可开始聊天，该用户的用户名下方
9 9-BZ
7 C3 7 C3
C2 C2
会出现一条ws的状态，如果状态是open即可开始聊天。当用户异常离线的时候，消息依然会发送给服务器，服务器一方面将消息入库，另一方面向相应的mq当中推送

-2 D -2 D
16 16
数据，当该用户登录的时候，点击刷新依然会收到一条离线消息。但是这条异常的消息并不会在用户上线的时候即使推给他，二十需要他主动刷新。

0 3 0 3
3.4服务器设计
0 22 0 22
- 2 - 2
3.4.1消息模块
PL PL
前端输入用户消息发送给本地服务器端，本地服务器通过ws获取前端数据或者主动推送数据[10]。不论是单聊消息还是群聊消息都是由一个模块处理的，这个模块的主

要工作流程如下，首先从socket当中获取一个客户端发送来的消息，然后经过数据工厂的处理[11]，记录这条消息是发给哪一个用户或者哪一个群组的，然后由服务器

的单例交换机向外发布消息事件，并记录了消息的相关信息，任何用户在登陆的时候都会生成一个队列来关注这个交换机，当交换机发生事件的时候队列都会把消息拿

走并比对自身的用户id与接受者是否相同，简单来说单聊采用的是广播监听[12]的方式，这样可以快速的处理在线用户的单聊而不用管理用户在线列表。

-BZ -BZ
同时这样的广播机制可以复用到群聊当中，服务器的用户类型会管理一组群聊，并在登录的时候关注群聊，当群聊中有消息推送的时候，根据群聊的id展示在指定的会
9 9
话窗口上。
7C3 7C3
DC2
Cqrs没有使用水车的原生库，而是修改了开源源码结合rabbitmq和watermill[13]消息模块的通信协议设置如下： D C2
6-2 6-2
31 31
20 20
为了方便拆解方便，讲所有的信息每4个字节一组打包，一个包中有五个部分的数据，分别为类型，发送者，接收者（可以为群组号），接下来的数据payload部分长度
0 2 0 2
L-2 L-2
，也就是20字节的头部，以及指定长度的负载，为了防止一些网络通信当中出现的异常，比如说丢失数据包，或者是粘包，分包。这样设计的好处是，程序一定从
P P
socket当中读取指定长度后才进行相应的逻辑，比如一个数据包从中被切分成两块：5字节的头部和15字节头部以及部分身体，这时候程序一定会等到读取满20字节的

头部以后才进行相应的逻辑[14]。

3.4.2监控日志模块设计

监控日志采用的是watermill开源库自带的日志和监控模式\github.com\！three!dots!labs\watermill\log.go有详细描述日志模块和监控模块的基本功能。

日志采用的是std 实现LoggerAdapter的接口info，监控是trace接口，大致思路是每条消息走进交换机（push）的时候都留下一个logfiled类型，里面记录了日志的行

9-BZ
为和路线，每个队列消费的时候也给ConnectionWrapper里面的日志模块增加一个logfiled，这样后面日志记录的时候就有结构化的信息。借用watermill的uuid可以给 9-BZ
C3 C3
每个消息定义一个唯一的标识方便debug和监控。 C 27 C27
6 -2D 6 -2D
31 31
3.4.3事务设计
0 0
22 22
-20 -20
在逻辑层确认收到一条来自用户的信息的时候会开启事务，这条信息要被推送给指定用户，或者推送给多个用户，这条消息会被指定保证应答，如果程序异常退出，重

P L
启的时候这些消息也会再次进行推送，直到确认消息被写出，但是没有设计消息的确认送达，这部分的确认由tcp自己完成。P L
3.4.4多端消息同步

当一个多端用户登录的时候，点击刷新可以拉取当前聊天的最新消息，由于同样关注一个队列，所以多端用户登录同样会收到用户的信息，不断的拉取最新的消息，可

以保证三端都可以进行即使通讯。

系统详细设计

4.1聊天系统设计
9-BZ 9-BZ
4.1.1前端设计 7C3 7C3
DC2 D C2
6-2 6-2
4.1.1.1状态设计
1 1
203
属性名 说明id 填入用户链接当中，当用户点击指定用户的时候跳转到该用户名路径下userName 用户名用于显示标签所带有的字段备注：用于显示前端的在线列表，前 2 03
-2 02 -202
PL PL
端监听userList的状态，每当userList变化的时候重新渲染。

表4-1 userList数据结构表

属性名 对应值ReadyState.CONNECTING "Connecting"ReadyState.OPEN "Open"ReadyState.CLOSING "Closing"ReadyState.CLOSED

"Closed"ReadyState.UNINSTANTIATED "Uninstantiated"说明：用于显示ws当前的状态。

表4-2 ws在线状态字典表

4.1.1.2组件设计

组件结构如下：

-CustomLinkExample-OldSchoolMenuLink-Router-About-OldSchoolMenuLink-Group-OldSchoolMenuLink组件名 说明CustomLinkExample 父组件，暴露给

DOMRendrOldSchoolMenuLink 用于渲染标签，当点击标签时切换路由，该标签最前方增加图标表示选中该标签About 单聊组件，用户的单聊信息通过该组件传输出

9 -BZ 9 -BZ
C3 C3
去group 群聊组件
7 7
表4-3 ws组件说明表
DC2 DC2
4.1.2数据库设计 1 6-2 1 6-2
2 03 2 03
02 02
数据名 数据类型 数据长度 小数点 是否为nullgid Bigint 20 0 Not nulltxt longtext 0 0 Not nulltime_stamp bigint 20 0 Not nullspeaker bigint 20 0 Not null
-2 -2
PL
表4-4 groupDialog数据表结构表 PL
数据名 数据类型 数据长度 小数点 是否为nullsender bigint 20 0 Not nulltxt longtext 0 0 Not nulltime_stamp bigint 20 0 Not nullreceiver bigint 20 0 Not null

表4-5 msg数据表结构表

数据名 数据类型 数据长度 小数点 是否为nullid bigint 20 0 Not nulluser_name longtext 0 0 Not nullpwd longtext 0 0 Not nulluid bigint 20 0 Not null

表4-6 users数据表结构表

4.1.3结构体设计
9 -BZ 9 -BZ
7 C3 7 C3
C2 C2
4.1.3.1本地客户端结构体表单

字段名称 类型 说明relation Relation-2

D
表示用户的账户id和他关注的好友，方便扩展好友和黑名单nickName string 表示该用户的昵称Head []byte-2
D
16 16
用于给io提供存储空

0 3 0 3
间，主要用于读取头部信息body
0 22 []byte 用于读取数据部分rw io.Reader 用于从读写中获取raw数据 0 22
- 2 - 2
PL
表4-7 User 结构体表
PL
字段名称 类型 说明UserId uint 表示当前登录用户的id，用于匹配收到的消息是否是自己的，以及每次发送消息的时候标注自己的id，方便入库和查找subId []uint 用于

标注黑名单，为空时默认接受所有登录用户的消息

表4-8 Relation结构体表

字段名称 类型 说明Gid uint 群组idTxt string 群组信息列表，一般为5条TimeStamp string 时间戳，记录发送消息的时间speaker uint 记录发送者的id

-BZ -BZ
表4-9 GroupDialog 结构体表
9 9
chatMsg、DBMsg同样用于对接来自服务器的信息，下同不多赘述。
7C3 7C3
DC2
服务器端结构体表单字段名称 类型 说明relation Relation 表示用户的账户id和他关注的好友，方便扩展好友和黑名单nickName string 表示该用户的昵称Head []byte DC2
6-2 6-2
31 31
20 20
用于给io提供存储空间，主要用于读取头部信息body []byte 用于读取数据部分rw io.Reader 用于从读写中获取raw数据
0 2 0 2
L-2 L-2
表4-10 AbsUser结构体表
P P
Relation 关系字段名称 类型 说明UserId uint 表示当前登录用户的id，用于匹配收到的消息是否是自己的，以及每次发送消息的时候标注自己的id，方便入库和查找

subId []uint 用于标注黑名单，为空时默认接受所有登录用户的消息

表4-11 Relation结构体表

字段名称 类型 说明Gid uint 群组idTxt string 群组信息列表，一般为5条TimeStamp string 时间戳，记录发送消息的时间speaker uint 记录发送者的id

表4-12 groupDialog结构体表

4.2.云盘系统设计 9 -BZ 9 -BZ

C3 C3
4.2.1.表单设计 C 27 C 27
-2D -2D
16
字段名称 类型 说明Gid uint 群组idTxt string 群组信息列表，一般为5条TimeStamp string 时间戳，记录发送消息的时间speaker uint 记录发送者的id
3 316
20 20
表4-13 云盘系统表单
02 02
系统实现与验证 P
L-2 PL
-2
5.1本地后端实现

本地后端也提供了一些日志信息，监控前端的数据是否有异常，包括来自前端的请求，切换到指定路由后修改了的websocket，以及向服务器发送的请求数据。

5.2服务器端实现效果

在控制台全线监控消息[15]。

Z Z
9-B 9-B
在控制台提供了对消息的监控，可以追踪的信息有：

C 3 C 3
交换机的创建，包括公共交换机和群组交换机，以及各个交换机的主题。
C 27 C 27
-2D
队列的创建，包括各个消费者的队列名称，以及绑定指定交换机是否成功消息的uuid和被哪些用户响应，可以定位到没有响应的用户，已经判断消息是否被不期望的用-2D
3 16 3 16
0 0
22 22
户响应。

- 2 0 - 2 0
PL PL
来自客户端的消息类型，发送者，接收者，消息长度，以及新消息的16进制串，应用层面的监控有新用户登录，消息推送。

可以定位到消息入库的时候的状态

5.3总体实现效果

图5-1 系统启动时主页

图5-2 主页动效展示图

鼠标悬停时消除最外层图标，最后一个选项卡表示禁用的功能没有配置路由。

图5-3 聊天主界面图

聊天主界面，鼠标悬停有蓝色线框动画，背景是svg动画。
选中指定标签后增加图标表示选中，后方图标表示ws连接状态，红色为未连接，沙漏是正在连接中，绿色是已连接，黄色机器人表示返回主页，绿色刷新表示刷新当前

9-BZ 9-BZ
C3 C3
用户的信息。
7 7
聊天之前需要点击主页最下方选项卡弹出登录界面。
DC2 DC2
图5-4 登录界面图 1 6-2 1 6-2
203 203
图5-5 新用户登陆时老用户界面图
-2 02 -2 02
后台日志如下： PL PL
图5-6 本地后端日志展示图

图5-7 服务器端日志展示图

如果部署在两台主机上应该显示一对用户，这里因为没有部署相关环境所以会显示两个，不能用浏览器再打开一个页面是因为客户端也要占用一个端口。

图5-8 聊天功能展示图

点击右下角图标输入要发送的文字或者表情。
9-BZ 9-BZ
C3
7 7 C3
C2 C2
图5-9 聊天信息推送图

-2 D -2 D
16 16
发送后立即推送最新的五条消息，刷新消息同样可以用主页的reflesh按键，按下后推送最新消息并有红点提示。

0 3 0 3
22
图5-10 聊天信息被已经开启的消费协程消费的日志
0 0 22
- 2 - 2
PL PL
新消息被所有在线用户响应，但是只有指定用户才会做出回应，这样做不需要管理在线用户，用户断开连接就断开连接，心跳超时后观察者自动关闭。

图5-11 同时在线的另一个用户的聊天记录图

重新登录用户后，现在的用户是11224，打开聊天窗口看到的试图是这样的。

图5-12 云盘界面图

云盘界面如上图，导航条自动根据文件数量分页，每页五个文件，载入文件时有从右往左划入的特效。

-BZ -BZ
图5-13 选择文件界面图
9 9
点击选择文件可以选择本地文件。
7C3 7C3
图5-14 选择文件后状态图 DC2 DC2
1 6-2 1 6-2
3 03
20
选择后点击上传。
2 2
0 02
L-2 -2
图5-15 上传文件前系统状态图
P
图5-16 上传后系统状态图
PL
图5-17 点击下载后下载的资源

在线游戏有五子棋。

图5-18 五子棋游戏界面图

系统测试

6.1测试用例[16] 9-BZ 9-BZ

C3 C3
C 27
功能名称 测试用例用户登录 用户通过指定路径登录用户登录 错误用户名密码反馈错误信息用户登录 已登录用户观察到其他用户登录用户登录 新登录用户获取到全量在 C 27
6 -2D 6 -2D
31 31
线列表用户私聊 已登录用户通过前端进行聊天用户私聊 未登录用户通过前端进行聊天，无反馈用户群聊 已登录用户通过前端进行聊天用户群聊 未登录用户通过前端进
0 0
22 点击后控制台提示发送的json字符串发送控件测试 若输入框为空则不发送聊天窗控件测试 自动聚焦到输入框聊天窗控件测试
22
-20 -20
行聊天，无反馈发送控件测试 新消息红点
L
提示聊天窗控件测试 P L
P 拉取最新消息时控制台输出最新消息的json字符串本地客户端测试 切换路径，路由改变，websocket重新连接本地客户端测试 websocket断开连

接返回错误，用户不可再访问旧连接本地客户端测试 接受消息1本地客户端测试 接受消息2本地客户端测试 向服务器发送刷新请求，并响应本地客户端测试 向服务器发

送新消息，并响应本地客户端测试 处理服务器消息标记当前用户发送的消息本地客户端测试 向服务器发送登录请求，并响应服务器端测试 响应新消息服务器端测试 响

应刷新服务器端测试 响应登录服务器端测试 拒绝非登录用户请求服务器端测试 读写器测试服务器端测试 序列化器测试功能名称 测试用例 测试结果功能名称 测试用例

测试成功用户登录 用户通过指定路径登录 测试成功用户登录 错误用户名密码反馈错误信息 测试成功用户登录 已登录用户观察到其他用户登录 测试成功用户登录 新登

Z Z
9-B 9-B
录用户获取到全量在线列表 测试成功用户私聊 已登录用户通过前端进行聊天 测试成功用户私聊 未登录用户通过前端进行聊天，无反馈 测试成功用户群聊 已登录用户通

C 3 C 3
过前端进行聊天 测试成功用户群聊 未登录用户通过前端进行聊天，无反馈
C 27 测试成功发送控件测试 点击后控制台提示发送的json字符串 测试成功发送控件测试
C 27 若输入框
为空则不发送 测试成功聊天窗控件测试 -2D自动聚焦到输入框 测试成功聊天窗控件测试 新消息红点提示 测试成功聊天窗控件测试 拉取最新消息时控制台输出最新消息的 -2D
3 16 3 16
0 0
22 22
json字符串 测试成功本地客户端测试 切换路径，路由改变，websocket重新连接 测试成功本地客户端测试 websocket断开连接返回错误，用户不可再访问旧连接 测试
2 0
-接受消息1 测试成功本地客户端测试 接受消息2 测试成功本地客户端测试 向服务器发送刷新请求，并响应L测试成功本地客户端测试 - 2 0
PL
成功本地客户端测试 向服务器发送
P
新消息，并响应 测试成功本地客户端测试 处理服务器消息标记当前用户发送的消息 测试成功本地客户端测试 向服务器发送登录请求，并响应 测试成功服务器端测试 响

应新消息 测试成功服务器端测试 响应刷新 测试成功服务器端测试 响应登录 测试成功服务器端测试 拒绝非登录用户请求 测试成功服务器端测试 读写器测试 测试成功服

务器端测试 序列化器测试 测试成功云盘系统测试 上传测试，选择文件，单击上传，文件添加到服务器和当前浏览器的文件列表最新页的最后一项 测试成功云盘系统测

试 下载测试，选择文件，点击文件序号，下载文件到本地 测试成功云盘系统测试 分页测试，点击下一页，前一页，点击页码序号，到达指定页面 测试成功云盘系统测

试 添加大量文件到服务器存储目录，自动分页并生成目录 测试成功

表6-1 测试用例表

致谢
参考文献

9 -BZ 9 -BZ
C3 C3
React Docs[EB/OL]https://reactjs.org/docs/faq-internals.html
7 7
C2 C2
Wenyu (Derek) Du, Junjie Wu, Shanshi Liu et al. Effective organizational improvisation in information systems development: Insights from the Tencent
D D
1 6-2
messaging system development[J] Information & Management, 2019, 56(4) 16-2
2 03 2 03
02
RabbitMQ Features[EB/OL] https://www.rabbitmq.com/#features
-2 -2 02
PL PL
Dimiter Dobrev Event-Driven Models. [J] IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences,2019

黄少波. 一种基于MVVM架构实现可视化设计模型的方法[P]. 广东省：CN113656027A,2021-11-16.

戴志诚,程劲草.基于虚拟DOM的Web前端性能优化研究[J].计算机应用与软件,2017,34(12):21-25+31.

曹亮,周宇凯. 禁止页面跳转方法及设备[P]. 北京市：CN113986089A,2022-01-28.

Wisswani Ni Wayan, Wijaya I Wayan Kandi Message Oriented Middleware For Library’s Metadata Exchange[J] TELKOMNIKA (Telecommunication Computing

Electronics and Control), 2018, 16(6)

9 -BZ 9 -BZ
7 C3 7 C3
C2 C2
孙叶敏. 一种基于互联网的共享云盘管理系统[P]. 上海市：CN112907180A,2021-06-04.

-2 D -2 D
16 16
周双全. 一种基于websocket的浏览器与本地应用程序通信方法[P]. 广东省：CN114035984A,2022-02-11.周文永. 基于XMPP协议的企业级IM关键功能的研究及其在

0 3 0 3
22
iOS端的实现[D].华南理工大学,2013.
0 0 22
- 2 - 2
PL
黄堂森.浅谈简单工厂模式在分层架构中的应用[J].数码世界,2019(01):125.
PL
朱昌发,冯枫,李泽. 一种基于观察者模式的微服务运行状态监控方法[P]. 湖北省：CN112685261A,2021-04-20.

孙耀辉. 一种基于AMQP协议的高可靠性任务调度方法和系统[P]. 北京市：CN107943567B,2021-12-28.

龙昱程.基于TCP协议的应用层协议设计[J].信息通信,2015(05):69-70.

黄媛媛,王彬,龙卉,刘学生.基于微服务架构的日志系统[J].电子技术与软件工程,2017(02):174.

-BZ -BZ
向鸿荣,李昕昕.场景测试方法和正交测试方法在论坛网站中的应用研究[J].无线互联科技,2021,18(16):97-98.
9 9
7 C3 7 C3
报告指标说明 D C2 D C2
1 6-2 16-2
2 03 2 03


-2 02
原文总字符数：即送检文献的总字符数，包含文字字符、标点符号、阿拉伯数字（不计入空格）
-2 02
 PL
检测字符数：送检文献经过系统程序处理，排除已识别的参考文献等不作为相似性比对内容的部分后，剩余全部参与相似性检测匹配的文本字符数 PL
 总相似比：送检文献与其他文献的相似文本内容在原文中所占比例

 参考文献相似比：送检文献与其标明引用的参考文献的相似文本内容在原文中所占比例

 可能自引相似比：送检文献与其作者本人的其他已公开或发表文献的相似文本内容在原文中所占比例

 单篇最大相似比：送检文献的相似文献中贡献相似比最高一篇的相似比值

-BZ -BZ
 是否引用：该相似文献是否被送检文献标注为其参考文献引用，作者本人的可能自引文献也应标注为参考文献后方能认定为“引用”
9 9
C3 C3
C 27 C 27
6 -2D 6 -2D
0 31
检测报告由万方数据文献相似性检测系统算法生成，仅对您所选择的检测范围内检验结果负责，结果仅供参考 0 31
22 22
-20 -20
万方检测官方网站：https://check.wanfangdata.com.cn/ 检测报告真伪验证官方网站：https://truth.wanfangdata.com.cn/

P L 北京万方数据股份有限公司出品 P L

9 -BZ 9 -BZ
7 C3 7 C3
D C2 D C2
1 6-2 16-2
2 03 2 03
-2 02 -2 02
PL PL