nginx源码阅读(七).nginx的模块化设计

前言

高度模块化是nginx的一个特点,在正式进入到具体的模块之前,有必要从整体把握各模块之间联系与nginx对模块的控制。在前面的分析中其实已经使用了模块中提供的方法,比如worker进程的工作循环中调用的ngx_process_events_and_timers()函数,用于处理事件。

模块之间的联系

官方提供了5个类型的模块:核心模块、配置模块、事件模块、http模块、mail模块。

• 配置模块主要负责解析nginx.conf文件,是其他模块的基础,该类模块中只有一个ngx_conf_module模块;
• 核心模块主要负责定义除配置模块之外的其他模块,该类模块中有6个核心模块。
  
  1. ngx_mail_module负责定义mail模块;
  2. ngx_http_module负责定义http模块;
  3. ngx_events_module负责定义事件模块;
  4. ngx_core_module则是nginx启动加载的第一个模块,它主要用来保存全局配置项。
  5. ngx_openssl_module只有当加载了之后,nginx才支持https请求
  6. ngx_errlog_module
• 事件模块即负责事件的注册、分发处理、销毁等,该类模块中主要有这几个模块:
  
  1. ngx_event_core_module负责加载其他事件模块,是其他事件模块的基础
  2. ngx_epoll_module,该模块则是我们后面需要重点分析的模块,它负责事件的注册、集成、处理等
  3. 其他的模块比如ngx_kqueue_module这些我们后面基本不会涉及,就不解释了,毕竟是另外一种I/O多路复用机制,大致的思想是一样的
• http模块和mail模块也无需太多解释,等到后面再介绍。

从中我们可以看出,核心模块中的部分模块与其他模块有一定的联系,比如核心模块中的ngx_event_module模块,它就作为事件模块的基础,会帮事件模块解析配置项以及存储事件模块中各模块的存储配置项的结构体指针。

这样的设计可以让核心模块尽量的简单,只做一些初始化还有退出的工作,而其他的事情交给相应类型的模块去细做即可。

除了核心模块与其他模块的联系之外,其实各类型模块中的子模块也有联系,同样也以事件模块为例子,在不同的系平台上,I/O多路复用机制可能也不同,比如linux2.6之后的epoll、FreeBSD的kqueue等,那么选择一种合适的机制就成了一个很重要的问题,事件模块中的ngx_event_core_module就负责这个工作;又比如http模块中,ngx_http_core_module也负责决定对于不同的请求该选用哪一个http模块来处理。

统一的通用接口

为了将每个模块简单的统一起来,nginx定义了ngx_module_t结构体作为每个模块的通用接口,同时考虑到灵活性的问题,ngx_module_t里面只涉及到了模块的初始化还有退出等操作,并且其中的ctx成员是一个void *指针,它可以作为任意一种具体类型的模块中的通用性接口,比如在事件模块中,又可以自己再实现一个通用性接口用于事件模块的统一。

还记得ngx_modules数组吗,它的类型就是ngx_module_t,即存储了所有模块