在上一讲里，我们看到了高性能的Web服务器Nginx，它资源占用少，处理能力高，是搭建网站的首选。
虽然Nginx成为了Web服务器领域无可争议的“王者”，但它也并不是没有缺点的，毕竟它已经15岁了。
“一个人很难超越时代，而时代却可以轻易超越所有人”，Nginx当初设计时针对的应用场景已经发生了变化，它的一些缺点也就暴露出来了。
Nginx的服务管理思路延续了当时的流行做法，使用磁盘上的静态配置文件，所以每次修改后必须重启才能生效。
这在业务频繁变动的时候是非常致命的（例如流行的微服务架构），特别是对于拥有成千上万台服务器的网站来说，仅仅增加或者删除一行配置就要分发、重启所有的机器，对运维是一个非常大的挑战，要耗费很多的时间和精力，成本很高，很不灵活，难以“随需应变”。
那么，有没有这样的一个Web服务器，它有Nginx的优点却没有Nginx的缺点，既轻量级、高性能，又灵活、可动态配置呢？
这就是我今天要说的OpenResty，它是一个“更好更灵活的Nginx”。
OpenResty是什么？
其实你对OpenResty并不陌生，这个专栏的实验环境就是用OpenResty搭建的，这么多节课程下来，你应该或多或少对它有了一些印象吧。
OpenResty诞生于2009年，到现在刚好满10周岁。它的创造者是当时就职于某宝的“神级”程序员章亦春，网名叫“agentzh”。
OpenResty并不是一个全新的Web服务器，而是基于Nginx，它利用了Nginx模块化、可扩展的特性，开发了一系列的增强模块，并把它们打包整合，形成了一个“一站式”的Web开发平台。
虽然OpenResty的核心是Nginx，但它又超越了Nginx，关键就在于其中的ngx_lua模块，把小巧灵活的Lua语言嵌入了Nginx，可以用脚本的方式操作Nginx内部的进程、多路复用、阶段式处理等各种构件。
脚本语言的好处你一定知道，它不需要编译，随写随执行，这就免去了C语言编写模块漫长的开发周期。而且OpenResty还把Lua自身的协程与Nginx的事件机制完美结合在一起，优雅地实现了许多其他语言所没有的“同步非阻塞”编程范式，能够轻松开发出高性能的Web应用。
目前OpenResty有两个分支，分别是开源、免费的“OpenResty”和闭源、商业产品的“OpenResty+”，运作方式有社区支持、OpenResty基金会、OpenResty.Inc公司，还有其他的一些外界赞助（例如Kong、CloudFlare），正在蓬勃发展。
顺便说一下OpenResty的官方logo，是一只展翅飞翔的海鸥，选择海鸥是因为“鸥”与OpenResty的发音相同。另外，这个logo的形状也像是左手比出的一个“OK”姿势，正好也是一个“O”。
动态的Lua
刚才说了，OpenResty里的一个关键模块是ngx_lua，它为Nginx引入了脚本语言Lua。
Lua是一个比较“小众”的语言，虽然历史比较悠久，但名气却没有PHP、Python、JavaScript大，这主要与它的自身定位有关。
Lua的设计目标是嵌入到其他应用程序里运行，为其他编程语言带来“脚本化”能力，所以它的“个头”比较小，功能集有限，不追求“大而全”，而是“小而美”，大多数时间都“隐匿”在其他应用程序的后面，是“无名英雄”。
你或许玩过或者听说过《魔兽世界》《愤怒的小鸟》吧，它们就在内部嵌入了Lua，使用Lua来调用底层接口，充当“胶水语言”（glue language），编写游戏逻辑脚本，提高开发效率。
OpenResty选择Lua作为“工作语言”也是基于同样的考虑。因为Nginx C开发实在是太麻烦了，限制了Nginx的真正实力。而Lua作为“最快的脚本语言”恰好可以成为Nginx的完美搭档，既可以简化开发，性能上又不会有太多的损耗。
作为脚本语言，Lua还有一个重要的“代码热加载”特性，不需要重启进程，就能够从磁盘、Redis或者任何其他地方加载数据，随时替换内存里的代码片段。这就带来了“动态配置”，让OpenResty能够永不停机，在微秒、毫秒级别实现配置和业务逻辑的实时更新，比起Nginx秒级的重启是一个极大的进步。
你可以看一下实验环境的“www/lua”目录，里面存放了我写的一些测试HTTP特性的Lua脚本，代码都非常简单易懂，就像是普通的英语“阅读理解”，这也是Lua的另一个优势：易学习、易上手。
高效率的Lua
OpenResty能够高效运行的一大“秘技”是它的“同步非阻塞”编程范式，如果你要开发OpenResty应用就必须时刻铭记于心。
“同步非阻塞”本质上还是一种“多路复用”，我拿上一讲的Nginx epoll来对比解释一下。
epoll是操作系统级别的“多路复用”，运行在内核空间。而OpenResty的“同步非阻塞”则是基于Lua内建的“协程”，是应用程序级别的“多路复用”，运行在用户空间，所以它的资源消耗要更少。
OpenResty里每一段Lua程序都由协程来调度运行。和Linux的epoll一样，每当可能发生阻塞的时候“协程”就会立刻切换出去，执行其他的程序。这样单个处理流程是“阻塞”的，但整个OpenResty却是“非阻塞的”，多个程序都“复用”在一个Lua虚拟机里运行。
下面的代码是一个简单的例子，读取POST发送的body数据，然后再发回客户端：
ngx.req.read_body() -- 同步非阻塞(1)
local data = ngx.req.get_body_data()
if data then
ngx.print("body: ", data) -- 同步非阻塞(2)
end
代码中的“ngx.req.read_body”和“ngx.print”分别是数据的收发动作，只有收到数据才能发送数据，所以是“同步”的。
但即使因为网络原因没收到或者发不出去，OpenResty也不会在这里阻塞“干等着”，而是做个“记号”，把等待的这段CPU时间用来处理其他的请求，等网络可读或者可写时再“回来”接着运行。
假设收发数据的等待时间是10毫秒，而真正CPU处理的时间是0.1毫秒，那么OpenResty就可以在这10毫秒内同时处理100个请求，而不是把这100个请求阻塞排队，用1000毫秒来处理。
除了“同步非阻塞”，OpenResty还选用了LuaJIT作为Lua语言的“运行时（Runtime）”，进一步“挖潜增效”。
LuaJIT是一个高效的Lua虚拟机，支持JIT（Just In Time）技术，可以把Lua代码即时编译成“本地机器码”，这样就消除了脚本语言解释运行的劣势，让Lua脚本跑得和原生C代码一样快。
另外，LuaJIT还为Lua语言添加了一些特别的增强，比如二进制位运算库bit，内存优化库table，还有FFI（Foreign Function Interface），让Lua直接调用底层C函数，比原生的压栈调用快很多。
阶段式处理
和Nginx一样，OpenResty也使用“流水线”来处理HTTP请求，底层的运行基础是Nginx的“阶段式处理”，但它又有自己的特色。
Nginx的“流水线”是由一个个C模块组成的，只能在静态文件里配置，开发困难，配置麻烦（相对而言）。而OpenResty的“流水线”则是由一个个的Lua脚本组成的，不仅可以从磁盘上加载，也可以从Redis、MySQL里加载，而且编写、调试的过程非常方便快捷。
下面我画了一张图，列出了OpenResty的阶段，比起Nginx，OpenResty的阶段更注重对HTTP请求响应报文的加工和处理。
OpenResty里有几个阶段与Nginx是相同的，比如rewrite、access、content、filter，这些都是标准的HTTP处理。
在这几个阶段里可以用“xxx_by_lua”指令嵌入Lua代码，执行重定向跳转、访问控制、产生响应、负载均衡、过滤报文等功能。因为Lua的脚本语言特性，不用考虑内存分配、资源回收释放等底层的细节问题，可以专注于编写非常复杂的业务逻辑，比C模块的开发效率高很多，即易于扩展又易于维护。
OpenResty里还有两个不同于Nginx的特殊阶段。
一个是“init阶段”，它又分成“master init”和“worker init”，在master进程和worker进程启动的时候运行。这个阶段还没有开始提供服务，所以慢一点也没关系，可以调用一些阻塞的接口初始化服务器，比如读取磁盘、MySQL，加载黑白名单或者数据模型，然后放进共享内存里供运行时使用。
另一个是“ssl阶段”，这算得上是OpenResty的一大创举，可以在TLS握手时动态加载证书，或者发送“OCSP Stapling”。
还记得第29讲里说的“SNI扩展”吗？Nginx可以依据“服务器名称指示”来选择证书实现HTTPS虚拟主机，但静态配置很不灵活，要编写很多雷同的配置块。虽然后来Nginx增加了变量支持，但它每次握手都要读磁盘，效率很低。
而在OpenResty里就可以使用指令“ssl_certificate_by_lua”，编写Lua脚本，读取SNI名字后，直接从共享内存或者Redis里获取证书。不仅没有读盘阻塞，而且证书也是完全动态可配置的，无需修改配置文件就能够轻松支持大量的HTTPS虚拟主机。
小结
- Nginx依赖于磁盘上的静态配置文件，修改后必须重启才能生效，缺乏灵活性；
- OpenResty基于Nginx，打包了很多有用的模块和库，是一个高性能的Web开发平台；
- OpenResty的工作语言是Lua，它小巧灵活，执行效率高，支持“代码热加载”；
- OpenResty的核心编程范式是“同步非阻塞”，使用协程，不需要异步回调函数；
- OpenResty也使用“阶段式处理”的工作模式，但因为在阶段里执行的都是Lua代码，所以非常灵活，配合Redis等外部数据库能够实现各种动态配置。
课下作业
- 谈一下这些天你对实验环境里OpenResty的感想和认识。
- 你觉得Nginx和OpenResty的“阶段式处理”有什么好处？对你的实际工作有没有启发？
欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
精选留言
2019-08-16 20:09:42
2019-08-19 08:14:54
2019-08-17 16:39:16
2019-08-16 10:33:26
同步阻塞:代码同步顺序执行，等待阻塞操作完成继续往下走。
同步非阻塞:代码顺序执行，遇见阻塞操作时，CPU执行世间会让出去，得到结果时通过callBack继续回到之前阻塞的地方。
大概是这样么?
然后就是同步阻塞的话，在阻塞的时候会占用CPU执行时间么?
同步非阻塞的话，遇到阻塞操作，主线程直接让出CPU执行时间，上下文会切换么?上下文切换开销会很大吧，如果只是让出怎么实现阻塞数据没就绪时不被分配cpu，如果一直没回调这个线程会死锁么?
代码中请求，redis，数据库这些操作是同步阻塞，还是同步非阻塞?
2019-08-23 08:55:22
2021-03-10 19:08:59
2020-04-05 11:00:51
老师，这块没太明白，同步和非阻塞原本是矛盾的，一个大动作由多个小动作组成，如果其中一个小动作是一个慢动作，而且是同步模式，下面的动作必然会被阻塞住吧？
你上面解释说“线程自己主动切换CPU给其他任务”，
1：那线程什么时候主动切换CPU给其他任务？
2：这里的其他任务指什么？
3：线程主动切换CPU给其他任务后处于什么状态？为什么？
5：还有我的假设中慢动作后面的动作不是被阻塞了吗？
6：还是说维度与层次不同，同步非阻塞的主体是线程，而不是线程中的一系列动作？
2019-08-16 18:19:10
2019-12-27 16:57:19
2019-08-16 11:52:37
2020-09-06 16:11:56
Nginx 有reload 命令，只是不是自动reload。
2019-08-16 17:59:40
同步非阻塞:nginx，是单线程模型，主线程类似一个多路复用器(和NIO的IO模型类似?)，所有的请求是以任务形式被受理，任务是交给协程程处理。任务结束，主线程检测到事件进行对应操作。主线程和协程一直都在处理任务，所以不会涉及到线程的上下文切换。传统的web服务器，Tomcat这些都是线程池形式的。一个请求交给一个线程，请求阻塞了这个线程就会被切换出去开销很大。nginx协程开销已经小了，又通过事件+异步非阻塞模型减少了上下文切换所以吞吐量就能很大。
2019-08-16 11:51:54
我感觉有些时候，写代码比写配置文件更加灵活，OpenResty 通过Lua脚本就可以达到这个效果。
你觉得 Nginx 和 OpenResty 的“阶段式处理”有什么好处？对你的实际工作有没有启发？
阶段式处理，有点类似一个类的生命周期，又有点类似责任链模式。实际工作中编写前端组件，也可以采取类似的方式，把组件渲染分阶段，生命周期细分，使组件更专注更内聚。
2023-02-06 12:44:59
2023-05-26 09:47:02
export https_proxy=http://proxyhost:proxyport 然后再curl
客户服务器使用上面这两种命令才可以访问百度，如果用OpenResty做可以做吗，是用Lua实现吗？
2023-05-25 14:52:38
2022-06-25 17:48:12
2022-04-01 19:09:03
2022-03-01 18:00:22
2021-10-30 00:14:43