初识OpenResty

发表于 | 更新于: | 分类于 | | 热度: ℃
  • openresty -s quit -p pwd -c conf/nginx.conf 关闭
  • openresty -p pwd -c conf/nginx.conf 开启
  • mockeagain 这个项目可以模拟慢速的网络，让程序每次只读写一个字节
  • openresty-systemtap-toolkit 和 stapxx 这两个 OpenResty 的项目，都基于 systemtap 这个动态调试和追踪工具。使用 systemtap 最大的优势，便是实现活体分析，同时对目标程序完全无侵入。
  • awesome-resty 这个项目，维护了几乎所有 OpenResty 可用的包。

  • Lua 中，我们使用两个点号来表示字符串的相加。

  • 若涉及到正则表达式的，请一定要使用 OpenResty 提供的 ngx.re. 来解决，不要用 Lua 的 string. 处理。

  • 在 OpenResty 编程中，我强烈建议你总是使用 local 来声明变量，即使在 require module 的时候也是一样。

  • 要在 OpenResty 中申请大块的内存，推荐用 ffi.C.malloc 而不是ffi.new。

  • 在 OpenResty 体系中，使用 Valgrind 来检测内存泄漏问题

  • LuaJIT 的运行时环境，除了一个汇编实现的 Lua 解释器外，还有一个可以直接生成机器代码的 JIT 编译器，LuaJIT 自带的 jit.dump 和 jit.v 模块。它们都可以打印出 JIT 编译器工作的过程。

  • Lua用元表metatable来进行模拟面向对象。

  • 为什么 lua-resty-mysql 库要模拟 OO 来做一层封装呢？

  • 所谓闭包 ，简单地理解，它其实是一个函数，不过它访问了另外一个函数词法作用域中的变量。

  • 在Lua中，下标不是从0开始的，但是在LuaJIT中，使用ffi.new创建的数组是从0开始的。

  • 在 OpenResty 中，我们总是优先使用 OpenResty 的 API，然后是 LuaJIT 的 API，使用Lua 库则需要慎之又慎。

  • 一般情况下，使用lua-resty-lrucache作为一级缓存（各种类型），shared dict作为二级缓存（只能存字符串）。

  • 如果 Lua 代码中没有 I/O 或者 sleep 操作，比如全是密集的加解密运算，那么 Lua 协程就会一直占用 LuaJIT VM，直到处理完整个请求。

  • 所有变量都声明为局部变量，并用 luacheck 和 lua-releng 这样的工具来检测全局变量

  • shared dict（共享字典，基于红黑树实现，性能很好，但是必须在配置文件中先行声明大小，并且不能动态更改）是基于 NGINX 共享内存区的 Lua 字典对象，它可以跨多个 worker 来存取数据，一般用来存放限流、限速、缓存等数据。可当成简单的redis，但是不能持久化，考虑到丢失的情况。不用自己加锁来进行同步，因为自身就是原子性的。

  • cosocket是 OpenResty 中的专有名词，是把协程和网络套接字的英文拼在一起形成的，即 cosocket = coroutine + socket。所以，你可以把 cosocket 翻译为“协程套接字”

  • openresty中的特权进程和master 进程的权限一样，如果 master 是普通用户，那特权进程也不可能拿到 root 权限。一般用特权进程来清理日志、重启 OpenResty 自身等需要高权限的任务。

  • 若使用的正则引擎是基于回溯的 NFA 来实现的，那么就有可能出现灾难性回溯
    （Catastrophic Backtracking），即正则在匹配的时候回溯过多，造成 CPU 100%，正常服务被阻塞。

  • 被动和主动安全防护模式：negative，黑名单，非黑即白；positive，身份认证，非白即黑

  • OpenResty 中，选择使用断言风格的测试框架 busted。busted结合 resty 这个命令行工具，也可以满足不少测试的需求。

  • 性能测试工具是 wrk：若遇到这种问题需注意（1） CPU 不能满载。这不会是 wrk 的问题，可能是网络的限制，更可能是你的代码中有阻塞的操作。你可以通过 review 代码来确定，也可以使用 off CPU 火焰图来确定。（2）CPU 一直满载，即使压测停止仍然如此。这说明在代码中存在热循环，可能是正则表达式引起的，也可能是 LuaJIT 的 bug 引起的，这两点都是我在真实的环境中遇到过的问题。这时，你就需要用 on CPU 火焰图来确定了。

  • 在压力测试中可以用专门的路由器搭建一个局域网，把 wrk 所在的机器和服务端所在的机器连在一起。之所以不推荐在已有的网络中直接测试，是因为大部分的网络中都存在交换机和防火墙，它们可能会对大流量的压测进行限制，造成测试结果的不准确。

  • 在 OpenResty 的编程中，对于可能出现阻塞的函数调用，要特别谨慎；否则，一行阻塞的代码，就会把整个服务的性能拖垮。

  • 在 OpenResty 中，也有两个可以帮你自动化检测代码风格的工具：luacheck 和 lj-releng。前者是 Lua 和 OpenResty 世界通用的检测工具，后者则是 OpenResty 自己用 perl 写的代码检测工具。

  • Mozilla RR可以把程序的行为录制下来，然后反复地重放。不管线上环境还是测试环境，只要你能够把 bug 的“罪证”录制下来，那就可以作为“呈堂证供”慢慢地分析了

  • Systemtap 的工作原理，是将 stap 脚本转换为 C，运行系统 C 编译器来创建 kernel 模块。当模块被加载的时候，它会通过 hook 内核的方式，来激活所有的探测事件。

  • 为什么基于 Nginx 的 OpenResty 却可以支持动态呢？Nginx 的逻辑是通过 C 模块来完成的，而 OpenResty 是通过脚本语言 Lua 来完成的——脚本语言的一大优势，便是运行时可以去做动态地改变。

  • API 网关既可以替代 Nginx 的所有功能，处理南北向的流量；也可以完成 Istio 控制面和 Envoy 数据面的角色，处理东西向的流量。

  • API网关数据库选型：需要存储的都是简单的配置信息，比如uri、插件参数、上游地址等，并没有涉及到复杂的联表操作，也不需要严格的事务保证。显然，这种情况下使用关系型数据库，可不就是“杀鸡焉用宰牛刀”吗？

-------------本文结束感谢您的阅读-------------