vlambda博客
学习文章列表

为什么 APISIX 选择 Nginx + Lua 这个技术栈?

笔者在今年的 COSCUP 大会做分享时,曾有观众问这样的问题,为什么 APISIX、Kong 和 3scale 这些网关都采用 Lua 来编写逻辑?

是啊,Lua 并不是一门广为人知的语言,离“主流编程语言”的圈子大概还差个十万八千里吧。甚至有一次,我在跟别人交流的时候,对方在说到 Lua 之前,先停顿了片刻,随后终于打定主意,以 “L” “U” “A” 逐个字母发音的方式表达了对这一罕见之物的称呼。

所以,为什么 APISIX 和其他知名的网关会选择用 Lua 呢?

事实上,APISIX 采用的技术栈并不是纯粹的 Lua,准确来说,应该是 Nginx + Lua。APISIX 以底下的 Nginx 为根基,以上层的 Lua 代码为枝叶。

LuaJIT VS Go

严谨认真的读者必然会指出,APISIX 并非基于 Nginx + Lua 的技术栈,而是 Nginx + LuaJIT (又称 OpenResty,以下为了避免混乱,会仅仅采用 Nginx + Lua 这样的称呼)。

LuaJIT 是 Lua 的一个 JIT 实现,性能比 Lua 好很多,而且额外添加了 FFI 的功能,能方便高效地调用 C 代码。

由于现行的主流 API 网关,如果不是基于 OpenResty 实现,就是使用 Go 编写,所以时不时会看到各种 Go 和 Lua 谁的性能更好的比较。

就我个人观点看,脱离场景比较语言的性能,是没有意义的。

首先明确一点,APISIX 是基于 Nginx + Lua 的技术栈,只是外层代码用的是 Lua。所以如果要论证哪种网关性能更好,正确的比较对象是 C + LuaJIT 跟 Go 的比较。网关的性能的大头,在于代理 HTTP 请求和响应,这一块的工作主要是 Nginx 在做。所以倘若要比试比试性能,不妨比较 Nginx 和 Go 标准库的 HTTP 实现。

众所周知,Nginx 是一个 bytes matter 的高性能服务器实现,对内存使用非常抠门。随便举两个例子:

  1. Nginx 里面的 request header 在大多数时候都只是指向原始的 HTTP 请求数据的一个指针,只有在修改的时候才会创建副本。
  2. Nginx 代理上游响应时对 buffer 的复用逻辑非常复杂,是我读过的最为烧脑的代码之一。

凭借这种抠门,Nginx 得以屹立在高性能服务器之巅。

相反的,Go 标准库的 HTTP 实现,是一个滥用内存的典型反例。这可不是我的一面之辞,Fasthttp,一个重新实现 Go 标准库里面的 HTTP 包的项目,就举了两个例子:

  1. 标准库的 HTTP Request 结构体没法复用
  2. headers 总是被提前解析好,存储成 map[string][]string,即使没有用到(原文见:https://github.com/valyala/fasthttp#faq)

Fasthttp 文档里面还提到一些 bytes matter 的优化技巧,建议大家可以阅读下。

事实上,即使不去比较作为网关核心的代理功能,用 LuaJIT 写的代码不一定比 Go 差多少。原因有二。

其一,拜 Lua 跟 C 良好的亲和力所赐,许多 Lua 的库核心其实是用 C 写的。

比如 lua-cjson 的 json 编解码,lua-resty-core 的 base64 编解码,实际上大头是用 C 实现的。

而 Go 的库,当然是大部分用 Go 实现的。虽然有 CGO 这种东西,但是受限于 Go 的协程调度和工具链的限制,它在 Go 的生态圈里面只能处于从属的地位。

关于 LuaJIT 和 Go 对于 C 的亲和力的比较,推荐 Hacker News 上的这篇文章:《Comparing the C FFI overhead in various programming languages》(链接 https://news.ycombinator.com/item?id=17161168)

于是我们比较 Lua 的某些功能,其实还是会回到 C 和 Go 的比较中。

其二,LuaJIT 的 JIT 优化无出其右

讨论动态语言的性能,可以把动态语言分成两类,带 JIT 和不带 JIT 的。JIT 优化能够把动态语言的代码在运行时编译成机器码,进而把原来的代码的性能提升一个数量级。

带 JIT 的语言还可以分成两类,能充分 JIT 的和只支持部分 JIT 的。而 LuaJIT 属于前者。

人所皆知,Lua 是一门非常简单的语言。

相对鲜为人知的是,LuaJIT 的作者 Mike Pall 是一个非常厉害的程序员。

这两者的结合,诞生了 LuaJIT 这种能跟 V8 比肩的作品。(关于 LuaJIT 和 V8 到底谁更快,一直是长盛不衰的争论话题。)

展开讲 LuaJIT 的 JIT 已经超过了本文想要讨论的范畴。简单来说,JIT 加持的 LuaJIT 跟预先编译好的 Go 性能差别并不大。

至于谁比谁慢,慢多少,那就是个见仁见智的问题了。这里我举个例子,

local text = {"The""quick""brown""fox""jumped""over""the""lazy""dog""at""a""restaurant""near""the""lake""of""a""new""era"}
local map = {}
local times = 1e8
local n = #text
for i = 1, n do
    map[text[i]] = 0
    for _ = 1, times do
        map[text[i]] = map[text[i]] + 1
    end
end

for i = 1, n do
    io.write(text[i], " ", map[text[i]], "\n")
end
package main
import "fmt"
func main() {
    text := []string{"The""quick""brown""fox""jumped""over""the""lazy""dog""at""a""restaurant""near""the""lake""of""a""new""era"}
    m := map[string]int{}
    times := int(1e8)
    for _, t := range text {
        m[t] = 0
        for i := 0; i < times; i++ {
            m[t]++
        }
    }
    for _, t := range text {
        fmt.Println(t, " ", m[t])
    }
}

上面两段代码是等价的。你猜是第一个 Lua 版本的快,还是第二个 Go 版本的快?

在我的机器上,第一个用时不到 1 秒,第二个花了 23 秒多。

举这个例子并不是想证明 LuaJIT 比 Go 快 20 倍。我只想说明用 micro benchmark 证明某个语言比另一个语言快的意义不大,因为影响性能的因素很多。一个简单的 micro benchmark 很有可能过分强调某一个因素,导致出乎意料的结果。

Nginx + Lua :高性能 + 灵活

让我们转回 APISIX 的 Nginx + Lua 的技术栈。Nginx + Lua 的技术栈给我们带来的,不仅仅是高性能。

经常有人问我们,既然你们是基于 Nginx 开源版本,而 Nginx 并不支持动态配置,为什么 APISIX 声称自己可以实现动态配置?你们是不是改了点东西?

是的,我们确实有在维护自己的 Nginx 发行版,不过 APISIX 的大部分功能在官方的 Nginx 上就能使用。我们之所以能做到动态配置,全靠把配置放到 Lua 代码里面来实现。

举路由系统作为一个例子。Nginx 的路由需要在配置文件里面进行配置。每次更改路由,都需要 reload 之后才能生效。这是因为 Nginx 的路由分发只支持静态配置,不能动态增减路由。

为了实现路由动态配置,APISIX 做了两件事:

  1. 在 Nginx 配置文件里面配置单个 server,这个 server 里面只有一个 location。我们把这个 location 作为主入口,这样所有的请求都会走到这个地方上来。
  2. 我们用 Lua 完成路由分发的工作。APISIX 的路由分发模块,支持在运行时增减路由,这样就能动态配置路由了。

你可能会问,在 Lua 里面做路由分发,会比 Nginx 的实现慢吗?

就像前面提到过的一样,凡是对性能要求比较高的,我们会把核心代码用 C 改写。我们的路由分发模块就是这么干的。路由分发模块在匹配路由时,会采用一个前缀树来匹配。而这个前缀树是用 C 实现的。感兴趣的读者可以看下代码:https://github.com/api7/lua-resty-radixtree/。

完成了 C 层面上的前缀树匹配,接下来就该 Lua 发挥灵活性的时刻了。对于匹配同一前缀的各个路由,我们支持通过许多别的方式来进行下一级的匹配,其中就包含通过一个特定的表达式来匹配。尽管硬着头皮,也能在 C 层面上接入一个表达式引擎,但是纯 C 实现做不了非常灵活地自定义表达式里面的变量。

举个例子,下面是 APISIX 用来匹配 GraphQL 请求的 route 配置:

{
        "methods": ["POST"],
        "upstream": {
            "nodes": {
                "127.0.0.1:1980": 1
            },
            "type""roundrobin"
        },
        "uri""/hello",
        "vars": [["graphql_name""==""repo"]]
}

它会匹配这样的 GraphQL 请求:

query repo {
    owner {
        name
    }
}

这里的 graphql_name 并非 Nginx 内置变量,而是通过 Lua 代码定义的。APISIX 一共定义了三个 GraphQL 相关的变量,连同解析 GraphQL body 在内不过 62 行 Lua 代码。如果要通过 Nginx C 模块来定义变量,62 行可能只不过是把相关方法的样板代码搭建起来,都还没有到真正的解析 GraphQL 的逻辑呢。

采用 Lua 代码来做路由还有一个好处:它减低了二次开发的门槛。如果在路由过程中需要有特殊的逻辑,用户可以实现成自定义的变量和运算符,比如通过 IP 库匹配到的地理位置来决定采用哪条路由。用户只需要写一些 Lua 代码,这要比修改 Nginx C module 的难度小多了。

在 APISIX 里面,不仅仅路由是动态的,我们的 TLS 服务端证书和上游节点配置都是动态的,而且无需修改 Nginx —— 上述功能可以跑在官方的 Nginx + Lua 技术栈上。当然通过修改 Nginx,我们还实现了更多的高级功能,比如动态的 gzip 配置和动态的客户端请求大小限制。后续我们将推行自己的 Nginx 发行版,这样开源用户也能轻松用上这些高级功能。

关于 Apache APISIX

Apache APISIX 是一个动态、实时、高性能的开源 API 网关,提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。Apache APISIX 可以帮忙企业快速、安全的处理 API 和微服务流量,包括网关、Kubernetes Ingress 和服务网格等。

全球已有数百家企业使用 Apache APISIX 处理关键业务流量,涵盖金融、互联网、制造、零售、运营商等等,比如美国航空航天局(NASA)、欧盟的数字工厂、中国航信、中国移动、腾讯、华为、微博、网易、贝壳找房、360、泰康、奈雪的茶等。

200 余位贡献者,一同缔造了 Apache APISIX 这个世界上最活跃的开源网关项目。聪明的开发者们!快来加入这个活跃而多样化的社区,一起来给这个世界带来更多美好的东西吧!

  • Apache APISIX GitHub:https://github.com/apache/apisix
  • Apache APISIX 官网:https://apisix.apache.org/
  • Apache APISIX 文档:https://apisix.apache.org/zh/docs/apisix/getting-started
APISIX 云原生微服务网关
APISIX 是一个云原生、高性能、可扩展的微服务 API 网关
55篇原创内容
Official Account

点击阅读原文,跳转 Apache APISIX GitHub 主页