IM产品开发中的问题与常见的坑

（此文章，将随着记忆与问题暴露做不断的总结记录）

IM产品，做支撑的服务端系统，是一个分布式的系统，按照对数据的处理职责来看，大致分为四大类：

1.网关层    （需要bind在外网网卡上，其他层模块bind在内网网卡上）

      解决用户接入问题，包括选择负载均衡，极速连接，访问控制，数据安全传输等。

     常见的坑：

     连接失败，连接慢；

     非法连接；

     非法请求；

     攻击； 

     兼容各种子系统的协议，把其他的产品接入到IM体系里，可能要解决http/https协议转换；

     解决接入层高并发是最有挑战性的事情。

2.逻辑层

  解决消息转发，状态维护，路由信息查找，社交网络，群聊，音视频转发，用户行为埋点等。

  常见的坑：

   消息ID的唯一性保证，不可重复性，丢消息，分布式系统对维护与重启的环节要求很高，稍有不慎就会丢消息；

   社交关系的维护，好友关系的正反推导是个复杂的问题；

   大群问题，万人群消息的转发；

   消息推送失败；

   维护不同用户关于消息收发的复杂配置；

   用户的状态信息维护是最痛苦的事情，服务器重启瞬间可能产生大量的广播，状态同步；

   与其他业务系统的交互，依赖别人是最容易背黑锅的事情，多一份依赖多一份不可靠性。（此处背黑锅最多!）

      

3.数据存取层 （此层一定要做节点备份）

 提供后端MYSQL，REDIS，高速缓存服务，文件上传与下载，从第三方服务中得到数据。

 解决一些耗时易阻塞的操作，往往是多进程多线程，

  常见的坑：

   重启时一部分消息被丢失，不可还原是最痛苦的事情，所以一定要做冗余，灰度更新；

   分布式缓存，保证数据的一致性是技术难点；

   库表的设计需要对业务经验的积累；

   对状态的同步，很难；

 

4.日志分析层 （此层是查BUG，后续无止境的工作，往往不被重视，实属运维运营岗）

 建立完整的日志收集、搜索、可视化分析体系，对用户行为做分析，接口调用统计，提供可靠的数据报表，对异常波动做报警等；

   [b]常见的坑：[/b]

[b]    产品设计之初就没有把此层考虑进去，导致后面无法追踪问题；[/b]

[b]    对海量数据存储能力，与频繁的IO的处理，是个挑战；[/b]

[b]    埋点日志追踪不到线上BUG，是个痛苦的事情。 [/b]



如果把这些层次都看成一体，得到用户反馈，然后去思考问题，那么常见的坑：

    1.IM系统的复杂性首先被产品低估；

    2.出现问题时不能有效定位来源在哪一个节点，这是分布式系统与多人协作开发的最大的痛苦，大家都证明自己无问题，但是总体就是有问题；

    3.配置文件的一致性与即时更新，是个问题；对其中某个节点的重启，可能必须关联好几个节点做协同，没有对总体的把握性很容易产生脏数据。