接着上次说的话题，我们来看看Kong又是怎么和Nginx互动的，要揭开它们的神秘面纱之前，咱们还得先聊聊Nginx的架构模型。

Nginx采用的是Master-Worker模型，一个Master进程管理多个Worker进程，基本的事件处理都放在 Worker 中，Master负责部分全局初始化以及对Worker的管理。Master进程监控着 Worker进程的运行状态，当 Worker进程因异常情况退出后，会自动启动新的 Worker进程，请求方不会有任何感觉。

为了一窥全貌，这里引用下Nginx的架构图，如果你的嗅觉足够，肯定会发现一些有技术含量的东西，这图可是弥漫着众多高可用性的强大气息啊。

关于内部功能模块，Nginx主要有5大块，分别是核心模块、配置模块、事件模块、HTTP模块、Mail模块。配置模块和核心模块是其他模块的基础，事件模块则是HTTP模块和Mail模块的基础。

而HTTP模块处理几乎所有用户客户端发起的请求，请求通过Master进入Worker进程主循环后，系统会根据请求调用11个阶段的处理模块，其中有7个阶段可以调用第三方的处理模块，几乎包含了所有的解析阶段，这就是我们经常会说的业务可扩展的切入点，在不需要调整Nignx源码的情况下而实现功能插件的调用，只不过被Nginx调用的功能插件是需要基于C/C++语言编写的，但这已不是重点，重要的是为满足企业不同的业务需求而打开了潘多拉盒子。

窥探了Nginx架构模型后，我们再看看OpenResty又是什么？

简单的说是ngx_http_lua_module插件模块、Nginx、Luajit三者的整合，是Nginx的扩展，并提供了诸多公共组件供开发插件调用，安装OpenResty就不需要再安装Nginx了。当然！如果不想用OpenResty而直接用Nginx搭配ngx_http_lua_module和Luajit也是可以的，满足喜欢走不寻常路的技术大咖们，这有点像组装机和品牌机的区别，只要够专业，搭配随意，变腐朽为传奇往往也只是一念之间而已。

Kong启动意味着OpenResty启动，也就等同于Nginx的启动，Kong会把配置文件通过OpenResty最终传递给Nginx。在OpenResty中Nginx启动会自动装载ngx_http_lua_module插件模块，该模块扩展了Nginx可支持的几个阶段。

在来自外部请求触发后，Nginx会调用ngx_http_lua_module插件模块中相应的方法，而这些方法已经集成了Luajit库的解析接口，会由LuaVM来解析用lua语言编写的脚本模块，这就是整个Kong的业务模块与Nginx交互的基本处理过程。

到这里也已解决了不会C/C++语言却又想编写Nginx插件模块的问题，做运维的兄弟们可以洗洗睡了。

OpenResty的作用就像媒介或桥梁，解决了原本并不能连接的两个端点，既然是连接自然是双向的，在Luajit库中除了提供C/C++语言调用lua语言外，也提供了FFI接口从lua语言调用C/C++语言的通道。

简单吧，还能想到什么？

对了，咱们缺的就是一个解析器！如果够专业，可以自定义任何语言让Nginx来调用，只要拥有一个自己的解析器，外加一个供Nginx调用的插件模块，那么属于你的世界来了，KVM、JVM、LLVM、LuaVM……等诸多神器都在欢迎你的到来，当能力匹配上任性时，才算堪称！做开发的兄弟们也可以洗洗睡了。