典型应用场景

可以这样说,任何一个开发语言、开发框架,都有它存在的明确目的,重心是为了解决什么问题。没有说我们学习一门语言或技术,就可以解决所有的问题。同样的,OpenResty 的存在也有其自身适用的应用场景。

其实官网 wiki 已经列了出来:

  • 在 Lua 中混合处理不同 Nginx 模块输出(proxy, drizzle, postgres, Redis, memcached 等)。
  • 在请求真正到达上游服务之前,Lua 中处理复杂的准入控制和安全检查。
  • 比较随意的控制应答头(通过 Lua)。
  • 从外部存储中获取后端信息,并用这些信息来实时选择哪一个后端来完成业务访问。
  • 在内容 handler 中随意编写复杂的 web 应用,同步编写异步访问后端数据库和其他存储。
  • 在 rewrite 阶段,通过 Lua 完成非常复杂的处理。
  • 在 Nginx 子查询、location 调用中,通过 Lua 实现高级缓存机制。
  • 对外暴露强劲的 Lua 语言,允许使用各种 Nginx 模块,自由拼合没有任何限制。该模块的脚本有充分的灵活性,同时提供的性能水平与本地 C 语言程序无论是在 CPU 时间方面以及内存占用差距非常小。所有这些都要求 LuaJIT 2.x 是启用的。其他脚本语言实现通常很难满足这一性能水平。

不擅长的应用场景

前面的章节,我们是从它适合的场景出发,OpenResty 不适合的场景又有哪些?以及我们在使用中如何规避这些问题呢?

这里官网并没有给出答案,我根据我们的应用场景给大家列举,并简单描述一下原因:

  • 有长时间阻塞调用的过程
    • 例如通过 Lua 完成系统命令行调用
    • 使用阻塞的Lua API完成相应操作
  • 单个请求处理逻辑复杂,尤其是需要和请求方多次交互的长连接场景
    • Nginx的内存池 pool 是每次新申请内存存放数据
    • 所有的内存释放都是在请求退出的时候统一释放
    • 如果单个请求处理过于复杂,将会有过多内存无法及时释放
  • 内存占用高的处理
    • 受制于Lua VM的最大使用内存 2G 的限制
    • 这个限制是单个Lua VM,也就是单个Nginx worker
  • 两个请求之间有交流的场景
    • 例如你做个在线聊天,要完成两个用户之间信息的传递
    • 当前OpenResty还不具备这个通讯能力(后面可能会有所完善)
  • 与行业专用的组件对接
    • 最好是 TCP 协议对接,不要是 API 方式对接,防止里面有阻塞 TCP 处理
    • 由于OpenResty必须要使用非阻塞 API ,所以传统的阻塞 API ,我们是没法直接使用的
    • 获取 TCP 协议,使用 cosocket 重写(重写后的效率还是很赞的)
  • 每请求开启的 light thread 过多的场景
    • 虽然已经是light thread,但它对系统资源的占用相对是比较大的

这些适合、不适合信息可能在后面随着 OpenResty 的发展都会有新的变化,大家拭目以待。

results matching ""

    No results matching ""