企业微信IM消息系统架构设计及技术难点分析

消息系统在高峰期，因过载直接给用户返回失败，还显示红点之时，产品的核心体验会遭受严重冲击 。

过载保护的挑战

那种直接拒绝请求的过载保护策略，虽能够保全系统，然而却会给用户造成明显的干扰。在即时通讯场景里，发送消息属于最基础的功能，它的可用性要求近乎达到百分之百。一旦因为系统过载致使发送失败，前端出现异常提示，便会立刻引发用户的不满以及投诉。

所以，得针对简单且粗暴的过载拒绝策略予以优化，目的在于能够达成，一旦系统压力过大的这个状况时，却依旧照样可以优先保障核心消息发送流程取得成功，把失败给用户造成的影响降低到最小限度，并非是使得用户直接察觉到系统存在问题 。

核心链路优先保障

所要进行优化的核心思路在于区分主流程以及非主流程。像是发送普通消息这种的核心链路，必然要获得最高优先级的保障。针对于企业应用而言，内部员工之间的单聊以及百人以下小群的聊天是最为基础，且最为敏感的业务。

相反，并非处于核心地位的辅助功能呈现出别样情况，像是与外部系统相互连通以此展开权限验证，要不就是消息审计日志的同步工作，那么能够采用异步重试之类的机制。即便那些辅助流程在短时间之内出现延迟现象，或者终究走向失败结局，也万万不可以对用户发送以及接收消息的主要体验造成影响。

大群聊天的流量控制

大量人数超过一万的大规模群组之中所出现的高频发言情况，极有可能在短时间之内给消息分发系统带去规模硕大的压力。要是对此情形不加以有效的控制举措的话，那么单单一个热门群组所产生的流量，就很有可能致使整个服务陷入瘫痪状态。鉴于这样的状况，所以就必须得实施一项以群组作为维度标准的并发度限制措施的。

比如说，能够就每一个群ID的那些消息进行这样的分发以及有关速度方面做出管控之处，以此来避免它因为特别占有过多的系统供其使用的资源。像这样子，既能够达成那个作为沟通基本之需求的大群相关事宜，又能够防止局部出现较为突出的热点进而引发全局的那种服务崩塌的状况，从而保证大多数有所使用者的正常的使用不会受到干扰造成影响。

控制消息的服务降级

群资料变更之类的控制消息，得通知每一位成员。于小群而言，这般实时同步是不可或缺的。然而在人数达数千乃至数万人的大群里，广播一条控制消息，会催生海量的分发任务以及后续的数据拉取请求 。

面临这样的场景时，能够施行业务降级。针对大规模群组而言，部分并非关键的控制消息能够有选择性地舍弃或者延迟进行分发。借助牺牲大群当中某些功能的实时性，以此来换取整个消息系统在高峰期的稳定状态，这是一种务实的权衡之举。

消息状态的一致性保证

存在一个技术难点，那就是需要保证发送方与接收方能看到的消息状态保持一致。企业微信运用了一种简洁的方案，即当接收方读取消息之后，借助原有的消息通道，采用增量同步的方式同步一个已读状态 。

有一个发送方客户端，它在收到那个状态通知之后，会直接于本地更新对应消息的展示，将其替换成“已读”样式。采用的这种方法会复用现有的通道以及协议。这样一来，前后端的改造幅度较小，并且能够比较快地使得双方状态趋向于一致，达成一种平衡状态。

高并发下的数据写入

于每日处理数量达上亿条之消息的系统情形下，针对同一条消息的状态展开高并发更新操作（诸如多次进行已读回执之类），将会致使数据产生冲突现象。要是运用乐观锁等常规方案，于高频写入的状况之下，冲突率会颇高，进而对性能造成影响 。

有一种实践方案，它是把具有相同消息ID的状态更新请求开展串行化处理，这确保了数据的一致性，其逻辑实现相对而言较为简单，它能够有力地支撑高并发场景之下的可靠写入，还能满足海量消息处理的稳定需求 。

于您所涉业务范畴内，系统遭逢极大压力之际，您会率先确保何种功能的体验呢？究竟是核心的沟通功能，亦或是辅助的管理功能呢？期待于评论区分享您所持之观点，亦恳请点赞以予本文支持。