① openresty的发展
1) OpenResty 并'不像'其他的开发语言一样'从零开始'搭建
备注: 而是基于'成熟'的'开源'组件'NGINX' 和 'LuaJIT' --> 站在'巨人的肩膀上'
2) OpenResty 诞生于 '2007' 年,不过它的'第一个版本'并没有选择 Lua,而是用了 'perl'
备注: 这跟作者'章亦春的技术'偏好有很大关系,也可能被'当时技术潮流有关'
3) 但 Perl 的'性能'远远不能达到要求,于是在第'二'个版本中,Perl 就被 Lua 给'替换'了
说明: 能在构建游戏的'c++'中使用'lua',足以说明'性能'了
备注: 在 当前OpenResty 官方的项目中,Perl 依然占据着'重要'的角色
[1]、OpenResty 工程化方面都是用 'Perl 来构建'
[2]、比如:测试框架 'nginx::test'、Linter、CLI 'opm'
4) 后来'章亦春'离开了'淘宝',加入了美国的 CDN 公司 Cloudflare
[1]、因为 OpenResty '高性能'和'动态'的优势很适合 'CDN' 的业务需求
[2]、很快, OpenResty 就成为 CDN 的'技术标准' --> 关注js、lua在'CDN'应用场景
5) 通过'丰富的lua-resty' 库,OpenResty 开始逐渐'摆脱'NGINX 的影子,形成自己的'生态'体系
[1]、比较'成功'的应用场景:在 'API 网关'、'软 WAF' 等领域被广泛使用
6) 其实,我们经常说 'OpenResty' 是一个被广泛使用的技术,但它并'不能算'得上是'热门'技术
备注:这听上去有点'矛盾',到底什么意思呢?
[1]、说它'应用广',是因为 OpenResty 现在是全球排名第'4'的 'Web' 服务器
排名顺序: 'Apache'、'nginx'、'Cloudflare'、'Openretsy' --> "2023/4"市场份额
[2]、我们经常用到的 '12306' 的余票查询功能或者是'京东'的商品详情页
备注:这些'高流量'的背后,其实都是 OpenResty 在默默地提供服务
[3]、说它并'不热门',那是因为使用 OpenResty 来'构建业务系统'的'比例'并不高
备注:使用者大都用 OpenResty 来'处理入口流量',并'没有深入'到'业务'里面去
自然: 对于 OpenResty 的使用也是'浅尝辄止',满足'当前的需求'就可以了
[4]、这当然也与 OpenResty '没有'像 Java、Python 那样有成熟的 'Web 框架和生态'有关
lua和luajit对比 程序开发中的linter是什么意思 LuaJIT分支和标准Lua有什么不同?
++++++++++++ 'Openresty三大特性' ++++++++++++
1) 详尽的'文档'和'测试用例'
2) 同步非阻塞 --> 指的是'lua api'
[1]、怎么理解?
[2]、nginx的'异步非阻塞'框架怎么理解?
3) 动态 --> '不用reload'
② 详尽的文档和测试用例
1) 文档和测试是'判断开源项目'是否靠谱的'关键'指标,甚至是排在'代码质量和性能'之前的
2) OpenResty 的'文档'非常详细,作者把每一个'需要注意的点'都写在了文档中
3) 绝大部分时候,我们只需要'仔细查看文档'就能解决遇到的问题,而'不用'谷歌搜索或者是跟踪到源码中
4) 为了方便起见,OpenResty 还自带了一个'命令行工具restydoc'
特点: 专门用来帮助我们'通过 shell' 查看文档,避免编码过程'被打断'
5) 不过'restydoc'文档中只会有'一两个通用'的代码片段,并'没有'完整和复杂的示例
6) 到哪里可以'找到'这样的例子呢?
[1]、对于 OpenResty 来说,自然是'/t目录',它里面就是所有的测试案例
举例:https://github.com/openresty/lua-nginx-module
需要看这个'子项目'的仓库,也即'每个相关的模块的仓库'
[2]、每一个测试案例都包含'完'整的 NGINX 配置和 Lua 代码,以及测试的输入数据和预期的输出数据
7) 不过OpenResty 使用的'测试框架',与其他'断言风格'的测试框架完全不同,后面会用'专门'介绍
③ 同步非阻塞
1) 协程'coroutines'是很多'脚本语言'为了提升'性能',在近几年'新增'的特性
备注: 常见提供'原生协程'支持的语言有:c++20、golang、python、rust、lua 等
备注: 但它们实现得'并不完美',有些是'语法糖',有些还需要显式的关键字声明
2) OpenResty 则'没有'历史包袱,在'诞生之初'就支持了协程,并基于此实现了'同步非阻塞'的编程模式
[1]、这一点是很'重要'的,毕竟程序员也是人,代码应该更符合人的'思维'习惯
[2]、显式的'回调'和'异步关键字'会打断思路,也给调试带来了'困难'
3) 什么是'同步非阻塞'? --> '同步理解'
[1]、同步按照代码来'顺序'执行
比如: 下面这'段伪码':
local res, err = query-mysql(sql)
local value, err = query-redis(key)
1) 在同一请求连接中,如果要等 MySQL 的查询'结果返回后',才能继续去查询 Redis,那就是同步
2) 如果'不用等' MySQL 的返回,就能继续往下走,去查询 Redis,那就是'异步'
[2]、对于 OpenResty 来说,绝大部分都是'同步'操作
备注:只有 ngx.timer 这种'后台定时器'相关的 API,才是'异步'操作
4) 什么是'同步非阻塞'? --> '非阻塞理解'
[1]、非阻塞是一个很容易和"异步"混淆的概念
[2]、这里我们说的'阻塞',特指阻塞'操作系统线程'
[3]、我们继续看上面的'例子':
1) 假设查询 MySQL 需要 1s 的时间
2) 如果在这 1s 内,操作系统的资源 'CPU' 是'空闲'着并'傻傻地等待'返回,那就是'阻塞'
3) 如果 CPU '趁机'去处理'其他连接'的请求,那就是'非阻塞'
[4]、非阻塞也是 'C10K、C100K' 这些'高并发'能够实现的关键
5) 同步非阻塞这个概念'很重要'
[1]、这一概念最好'不要通过类比'来理解,因为'不恰当'的类比,很可能把自己搞得'更糊涂'
[2]、在 OpenResty 中'上面的伪码'就可以直接实现'同步非阻塞',而不用任何显式的关键字
[3]、这里也再次体现了,让开发者'用起来更简单',是 OpenResty 的'理念'之一
同步、异步、阻塞、非阻塞 烧水案例 nginx框架的异步非阻塞高性能 openresty 同步非阻塞
④ 动态
1) OpenResty 有一个非常大的'优势',并且还'没有'被充分挖掘,就是它的'dynamic 动态'
2) 传统的 Web 服务器
[1]、比如 nginx, 如果'发生任何配置的变动',都需要你去'修改磁盘上'的配置文件
[2]、然后'重新reload加载'才能生效,这也是因为它们'并没有提供 API'来'控制'运行时的行为
[3]、所以在需要'频繁变动'的'微服务领域',NGINX 虽然有多次尝试,但'毫无建树'
3) OpenResty 是由'脚本语言 Lua '来控制'逻辑'的,而动态,便是 Lua '天生'的优势
[1]、通过 OpenResty 中 lua-nginx-module 模块中提供的 'Lua API'
[2]、我们可以'动态'地控制'路由'、'上游'、'SSL 证书'、'请求'、'响应'等
[3]、甚至'更进'一步,你可以在'不reload' OpenResty 的前提下,修改'业务'的处理逻辑
[4]、并'不局限'于 OpenResty 提供的 Lua API
[5]、OpenResty 的能力圈和想象力就'扩展'到了其他领域,比如 'Serverless 和边缘计算'等
4) 遗留: nginx ingress 如何实现'动态'的?
⑤ 学习重点
1) OpenResty 有'这么多'的重点特性,该'如何'学习?
2) 学习需要'抓重点',围绕'主线'来展开,而'不是'眉毛胡子一把抓,要构建出自己'脉络清晰'的知识体系
3) 不管多么'全面的课程',都'不可能覆盖'所有问题,更不能直接帮你解决'线上'的每个 'bug 和异常'
4) 想要学好 OpenResty,必须你理解下面 '8' 个重点:
[1]、'同步非阻塞'的编程模式;
[2]、不同'阶段'的作用;
[3]、LuaJIT 和 Lua 的'不同'之处; --> '提升性能'
[4]、OpenResty API 和'周边库'; --> '尤其是中间件'
[5]、协程 和 cosocket; --> '进阶'
[6]、单元测试框架和性能测试工具; --> '性能测试'
[7]、火焰图和周边工具链 --> '性能和排错'
[8]、性能优化 --> OpenResty 的'测试框架和性能分析'工具集
5) 学习预期达到的'目的':
[1]、能'举一反三'
[2]、根据自己的'兴趣点和专业背景',有针对性地'深入阅读'某些章节
[3]、的重点在于构建 OpenResty 的全貌,而'非死磕某个知识点'
6) 想要给 OpenResty 以及周边库'贡献'代码,那么'最大的门槛'
[1]、并不是对 OpenResty 原理的'理解'
[2]、也不是如何编写 'NGINX C 模块'的问题
[3]、而是'测试案例'和'代码'规范
⑥ 答疑解惑
PR: 'Rull Request'