知识卡片
从"嵌入脚本语言"到"编译型DSL平台":OpenResty的技术演进路线
内容
OpenResty的未来技术方向揭示了一条基础设施类项目常见的成熟路径:从”提供一门可编程的通用脚本语言”,逐步演进为”提供针对具体业务领域的专用抽象”。具体规划包括:为PHP、Python、JavaScript等语言实现常用子集,让开发者可以用自己更熟悉的语言写代码,底层再统一转换成LuaJIT字节码——这一步的意图是把OpenResty整体看作一个虚拟机、Lua看作这个虚拟机上的”机器语言”,让开发者能在更高的抽象层面思考业务问题,而不必纠缠于Lua本身的实现细节,同时依然能享受到接近手写Lua代码的运行时效率;更进一步,是在此基础上为典型互联网业务场景(比如反向代理、负载均衡这类高度模式化的问题)提供更贴近业务语义的领域专用语言(DSL)和配套的编译器、运行时支持——案例中提到的OpenRestyEdge平台就是这个方向的实践,用Edge小语言编写的规则会被自动编译成针对LuaJIT和OpenResty环境优化过的Lua代码,同时带有请求粒度的沙箱保护。这条演进路线背后的判断是:传统的”解释型Web框架”倾向于用不断叠加运行时封装(类、函数封装)的方式应对业务复杂度增长,而”编译型”路线则倾向于为特定问题域设计更贴近业务语义的小语言,再通过优化编译技术把这种更高层的表达自动转化为接近手写底层代码的执行效率——这个思路的价值不局限于OpenResty本身,对任何”底层技术已经足够成熟、下一步该往哪走”的基础设施项目都有参考意义:与其无休止地在同一层抽象上叠加更多的运行时封装,不如认真考虑往上再抽象出一层更贴近具体问题域的表达方式,同时用编译技术保证这层新抽象不会侵蚀掉底层已经积累的性能优势。
参考来源
- 位置:《高可用架构(第1卷)》第2章《高可用架构原理与分布式实践》"2.11 OpenResty的现在和未来"节,"2.11.7 未来重点解决的问题和新增特性"(源文件:_epub-src/OEBPS/Text/Chapter2_11_8.xhtml)
- 结论依据:原文说明"实现PHP、Python、JavaScript等语言的常用子集……在这种模型下,OpenResty就是一个虚拟机,而Lua语言是这个虚拟机上的'机器语言'……我们希望能通过自己的实践,让业界越来越多地关注'编译型'Web框架所使用的优美抽象和优化编译技术,而不仅仅是传统的'解释型'Web框架所使用的不断地叠加运行时封装",直接支撑本卡片结论。
- 原始内容:实现PHP、Python、JavaScript等语言的常用子集,让开发者可以用自己喜欢的语言写OpenResty的代码,底层转换为LuaJIT的字节码……我们希望能通过自己的实践,让业界越来越多地关注"编译型"Web框架所使用的优美抽象和优化编译技术,而不仅仅是传统的"解释型"Web框架所使用的不断地叠加运行时封装。