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 库: 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

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » OpenResty Con 2016 见闻杂记

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址