企业微信作为一款办公协同的产品，聊天消息收发是最基础的功能。消息系统的稳定性、可靠性、安全性尤其重要。
消息系统的构建与设计的过程中，面临着较多的难点。而且针对toB场景的消息系统，需要支持更为复杂的业务场景。
针对toB场景的特有业务有：
1）消息鉴权：关系类型有群关系、同企业同事关系、好友关系、集团企业关系、圈子企业关系。收发消息双方需存在至少一种关系才允许发消息；
2）回执消息：每条消息都需记录已读和未读人员列表，涉及频繁的状态读写操作；
3）撤回消息：支持24小时的有效期撤回动作；
4）消息存储：云端存储时间跨度长，最长可支持180天消息存储，数百TB用户消息需优化，减少机器成本；
5）万人群聊：群人数上限可支持10000人，一条群消息就像一次小型的DDoS攻击；
6）微信互通：两个异构的im系统直接打通，可靠性和一致性尤其重要。
整体架构分层如下。
1）接入层：统一入口，接收客户端的请求，根据类型转发到对应的CGI层。客户端可以通过长连或者短连连接wwproxy。活跃的客户端，优先用长连接发起请求，如果长连失败，则选用短连重试。
2）CGI层：http服务，接收wwproxy的数据包，校验用户的session状态，并用后台派发的秘钥去解包，如解密失败则拒绝请求。解密成功，则把明文包体转发到后端逻辑层对应的svr。
3）逻辑层：大量的微服务和异步处理服务，使用自研的hikit rpc框架，svr之间使用tcp短连进行通信。进行数据整合和逻辑处理。和外部系统的通信，通过http协议，包括微信互通、手机厂商的推送平台等。
4）存储层：消息存储是采用的是基于levelDB模型开发msgkv。SeqSvr是序列号生成器，保证派发的seq单调递增不回退，用于消息的收发协议。
发送方请求后台，把消息写入到接收方的存储，然后push通知接收方。接受方收到push，主动上来后台收消息。
不重、不丢、及时触达，这三个是消息系统的核心指标：
1）实时触达：客户端通过与后台建立长连接，保证消息push的实时触达；
2）及时通知：如果客户端长连接不在，进程被kill了，利用手机厂商的推送平台，推送通知，或者直接拉起进程进行收消息；
3）消息可达：假如遇到消息洪峰，后台的push滞后，客户端有轮训机制进行兜底，保证消息可达；
4）消息防丢：为了防止消息丢失，只要后台逻辑层接收到请求，保证消息写到接收方的存储，失败则重试。如果请求在CGI层就失败，则返回给客户端出消息红点；
5）消息排重：客户端在弱网络的场景下，有可能请求已经成功写入存储，回包超时，导致客户端重试发起相同的消息，那么就造成消息重复。为了避免这种情况发生，每条消息都会生成唯一的appinfo，后台通过建立索引进行排重，相同的消息直接返回成功，保证存储只有一条。
扩散读
即：每条消息只存一份，群聊成员都读取同一份数据。
优点：节省存储容量。
缺点：
① 每个用户需存储会话列表，通过会话id去拉取会话消息；
② 收消息的协议复杂，每个会话都需要增量同步消息，则每个会话都需要维护一个序列号。
扩散写
即：每条消息存多份，每个群聊成员在自己的存储都有一份。
优点：
① 只需要通过一个序列号就可以增量同步所有消息，收消息协议简单；
② 读取速度快，前端体验好；
③ 满足更多ToB的业务场景：回执消息、云端删除。
同一条消息，在每个人的视角会有不同的表现。例如：回执消息，发送方能看到已读未读列表，接受方只能看到是否已读的状态。云端删除某条群消息，在自己的消息列表消失，其他人还是可见。
缺点：存储容量的增加。
企业微信采用了扩散写的方式，消息收发简单稳定。存储容量的增加，可以通过冷热分离的方案解决，冷数据存到廉价的SATA盘，扩散读体验稍差，协议设计也相对复杂些。
1）每个用户只有一条独立的消息流。同一条消息多副本存在于每个用户的消息流中；
2）每条消息有一个seq，在同个用户的消息流中，seq是单调递增的；
3）客户端保存消息列表中最大seq，说明客户端已经拥有比该seq小的所有消息。若客户端被push有新消息到达，则用该seq向后台请求增量数据，后台把比此seq大的消息数据返回。
高峰期系统压力大，偶发的网络波动或者机器过载，都有可能导致大量的系统失败。im系统对及时性要求比较高，没办法进行削峰处理。那么引入一些柔性的策略，保证系统的稳定性和可用性非常有必要。
具体的做法就是启动过载保护策略：当svr已经达到最大处理能力的时候，说明处于一个过载的状态，服务能力会随着负载的增高而急剧下降。如果svr过载，则拒绝掉部分正常请求，防止机器被压垮，依然能对外服务。通过统计svr的被调耗时情况、worker使用情况等，判定是否处于过载状态。过载保护策略在请求高峰期间起到了保护系统的作用，防止雪崩效应。
解决方案思路就是：尽管失败，也返回前端成功，后台保证最终成功。
为了保证消息系统的可用性，规避高峰期系统出现过载失败导致前端出红点，做了很多优化。
具体策略如下：
1）逻辑层hold住失败请求，返回前端成功，不出红点，后端异步重试，直至成功；
2）为了防止在系统出现大面积故障的时候，重试请求压满队列，只hold住半小时的失败请求，半小时后新来的请求则直接返回前端失败；
3）为了避免重试加剧系统过载，指数时间延迟重试；
4）复杂的消息鉴权（好友关系，企业关系，集团关系，圈子关系），耗时严重，后台波动容易造成失败。如果并非明确鉴权不通过，则幂等重试；
5）为了防止作恶请求，限制单个用户和单个企业的请求并发数。例如，单个用户的消耗worker数超过20%，则直接丢弃该用户的请求，不重试。
优化后，后台的波动，前端基本没有感知。即时通讯开发
系统稳定性设计2：系统解耦
由于产品形态的原因，企业微信的消息系统，会依赖很多外部模块，甚至外部系统。
例如：与微信消息互通，发送消息的权限需要放到ImUnion去做判定，ImUnion是一个外部系统，调用耗时较长。
再如：金融版的消息审计功能，需要把消息同步到审计模块，增加rpc调用。
再如：客户服务的单聊群聊消息，需要把消息同步到crm模块，增加rpc调用。为了避免外部系统或者外部模块出现故障，拖累消息系统，导致耗时增加，则需要系统解耦。
我们的方案：与外部系统的交互，全设计成异步化。
思考点：需要同步返回结果的请求，如何设计成异步化？
例如：群聊互通消息需经过ImUnion鉴权返回结果，前端用于展示消息是否成功发送。先让客户端成功，异步失败，则回调客户端使得出红点。
如果是非主流程，则异步重试保证成功，主流程不受影响，如消息审计同步功能。那么，只需要保证内部系统的稳定，发消息的主流程就可以不受影响。
系统稳定性设计3：业务隔离
企业微信的消息类型有多种：
1）单聊群聊：基础聊天，优先级高；
2）api 消息：企业通过api接口下发的消息，有频率限制，优先级中；
3）应用消息：系统应用下发的消息，例如公告，有频率限制，优先级中；
4）控制消息：不可见的消息。例如群信息变更，会下发控制消息通知群成员，优先级低。
群聊按群人数，又分成3类：
1）普通群：小于100人的群，优先级高；
2）大 群：小于2000人的群，优先级中；
3）万人群：优先级低。
业务繁多：如果不加以隔离，那么其中一个业务的波动有可能引起整个消息系统的瘫痪。
重中之重：需要保证核心链路的稳定，就是企业内部的单聊和100人以下群聊，因为这个业务是最基础的，也是最敏感的，稍有问题，投诉量巨大。
其余的业务：互相隔离，减少牵连。按照优先级和重要程度进行隔离，对应的并发度也做了调整，尽量保证核心链路的稳定性。