前言

昨天「去哪儿」开源了自研的 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