前言

昨天「去哪儿」开源了自研的 IM Startalk，作为一个在 IM 领域划水了一段时间的人，也想了解下其他人是如何去考虑 IM 设计，所以就开始了源码阅读之旅。接下来会用几篇文章简单分析一下。

本篇分析的是 Cowboy HTTP Server.

结构

基本采用了 Cowboy HTTP 框架实现，路由表保存在 config 中： config/ejb_http_server.config，让我想到 Haskell 的 yesod Orz。 于是整个项目就相对比较清晰了。 下面挑几个感兴趣的 API 来分析。

获取在线用户

http_getonlineuser.erl

从这个 module 可以看到几个点：

  1. 在线人数是通过 ets 缓存到 erlang 内。
  2. 用户会根据 Host 划分，跟 Domain 相关。猜测是类似于 BearyChat 的 Team 的概念。
  3. 表示用户的参数 u 是通过 query string 传进来，可能会有 username@domain 的形式存在。

获取 p2p 消息

http_getmsgs.erl

可以得到几个信息

  1. 这个 API 是通过指定发送人和接收人获取 p2p 在某个时间点之后（或之前）N 条聊天记录。
  2. check_time_limit 对请求做了一次频率限制

查聊天室消息

http_getmucmsg.erl

和 p2p 消息类似，不赘述

查询消息记录

http_gethistory.erl

  1. 根据消息 ID 查出未读的消息
  2. 根据 User 和 Domain 查出 Time 之后所有消息。

又是查消息

http_get_adjacentmsg.erl

这个 module 提供了一个 POST API，能查询 p2p 和 room 的聊天记录（通过 flag参数控制）。 p2p 部分和http_getmsgs.erl提供的又不太一样，虽然是从同一张表查询，但这个module会根据 Timestamp 判断是否在一个月内的数据，是的话会从msg_history中查询，否则从msg_history_backup查询。 而 room 部分，会从muc_room_history` 查询。

发送消息

http_sendmessage.erl

发送消息流程：

  1. 检查 IP 等是否在黑名单中
  2. 通过 Erlang RPC 发送消息。
    • 从 rpc_send_message/1 的实现，可以猜测系统内部实现了 random robin；Nodes 会在系统启动的时候加载，暂时没发现有 health check 等功能。
  3. 如果 Erlang RPC 发送失败，会 fallback 到 HTTP

但是目前无法理解几个地方，rpc_send_message/1 中，rpc:call 调用的是另一个节点同一个模块（http_sendmessage）的 http_send_message 函数。但实际上并不存在这个一个函数。即使存在，也不明白为何要进行一次 Erlang rpc 将创建消息的请求交给另一个节点处理，目前没发现负载检测的模块，所以通过当前节点发送 HTTP 请求应该会更快点。

其他

  1. 还有其他功能例如创建聊天室、创建机器人等也不赘述了，大都是 CRUD 操作。
  2. 暂时还没找到更新消息已读状态的逻辑，可能会在剩下的那个核心代码部分。 3.总体来看，这份代码的质量相对较低。代码中很多 typo、重复代码、僵尸代码，代码风格不统一等，有很多地方的实现也像是临时改掉，甚至还有错误（无法理解）的实现，还有安全性也需要注意，例如 ejb_odbc_query.erl DB 操作做的 escape 是手写的，这里会是一个注入点。