OpenResty Con 2016 见闻杂记

我昨天参加了在深圳举办的 OpenResty Con 2016，趁着周末有空记录下与会过程，作为路边社的一篇报道。
由于内容基于会上的笔记和事后的回忆，读起来会显得琐碎，具体细节可能会有些出入。

早上九点，在腾讯大厦副楼的会议厅，大会开始了。

首先是温铭作为举办方致辞，内容是 OpenResty 基金会成立的历程。作为基金会的首席律师兼会计兼其他，温铭回顾了基金会的发展，并陈述了 OpenResty 在不久将来的愿景。

接着是春哥的演讲。作为 OpenResty 的 “仁慈的独裁者”，春哥回顾了 2016 年 OpenResty 主要的发展。大的发展有两个：一个是追随 Nginx 开辟第二战场 —— stream-lua-nginx-module；另一个是支持动态 upstream 的 balancer_by_lua。还有一个值得一提，ngx.semaphore 是对多个 lua 协程间的同步的一次革新，在这基础上可以实现 CountDownLatch 之类更高一层的抽象。春哥还展望了 2017 年的计划，中心思想只有一句话，小语言该搞起来了。春哥计划实现用于流量控制的 Edge 语言，用于调试的 Y 语言，用于数据分析的 ORSQL 语言。这些 DSL 会基于一个元 DSL —— fan 语言开发。不过，话说 sregex 和 opm 的坑什么时候可以填起来？

春哥之后是 20 分钟的中场休息时间。也是跟周围的人闲聊的好时候。有人觉得春哥讲得比较玄幻。实现一个 DSL，然后用 DSL 去写业务，把业务逻辑复杂的地方隐藏在编译器的实现里，的确是个激进的想法。是否可行，有待明年的验证了。会后我跟一对在医疗信息化创业的夫妇聊天，他们表示，他们需要设计一套 DSL，去抽象医疗行业里的大量行业逻辑。祝他们找到成功的法门。有人把部分流量迁移到 OpenResty 上，原本要用30台机器，现在只用几台机器就够了，感觉很受鼓舞，准备把剩下的流量也迁过去。有人问到 OpenResty 的 html 渲染模板选择，不过周围的人要不是转发路由，要不直接吐 json，对于这个问题没法回答。

然后是 Marco，Mashape 的 CTO， 做关于 Kong 的演讲。Mashape 是家从事 API market 的公司，他们开源了名为 Kong 的 API Gateway。演讲主题是 monolithic way VS microservice(the kong) way。过去的 monolithic way中，先有 API，然后再添上 API Gateway，Gateway 是 API 的一部分。而新的 microservice way中，API Gateway 会先于 API 存在，具体的 API 实现可能隐藏在 Gateway 的后面。Kong 采用插件化的方式，支持动态增减功能。有趣的是，每个 Kong 实例通过 serf 组件来实现基于 gossip 协议的分布式通信。另外，Kong 的 data source 可以选择 cassandra，支持分布式的数据层。这个演讲主要是讲 Kong 的功能，没有提他们是怎么实现的。不过由于 Kong 是开源的，估计感兴趣的同学都已经下载了源码开始研究了吧。

下午一开始是来自 Tencent 的 TOSA（腾讯开源联盟）组织者王春雨，讲腾讯在开源方面已经做的、正在做的、将要做的事。由于这次 OpenResty Con 是跟腾讯大讲堂合办的，所以这其实是腾讯大讲堂的议题。虽然无关 OpenResty，但是关乎 OpenSource。其中有些道理，比如把代码开源出来只是完成开源的50%，我是很赞同的。王春雨总结了“如何避免开源 = 项目结束”的四点：

1. 体量小

2. 解耦

3. 同源

4. 持续投入

（私以为还能添上一点：有来自其他公司的开发者积极参与）

这可以作为检验大公司开源项目能走多远的试金石。以 Tengine 作为反例，该项目的文档已经很久没有更新了。举个例子，文档里说明最多支持 128 个动态模块加载。但实际上最多支持的动态模块加载数是 256 个，而且这个参数可以通过编译时选项调整。就这一点上，我只能说 Tengine 并没有完全开源，因为它没有一个社区，没有一个长期计划。

接下来，是来自今日头条的吴兆玉来讲他们的 API Gateway —— Orange。上午的 Marco 也是讲 API Gateway，所以兆玉特意说了些跟 Kong 不同的地方。比如 Orange 提供了 condition selector，可以从输入中解析出参数，然后走匹配的规则。这有点像 logstash/heka/flume 等日志分析组件的做法。另外 Orange 还附赠了一个 dashboard。跟 Kong 一样，Orange 也是开源的。

在这个演讲之后，是几个闪电演讲。
有位用 OpenResty 实现全部后端逻辑的开发者，分享了他们做 RESTful 路由的实践。思路是按资源组织文件夹，然后用 HTTP 方法名决定调用的文件名。最后在 content_by_lua_file看到的是这样的文件名规范：$luapath/$1/$request_method.lua。
另一位来自香港的小哥，分享了他同事做的一个 openresty repl 库：saks/lua-resty-repl。通过这个库，可以在运行时打开一个 console，去查询上下文的一些信息。跟 print debug 说再见！小哥如是说。我觉得这是个很有趣的项目，至少可以用来代替 luajit 自身那个不好用的 repl，于是特地看了下它的源码，了解其幕后的实现。这个库通过 ffi 调用了 readline 库来实现 repl。对于 GNU/Linux，这个库是自带的；对于 Mac，可以 brew install readline 来安装这个库；对于 Windows，目前不支持，不过移植到 Windows 是可实现的。 saks 小哥响应很快，周一就实现了对 Mac 的支持。

下一个演讲者是来自新浪的周晶，讲的是新浪移动的 OpenResty 开发实践。这个演讲有趣的地方，在于新浪移动是如何在业务压力倒逼下，从老早的 Apache+PHP 迁移到现在的 OpenResty+PHP，以及这一过程中，OpenResty 是如何移花接木，一步一步占据原本属于 PHP 的份额。

来自 AISpeech 的张顺则把 OpenResty 用到了计算密集型的应用上。总结他的演讲，就是 hack everything。他们在 Nginx 传统的 master/worker/cache 进程组合中，通过 fork 引入新的一组计算进程。worker 进程通过 socket 跟计算进程通信，传递计算任务和结果。由于借助 lua 协程可以同时跟多个外部组件进行 socket 通信一样，worker 进程可以把计算任务分割，交由多个不同类型的计算进程并行处理。当然你可能会觉得，这是个 monolithic 实践。不过 OpenResty everywhere 可以让他们复用相同的 lua-resty-* 库，也许微服务不是包治百病的良药，对吧？这还不是最有趣的，他们实现了名为 lasa 的程序，兼容 OpenResty 部分 API，跑在 ARM 和 MIPS 平台的各种设备上。lasa 就是一个中枢节点，介于平台特定的 UI 界面层和服务端之间，完成平台无关的业务处理。之所以要兼容 OpenResty 部分 API，也是为了最大复用各种库。现在同样的代码逻辑，既可以在服务端的 OpenResty 上跑，也可以在客户端的 lasa 上跑。

本次大会最后一个演讲，是由又拍云的叶靖分享的《OpenResty在云处理服务集群中的应用》。干货很多。
Nginx 有一个 undocumented 的 “feature”，如果启用了 proxy_request_buffering， upstream 重试就没办法生效（感兴趣的同学可以看下 Nginx 代码中 ngx_http_upstream_next的实现）。对于这个问题，又拍云的解决办法很简单，就是用 lua 代码接管 proxy_pass 的逻辑。他们开源了一个 lua-resty-httpipe 的库，可以串联多个 upstream。
这次演讲，叶靖的重点是基于 lua-resty-checkups 和 balancer_by_lua 的服务动态发现。又拍云使用 mesos 来调度 docker 集群，然后向 consul 注册服务。通过前面的两位主角，他们实现了从 consul 获取 upstream 列表，动态转发的一套系统。这套名为 slardar 的系统也已经开源出来，感兴趣的同学可以去了解一下。
叶靖提到，鉴于正态分布原理，他们写了个 python 脚本，从 elasticsearch 中获取一段时间内 502 数 x，如果 x - µ > 3σ，则自动触发 upstream 下线。据说又拍云只有 8 位运维，总共 60 多个开发。一个精益的开发团队，离不开这类四两拨千斤的巧劲。
slardar 还有一个有趣的地方，这个系统支持动态加载 lua 代码。这一切基于三个 lua 标准库里的方法 loadfile、loadstring、setfenv。再加上 timer + 共享内存的同步，确保每个 worker 都能加载上同样的 lua 代码。另外为了保证加载的 lua 代码是有效的，还要先 pcall 一下。感兴趣的同学可以到 slardar 的代码里寻宝。
正如其他使用 OpenResty 的团队，又拍的工程师也造了一个轮子用于测试代码。他们的轮子是 Python 写的。一开始是命令式的测试用例，客户端发起请求，然后检查响应是否正确。随着业务的发展，测试用例越来越难懂。修复不能通过的用例，并不比修复代码中的 BUG 简单。后来他们借鉴自 TEST::Nginx，实现了一套基于 Python 的数据驱动框架，测试逻辑一目了然。