实战搭建完整的IM即时通讯应用1

介绍

即时通讯应用服务，整套蕴含服务端、治理端和客户端

预计 3 篇分享：这次是第一篇，我的项目的整体介绍和实体关系的梳理

现已部署上线，客户端和治理端，欢送体验

能够注册客户端账号，也能够应用初始默认账号，现有初始账号阐明：

<img width=”300″ src=”https://i.loli.net/2020/07/15/fO2naUmPluYRsBd.png”>

性能简介

1. 注册，登录，集体、群组聊天，个人信息编辑等根底性能
2. 申请增加好友和申请入群
3. 表情，图片，视频，定位信息反对
4. 聊天会话列表记录
5. 音讯记录（微信的音讯记录实在一言难尽）
6. 反对多点同时登录
7. 百度 UNIT 机器人主动回复(todo)
8. 治理端，进行角色和权限的治理，群状态治理（我也当一回马化腾）

需要简介

挪动互联网倒退至今，以微信为首的即时通讯服务曾经融入了咱们生存中的各个角落，在公司的一些业务中也扮演着重要的角色，对于即时通讯咱们公司原来是应用的环信的服务，然而有很多定制化的需要无奈实现，所以起初决定外部开发一个满足定制化需要的即时通讯微服务。

应用 socket.io 框架是因为过后后端缺人，加上看了一些例子后感觉应用起来真的很不便，而且全平台反对，所以这个微服务就在前端团队进行落地实际，目前成果还不错。

社区目前这方面的内容比拟少或者太简陋（只有一个公共的聊天室这种）。另外就是在业务开发过程中被 PM 搞得很好受，所以想脱离一些特有的业务上的货色，实现一个性能简略五脏俱全的不掺杂公司业务的 IM 利用, 蕴含服务端，治理端和客户端。客户端的模拟对象是微信，因为我很相熟，不必在产品下面思考太多，另外就是试用的人很相熟，不须要太多的沟通老本。

框架简介

要开发一套残缺的即时通讯服务，须要以下局部：

1. 服务端：用来实现根底的服务接口和数据长久化
2. 客户端：实现登录、聊天等根底性能，相似微信
3. 治理端：治理群组、用户和角色权限

server

为企业级框架和利用而生

选用阿里的 egg.js 框架做撑持，看中的起因是他们外部大规模的落地和平安方面做得比拟好，没有抉择 nest 的起因是集成 socket.io 比拟麻烦，ORM 选用 sequelize，数据库是 mysql , 之前一起应用过，上手难度小

admin

开箱即用的中台前端 / 设计解决方案

抉择 Ant Design Pro 作为模板开发治理端，选用的起因是我对 Vue 全家桶比拟相熟，想借着这个机会相熟下整套 React 生态 的开发流程，感触下目前国内两大开发框架的本质区别和必由之路，Ant Design Pro 曾经公布了好几年了，也确实给中小型企业带来效率的晋升，也正好适宜我这的需要。

client

????️ Vue.js 开发的规范工具

应用 @vue/cli 搭建 IM 服务的客户端，一个挪动端的 H5 我的项目，UI 框架应用的有赞 vant，集成了我的开源组件 vue-page-stack 和黄老师的 better-scroll，实现 IM 的根底性能

实体关系

作为一个前端工程师，大多数的日常工作是不须要思考实体关系的。然而，就我的理论体验来看，懂得实体关系能够帮忙咱们更好的了解业务模型。而对产品和业务了解的晋升对咱们的帮忙是十分大的，能够在需要评审的时候发现很多不合乎逻辑的中央（怎么又要吐槽产品经理了），这时候能提出来就会被动防止咱们在后续的过程中进行重复开发，同时能够和产品侧的同学造成比拟良好的互动（而不是互怼）。上面简略列举下比拟重要的实体关系：

<img width=”600″ src=”https://i.loli.net/2020/07/14/Zhz85V2ptOylDcj.png”>

通过上图能够看到 user 是整个关系图中的外围，上面介绍下各个实体之间的关系：

1. user 和 user_info(用户信息) 是一对一的关系
2. user 和 role(角色)是多对多的关系
3. role 和 right(权限)是多对多的关系
4. user 和 apply(申请)是多对多的关系，申请都是波及到两个 user（申请人和被申请人）
5. user 和 group(群组)是多对多的关系
6. group 和 conversation(会话) 是一对一的关系
7. friend 和 conversation(会话) 是一对一的关系
8. conversation 和 message(音讯)是 1 对多的关系
9. friend(好友关系) 和 user 没有间接关系，friend 由两个 user 确定

上面具体介绍下会话、角色与权限：

会话

实现一个即时通讯利用，须要思考的第一个事件就是会话，就是咱们微信外面的对话窗口。思考会话和音讯、用户、群组之间的关系破费了不少的精力，最终造成以下的根本关系：

1. 2 个用户参加的聊天属于建设了 Friend 关系（互为好友）
2. 多个用户参加的聊天组成了群组关系
3. Friend 和会话之间的关系是 1 对 1 的关系，能够通过 Friend 找到此 Friend 的会话，也能够通过会话确定 Friend
4. 群组和会话之间的关系是 1 对 1 的关系，能够通过群组找到此群组的会话，也能够通过会话确定群组
5. 音讯属于某个会话，能够依据会话查看对应的音讯列表
6. 保留音讯的时候更新会话的激活工夫，用户的会话列表依据激活工夫排序，也就是最近的会话再最后面

也就是说，用户和会话没有间接的关系，只能通过用户对应的单聊和群聊去获取会话，这样做能够有以下的益处：

1. 无论是单聊还是群聊，连贯上的用户只有 join 进对应的会话 room 外面就能够，音讯也是在对应的 room 外面公布
2. 无论是单聊还是群聊，音讯的保留和查问都比较简单，都是只针对这个会话
3. 获取集体的会话列表也变得很简略，用户的会话列表通过查问用户『所有的 Friend 和群组』->『所有的会话』->『排序会话(依据激活工夫)』，就能够获取

角色和权限

为了设计一个灵便、通用、不便的权限管理系统，本零碎采纳 RBAC（基于角色的访问控制）管制，来设计一个通用的『用户角色权限』平台，不便前期扩大。

RBAC

RBAC（基于角色的访问控制）是指用户通过角色与权限进行关联。即一个用户领有若干角色，每一个角色领有若干权限(当然了，别把抵触的角色和权限配在一起)。这样，就结构成“用户—角色—权限”的受权模型。在这种模型中，用户与角色之间、角色与权限之间，个别是多对多的关系。

本零碎默认的角色和权限

本零碎默认有管理员、个别用户、禁言用户和封禁用户这几种角色，给不同的角色调配不同的权限，所以须要针对治理和发言等接口路由做一下对立的鉴权（通过中间件的形式）解决，具体形式和办法在后端我的项目中会具体阐明。本零碎临时采纳事后定义了角色和权限的形式，后续想要扩大的话能够编辑角色和权限。

管理员

没见过微信的治理端，然而能够设想一下，管理员能够配置用户的角色和权限，能够编辑群组的状态：

1. 登录的权限
2. 群组状态的编辑
3. 针对用户的角色和权限的编辑

普通用户

注册登录后，能够失常的增加好友和退出群组，能够批改集体根底信息和解决申请

1. 注册登录
2. 编辑集体根底信息
3. 增加好友，申请入群
4. 解决好友申请和入群申请
5. 聊天

禁言用户

1. 注册登录
2. 编辑集体根底信息
3. 增加好友，申请入群
4. 解决好友申请和入群申请

封禁用户

无奈登录

角色的组合

举个例子：当初有一个新版的集体核心须要上线测试，首先新建一个角色『测试集体核心』，再给这个角色调配对应的权限；而后给普通用户做个分组，选出一些人配置上这个角色，这样就能够进行测试了。

即时通讯原理

上面说下即时通讯服务的外围通信原理，和个别的 http 服务一样，有一个服务端和客户端进行通信，只不过具体的协定和解决形式不一样。

WebSocket

因为历史起因，当初支流的 http 协定是无状态协定（HTTP2 临时利用不宽泛），个别状况是由客户端被动发动申请，而后服务端去响应。那么为了实现服务端向客户端推送信息，就须要前端被动向后端去轮询，这种形式低效且容易出错, 在之前咱们的治理端首页的确是这么做的（5s 一次）。

为了实现这种服务端被动推送信息的需要，HTML5 开始提供一种在单个 TCP 连贯上进行全双工通信的协定，也就是 WebSocket。WebSocket 使得客户端和服务器之间的数据交换变得更加简略，容许服务端被动向客户端推送数据。WebSocket 协定在 2008 年诞生，2011 年成为国际标准，目前绝大部分浏览器都曾经反对了。

WebSocket 的用法相当简略:

var ws = new WebSocket("wss://echo.websocket.org");

ws.onopen = function(evt) {console.log("Connection open ...");
  ws.send("Hello WebSockets!");
};

ws.onmessage = function(evt) {console.log( "Received Message:" + evt.data);
  ws.close();};

ws.onclose = function(evt) {console.log("Connection closed.");
};

有了 WebSocket 协定让服务端被动推送信息有了先进的武器，那么有没有什么形式能够兼容新旧浏览器呢？其实很多人想到了这点，答案就是socket.io

socket.io

socket.io进一步封装了 WebSocket 的接口，而且能够在旧版本浏览器中自主切换到应用轮询的形式进行通信（咱们使用者是不会感知的），造成了一套对立的接口，大大加重了开发的累赘。次要具备以下长处：

1. 封装出了一套十分易用的接口，前后端对立，应用非常简单
2. 全平台反对（原生和 H5，微信小程序中也有对应的实现）
3. 自适应浏览器，在比拟老的浏览器中被动切换应用轮询的形式，不须要咱们本人搞轮询

这是 socket.io 主页

最快，最牢靠的即时通讯引擎(FEATURING THE FASTEST AND MOST RELIABLE REAL-TIME ENGINE)

应用起来真的很简略：

var io = require('socket.io')(80);
var cfg = require('./config.json');
var tw = require('node-tweet-stream')(cfg);
tw.track('socket.io');
tw.track('javascript');
tw.on('tweet', function(tweet){io.emit('tweet', tweet);
});

总结

有了以上的根底，咱们就根本实现了开始写代码之前的筹备：明确了这个利用的根底性能和实体之间的关系，也明确了根底的技术计划选型，划分了 3 个我的项目的各自工作。上面就开始实现 server 端吧

未完待续：下一篇介绍 server 端