web技术分享| 一人一天一个可移植的实时聊天系统

在开始打造我们自己的实时聊天系统之前，我们需要先思考🤔几个问题：

• 用户体量大概多少？如何扩容？
• 用户分布的区域？
• 如何保证消息（低延时、必）送达？

做过 IM 或信令的小伙伴都知道，实时传输对服务端有着颇高的要求。就以社交 APP 为例，每秒种要处理成百上千甚至更多的文字和图片的传输；弱网丢包的情况要保证消息的完整性的同时还要确保消息已送达；这其中的技术原理和解决方案不是一个 WebSocket 所能涵盖的。

就消息必达而言，系统除了要有择优链路能力以外，还要具备多活链路。比如：一旦有一条链路出现问题，那么该消息就不一定能够送达。然而现实环境往往必我们想象中理想环境来的更糟糕和残酷，与此同时我们还要面对：网络丢包、用户量指数上升并发上不去，甚至系统宕机等等。

因此，要打造一个怎样的聊天系统，取决于我们产品的需求，根据需要选择集群部署的数量、节点的分布等诸多因素。

实时聊天系统应具备的特性

• 高并发
• 低延时
• 消息必达
• 弱网抗性
• 集群部署
• 消息推送（可选）

实时聊天系统应具备的功能

• 点对点消息
• 群组消息
• 呼叫邀请

现在的社交 APP 玩法十分丰富，提供图文传输还加入了实时通讯模块，衍生出了直播连麦、主播 PK等诸多玩法，其中很大一部分都是通过自定义实时消息来完成。举个简单的例子：微信电话，A 给 B 发送一条带状态的消息、B 接收或者挂断操作之后，状态会被锁定之后无法变更，系统再将结果发送给 A，这个过程我们称之为呼叫邀请。

总之，实时消息不仅能带来通讯便利，同时还能辅助我们丰富我们的