【实战分享】又拍云 OpenResty / Nginx 服务优化实践

2018 年 11 月 17 日，由 OpenResty 主办的 OpenResty Con 2018 在杭州举行。本次 OpenResty Con 的主题涉及 OpenResty 的新开源特性、业界最佳实践、性能优化、Trace、 API 网关等方面。

又拍云受邀参加 OpenResty Con 2018，又拍云系统开发工程师张超在大会上做了《又拍云 OpenResty / Nginx 服务优化实践》的开场演讲。

又拍云在自身业务中大量使用了 Nginx、OpenResty，使用两者开发了云处理、云存储业务平台，并在又拍云 CDN 平台中使用 ngx_lua 作为反向代理服务， CDN 平台的 API、文件上传服务通过 ngx_lua 对大文件进行流式上传，利用 ngx_lua 对网络线路进行动态的调度，自动选择最合适的线路进行上传加速。同时，又拍云在 Github 上也一直保存、更新着又拍云所报告和修复的关于 Nginx 和 OpenResty 的 bug，是 OpenResty 重要的贡献者。

△ 又拍云系统开发工程师张超

张超，又拍云系统开发工程师，负责又拍云 CDN 平台反向代理层组件的开发和维护。Nginx、OpenResty 等开源软件爱好者。本次分享着重介绍了又拍云 CDN 平台在不断的更新迭代中总结出的关于 OpenResty 和 Nginx 服务优化的经验，包括构建容器化的生产环境性能分析环境、集成 SSL 硬件加速至 OpenResty 及其陷阱等案例。

分享主要分三块展开：

关于性能分析、 Tips 以及使用 Nginx 编码的注意点，使应用代码能够获得更好的运行性能；
又拍云对 DNS 的解析管理；
SSL 硬件加速的实践，侧重介绍在使用过程中与 LuaJIT 的冲突及解决思路。

以下是分享实录：

又拍云和 OpenResty 的那些事

又拍云从 2013 年就开始关注并且使用 OpenResty ，是最早使用 OpenResty 的厂商之一。

△ 又拍云 CDN 架构与 API、云处理架构

上图左边是又拍云 CDN 的简单架构图，右边是又拍云的 API、云处理方面的架构图。图中除了 Cache Server，其他所有的服务全部是基于 OpenResty 实现的，包括又拍云存储的网关。去年，又拍云引入了 Kong，将它作为公司的 API 服务，日志上报、流量上报、监控数据上报等服务的统一入口网关，并做了统一的认证，给我们省了不少的事情。

upyun-resty 这个 github 仓库记录了又拍云所开源的 lua-resty 库、C 模块以及又拍云所报告和修复的关于 OpenResty 和 Nginx 的 bugs。

大家如果有兴趣的话可以浏览这个页面：https://github.com/upyun/upyun-resty

从 2013 到 2018 年，又拍云的业务发展愈加全面，不得不去做更深入的一些优化。业务发展到了一定阶段，必然会遇到性能瓶颈，而这些问题就交由我们这些工程师们来解决。

性能分析、Tips

我们经常会在线上或本地开发机器上执行 top、pidstat 等命令，这些命令会报告一些系统和进程的资源使用情况，这就是资源分析。资源分析主要聚焦于资源利用率、饱和度以及错误数，这就是经典的 USE 分析方法。这个分析方法由 Brendan Gregg 大神提出，非常有用。通过资源分析可以非常直观的看到业务应用在线上跑着，会吃掉多少的内存，占用多少的 CPU，产生多少磁盘吞吐等。

第二个是针对应用程序本身所展开的工作负载分析，工具也比较多，包括 perf，systemtap，bcc/ebpf 等工具。通过 systemtap、bcc/ebpf 可以将数据进行汇总，利用工具画出火焰图。负载分析主要是针对应用程序自身的表现，比如 OpenResty，在作为一个反向代理服务器或者网关存在时，大家比较关心它的指标就是请求延时和状态码，像 501、502、504 状态码的比例。

当我们需要展开分析时，会发现线上环境，工具等条件不足，甚至连基本的编译工具都没有，这时候像 systemtap 这样的工具就没法用了。又拍云也遇到了这样的问题，因此我们采用了容器化，把所有的工具全部扔到了容器里，包括一些基本的编译器，链接器，常用的 perf、systemtap、gdb、mozilla rr 等工具。大家可能会觉得容器的权限会不会有问题，当然首先这个容器必须是以特权模式去运行，另外还需要把宿主机的内核头文件进行映射，并且必须使用宿主机的 pid namespace，否则在容器里面没有办法去追踪宿主机上的进程。

△ 容器案例

上图例子中运行的容器使用的是 upyun_stap 的镜像，跑起来后可以在这个容器里面做任何的事情，但是它对内核是有一定的要求，如果想使用 systemtap，内核就必须把一些相关的选项打开。这是我们一个小的思路，如果遇到环境工具不足的情况，可以考虑采用容器化的方法。

ngx_lua 编程怎样挑选合适的 API 获得更好的编程体验

介绍一下 ngx.ctx 和 ngx.var，这两个 API 一般用于储存和请求相关的数据，它们的数据都是关联到某个请求。ngx.ctx 本质上就是一个 Lua table，后者 ngx.var 实际上是一个获取 Nginx 变量的接口，通过它可以设置和获取变量。相比较而言， ngx.ctx 是更好的选择，首先 Lua table 的实现非常快，云风曾在一篇文章里提过，Lua table 查询一次的耗时，几乎等于对 key 进行一次 Hash 的过程。其次 ngx.var 返回的是 Nginx 变量的值，它的返回值只能是字符串，类型比较单调，如果存一些结构化的数据，就不得不去进行序列化，从而会带来一定的开销，并且在 ngx.var 的接口内部还有一些 Hash 的计算、内存的分配等。

△ Tips

分享一个 Tips，我们可以适当的 cache 一下 ngx.ctx，去避免相对比较昂贵的 metamethod 元方法调用。比如上面这个代码片段，先把 ngx.ctx 进行 local，然后再对它进行一些复杂和取用，这样就避免了额外的 metamethod 调用。

ngx.ctx 也有一些缺陷，最大的缺陷就是生命周期只能局限在一个 Nginx location 当中。换言之，如果业务比较复杂，Nginx 发生了内部重定向，存储于 ngx.ctx 内的数据都会被丢失，所有模块的上下文都会被清掉，因为 ngx.ctx 实际上是存在 ngx_lua 模块的上下文当中。所以在发生一次内部调用之后，数据就再也获取不到了。这个问题去年我们在 github 也问过，后来用 Lua 实现了一个折中的方案，我们模拟了 ngx.ctx 的实现过程，将它保存在我们自己所创建的表里，然后将它的索引值保存到变量中，因为变量的生命周期是不受 location 影响，而是贯穿整个请求的，不管请求中间发生过多少次的内部跳转，变量都是一直存在的。

△ 方法案例

举一个例子，上图从 location / t1 跳转到了 t2，数据还是可以从 location /t 2 中获取出来。通过这个方法，就可以保证即使发生了内部跳转，依旧可以获取数据。

HTTP headers 操作
介绍大家在用 OpenResty 的时候，必然是离不开操作 HTTP 头部的，主要的接口就是 ngx.req.get_headers，这个接口会返回所有的请求头，如果说没有给它指定 raw 参数，所有的名字都是小写的形式存在的。如果你传入的请求头名称不是全小写的，第一次是获取不到的，它会把这个全部转换成小写，再去访问一次。因此在这个过程中，我们会访问表两次，而且中间有一次经过了元方法的调用，在针对这个事情上有一个比较好的办法，那就是手动的把它的元表去掉，然后在访问的时候全部使用小写的形式。这样就可以省掉元方法的调用，可能一次元方法、两次元方法，看不出什么效果，但是当一个请求里面可能操作比较多的请求头，同时 qps 比较高的时候，就能体现出一定的差距来。

然后是日志处理，我们大多都会采用 Nginx access log 模块去管理访问日志。它最大的弊端就是和磁盘、文件系统进行了交互，那么就有可能受到文件系统或磁盘的影响，如果磁盘抽风或磁盘利用率满了，反过来就会影响到 Nginx 的进程。因为 OpenResty 和 Nginx 在写磁盘的时候，是同步写的，如果 access_log buffer 的参数设置不合理，会产生多次的 write() 系统调用，对应用程序本身是非常不利的。建议大家可以使用 lua-resty-logger-socket 组件，又拍云也使用了这个工具，将日志发送到同一个机房同一个网段的其他服务，由其他的服务去上报日志，这样可以避免 CDN 服务和磁盘直接进行交互，最大程度保障服务不会收到磁盘本身的影响。因为一块磁盘有时候不仅一个服务在用，其他的服务也在用，如果其他的服务产生太多的磁盘写入，就会反过来影响到 CDN 服务。

养成良好的编程习惯

不要滥用全局变量：在 ngx_lua 编程中，全局变量是在一张表里，虽然 Lua table 设计的很好，每次访问都仅仅是一次表查询，虽然速度很快，但是和本地变量的读取还是有差距的，所以全局变量能不用就不用。
避免低效的字符串拼接操作：举一个臭名昭著的例子，在 for 循环里去拼接字符串，会产生大量的内存分配，大量的内存拷贝，带来 GC 开销。
避免太多的 table resize 操作：大家在编程时，需要一个表就创建出一个空表，往里面写数据，这个过程中会发生一些 table resize，表内部的 hash part 大小会发生改变。比较好的办法就是使用 table.new 创建预先定义好大小的表。
使用 LuaJIT 和 lua-resty-core 的搭配，避免使用官方的 Lua 解释器：LuaJIT 非常的强悍，所以也应该尽可能的去使用 JITable 的函数，同样 LuaJIT 的 ffi 实现也非常的优秀，比使用原生的 Lua C stack 的交互方式更加的方便、高效。

DNS 解析管理

大家可能对 Nginx 本身的域名解析的理解上存在一些偏差，这里会介绍一下 Nginx 运行时所使用的 DNS 解析器的一些缺点，以及分享又拍云基于 ngx_lua 所做的解决方案。

△ 案例

图中虚拟主机的后端是写在 upstream group 里面，只有一个 server 指向 http://upyun.com 域名，大家会觉得这样写完就没事了。某一天 http://upyun.com 指向的那台机器崩掉了，匆匆忙忙去改解析，却发现没有生效，然后服务还是出现一堆 502。因为这样的一个域名，在 Nginx 或者 OpenResty 刚刚启动的过程中，就已经解析完了，worker 进程在处理请求的过程中不会对域名的解析发生任何改变，其实解析在处理 server 指令的时候就已经完成了，这第一个误区。这种情况下只能手动去重启服务，如果服务像 CDN 那么多，会比较耗时和麻烦。第二如果不用 upstream 直接带过去也是不行的，两者实际上没有太多的差别，Nginx 内部也会创造一个 upstream group，然后把域名解析好。所以这两种方法，总的来说只会解析一次，使用的是 getaddrinfo 或者 gethostbyname，调用系统配置的 nameserver 去进行配置。

分享一个比较好的方法，可以强迫你的服务进行解析，就是在 proxy_pass 指令里使用变量，把整个解析过程推迟到运行时。proxy_pass 后面的那一串是一个复杂值，会进行一个变量的解释，最后再对域名进行解析，这时候会使用到 Nginx 的 resolver，比如上面所定义的，定义了三个 nameserver。然而 Nginx 的运行时 DNS resolver 的问题也挺多的，DNS resolver 虽然支持轮询，也支持 cache，可以简单的缓存在内存中，但是不支持配置备用 name server，所有配置好的 nameserver 之后都会被使用。同样 DNS resolver 也没有实现故障转移，最关键的是不支持在故障时使用陈旧数据。因为出现故障时，有数据肯定好过没数据，即使解析是旧的，也能挡住一定的危害。

solver的运行情况

我们对 DNS resolver 不是非常的满意，又拍云的业务也都是用 Ngx_lua 所编写的，索性就直接弄了一个 lua-resty-domain 的库，它主要承担的是域名的管理。它基于 OpenResty 官方的 lua-resty-dns （DNS 解析器的库）同时结合 Cloudflare 开源的 lua-resty-shcache （一个缓存组件的库），也结合了又拍云所开源的 lua-resty-checkups（主要是做心跳和负载均衡的库）。全部结合起来以后，lua-resty-domain 能够做到复杂的 load balancing，包括简单的轮询、带权轮询和一致性 Hash，或者是其他的一些负载均衡的办法。lua-resty-domain 支持心跳功能，就是向目标的 nameserver 发起解析请求，看它的解析情况，以及是否超时等。 lua-resty-domain 也支持故障转移，如果所有主 nameserver 都挂掉了，会去使用备用的。因为结合了 lua-resty-shcache 所以也支持 cache 功能，可以把解析出来的数据存在共享内存当中。最关键的是，lua-resty-domain 能在所有的 nameserver 挂掉的时候，提供一些陈旧数据，保证业务不会受到影响。综合来说，这是一个比较好的解决方案。

△ lua-resty-domain 配置

在 cluster 块中定义了一主一备的 nameserver，能在 DNS 解析方面提供一个高可用的解决方案。DNS 是每个服务里面不可获缺的一部分，比如使用了公共的 DNS 的时候，无法保证公共DNS 时刻没有问题，比如某个时刻 DNS 服务器负载较高，解析延时上升反而影响到了业务，这就划不来了。所以万事还是要从自己做起，做好一个完美的解决方案，尽可能的避免这样的影响。

除了使用 lua-resty-dns 库，ngx_lua 的 Cosocket，内部也提供了简单的域名解析功能，使用的也是 Nginx 的 resolver，但我们不太想用。所以我们参考了一下 Kong，把 ngx.socket.tcp 的 connect 方法重写了一下，先调用 lua-resty-domain 进行解析，再将解析出来的地址传递给原来的方法，强迫它使用我们所定义好的域名解析功能。虽然这些代码没有特别容错，但是足够表述出这种思想，这是一个非常好的 idea。

SSL 硬件加速实践 BUG 解析

SSL Acceleration 会把应用中所涉及到的加解密、签名等占用 CPU 的任务全部 offload 到像 Intel QAT card 这种具备计算能力的硬件上去，从而降低应用程序的负载。 Acceleration 这个词比较有迷惑性，并不是说计算本身得到加速，而是说这种技术能够让应用程序的吞吐得到提升。尤其结合异步模式，采用异步的方式把任务全部都交付给硬件后，应用就可以处理其他请求了，这样使得应用程序的吞吐得到了一个质的提升。

CDN 厂商最关注的就是 CDN 和带宽的比例，CDN 跑到 80%、90%，但是带宽一直上不去的话就完全利用不起来机房的带宽，这对成本来说是不利的。如果在同等的 CPU 消耗情况下，能产生的带宽和吞吐量上去了，对成本会比较有利。又拍云所采用的就是 OpenResty+Asynchronous OpenSSL+Intel QAT 的组合方案。

△ 硬件加速前后数据

这张对比图，上面是没有使用硬件加速的数据，下面是使用了硬件加速的数据，分别做了一次RSA 私钥签名以及公钥认证的过程，可以看到最后一行的对比，使用 QAT 卡之后私钥签名的过程至少提高了十倍，后面用公钥认证也有八到九倍的提升。不过这是最理想的情况，是没有任何业务的时候的得到的一个理论值，业务当中肯定是达不到的。

△ 实际 CPU 效果

这是我们监控中采集到的 CPU 的变化曲线，当时的连接数大概是三四万个到 443 端口的连接。 CPU 的变化可能就没有那么理想，大约降低了10%，因为其他的业务也需要占据一定的 CPU。集成到又拍云这样复杂的 CDN 系统中也算是一个非常不错的提升了。

异步模式的 OpenSSL 和 LuaJIT 不能很好的共存，会出现应用程序崩溃的问题，这是非常不幸的。对此我们也排查了很久，究竟是什么导致的崩溃。

首先尝试过将 LuaJIT 的 JIT compiler 禁用，结果是还会出现崩溃。也尝试过关闭 OpenSSL 的异步模式，崩溃确实没有出现了，但是同步的去做硬件 offload 过程，没有比直接用软件计算快多少，那就没必要用这个方案了。另外我们在 ssl_certificate_by_lua* 阶段有 ocsp 校验过程，会有一些 Light Thread 的协程切换，我们也试过关闭 ocsp，但崩溃问题还是会出现。最后，我们甚至将服务中用到的其他一些组件全换成了原生组件，但问题依旧存在。

△ 流程图

后来，LuaJIT 社区有一个哥们说我们的程序是不是存在这么一个情况。

首先 Nginx 要进行 SSL handshake，运行在系统栈上。异步模式 Open SSL 内部使用了 OpenSSL fibre，其实就是协程，启用这个模式后，会涉及到 fibre 上下文切换的过程，此时程序会运行到 OpenSSL fibre 的栈上，前面我提到了我们的程序在 ssl_certificate_by_lua 阶段也有业务介入，那么反过来程序又会跑到了 LuaJIT 的栈上，从而可以运行应用代码。应用代码又调用了 ssl.set_der_cert 这样的接口去设置证书，证书都是保存在 redis 这样的外部组件里的，拿出来就需要设置进去。设置进去以后，会涉及到一些摘要计算，此时程序运行到了 OpenSSL fibre 的栈上去了，在交付给硬件以后，OpenSSL fibre 可能会将自己切出，所以此时应用程序又回到了系统栈上，即握手之前的位置，然后 Niginx就非常愉快的去处理其他的请求，其他请求也是类似，所有的业务代码都是由 LuaJIT 运行的，某个时刻就又跑到了 LuaJIT 的协程栈上。

整个的过程简单来说，就是我们重入了 LuaJIT，但是并没有调用到 lua_yield() 函数。

Lua 是用 lua_resume() 和 lua_yield()，去进行协程切换的。我们相当于违反了这个规则，重入到了 LuaJIT，发生了不可预期的问题。

△ 禁用代码

目前想到的最好的办法就是在 ngx_lua 和 ssl 相关的 API 里去禁掉上下文切换。所幸 OpenSSL 异步模式提供了相关接口，我们在相关的函数里加入了两段代码，重新编译完放上去后，应用程序就开始正常的工作了。

我的分享就到这里，希望大家遇到同样的问题能有一些启发。

推荐阅读：

一年了，我们都用 Spring Cloud 干了啥？