转载

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%，我是很赞同的。王春雨总结了“如何避免开源 = 项目结束”的四点：

体量小
解耦
同源
持续投入

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

这可以作为检验大公司开源项目能走多远的试金石。以 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 库： lua-resty-repl 。通过这个库，可以在运行时打开一个 console，去查询上下文的一些信息。跟 print debug 说再见！小哥如是说。我觉得这是个很有趣的项目，至少可以用来代替 luajit 自身那个不好用的 repl，于是特地看了下它的源码，了解其幕后的实现。这个库通过 ffi 调用了 readline 库来实现 repl。对于 GNU/Linux，这个库是自带的；对于 Mac，可以 brew install readline 来安装这个库；对于 Windows，目前不支持，不过移植到 Windows 是可实现的。

下一个演讲者是来自新浪的周晶，讲的是新浪移动的 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_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 的数据驱动框架，测试逻辑一目了然。

原文 https://segmentfault.com/a/1190000007767406

正文到此结束