(此文章,将随着记忆与问题暴露做不断的总结记录)
IM产品,做支撑的服务端系统,是一个分布式的系统,按照对数据的处理职责来看,大致分为四大类:
1.网关层 (需要bind在外网网卡上,其他层模块bind在内网网卡上)
解决用户接入问题,包括选择负载均衡,极速连接,访问控制,数据安全传输等。
常见的坑:
连接失败,连接慢;
非法连接;
非法请求;
攻击;
兼容各种子系统的协议,把其他的产品接入到IM体系里,可能要解决http/https协议转换;
解决接入层高并发是最有挑战性的事情。
2.逻辑层
解决消息转发,状态维护,路由信息查找,社交网络,群聊,音视频转发,用户行为埋点等。
常见的坑:
消息ID的唯一性保证,不可重复性,丢消息,分布式系统对维护与重启的环节要求很高,稍有不慎就会丢消息;
社交关系的维护,好友关系的正反推导是个复杂的问题;
大群问题,万人群消息的转发;
消息推送失败;
维护不同用户关于消息收发的复杂配置;
用户的状态信息维护是最痛苦的事情,服务器重启瞬间可能产生大量的广播,状态同步;
与其他业务系统的交互,依赖别人是最容易背黑锅的事情,多一份依赖多一份不可靠性。(此处背黑锅最多!)
3.数据存取层 (此层一定要做节点备份)
提供后端MYSQL,REDIS,高速缓存服务,文件上传与下载,从第三方服务中得到数据。
解决一些耗时易阻塞的操作,往往是多进程多线程,
常见的坑:
重启时一部分消息被丢失,不可还原是最痛苦的事情,所以一定要做冗余,灰度更新;
分布式缓存,保证数据的一致性是技术难点;
库表的设计需要对业务经验的积累;
对状态的同步,很难;
4.日志分析层 (此层是查BUG,后续无止境的工作,往往不被重视,实属运维运营岗)
建立完整的日志收集、搜索、可视化分析体系,对用户行为做分析,接口调用统计,提供可靠的数据报表,对异常波动做报警等;
常见的坑:
产品设计之初就没有把此层考虑进去,导致后面无法追踪问题;
对海量数据存储能力,与频繁的IO的处理,是个挑战;
埋点日志追踪不到线上BUG,是个痛苦的事情。
如果把这些层次都看成一体,得到用户反馈,然后去思考问题,那么常见的坑:
1.IM系统的复杂性首先被产品低估;
2.出现问题时不能有效定位来源在哪一个节点,这是分布式系统与多人协作开发的最大的痛苦,大家都证明自己无问题,但是总体就是有问题;
3.配置文件的一致性与即时更新,是个问题;对其中某个节点的重启,可能必须关联好几个节点做协同,没有对总体的把握性很容易产生脏数据。