IM即时通讯开发架构：可靠性有序性弱网优化

Posted 2022-11-14 wecloud1314

消息的可靠性是IM系统的典型技术指标，对于用户来说，消息能不能被可靠送达（不丢消息），是使用这套IM的信任前提。

 

换句话说，如果这套IM系统不能保证不丢消息，那相当于发送的每一条消息都有被丢失的概率，对于用户而言，一定会不会“放心”地使用它，即“不信任”这套IM。

从产品经理的角度来说，有这样的技术障碍存在，再怎么费力的推广，最终用户都会很快流失。所以一套IM如果不能保证消息的可靠性，那问题是很严重的。

消息可靠性主要依赖2个逻辑来保障：

    1）上行消息可靠性；
    2）下行消息可靠性。

1）针对上行消息的可靠性，可以这样的思路来处理：

用户发送一个消息（假设协议叫PIMSendReq），用户要给这个消息设定一个本地ID，然后等待服务器操作完成给发送者一个PIMSendAck（本地ID一致），告诉用户发送成功了。

如果等待一段时间，没收到这个ACK，说明用户发送不成功，客户端SDK要做重试操作。

2）针对下行消息的可靠性，可以这样的思路来处理：

服务收到了用户A的消息，要把这个消息推送给B、C、D 3个人。假设B临时掉线了，那么在线推送很可能会失败。

因此确保下行可靠性的核心是：在做推送前要把这个推送请求缓存起来。

这个缓存由存储系统来保证，MsgWriter要维护一个（离线消息列表），用户的一条消息，要同时写入B、C、D的离线消息列表，B、C、D收到这个消息以后，要给存储系统一个ACK，然后存储系统把消息ID从离线消息列表里拿掉。

针对消息的可靠性问题，具体的解决思路还可以从另一个维度来考虑：即实时消息的可靠性和离线消息的可靠性。

消息的有序性问题是分布式IM系统中的另一个技术“硬骨头”。

因为是分布式系统，客户端和服务器的时钟可能是不同步的。如果简单依赖某一方的时钟，就会出现大量的消息乱序。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

比如只依赖客户端的时钟，A比B时间晚30分钟。所有A给B发消息，然后B给A回复。

发送顺序是：

客户端A：“XXX”
客户端B：“YYY”

接收方的排序就会变成：

客户端B：“YYY”
客户端A：“XXX”

因为A的时间晚３０分钟，所有A的消息都会排在后面。

如果只依赖服务器的时钟，也会出现类似的问题，因为2个服务器时间可能也不一致。虽然客户端A和客户端B时钟一致，但是A的消息由服务器S1处理，B的消息由服务器S2处理，也会导致同样消息乱序。

为了解决这种问题，我的思路是通过可以做这样一系列的操作来实现。

1）服务器时间对齐：

这部分就是后端运维的锅了，由系统管理员来尽量保障，没有别的招儿。

2）客户端通过时间调校对齐服务器时间：

比如：客户端登录以后，拿客户端时间和服务器时间做差值计算，发送消息的时候考虑这部分差值。

在我的im架构里，这个能把时间对齐到100ms这个级，差值再小的话就很困难了，因为协议在客户端和服务器之间传递速度RTT也是不稳定的（网络传输存在不可控的延迟风险嘛）。

3）消息同时带上本地时间和服务器时间：

具体可以这样的处理：排序的时候，对于同一个人的消息，按照消息本地时间来排；对于不同人的消息，按照服务器时间来排，这是插值排序算法。

IM系统架构中的数据安全比一般系统要复杂一些，从通信的角度来说，它涉及到socket长连接通信的安全性和http短连接的两重安全性。而随着IM在移动端的流行，又要在安全性、性能、数据流量、用户体验这几个维度上做权衡，所以想要实现一套完善的IM安全架构，要面临的挑战是很多的。

IM系统架构中，所谓的数据安全，主要是通信安全和内容安全。

所谓的通信安全，这就要理解IM通信的服务组成。

目前来说，一个典型的im系统，主要由两种通信服务组成：

    1）socket长连接服务：技术上也就是多数人耳熟能详的网络通信这一块，再细化一点也就是tcp、udp协议这一块；
    2）http短连接服务：也就是最常用的http rest接口那些。

这个可能不太好理解，上面既然实现了通信安全，那为什么还要纠结“内容安全”？

我们了解一下所谓的密码学三大作用：加密（ Encryption）、认证（Authentication），鉴定（Identification） 。

详细来说就是：

    加密：防止坏人获取你的数据。
    认证：防止坏人修改了你的数据而你却并没有发现。
    鉴权：防止坏人假冒你的身份。

在上节中，恶意攻击者如果在通信环节绕开或突破了“鉴权”、“认证”，那么依赖于“鉴权”、“认证”的“加密”，实际上也有可有被破解。

针对上述问题，那么我们需要对内容进行更加安全独立的加密处理，就这是所谓的“端到端加密”（E2E）。

比如，那个号称无法被破解的IM——Telegram，实际上就是使用了端到端加密技术。

雪崩效应问题

在分布式的IM架构中，存在雪崩效应问题。

我们知道，分布式的IM架构中，为了高可用性，用户每次登陆都是根据负载均衡算法分配到不同的服务器。那么问题就来了。

举个例子：假设有5个机房，其中A机房故障，导致这个机房先前服务的用户都跑去B机房。B机房不堪重负也崩溃了，A+B的用户跑去机房C，连锁反应会导致所有服务挂掉。

防止雪崩效应需要在服务器架构，客户端链接策略上有一些配合的解决方案。服务器需要有限流能力作为基础，主要是限制总服务用户数和短时间链接用户数。

在客户端层面，发现服务断开之后要有一个策略，防止大量用户同一时间去链接某个服务器。

通常有2种方案：

    1）退避：重连之间设置一个随机的间隔；
    2）LBS：跟服务器申请重连的新的服务器IP，然后由LBS服务去降低短时间分配到同一个服务器的用户量。

这2种方案互不冲突，可以同时做。