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

什么是轻舟业务网关

轻舟业务网关是轻舟大学生项目组所有API服务的入口。他承载了项目组内所有API的流量，且在网关层具备了传输解密,登录态鉴权,传输防篡改,路由修改,缓存,未发布Mock,APi文档等通用能力。是使用Openresty+Lua技术栈实现，在Lua层实现业务逻辑，并使用nginx的proxy能力进行反向代理。

现状

控制颗粒细

相比于集团网关，轻舟业务网关更贴近于业务。拥有更细颗粒度的控制。我们以method+path+api_version来确定唯一控制级，在这个控制级里可设置是否签名,登录态鉴权,内外网访问,后端转发Path,后端服务器等等。可以说是以接口来控制业务。
e.g
请求 /api-passport/user/info/base => api-passport服务器组 后端uri为api/v1/user/info/base 需要鉴权 不需要签名 可公网访问
请求 /api-passport/user/phone => api-passport服务器组 后端uri为api/v1/user/phone 需要鉴权 需要签名 可公网访问
请求 /wrk/test => wrk服务器组 后端uri为 api/test 不需要鉴权 不需要签名 只允许内网访问

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

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

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

由于我们的颗粒过细，且支持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事件本身是阻塞的&#x