浅谈openresty
熟悉了nginx后再来看openresty，不得不说openresty是比较优秀的。
对nginx和openresty的历史等在这此就不介绍了。
首先对标nginx，自然有优劣
一、开发难度
nginx：
毫无疑问nginx的开发难度比较高，需要扎实的c/c++基础，而且还需要对nginx源码比较熟悉，开发效率慢，比如实现一个类似echo的功能，至少要上百行代码。而openresty只需要一句ngx.say即可。
openresty：
由于是lua脚本级别的，开发效率自然高出许多，开发难度也降低了很多，不需要知道nginx的源码，只需要知道nginx的大概的流程和基础原理，还有基础配置。当然必须要去了解openresty提供的接口。官方接口文档链接如下：
Lua Ngx API - OpenResty Reference
因此openresty开发容易上手，开发效率很高。
二、性能
这个是离不开的话题，nginx的性能在web架构上是出了名的高效。在大部分程序员固有的思维中可能想当然的认为脚本肯定比如c运行得快。当然这是正常的，毕竟绝大多数脚本确实如此。然而在openresty这你可能需要改变这样认知。
首先openresty的基于nginx的，在其中嵌入了lua模块，但是其也充分发挥了nginx的高性能，如果你认为使用lua脚本性能就降低了，那就错了。
首先lua虽是脚本语言，但是他特别小巧，也是使用c来实现的，而且使用的LuaJIT的技术编译lua代码，运行效率比原来的lua解释器高出了许多，如果再深入到源码，会发现，openresty大致是使用向lua注册c函数或ffi方式实现lua对nginx接口，也可以这么理解，lua脚本源码在nginx启动的时候，就被翻译成了二进制的代码。所以其性能非常好。
但是你非要和原生的nginx相比，性能到底有没有说的这么好，大家不防自己试试。看如下配置
server {
listen 8888 ;
server_name test;
location /ngx {
echo "ngx hello\n" ;
}
location /lua {
content_by_lua_block {
ngx.say("lua hello\n")
}
}
}
使用ab测试工具进行10万次测试
ab -k -c 20 -n 100000 'http://localhost:8888/ngx'
ab -k -c 20 -n 100000 'http://localhost:8888/lua'
我在我的设备上测试结果则lua脚本完胜。而且某些指标lua还胜出不少。
我曾经是也自以为lua性能可不如c，自此我无数次的测试后，发现，我的认知错了。
因此从性能上而言，openresty是完全发挥了nginx的高性能，在某些方面性能不降还反超了。
三、灵活性
nginx：
灵活性是nginx的一个主要的特性。其完全模块化的设计，模块之间耦合度比较低，非模块代码极少，此设计使其具备高度的灵活性。
openresty：
openresty提供了大量比较精良的lua库，也具备比较高度的灵活性，但和nginx比起来要逊色一些。
openresty主要是使用其提供的lua库和一些第三方的lua库，对于nginx中一些复杂的开发，openresty可能达不到要求。
比如:mysql，openresty自带的库，有使用限制，不能在进程初始化，模块初始化等阶段使用
在nginx中，使用c自然使用c接口调用mysql可以在任何地方进行mysql的连接初始化等操作。当然我们或许可以使用第三方的mysql的lua库来解决此问题。
再如，如果我们需要额外新的内置变量，这个是就openresty所不能做到的。
总体而言，openresty灵活性也很不错，但是比nginx要逊色一些。
本次只是简单的浅谈。
总体而言，使用openresty比nginx更有性价比，主要就是nginx的开发难度比较大，而且openresty充分发挥了nginx的高性能，某些方面还反超了，因此只要能使用openresty开发，我肯定优先选择openresty。但是如果想要更加用好openresty还是需要进一步去了解openresty源码特别是nginx的源码，这样只会对你开发工作如虎添翼。
比如了解了openresty的源码，你才可能知道，其access_by_lua_block是在access阶段中最后一个被执行(第一次进入时，会自动将本模块移到最后该阶段最后一个，此操作进行一次，具体参见函数ngx_http_lua_access_handler的实现)