SegmentFault 专访丨OpenResty 国内社区推进者：艾菲

导读

OpenResty Con 2015

即将在北京举办，这是全球第一届 OpenResty 技术大会。而本次大会的发起者之一艾菲本人，也正是 OpenResty 国内推进者，于是借此机会，SegmentFault 独家专访艾菲，了解他与 OpenResty，与开源的共同经历。

艾菲（

@河马大侠AF

），企业安全架构师，iresty 组织成员。嵌入式工程师出身，实现过一套完整的工业机器人主控系统，自动壁障，路径规划，精确识别，任务控制，希望用代码赋予机器生命。2013 年加入奇虎，被 OpenResty 的魅力吸引，感受到另外一种充满生命力的软件设计思想，并着手根据自身业务特性在 OpenResty 中添加更多 API。

关于 OpenResty：

OpenResty（也称为 ngx_openresty）是一个全功能的 Web 应用服务器，它打包了标准的 Nginx 核心，很多的常用的第三方模块，以及它们的大多数依赖项。

OpenResty 通过汇聚各种设计精良的 Nginx 模块，将 Nginx 有效的变成一个强大的 Web 应用服务器，从而让 Web 开发人员可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及Lua 模块，快速构造出足以胜任 10K+ 并发连接响应的超高性能 Web 应用系统。

OpenResty 国内社区推进者：艾菲

初识 OpenResty

你是从什么时候开始接触 OpenResty 的？

在加入奇虎之前，我在一家创业公司做嵌入式开发，负责一款工控机器人的主程序设计开发，业余时间研究反汇编，做外挂，自娱自乐。

2013 年 7 月正式加入奇虎企业安全事业部，负责服务端日志数据处理和升级程序，因为业务上的交集接触到 OpenResty（简称OR），刚开始是完全将 Nginx 当做 Lua 的网络库，通过脚本的方式来操作各种请求，生成消息体。后来，随着使用的深入才越发觉得将脚本语言的 VM 嵌入 Nginx 的开发模型兼具优秀的执行效率和开发效率都是其它任何语言或者框架不可比拟的。

今年 9 月，Nginx 官方宣布支持 JavaScript，其设计思想和 OR 如出一辙，只是主角换成了用户群体更为广泛的 JS，这充分说明将脚本解释器嵌入一个 Nginx，并提供利用脚本语言访问 Nginx 的思路是正确的。

奇虎是国内为数不多的选择 OpenResty 做服务端的公司，公司的产品线选择这门技术是有一定风险的，能不能谈谈最终选择这门技术的思路？

其实这里边想谈的很多，产品线上新技术的引入通常情况下都会遭到质疑甚至否定，最好的方式是给产品一个过渡期，将新技术慢慢引入到业务中。

在最开始的产品线上有两套服务端程序，一套是用 CPP 搭建的 HTTP 服务器 + 日志分析主程 + 策略任务分发主程，另外一套则是用 OR 搭建的 HTTP 服务器，Web 层面是基于 Yii 框架写的，而存储则是共用 Postgres。这样一来，两套框架上的业务就有一个横向的比较，一段时间后，无论从业务稳定性、开发效率、QPS 等方面 OR 都以压倒性优势胜出，可以说 OR 在这个时候就已经表现出其强悍的生产力。

再后来，之前的混合式的服务端框架已经达到性能瓶颈，加上部门产品线的战略调整，我们有机会设计一套具备更高性能的服务端架构，这让我们非常兴奋。新架构方案选型非常 OPEN，几乎所有的重要组件都是来自开源社区，这是因为之前开源软件的使用经验让我们意识到开源的代码才是安全、稳定的，更值得信任的。

在选型过程中还有一些小故事，架构选型的时候正值 Golang 如日中天，NodeJS 也是风声水起，在 Golang、NodeJS 还是 OR 之间存在一些分歧，后来我们团队的大拿认为，我们期望的是一套能用同步的思维编码，但背后的实现是异步的，这样既不会陷入 callback hell，也不会在代码里做大量的并发控制，在这样的思想指导下，OR 就成为服务端架构核心的唯一选择。

当然在项目的实施过程中也遇到了很多挑战，所幸 OR 的开源生态并非我们预料的那样糟糕，我们都能找到相似的场景解决方案，稍加调整也能应用到自己的产品线。

能方便谈谈你们的产品线在发展过程中都遇到过哪些问题吗？

任何产品在实现的过程中，细枝末节的问题都会遇到不少，这里就不一一提了，我将我们遇到的问题归为两大类：平台兼容性和实施部署。

平台兼容性问题是产品性质决定的，我们的产品面向的是企业级用户，而一些小的企业或者单位不愿意也没有能力去部署维护一套基于 Linux 系统的服务端系统，而 Windows 系统上的架构又很难满足大型企业的需求，我们也曾用过将大企业的终端切分成小节点，分开部署，级联管理的方式，但是带来了巨大的部署成本，所以我们被迫设计一套能将相同业务代码跑在不同系统环境下的架构，这一点其实还是蛮厉害的，当然也要赞一下我们组的大神们做出的架构选型，他们真的是非常给力。

实施部署问题我相信是大多数互联网公司发展到一定规模都会遇到的问题，但我们实施层面并不是成百上千台服务器的功能灰度发布，或是服务发现、容灾等偏向于运维的问题，这一点差别还是蛮大的。首先，我们的服务器是基于私有云架构的，我们需要将产品服务端部署在用户现场，而现场物理机的系统可能是 CentOS、Ubuntu、RedHat 等等，众所周知，软件在各种 Linux 发行版本的依赖是有差异的，而实施人员又无法去 yum，apt-get（大多企业用户是隔离网环境），这几乎使得产品的批量化部署成为了不可能，或者门槛很高，于是在产品开发的初期我们就比较“激进”地选择了 Docker，在 Docker 里构建一套完整的天擎服务端，然后将镜像打包到用户现场，跑起来，这样一来真正的部署过程就简化为两个步骤：1. 装 Docker； 2. 导入镜像。

OpenResty 的优势

OpenResty 有哪些典型的应用场景以及技术优势，你能简单介绍下吗？

项目的官方文档上提到 OR 的主要技术应用点有以下方面：

• 在 Lua 中揉和和处理各种不同的 NGINX 上游输出（proxy，drizzle，postgres，redis，memcached 等）
• 在请求真正到达上游服务器之前，Lua 可以随心所欲的做复杂的访问控制和安全检查
• 通过 Lua 随心所欲的控制操作响应头里的信息
• 在内容 handler 中随意编写复杂的 web 应用，使用同步的编程方式但是内置的异步非阻塞，访问后端数据库和其他存储
• 在 rewrite 阶段，通过Lua完成非常复杂的 URL Dispatch
• 通过 Lua 为子请求或者任意 location 实现快速高效的缓存机制

上述的技术特点决定了 OR 的应用场景可以是广泛的，可以用于实现 api server、路由控制、高并发入口、动态服务降级、动态负载均衡，由于脚本语言的易用性，这些控制的实现复杂度不会很高。值得一提的是现在的网络环境越来越复杂，网络攻击手段也越来越高明，这就要求WAF（网站应用级入侵防御系统）也应该是一个高效的响应系统。

这里的高效不仅包括过滤、拦截过程，而且还要具备防添加御规则的高效。这些应用场景都是我们在项目的开发中遇到并总结出来的，并由发起了一个开源项目《OpenResty 最佳实践》，本意是将这些应用实践记录下来，没想到却引起了众多开发者的共鸣，大家都积极响应，参与贡献，并与我们分享 OR 在各自技术场景中的应用。让我们惊讶的是，OR 不光是在 api server 场景下，而且在前端渲染，一些知名游戏的服务端还有云服务等领域都有应用，一些技术爱好者为了在公司内部推广这门技术，甚至为其编写框架，想在 PHP 开发者中推广。我们非常高兴看到这样的结果，同时也会尽力去办好这次大会，组织更多技术交流，也算是对开源项目的支持和对开源文化的回馈。

关于社区与开源

谈到回馈开源社区，据我所知在国内除了一些知名的作品，其它的开源项目参与者少，你怎么看这种现象呢？

这种现象很正常，普通的开源项目一般能有一定量的用户加上几个贡献者就已经很不错了。

在我看来，目前存在两种形式的开源，第一种充分利用像 GitHub 这样的代码托管平台提供的服务，将源码贡献出来供交流或自娱自乐，一些优秀作品的作者甚至会提交详细项目文档和创办讨论组，在论坛做 Q&A。这类开源项目在开源的初期往往完成度就已经很高，但是后期的发展思路和方向都会收到作者自身精力的限制到达一个瓶颈。

第二种开源是为某种领域的应用构建生态核心区域，然后创办技术社区来讨论项目未来的发展，之后可以形成某种形式的商业支持，帮助和推动项目的发展。OR 这个项目在很长一段时间内都属于第一种形式的开源，所以我们希望在 11 月 14 日举办一场 OpenResty 技术大会，同时这也是这门技术的首次技术型会议，我们希望通过这样一种形式让这门技术吸引到更多人的注意力，持续推动这门技术的发展，当然我们也请到作者章亦春老师本人来到大会现场，谈谈他对这个项目的未来发展的想法，希望能促成一些商业化的支持，让社区走的更远。

目前社区商业化是个难题，垂直类社区普遍会做一些人才输送和项目外包，你怎么看？

整个团队都清楚地认识到社区商业化的必要性，要让参与的人有回报才能促进良性循环，问题在于商业化的形式，我们请教过一些做过社区商业化的前辈，也假设过一些可能性，但都差强人意。

最开始我们想是否能对社区的成员设立收费环节，又或者在在线平台做收费视频教程，但这些都有可能会影响到社区成员的感受而导致成员的流失。也有人提议，能否通过举办技术大会来实现盈利，但就目前这次大会来看，依靠会议的盈利来支持社区的开销是不可能的，我们收取的赞助费和门票只够支付场地费和活动的集体开销，而活动本身是为了面向技术爱好者，打造良好的技术氛围，吸引更多人参与，并在其中得到成长。因此活动要接地气，不能走高大上的路线，在这里做商业化的切入不太合适。还有朋友建议是否能通过对外提供解决方案并收取咨询费来实现商业化，但是个人觉得成不了规模，同时可能还会收到社区成员自身所在公司的限制，自然就更谈不上盈利咯。

我们心中都存在一种理想主义的商业模型，希望促进 OR 的发展，让其在各个领域都能得到应用，然后通过基金会的形式建立基金池，企业通过赞助基金会的来影响社区的发展，社区的贡献者也能通过贡献获取收益，在这样的良性模式下催生出更多具有创造力的组件，让 OR 的生态更加丰富。

OpenResty 最开始的讨论仅限于 Google Group，这让国内的开发者访问门槛变高，很难得到该技术最新的发展趋势和应用场景。所以我们希望通过对外演讲、在线视频、开源项目、论坛建设的方式推动 OpenResty 在国内的发展，聚拢现有的使用者，活跃技术交流从而促进这门技术的发展。

2015 年中，我们正式以 iresty 组织的名义发起对外宣传，并在一群技术爱好者的帮助下促成了 11 月 14 日首届 OpenResty 技术大会，期望通过这次大会促进 OpenResty 技术交流，让更多的人加入到 OpenResty 阵营，来推动 OpenResty 社区的发展。这次联合了来自奇虎360、京东、阿里云、又拍云、酷狗、Adobe 等公司的一线工程师来做分享，OpenResty 主要作者

章亦春老师

也会参加本次大会，一同探讨 OpenResty 未来的发展。

大会详情大家可以访问

http://www.iresty.com

了解。最后，再次宣传下 OpenResty 社区

http://openresty.org

，期待看到越来越多的开发者加入！