好未来轻舟业务网关性能提升之旅

1、控制颗粒细

相比于集团网关，轻舟业务网关更贴近于业务。拥有更细颗粒度的控制。我们以method+path+api_version来确定唯一控制级，在这个控制级里可设置是否签名,登录态鉴权,内外网访问,后端转发Path,后端服务器等等。可以说是以接口来控制业务。

e.g

请求 /api-passport/user/info/base => api-pas sport服务器组 后端uri为api/v1/user/info/base 需要鉴权 不需要签名 可公网访问

请求 /api-passport/user/phone => api-pass port服务器组 后端uri为api/v1/user/phone 需要鉴权 需要签名 可公网访问

请求 /wrk/test => wrk服务器组 后端uri为 api/ test 不需要鉴权 不需要签名 只允许内网访问

2、总是出现一些莫名其妙的数据丢失

在网关内，我们为了保证数据一致性，采用了nginx.dict的方式来存储的数据。在该模型下数据都存储在master的内存中，当Worker节点需要使用他的时候，需要通过IPC方式进行同步。且OpenResty为了保证数据一致性，该操作读写的时候均有唯一锁。我们在业务中遇到莫名其妙的dict丢失。重新写入数据就正常。至今未找到原因

3、性能过差，在网关层消耗时间过多

由于我们的颗粒过细，且支持restful这种需要通过正则才能匹配的路由。所以当我们在做路由解析的时候采取的是通过遍历所有路由，然后正则匹配。由于正则匹配非常消耗性能。导致在网关层消耗时间过长，QPS较低。

介于以上情况，我们对网关进行了优化。优化之后单机QPS4核的服务器可达到8wQPS(当然这个性能受限于后端服务以及服务器的网卡)。

在此过程中，使用了API7开源的很多组件以及apisix中很多高性能优化的点。非常感谢API7团队。

FFI

FFI全称是Foreign function interface。在luajit中我们可通过FFI在一个进程内去调用C级别的函数。相比于自己去实现会提升非常多的性能

例子:

在UDC的SDK中，需要去获取到机器的内核版本,CPU架构等等。但是这个数据Lua/OpenResty并没有直接暴露给我们。只能通过Lua去执行uname方式去获取。但是如果想获取到Shell的返回值就势必需要使用到io。但是在lua中io事件本身是阻塞的，一旦阻塞就会有影响同进程上的其他Lua子协程。但是本身系统级别是有暴露uname这个C接口的。那么我们使用FFI的方式去调用C中的uname就可以拿到我们想要的结果

-- 定义FFIffi.cdef [[    int uname(struct uts *buf);]]
local os = ffi.os
--  macOS和Linux中的uts的定义不一样，所以需要判断定义if os == "OSX" then    ffi.cdef [[        struct uts {                char os[256];                char hostname[256];                char release[256];                char version[256];                char machine[256];                char domain[256];        };    ]]elseif os == "Linux" then    ffi.cdef [[        struct uts {                char os[65];                char hostname[65];                char release[65];                char version[65];                char machine[65];                char domain[65];        };    ]]end
_M.os = osfunction _M:getSystemInfo()    local res = {}        -- Windows 不支持uname。暂时没有Windows运行需求。所以做unkonw兜底    if self.os == "Windows" then        res["os"] = "Windows"        res["hostname"] = "unknown"        res["release"] = "unknown"        res["version"] = "unknown"        res["machine"] = "unknown"        return res    end
    local uts = ffi.new("struct uts[1]")    C.uname(uts)    res["os"] = ffi.string(uts[0].os)    res["hostname"] = ffi.string(uts[0].hostname)    res["release"] = ffi.string(uts[0].release)    res["version"] = ffi.string(uts[0].version)    res["machine"] = ffi.string(uts[0].machine)    return resend

可以看到我们使用ffi.cdef定义了C中的接口后。直接使用C.函数名就可以直接调用系统中的函数。就可以获得对应的内核版本号等信息。且由于是直接调用C函数，他并不存在协程阻塞哦。

复用

这里说的复用并不是代码的复用。而是将table,变量等进行复用

Table复用

在Lua中，Table相当于是PHP中的array。但是新建的开销 相比于复用肯定是来的高的。OpenResty官方团队实现了tablepool(Table池)

Demo:

access_by_lua_block {  local tablepool = require "tablepool"   ngx.ctx.api_ctx = tablepool.fetch("ngx_ctx",0,10)}
log_by_lua_block {  local tablepool = require "tablepool"  tablepool.release("ngx_ctx",ngx.ctx.api_ctx)}

我们在Access阶段创建pool后，可按照正常的table方式来使用。使用完成后可直接在log阶段内直接对table进行回收。回收会tablepool组件会在自动清空table中的数据，来保证下次获取的时候不会出现数据污染

协程内的缓存

在网关中，我们需要频繁的获取Header中的数据。在OpenResty中我们采用ngx.re.get_ headers()。虽然这是系统级的函数，底层也是使用高效的FFI实现的。但是也会产生性能开销。所以我们可以使用context来做一层协程内的缓存。我们封装了自己的request类。

local req_header  = ngx.req.get_headers
local function get_header(ctx,key,default) then    if ctx.header == nil then      ctx.header = ngx.req.get_headers()    end    return ctx.header[key] or defaultend

毕竟Lua的Table的性能会远远高于FFI每次获取的性能。这样做了一层协程内的缓存。当然ngx.var变量也可以这样处理。这样可以大大提供我们的性能。

遍历+正则 VS radixtree

前面提到业务网关的颗粒度非常细，基本上使用uri+method+version来匹配。在早期版本中我们采用的是遍历+正则。也就是将Route进行挨个遍历，使用正则来匹配。他的复杂度是O(n)这边的n=路由条数。随着路由增多，那么我们的性能会越来越差,而且我们存在restful路由，需要使用大量的正则匹配。而无法直接使用table筛选。而且路由作为网关最最基础的组件，我们必须保证其高性能,低资源占用

介于业务特性，我们把目光看到了lua-resty-radixtree。他是基于antirez/rax实现的Lua中的radixtree。而且支持正则，可以完全满足我们的需求。

从数据结构上来看，前缀树的性能会远远大于遍历+正则。而且对于前缀树来说，他的复杂度最差是O(k).K=key长度。但是实际上我们往往到不了这个级别。

当然LuaTable的Hash查找可以秒杀前缀树1-2个量级。根本原因是编译LuaJIT的时候，使用了CPU指令集来计算。如果能命中LuaTable他的复杂度是O(0)。

所以在lua-resty-radixtree中 他的顺序是LuaTable => radixtree。当解析路由的时候直接使用LuaTable去获取信息，如果无法命中再由redixtree来解析。毕竟我们的静态路由会远远大于正则路由

在同等压测结果下，路由层的匹配性能带来了百倍的提升，甚至在极端场景下带来了200倍+的提升

连接池

在proxy场景来说，其实往往最大的开销是Connect。那么连接池的作用也非常作用。nginx中proxy模块的连接池默认是关闭的。打开连接池之后 可以带来将近一倍的性能提升。这个配置大家可以自己去Baidu/Google寻找一下，不再赘述啦

从Dict 到 内存缓存

由于历史遗留问题，业务网关的数据存储在MySQL中。并没有使用类似ETCD的配置中心。早期为了保证数据同步，采用了dict方式来存储以及分发。但是dict本质是存储在master,Worker需要的时候通过IPC的方式从master读取。且有读写互斥锁。而且我们也出现莫名其妙的丢失的情况。所以在这次改造中，我们将dict 切换到Worker级别内存中。如果是数据存储，直接申请单独内存块。如果是缓存则使用LruCache。由于数据是在MySQL上，所以暂时使用worker-event来分发update事件。但是为后面将配置中心切换至etcd打下来基础。

ngx.req.set_xxx VS ngx.var.xxx

在我们网关场景中，并不少的存在修改转发URI、Header等等需求。OpenResty其实开放了ngx.req.set_uri、ngx.req.set_header等API来方便我们修改。但是我说更好的性能去实现这个你能信么~

我们就拿ngx.req.set_uri来举例。他的代码如下https://github.com/openresty/lua-nginx-mod ul/blob/master/src/ngx_http_lua_uri.c

OpenResty在修改的时候需要判断URI是否符合规范，是否需要Jump判断，最终去修改nginx request中的uri,以及相对应的var.uri等变量，而且中间会存在多次变量创建,内存拷贝的开销。但是实际上我们并没有Jump等需求，只有很简单的rewrite请求。在nginx中，可以在proxy_pass跟上目标地址也可以实现rewrite的需求。而且由于他只需要在Lua代码中进行对ngx.var的变量赋值即可完成修改。这个性能相比ngx.req.set_uri性能会好得多。

Demo

# nginx配置文件set upstream_uri "":location / {   ...   proxy_pass http://api_upstream$upstream_uri;   ...}
-- Lua代码ngx.var.upstream_uri = "/api/v1/user/info"

通过以上Demo，我们就可以将请求到后端的uri修改成/api/v1/user/info。需要值得注意的是当uri上有args的时候，也需要将其拼接到ngx.var.upstream_uri中。当我们在Lua逻辑中修改uri次数越多，那么节省的资源会更多。

ngx.req.set_header其实也是同理https://github.com/openresty/lua-nginx-mod ule/blob/master/src/ngx_http_lua_headers_in.c#L174-L289 同样也会涉及多次内存拷贝以及变量创建的开销。我们可以通过类似上面的代码来实现ngx.req.set_header功能。

# nginx配置文件set trace_id "":location / {   ...   proxy_set_header TraceId $trace_id;   ...}
-- Lua代码ngx.var.trace_id = uuid()

当然这样写法会有一些限制，比如说只能追加指定的Header等。如果部分Header是必传的，我们可以那么设置。如果是动态的，还是建议通过ngx.req.set_header。毕竟有时候便捷性和性能不能兼得，需要根据自己需要的业务场景去做出做好的选择。

以上就是轻舟业务网关优化的过程，其中非常感谢API7开源的apisix以及各个高性能的组件。

网关的作用是是抽离公共部分,同时需要以最低的延迟损耗来完成这些事情。当然网关的优化是无止境的。只有更好的赋能于业务，给开发带来更好的体验才是王道。

Maybe我们会继续在轻舟业务网关上搞事情，比如说。。。

• 配置中心切换至ETCD

• Mock功能更强大，可以模拟数据(当前只能返回固定的结构)

• 可自定义Cache属性 (现在只有开关 yes or no)

• 支持接口级别的限流

• 健康检查

• 防火演练

• 服务熔断