本文字数：4591字
预计阅读时间：25
01
导读
如今OpenResty已广泛被各个互联网公司在实际生产环境中应用，在保留Nginx高并发、高稳定等特性基础上，通过嵌入Lua来提升在负载均衡层的开发效率并保证其高性能。本文主要介绍接口鉴权、流量控制以及记录追踪几个工具在实际生产环境中的应用实践，用于解决实际业务问题，提升业务运维效率，对于Openresty基本原理不再赘述。
1.1 OpenResty简介
OpenResty官网介绍如下：
1、OpenResty是一个基于Nginx与Lua的高性能Web平台，其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态网关；
2、OpenResty通过汇聚各种设计精良的Nginx模块（主要由OpenResty团队自主开发），从而将Nginx有效地变成一个强大的通用Web应用平台。这样，Web开发人员和系统工程师可以使用Lua脚本语言调动Nginx支持的各种C以及Lua模块，快速构造出足以胜任10K乃至1000K以上单机并发连接的高性能Web应用系统；
3、OpenResty的目标是让你的Web服务直接跑在Nginx服务内部，充分利用Nginx的非阻塞I/O模型，不仅仅对HTTP客户端请求,甚至于对远程后端诸如MySQL、PostgreSQL、Memcached以及Redis等都进行一致的高性能响应；
4、目前，OpenResty已在TikTok、微软、淘宝、腾讯、网易、百度、平安银行以及搜狐等各个行业广泛应用，本文主要对于生产环境的应用实践进行展开描述，对于OpenResty本身的实现原理不再阐述。
02
工具介绍
2.1 接口鉴权
-背景：随着线上环境的日益复杂，服务接口请求很容易被外部拦截，根据拦截的接口请求，执行数据的爬取，外部恶意刷量、攻击等等，对线上服务安全性、稳定性以及可用性造成一定的影响，因此，服务接口安全性需求的也日益增加；
-目标：实现一个通用的、经过简单配置变更即可快速实现指定服务接口接入鉴权处理逻辑，增强服务接口安全性，同时可在不同APP版本之间，实现灵活配置指定是否参与鉴权，参与鉴权使用的key等等，在保证服务接口安全的同时，兼顾老用户的使用体验；
-适用场景：适用于安全性要求相对较低，接口接入鉴权拦截效率高的场景，例如：新闻内容相关服务接口等。而对于安全性要求较高的服务接口则不适用，例如：用户信息相关服务接口等。
2.1.1 实现原理
1、通过WEB端实现APP版本、versionkey、鉴权接口以及鉴权开关的动态管理；
2、Lua初始化指定内存区，动态加载数据库中存储的鉴权接口、鉴权key等相关信息到内存中，供后续处理逻辑使用；
3、客户端版本指定区间范围内固定versionkey，在用户请求时，客户端根据versionkey进行计算生成鉴权key，并拼接到用户请求地址参数后进行下发；
4、用户请求到负载均衡层时，进行用户请求参数解析，对用户请求类型、参数中APP版本、鉴权参数等进行校验，判断用户请求是否参与鉴权；
5、负载均衡层针对参与鉴权的用户请求，进行请求参数解析签名，按照约定算法进行参数排序组装；
6、负载均衡层根据APP版本区间对应的versionkey以及约定的计算算法，计算生成鉴权key，并与客户端下发key进行比对；
7、针对匹配成功的请求进行放行，匹配失败的请求进行拦截并向客户端返回鉴权失败消息。
2.1.2 注意事项
1、versionkey和APP版本区间是1对多的关系，需采用前闭后开区间执行严格对应，防止执行APP版本切换versionkey时导致新版本客户端用户请求鉴权失败；
2、用户请求参数组装，需注意去重、解码、排序，不同的请求类型例如get和post，请求参数格式存在差别，需对请求url或者body体中的参数进行解码、去重、排序后进行鉴权key计算，避免因APP端和负载均衡层参数形式展示不同导致计算的鉴权key不同，影响正常的用户请求；
3、鉴权数据可视化，参与鉴权的接口、鉴权流量，鉴权失败量、鉴权失败原因等需实现可监控告警，及时发现鉴权异常问题，避免因参与鉴权影响正常用户体验；
4、需保留鉴权动态开关功能设置，以便于实现秒级打开/关闭鉴权拦截功能，实现快速鉴权拦截切换，保障线上业务安全性。
2.1.3 处理流程
1、APP接收用户请求，调用具体的服务接口响应本地用户请求；
2、OpenResty源站接收本次请求，进行用户请求参数解析，如是Get请求，则解析请求参数，如是Post请求则解析请求的参数和Body体；
3、进入鉴权判断逻辑之前，首先对解析参数中APP版本进行判断，此次用户请求携带的APP版本是否在参与鉴权的APP版本区间之内，如不在，则正常转发此次用户请求到后端对应服务，响应处理本地请求；
4、如此次用户请求携带的APP版本在鉴权版本区间范围之内，则进一步判断用户请求携带的鉴权参数是否完整，如鉴权参数不全，则向APP返回报错信息：鉴权参数不全；结束本次用户请求的处理过程；
5、如用户请求携带鉴权参数完整，则对本次用户请求的时效性进行判断，如不符合预期，则向APP返回报错信息：用户请求不在有效期内；结束本次用户请求的处理过程；
6、如鉴权参数完整，且在有效期内，则开始根据约定的算法、用户请求参数和app key，计算鉴权key，并与APP下发的鉴权key进行校验对比，如不匹配，则向APP返回报错信息：鉴权key错误；结束本次用户请求的处理过程；
7、如鉴权key校验通过，则顺利完成本次鉴权逻辑处理，转发到后端服务进行响应处理本次用户请求。
鉴权处理流程图：
2.1.4 实现简介
2.1.4.1 获取versionkey
根据APP版本获取该版本对应的versionkey，需要注意的是，一个versionkey的有效APP版本区间，例如a版本开始使用key1进行鉴权，到d版本开始切换使用key2，这样key1对应的APP版本区间就是[a, d)：
local function get_version_key(version)
local version_number = blacklist:get(config.sig_version)
local first_version = blacklist:get(config.sig_first_version)
local first_version_key = blacklist:get(first_version)
local lower_version_key = first_version_key
for i = 2, version_number, 1 do
local n = tostring(i)
local k = config.sig_version_number_prefix .. n
local v = blacklist:get(k)
if v == nil then
return nil, "not found ".. k
end
if version < v then
return lower_version_key, nil
end
local version_key = blacklist:get(v)
if version_key == nil then
return nil, "not found " .. v
end
lower_version_key = version_key
end
return lower_version_key, nil
end2.1.4.2 鉴权拦截功能
针对参与鉴权的用户请求，判断鉴权参数完整性、鉴权key准确性以及鉴权失败拦截信息反馈APP端等：
local function sig_check()
local sig_prefix = ngx.var.sig_prefix
if sig_prefix == nil or sig_prefix == "" then
--ngx.log(ngx.ERR, "sig_prefix not set")
return
end
-- 鉴权动态开关, 控制是否开启鉴权功能
local switch_flag = config.sig_switch .. sig_prefix
local init_version = blacklist:get(switch_flag)
if init_version == nil then
ngx.log(ngx.ERR, "switch_flag not set")
return
end
local sig_string, create_err
if ngx.var.request_method == "GET" then
sig_string, create_err = create_get_method_sig_string()
else
-- post and 请求格式
content_type == "application/json" then
sig_string, create_err = create_post_sig_string()
sig_string, create_err = create_post_json_method_sig_string()
else
return
end
end
sig_string = sig_string .. version_key
#鉴权计算,使用算法根据实际需求替换字符串“aa”
local aa = resty_aa:new()
if aa == nil then
ngx.log(ngx.ERR, "resty_aa new err ")
return
end
local ok = aa:update(sig_string)
if not ok then
ngx.log(ngx.ERR, "resty_aa update err ")
return
end
local digest = aa:final()
local right_sig = resty_str.to_hex(digest)
if right_sig ~= sig then
ngx.log(ngx.ERR, "signature failed, right_sig: ", right_sig, " client_sig: ", sig, " sig_string: ", sig_string)
end2.1.4.3 鉴权数据可视化
鉴权监控示例图：
1、参与鉴权接口总计QPS统计样例图：
2、分接口鉴权QPS统计样例图：
3、鉴权失败情况统计样例图：
4、鉴权失败告警信息样例图：
2.2 流量控制
当今线上业务服务都采用多IDC或多可用区部署，保障单个IDC或可用区不可用时业务的可用性，如遇到IDC/可用区网络割接、机器维护时，如何快速摘到相关业务流量，保证用户使用不受影响呢？服务异常时，如何快速摘掉一个节点流量保护排查现场，快速恢复服务呢？流量控制工具的设计实现，主要目标就是在负载均衡层可以快速服务摘掉一个节点、一个IDC/可用区的业务流量，满足以上场景使用需求。
2.2.1 实现原理
1、WEB端进行源站节点、需要摘掉的服务节点、IP或者IP段等信息的动态管理维护；
2、Lua实现共享内存区域初始化，加载动态置为down状态的节点信息到共享内存；
3、通过lua的set_peer_down方法，将指定服务节点、IP或者IP段动态置为down/up状态，实现动态摘掉/恢复指定服务节点、指定机器或者指定IDC/可用区的线上流量。
2.2.2 注意事项
1、需注意源站nginx进程多woker之间数据保持同步问题，通过共享内存解决；
2、节点状态监控，实时监控确认节点状态，防止节点状态动态变更失败；
3、节点状态置为down有效期告警管理，避免人工置为down状态摘掉流量后，忘记恢复。
2.2.3 处理流程
2.2.4 实现简介
2.2.4.1 共享内存初始化
初始化共享内存，用于存放节点以及节点状态信息，openresty多woker进程，通过共享内存获取节点及状态信息，实现每个woker节点处理请求，获取到的后端集群节点状态数据一致性：
lua_shared_dict healthcheck 1m;
lua_shared_dict logger_dict 10m;
lua_shared_dict logger_metric_dict 10m;2.2.4.2 节点状态变更
通过“set_peer_down”将指定节点状态进行变更，控制节点流量开关，这里需要注意针对backup节点需特殊处置，避免未实现完全摘除指定节点流量的目标：
local function set_primary_backup_peer_down(name, addr, is_backup, down_value)
local err_msg
local ok = false
local peers
if is_backup then
peers, err_msg = get_backup_peers(name)
else
peers, err_msg = get_primary_peers(name)
end
if not peers then
err_msg = "failed to get servers in upstream "..name.." err: "..err_msg
return ok, err_msg
end
for i, srv in ipairs(peers) do
for k, v in pairs(srv) do
if k == "name" and v == addr then
local peer_id = i - 1
ok, err_msg = set_peer_down(name, is_backup, peer_id, down_value)
break
end
end
end
return ok, err_msg
end2.3 记录追踪
2.3.1 实现原理
1、WEB端维护CID白名单，控制过滤收录的用户请求日志；
2、Lua开发实现过滤器，实现在Openresty集群，将指定CID用户的所有请求记录进行过滤；
3、Lua实现批处理器，将过滤器处理的请求记录数据批量写入ES集群（这里以ES为例）。
2.3.2 注意事项
1、数据批量处理，杜绝过滤一条处理一条，避免对后端存储ES集群造成读写压力；
2、批处理逻辑设置超时时间，避免因过滤数据较少，导致数据长时间未写入后端存储。
2.3.3 处理流程
2.3.4 实现简介
2.3.4.1 全局配置
通过nginx http配置中，进行过滤器全局配置，实现针对整个Openresty集群的用户请求进行过滤处理，避免针对所有接口进行过滤器配置：
log_by_lua_file "/opt/openresty/lualib/logger-plugin/logger.lua";
server {
set $resp_body "";
body_filter_by_lua_file "/opt/openresty/lualib/logger-plugin/filter.lua";
}2.3.4.2 过滤器
过滤器需要设置body体大小，避免因用户请求返回数据较大影响处理效率：
local ngx = ngx
local string = string
local max_size = 51200 -- 50 * 1024 = 50k
local body = string.sub(ngx.arg[1], 1, max_size)
ngx.ctx.resp_buffered = (ngx.ctx.resp_buffered or "") .. body
if ngx.arg[2] then
ngx.var.resp_body = ngx.ctx.resp_buffered
end2.3.4.3 批处理器
批处理限制数据，声明设置批量处理条数限制、处理超时时间设置、后端存储配置以及批量处置的整体body大小限制等等：
local _M = {}
_M.conf = {
dict = ngx.shared.logger_dict,
name = "ES",
send_metric_exptime = 3600, -- second
elasticsearch_index = "****",
endpoint_addr = "ES地址",
-- 失败后，延迟发送时间
response_body_max_size = 51200, -- 50 * 1024
response_body_max_tag = "response_body_max_tag",
retry_delay = 5, -- second
-- 发送失败最大次数
max_retry_count = 5,
-- 设置每批发送日志的最大条数，当日志条数达到设置的最大值时，会自动推送全部日志到 ES
batch_max_size = 1000,
batch_max_size_exceeded_metric = "***",
batch_log_max_size = 52428800, -- bit, 50 * 1024 * 1024 bit = 50M
batch_log_max_size_metric = "***",
batch_log_max_size_exceeded_metric = "***",
-- inactive_timeout 刷新缓冲区的最大时间（以秒为单位），
-- 当达到最大的刷新时间时，无论缓冲区中的日志数量是否达到设置的最大条数，
-- 也会自动将全部日志推送到 ES
inactive_timeout = 10,
-- buffer_duration: 必须先处理批次中最旧条目的最长期限（以秒为单位）
buffer_duration = 10,
}
return _M03
总结
本文主要介绍了鉴权和流量控制工具在生产环境的实践，通过Lua开发实现Openresty端工具链开发实现，在不影响负载均衡层性能的前提下，快速构建运维工具，提升运维工作效率。Openresty在互联网行业有较广泛的应用，本文只是简单介绍了这几个工具的实践，希望能够对大家日常工作起到帮助作用。
参考文档：
1、Openresty：[http://openresty.org/cn/nginx.html]
2、lua-nginx-module：[https://github.com/openresty/lua-nginx-module]
3、ngxreqget_uri_args：[https://github.com/openresty/lua-nginx-module#ngxreqget_uri_args]
4、ngxreqget_post_args：[https://github.com/openresty/lua-nginx-module#ngxreqget_post_args]
5、lua-upstream-nginx-module：[https://github.com/openresty/lua-upstream-nginx-module]
6、set_peer_down：[https://github.com/openresty/lua-upstream-nginx-module#set_peer_down]
7、lua-resty-elasticearch：[https://github.com/midoks/lua-resty-elasticsearch]
8、lua-resty-http：[https://github.com/ledgetech/lua-resty-http]
