❲OR 社区 MeetUp❳OpenResty第三次MeetUp

Posted 2021-04-24 VanillaOpenResty开发

OpenResty 社区第三次 MeetUp 圆满结束，本次 MeetUp 以邀请制的方式进行，要求报名的同学填写自己来参加 MeetUp 所希望讨论的问题与观点，问题比较典型、观点相对鲜明的同学将会受邀参会。本次如果报名未被邀请的同学，感谢对社区的关注与热心参与，我们期待在后面的 MeetUp 与你相遇，如果被邀请而不能按时参加的同学，请提前与小编联系，因为人数很有限，我们尽可能的不要浪费机会。

本次 MeetUp 按照以下议程进行：

1. 我与 OR 的故事
   

2. ORAB 例会纪要分享、OR 近期的一些 TODO 以及新特性、社区新动向

3. MeetUp 主题 （就受邀同学的问题、观点进行陈述与讨论）

下面是本次 MeetUp 的过程笔录，感谢社区小伙伴 @子布 @yang 的辛苦整理，也欢迎更多的社区志愿者加入，大家齐心协力，OR 社区因你更精彩。

 0X00

我与 OR 的故事

郭州伟

    因项目需求做方案选型（根据app_id等字段进行灰度分流），采用了OR，借鉴新浪开源项目ABtestingGateway。目前想深入了解OR实现API Gateway 及WEB框架。

李璐

才接触不久，群也是这个月才加的。

去年有个项目，那时候是第一次听说OR，那个项目当时预估的量非常大，php和LUA同时开发，最后用的是Lua。当时并不知道这是什么，最开始是想往nginx方面学习，后来查了资料。今年3月份加入了部门的Lua小组，那时候才开始慢慢的感觉到了这些氛围。这个月初老大让做个限流管理平台，现在Nginx有非常多的配置，钱包这边每隔一段时间都要上一个限流的配置。现在上的非常麻烦，需要做一个WEB型的平台在线配置，刚开始想用PHP，但是没人想做，后来说用Lua做，大家一听都挺感兴趣的。刚开始做这个东西也是什么都不知道，看过几遍文档，看过OR最佳实践，后来用香草慢慢做，发现上手挺快的。但是感觉有些周边不太完善的地方，在香草群里各种问，院生老师和大家也热心帮助。 现在第一版已经上线了，马上要开始做第二版，以后也会往这方面做，但是还没有大规模的使用，还属于兴趣小组的自发性学习的阶段，但是我非常看好OR，学习的时候发现它非常巧妙。

杨旭 

刚接触OR不久，现在做的东西和OR相距很远，现在属于学习阶段。

刘东亮

第一次了解OR是老罗的发布会，我就去查了下才开始了解。

周为

以前有一段时间网站总是被人攻击，一开始我们是通过改Nginx配置的方式进行拦截，这样的问题是Nginx配置写起来很麻烦，而且需要不断分析日志再修改配置进行拦截。

后来发现有ngx_lua_waf这个扩展，可以提供简单的WAF功能，觉得不错就学习了下。功能不错，可是还是觉得规则配置不够灵活方便。 再后来随着学习认识到WAF里比较复杂的规则，如果没有可视化编辑器的话，基本很难使用。后来就自己做了一个项目VeryNginx，吸取了其他项目的优点，提供了可视化的状态界面和灵活的WAF功能，算是把安全性的问题解决了，后来就在此基础上继续完善。这次想和大家交流Nginx和Lua结合在一起能做哪些有意思的东西。

温铭

我去年在推OR的社区，今年会更多关注在基金会和商业化的思考，想和大家聊一聊，看大家有什么想法。

院生

最佳实践的书是我写的，群里的问题要是@我了，我都会回复的。

周晶

12年刚入行第二年，当时还在凤凰网，一次同事聊天听说了 OpenResty，当时热衷于用各种压测工具压测代码性能，OpenResty 的表现震撼了我，从那时埋下了一颗种子，到新浪负责后端技术架构后，一次技术选型的机会使我有机会真正在生产环境上使用OpenResty，也重新更全面认识了 OpenResty，后一直致力于 OpenResty 的推广，学习OpenResty 的过程中有幸看到了 《OpenResty最佳实践》这本书，觉得温铭的历程和我在新浪的历程几乎一模一样，后来加入了社区组织，跟社区的很多朋友志同道合、相见恨晚，怎么在公司推广自己觉得很牛逼，但又不被人熟知和认可的技术，是一件很不容易的事情，不过这个过程却使人成长很多，不止是技术，希望社区有更多的同学聚到一起来做些更有意义的事情。

0X01

OR近期的一些TODO

1：HTTP2.0的全面支持（lua_resty_http20库，用来支持测试）

2：对AIO的支持， 从ngx.location.capture()开始，包含子请求的AIO修复，以及暴露新的LuaAIO API

3：分布式SSL Session缓存的开源与发布（涉及Openssl的补丁）

4：OPM的包管理工具链（需要一个OR的github Oath2的客户端实现）

5：二进制的Linux包仓库（只要服务器端尽量是静态的就好，类似Nginx官方的Linux仓库）

6：给OpenResty的代码仓库添加 TravisCI的支持

0X02

OR的一些新特性、新动作

1：RestyDoc工具会在下一个OR中发布(OpenResty 1.9.15.1)

2：创建、开启OR的小语言时代

4：LuaJIT官方非常配合OR的实际需求，成为OR的CLR(Common Language Runtime)

0X03

OpenResty的问题讨论与大家的分享

1. 瞬时密集访问与延时  

 方案： 熔断（负载均衡层随机抛弃用户） 

        流量分区--再分小区（地域/运营商）保住主要地区用户拒绝其他。

      服务降级（支付 收钱 转账 还款）保住主要服务放弃其他。

        算法计算用户使用习惯，否定一部分服务请求。

2. OR的未来使用场景或者网络安全   

3. IO密集型性能优化、经典使用OR场景

周为Say :   

       刚开始接触OR的时候了解的不多，后来发现OR做为一个基础设施能做很多东西。用OR做了VeryNginx，主要用在网络安全方面，是一个完全可以通过WEB界面进行配置的防火墙，工作在第七层，可以防CC攻击，限制请求频率，做动态反向代理等功能。目前我想用OR做一些复杂的东西会受到数据结构方面的一些限制，SharedDict可以跨Worker共享数据，可是它的数据结构有限，只能用Key-Value来存储字符串。而如果用Lua的Table来存储，那里面的内容又不能跨Worker共享，不知道有没有什么好的方法？

问题 2 :    OR可以用在哪些场景中呢

院生Answer:

      推荐看德江提的一个Patch，自测已经通过，还没有合进主线。他提供了一些新的数据结构，比如 hash、list 等。OR 可以用同步的方法写异步的代码,用来做WEB也挺好的。

周晶Answer:

         现在很多新的模块，像长链接、推送也可以使用，我们目前用来做的更多的不止是 API或者API网关，我们也在很多重要的Web项目中使用 OpenResty。

4. UpStream下Server的探活:一个OR + Lua灰度方案

郭州伟Say:

     公司线上有物流配送开放平台，为第三方商家提供物流配送服务。因为没有完善的链路流程测试工具，当在开发某环节的新功能时，即使单元测试通过，也不能确保整个链路运行是正常的。为此我们开发了一个灰度系统，当新的功能开发完毕后将其部署到某一个Group集群，然后将某固定用户的请求分流到此Gourp集群，其他用户的请求走原有功能的机器，对此固定用户进行完整的链路回归测试，如果链路测试通过就可以将新功能全量部署在所有机器上。实现方案借鉴了新浪的ABTestingGateway，可以建多个Policy,Runtime时生效其中一个Policy策略。

遇到的问题  :  

Upstream动态配置分流服务器，采用模块。此module有缺陷：Upstream分流配置是在内存中更改，当Nginx重启后配置信息就会丢失。

我们目前的处理方案是将Upstream分流配置实时同步到Redis和生成本地文件Upstream.conf。Nginx重启后加载本地Upstream.conf或从Redis拉取配置。

我们遇到的另外的问题是如何对Upstream后的Http-server进行探活？当某台机器挂掉后，要及时更改Upstream的配置把此Server下线。

经调研有个模块n可以实现，但在实际的测试过程中发现和e同时使用有坑：采用OpenResty1.9.71和Tengine2.1.1分别测试均不稳定。

周为Answer :  

    你们的Nginx本地配置和Redis有可能不同步。针对这个问题Nginx可以在收到第一个请求时去Redis取一下配置， 比较Redis中的配置版本和本地配置版本，判断是否需要更新，再有请求过来的时候判断距离上次检查配置更新的时间有没有超过1秒，如果超过1秒就检查下 Redis的配置，这样可以保证Redis中的配置更新后在1 秒内 能生效。

院生Answer :  

Upstream下server的动态修改还有一种方案，可以参考春哥的balancer_by_lua。

张昭Answer :  

对于Http-server探活的问题可以在每个Server上部署一个check_status接口，然后由一个Server请求所有Server的接口，当请求失败时说明那个Server-down了。此接口可以由应用Server提供服务也可以由Nginx-Server提供服务。由于此接口没有业务逻辑，可以放在Nginx层处理，不用透传到应用Server，少走些流程速度更快。

对于本地配置和redis不同步可以在每一台server上起一个定时任务，每隔1秒去请求Redis，将Redis中的增量配置同步到Nginx中。

李璐Answer :  

你的Upstream中写的是ip，我们用的是命名服务，内部会完成状态的更新，使用方直接使用即可，不用关心server的状态。

6. 如何才能让更多的同学加入OR的世界

李璐Share :  

一是可以通过固定圈子里的人带动周边的人，比如带动各种社区，让更多人听到OR的名字；二是最好有一个标志性的项目。我最开始听说Redis的时候是因为新浪微博的项目，现在一说到新浪微博我肯定会想到Redis；再一个是公司内部的分享，我们部门去年实际上已经在用OR做项目了，但是他们是闷声做的，谁也不知道。后来是因为部门逼着大家写WIKI，那哥们被逼得没有办法才写了OR，大家才知道OR，所以公司内部主动分享会提高OR的普及。

院生Share :

OR和Nginx最大的差异在于它的动态化，Lua的动态化可以直接调用Nginx，在这块不知道是否可以增加一些行为让他能够直接超越Nginx。

周晶Share :

我当初做OR的框架Vanilla就是为了让更多的人加入OR的世界。香草的框架目录结构和YAF一模一样，包括debug的方法都和PHP一样，目的就是为了让写PHP写的很爽的程序员能看到香草框架会很亲近。

张昭Share :

7.哪种meetup形式会更好，讲座式还是座谈式？

周晶Share :

座谈式的大家来一次就认识了，以后想做相关方面的可以方便的找到对应的人沟通交流。尤其OR这种相对小众的技术，找人不太好找。

周为Share :

座谈式更好些，每个人都能有机会说上话，有需要讲的可以多讲一些，没有要讲的可以听其他同学讲。

张昭Share :

今天的座谈比之前更深入一些，能了解到别的同学做的什么业务，可以从中借鉴一些有用的经验。纯讲座式面会更广一些，能普及到更多的同学，能争取到更多的同学加入到or社区。我建议可以两种方式结合起来，讲座分享和圆桌座谈交插着进行。

8.开源软件服务的商业化道路与商业化模式在国内氛围不好的环境下如何尝试成长值得大家思考，希望大家能够多提意见集思广益，为开源的商业化道路提供一定分享帮助。

欢迎微信扫描下面的二维码随时获取 OpenResty 社区最新动态。