OpenResty—专注高性能服务开发

内容简介： 
OpenResty设计初衷
应用场景和示例
新手拦路虎

企业安全的最佳实践

奇虎企业安全从2012年开始使用OpenResty，这门技术学习曲线比较陡，能参考到资料比较少，我们团队做了很多努力，希望能降低入门的难度。先说下几年前做架构选型的时候，我为什么会选择OpenResty。这个很重要，我们经常看到一些架构分享，但是基本上听的时候很high，但听完发现好像没法用到自己的业务上。其实架构如何设计并不重要，因为每家公司，每个团队，他们的公司文化和技术背景各不相同，生搬硬套会适得其反。重要的是当初为什么这么选择，中途为什么调整。我们的产品要求服务端提供高性能的API接口，QPS至少过万，未来需要支撑到10万。我们并没有急于去使用PHP、Python或者其他的语言来实现功能，而是先勾勒出一个理想化的技术模型。

这个模型应该具备：

1、非阻塞的访问网络IO。在连接MySQL、redis和发起HTTP请求时，工作进程不能傻傻的等待网络IO的返回，而是需要支持事件驱动，用协程的方式让CPU资源更有效的去处理其他请求。很多语言并不具备这样的能力和周边库。

2、有完备的缓存机制。不仅需要支持redis、memcached等外部缓存，也应该在自己的进程内有缓存系统。我们希望大部分的请求都能在一个进程中得到数据并返回，这样是最高效的方法，一旦有了网络IO和进程间的交互，性能就会受到很大影响。

3、同步的写代码逻辑，不要让开发者感知到回调和异步。这个也很重要，程序员也是人，代码应该更符合人的思维习惯，显式的回调和异步关键字，会打断思路，也给调试带来困难。

4、最好是站在巨人肩上，基于成熟的技术上搭建。采用一门全新的语言和技术，需要经历前期频繁调整的阵痛，还可能站错队。基于以上几点的考虑，我们考察了当时的一些方案，选择了诞生不久的OpenResty。

首先，它最大的特点就是用同步的代码逻辑实现非阻塞的调用。

其次它有单进程内的LRU cache和进程间的share DICT cache，而且它是揉合 NGINX 和 LuaJIT 而产生的。

第一次看到这样的方案，我觉得它肯定会颠覆高性能服务端的开发。为什么呢？在我之前的公司里，每天会有几百亿次的查询请求，而服务器只用了十台。

我们采用了NGINX C模块 ＋ 内置在 NGINX 中的KV数据库（自己开发的），来实现所有的业务逻辑，达到这个目标。没有跨越机器，也没有跨越进程，所有的逻辑都在 nginx 里面完成。听上去很牛逼，但是过程非常艰辛，两三个十几年工作经验的大牛做了年多才稳定下来。绝大部分开发能力不足，只能望尘莫及。而且后续的调试和维护，也会花费不少精力。但是OpenResty的出现改变了这一切，OpenResty非常的pythonic，适合人类的正常思维。我个人是python粉丝，所以很喜欢这样的设计思路。你可以把 NGINX 的功能进行自由的拼接，更重要的是，你是用轻巧的 Lua 来完成操控的。并且性能上可以比肩C模块，甚至比之更高。需要提醒的是，OpenResty并不是服务端的银弹，它有自己适合的应用场景。它更适合高并发API Server的开发，适合利用 NGINX 做各种复杂的访问控制和安全检测等。从业界的公司中看，cloudflare、Github、京东、阿里云、又拍云、酷狗音乐等都有比较深的使用。

我们来看两个代码片段，亲身感受下OpenResty的简洁明快。

这个是hello world的例子。只有一行代码，应该是所有语言里面最简单的了。
当然，他也有不好的地方，就是写在 nginx 的配置文件里面，并没有那么直观
如果你没什么感觉，那么对比下这个代码吧。这个是 NGINX 刚刚发布的 nginScript 对应的hello world代码：

五倍的代码量，而且还多了奇怪的双引号和分号。
说到 nginScript，再多说几句，由于javascript本身的流行和开发社区的强大，如果未来两三年它从一个简单的 NGINX 配置语言，逐渐演变成类似 ngx_lua 这样功能非常完备的开发语言，也不能算是出人意料。