为什么 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 的高性能服务器实现，对内存使用非常抠门。随便举两个例子：
-
Nginx 里面的 request header 在大多数时候都只是指向原始的 HTTP 请求数据的一个指针，只有在修改的时候才会创建副本。
-
Nginx 代理上游响应时对 buffer 的复用逻辑非常复杂，是我读过的最为烧脑的代码之一。
凭借这种抠门，Nginx 得以屹立在高性能服务器之巅。
相反的，Go 标准库的 HTTP 实现，是一个滥用内存的典型反例。这可不是我的一面之辞，Fasthttp，一个重新实现 Go 标准库里面的 HTTP 包的项目，就举了两个例子：
-
标准库的 HTTP Request 结构体没法复用
-
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 做了两件事：
-
在 Nginx 配置文件里面配置单个 server，这个 server 里面只有一个 location。我们把这个 location 作为主入口，这样所有的请求都会走到这个地方上来。
-
我们用 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