答疑五：如何在工作中引入OpenResty.pdfVIP

50-答疑（五）：如何在⼯作中引⼊OpenResty？

你好，我是温铭。

⼏个⽉的时间转瞬即逝，到现在，OpenResty专栏的最后⼀个版块微服务API⽹关篇，我们就已经学完了。

恭喜你没有掉队，始终在积极学习和实践操作，并且热情地留下了你的思考。

很多留⾔问题很有价值，⼤部分我都已经在App⾥回复过，⼀些⼿机上不⽅便回复的或者⽐较典型、

有趣的问题，我专⻔摘了出来，作为今天的答疑内容，集中回复。另⼀⽅⾯，也是为了保证所有⼈都不漏掉

任何⼀个重点。

下⾯我们来看今天的这5个问题。

问题⼀：OpenResty在⼯作中的使⽤

Q：快结课了，我也基本上跟下来了，但⾃⼰的实践还是偏少（⼯作中⽬前未⽤）。不过，这确实是很强⼤

的⼀⻔课。感谢温⽼师的持续，后期⼯作中我也会择机引⼊。

A：感谢这位同学的认可，关于这条留⾔，聊⼀聊，如何在⼯作中引⼊OpenResty，这确实是⼀个值得

⼀谈的话题。

OpenResty基于Nginx，并在它的基础之上加了lua-nginx-module的C模块和众多lua-resty库，所以

OpenResty是可以⽆痛替换Nginx的，这是成本最低的开始使⽤OpenResty的⽅法。当然，这个替换过程

也是有⻛险的，你需要注意下⾯这。

第⼀，确认线上Nginx的版本。OpenResty的主版本号与Nginx保持⼀致，⽐如OpenResty1.15.8.1使⽤

的就是Nginx1.15.8的内核。如果⽬前线上Nginx的版本号⽐OpenResty的版⾼，那么你谨慎换

⽤OpenResty，毕竟，OpenResty升级的速度还是⽐较慢的，离Nginx的主线版本要半年到⼀年的时

间。如果线上Nginx的版本和OpenResty的⼀致或者⽐OpenResty的低，那就具备了升级的前提条件。

第⼆，测试。测试是最主要的⼀个环节，使⽤OpenResty替换Nginx的⻛险很低，但肯定也存在⼀些⻛

险。⽐如，是否有⾃定义的C模块需要编译，OpenResty依赖的openssl版本，以及OpenResty给Nginx

打的patch是否对业务会造成影响等。你需要⼀些业务的流量过来做验证。

第三，流量切换。基本的验证通过后，你还需要线上流量的灰度来验证，这时候为了能够快速的回滚，

我们可以新开⼏台服务器来部署OpenResty，⽽不是直换原有的Nginx服务。如果没有问题，我们可以

选择⼆进制⽂件热升级的⽅式，或者是从LB中逐步摘掉和替换Nginx的⽅式来升级。

OpenResty除了可以替代Nginx外，另外两个⽐较容易的切⼊点是WAF和API⽹关，它们都是对性能和动

态有⽐较⾼要求的场景，也有对应的开源项⽬可以开箱即⽤，我在专栏中也有部分涉及到。

再继续把OpenResty深⼊到业务层⾯的话，就需要考虑⽐较多技术之外的因素了，⽐如是否容易招聘到

OpenResty相关的⼯是否能够和公司原有的技术系统进⾏融合等等。

总的来说，从替代Nginx的⻆度来切⼊，然后慢慢扩散来使⽤OpenResty，是⼀个不错的注意。

问题⼆：OpenResty的数据库封装

Q：根据你的指点，要尽量少⽤..字符串拼接，特别是在代码热区。但是我在处理数据库时，需要动态

构建SQL语句（在语句中插⼊变量），这应该是⾮常常⻅的使⽤场景。可是对于这个需求，我⽬前感觉，只

有字符串拼接是最简单的办法，其他真的想不到既简单⼜⾼性能的办法。

A：你可以先⽤我们前⾯课程介绍过的SystemTap或者其他⼯具分析下，看SQL语句的拼接是否是系统的

瓶颈。如果不是，⾃然就没有优化的必要性，毕竟，过早的优化是万恶之源。

如果瓶颈确实是SQL语句的拼接，那么我们可以利⽤数据库的prepare语句来做优化，也可以⽤数组的⽅

式来做拼接。但lua-resrty-mysql对prepare的⽀持⼀直处于TODO状态，所以只剩下数组拼接的⽅

式了。这也是⼀些lua-resty库的通病，实现了⼤部分的功能，处于能⽤的状态，但更新得并不够及时。除

了数据库的prepare语句外，lua-resty-redis对cluster也⼀直没有⽀持。

字符串拼接，包括lua-r