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 Con 2015

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

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

大会详情你们能够访问 http://www.iresty.com 了解。最后，再次宣传下 OpenResty 社区 http://openresty.org ，期待看到愈来愈多的开发者加入！