前言

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

本篇分析的是 HTTP 负载均衡.

基于 OpenResty 增加相关能力

核心基于 OpenResty，利用 lua 扩展 NGINX 本身的能力，增加

1. 上游服务探活
2. 用户鉴权
3. 用户级黑白名单
4. 频率限制

上游监控

使用 https://github.com/openresty/lua-resty-upstream-healthcheck 做 upstreams 的探活，并生成报告页面。

鉴权

对 /newapi/ 和 /package/qtapi/ 会做鉴权。

or.server.location.package.qtapi.conf

location /newapi/ {
    rewrite_by_lua_file /home/work/openresry/nginx/lua_app/checks/qim/checkchains.lua;
    proxy_pass http://im_http_service_api/im_http_service/newapi/;
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-Scheme    $scheme;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
}

checks/qim/checkchains.lua 中会从 HTTP Headers 中取出 qcookie 解析成一个 dict [code]，再从 dict 中拿出 q_ckey 的值 [code]。q_ckey 包含了 user, t, 和 key [code]，根据 user 的信息从 redis 中取出 hkeys，检查 md5(hash_key + t) 和 key 是否相等，相等则认为验证通过。

从解析逻辑可以看到: 1. qcookie 的格式为 {key1}={val1};{key2}={val2}...，即以 ; 分隔每个键值对，= 分隔键和值。 2. q_ckey 的值是一个由 base64 编码过的 {key1}={val1}&{key2}={val2}... 格式的值。

Questions：

• ckeycheck.lua#L92 在进行 key 计算的时候，调用的是 hkeys，而不是拿出 hash value？

Learned:

• redis.lua 通过 setmetatable 可以实现类似 Python 的 __getattr__ 效果。

用户级黑白名单

OR 也针对 /newapi/ 和 /package/qtapi/ 做用户级别黑白名单

处理过程大致为：

1. 和 鉴权 同样的步骤，从 qcookie 拿出 user_id
2. 如果 user_id 在 hardcode 的黑名单中，直接返回拒绝请求；如果 user_id 在 hardcode 的白名单，直接放行，不会进行频率检查。

频率限制

频率限制会以 HTTP method, HTTP request body, request url 三者的联合摘要作为 contentmd5 再和 RemoteAddr(IP) 连接作为 redis key 查询。 如果超过设置的 limit ，就会返回拒绝请求，否则在 redis 内加 1 并设置一个过期时间。

补充

在 NGINX 配置 中可以看到 /search/ 是没有进行上面提及的校验。 这部分 location 的校验散落在各个业务上游逻辑里，例如 search 的检查：https://github.com/qunarcorp/qtalk_search/blob/master/utils/authorization.py