OpenResty—专注高性能服务开发

来源:互联网 时间:1970-01-01

内容简介: 
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 这样功能非常完备的开发语言,也不能算是出人意料。





相关阅读:
Top