内容简介:昨天「去哪儿」开源了自研的 IM本篇分析的是基本采用了 Cowboy HTTP 框架实现,路由表保存在 config 中:
前言
昨天「去哪儿」开源了自研的 IM Startalk ,作为一个在 IM 领域划水了一段时间的人,也想了解下其他人是如何去考虑 IM 设计,所以就开始了源码阅读之旅。接下来会用几篇文章简单分析一下。
本篇分析的是 Cowboy HTTP Server .
结构
基本采用了 Cowboy HTTP 框架实现,路由表保存在 config 中: config/ejb_http_server.config ,让我想到 Haskell 的 yesod Orz。 于是整个项目就相对比较清晰了。 下面挑几个感兴趣的 API 来分析。
获取在线用户
从这个 module
可以看到几个点:
-
在线人数是通过
ets
缓存到 erlang 内。 -
用户会根据
Host
划分,跟Domain
相关。猜测是类似于 BearyChat 的 Team 的概念。 -
表示用户的参数
u
是通过 query string 传进来,可能会有username@domain
的形式存在。
获取 p2p 消息
可以得到几个信息
check_time_limit
查聊天室消息
和 p2p 消息类似,不赘述
查询消息记录
- 根据消息 ID 查出未读的消息
-
根据
User
和Domain
查出Time
之后所有消息。
又是查消息
这个 module 提供了一个 POST API,能查询 p2p 和 room 的聊天记录(通过 flag 参数控制)。
p2p 部分和
http_getmsgs.erl 提供的又不太一样,虽然是从同一张表查询,但这个
module 会根据 Timestamp 判断是否在一个月内的数据,是的话会从
msg_history 中查询,否则从
msg_history_backup 查询。
而 room 部分,会从
muc_room_history` 查询。
发送消息
发送消息流程:
- 检查 IP 等是否在黑名单中
-
通过 Erlang RPC 发送消息。
- 从 rpc_send_message/1 的实现,可以猜测系统内部实现了 random robin;Nodes 会在系统启动的时候加载,暂时没发现有 health check 等功能。
- 如果 Erlang RPC 发送失败,会 fallback 到 HTTP
但是目前无法理解几个地方, rpc_send_message/1
中, rpc:call
调用的是另一个节点同一个模块( http_sendmessage
)的 http_send_message
函数。但实际上并不存在这个一个函数。即使存在,也不明白为何要进行一次 Erlang rpc 将创建消息的请求交给另一个节点处理,目前没发现负载检测的模块,所以通过当前节点发送 HTTP 请求应该会更快点。
其他
- 还有其他功能例如创建聊天室、创建机器人等也不赘述了,大都是 CRUD 操作。
-
暂时还没找到更新消息已读状态的逻辑,可能会在剩下的那个核心代码部分。
3.总体来看,这份代码的质量相对较低。代码中很多 typo、重复代码、僵尸代码,代码风格不统一等,有很多地方的实现也像是临时改掉,甚至还有错误(无法理解)的实现,还有安全性也需要注意,例如 ejb_odbc_query.erl
DB 操作做的
escape
是手写的,这里会是一个注入点。
以上所述就是小编给大家介绍的《去哪儿 IM 分析 - Cowboy HTTP Server》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 使用动态分析技术分析 Java
- 使用动态分析技术分析 Java
- 案例分析:如何进行需求分析?
- 深度分析ConcurrentHashMap原理分析
- 如何分析“数据分析师”的岗位?
- EOS源码分析(3)案例分析
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
URL 编码/解码
URL 编码/解码
XML、JSON 在线转换
在线XML、JSON转换工具