Nginx基础教程（107）Nginx与设计模式之代码级别的模式：Nginx代码的“精装修”：扒一扒那些让服务器飞起来的设计模式

在一行行简洁的C语言代码背后，Nginx像一位深藏不露的武林高手，用八种隐秘的设计模式招式，轻松应对着每秒数万并发请求的挑战。

01 Nginx与设计模式的不解之缘

设计模式是软件开发中常见问题的经典解决方案。它代表了一种高层次的抽象思维，是一套从实践中提炼出的方法论。当这种思维遇上追求极致性能的Nginx，就产生了奇妙的化学反应。

有些人可能认为，设计模式只适用于Java、C++这类面向对象语言。但Nginx这个纯C语言写就的高性能Web服务器，打破了这种偏见。

它以结构体、函数指针和宏等C语言特性，巧妙地实现了多种经典设计模式。

从更高层面看，Nginx的开发团队深谙软件设计的精髓：封装变化点。面对不同操作系统的网络IO差异，他们用设计模式思维找到了优雅的解决方案。这种设计思想渗透到了Nginx的每个角落。

02 工厂模式：模块配置的标准化生产流水线

当你修改Nginx配置文件时，是否好奇这些配置是如何被解析并转化为内存中的数据结构？这就是工厂模式在起作用。

工厂模式的核心思想是标准化生产过程。在Nginx中，每个模块的配置数据结构并不直接创建，而是通过工厂函数来生成。

看看这段来自Nginx源码的抽象逻辑：

// 每个模块都会定义自己的“创建配置”函数
static void *create_loc_conf(ngx_conf_t *cf) {
    ngx_http_example_loc_conf_t *conf;
    
    conf = ngx_pcalloc(cf->pool, sizeof(ngx_http_example_loc_conf_t));
    if (conf == NULL) {
        return NULL;
    }
    
    // 初始化默认值
    conf->enabled = 1;
    conf->max_size = 1024;
    
    return conf;
}
 
// 模块定义中注册这个工厂函数
ngx_http_module_t example_module_ctx = {
    NULL,                         /* preconfiguration */
    NULL,                         /* postconfiguration */
    create_loc_conf,              /* create location configuration */
    NULL                          /* merge location configuration */
};

每一个Nginx模块都可以实现自己的工厂函数，创建出模块专属的配置数据结构。这种设计使得配置管理的复杂性被封装，配置的创建过程对框架透明。

对于Nginx使用者来说，工厂模式的身影也随处可见。当你这样配置虚拟主机时：

server {
    listen 80;
    server_name example.com;
    
    # 每个location块背后，都对应着一系列配置对象的“生产”
    location /api {
        proxy_pass http://backend;
        # 这些指令会触发对应模块的工厂函数，创建配置对象
        proxy_set_header Host $host;
        proxy_connect_timeout 30s;
    }
    
    location /static {
        root /var/www;
        # 静态资源相关的配置对象也被“工厂化”创建
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

Nginx解析配置文件时，会自动调用对应模块的工厂函数，创建并初始化配置结构。这使得配置管理变得模块化和可预测。

03 组合模式：请求树的构建艺术

处理一个HTTP请求时，Nginx可能会生成一系列子请求。这些请求如何组织？组合模式给出了答案。

在Nginx的请求结构体中， ngx_http_request_t 使用 main、 parent 等指针将请求组织成一棵请求树。

// 简化的请求结构关系
typedef struct ngx_http_request_s {
    // 指向主请求的指针（如果是主请求，则指向自己）
    struct ngx_http_request_s *main;
    
    // 指向父请求的指针（如果是主请求，则为NULL）
    struct ngx_http_request_s *parent;
    
    // 其他请求数据...
    ngx_uint_t count;          // 引用计数
    unsigned subrequests:8;    // 子请求计数器
    
} ngx_http_request_t;

这种设计最精妙之处在于：从外部来看，主请求和子请求没有任何区别，可以一致处理。这就是组合模式的核心思想——以一致的方式处理整体和部分。

组合模式在实际配置中大显身手，特别是在需要内容拼接的场景：

location /dashboard {
    # 主请求处理整体框架
    echo "Dashboard Header";
    
    # 发起子请求获取用户信息 - 这是第一层组合
    echo_subrequest GET /api/user-info;
    
    # 发起子请求获取通知 - 第二层组合
    echo_subrequest GET /api/notifications;
    
    # 甚至可以嵌套：子请求再发起子请求
    # /api/user-info 内部可以再请求 /api/preferences
    
    echo "Dashboard Footer";
}

这种请求树的结构，使得Nginx能够优雅地处理复杂的页面组装逻辑，同时保持代码的清晰和可维护性。

04 观察者模式：请求间的智能通知系统

在组合模式构建的请求树中，各个请求如何通信？观察者模式提供了解决方案。

当一个子请求完成时，它需要通知父请求继续执行。Nginx通过设置父请求的回调函数来实现这一机制。

// 子请求完成时，在ngx_http_finalize_request函数中
if (r->parent) {
    // 通知父请求：子请求已完成
    ngx_http_post_request(r->parent, NULL);
}

这种设计实现了异步处理中的状态同步。父请求不需要不断轮询子请求的状态，而是注册一个回调，等待通知。这大大提高了系统的效率。

在实际的Nginx配置中，这种观察者模式的思维体现为请求处理的流水线化：

http {
    # 定义上游服务器组
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }
    
    server {
        location /api {
            # 主请求发起对后端服务的“观察”
            proxy_pass http://backend;
            
            # 这些头信息是“通知”的一部分
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            
            # 超时设置：如果后端不“通知”，主请求也不会无限等待
            proxy_read_timeout 30s;
        }
    }
}

后端服务器的响应就像是发给Nginx的“通知”，触发后续的处理流程。这种事件驱动的设计正是Nginx高性能的秘诀之一。

05 原型模式：快速克隆的请求副本

当Nginx需要创建子请求时，一个高效的方法是克隆父请求的大部分字段，而不是从头创建。这就是原型模式的应用。

Nginx创建子请求时，它从父请求里拷贝了大部分字段，创建了一个基本相同的请求对象。这种方法既节省了初始化时间，又确保了子请求与父请求在上下文上的一致性。

// 创建子请求的简化逻辑
ngx_http_request_t *subrequest;
subrequest = ngx_palloc(r->pool, sizeof(ngx_http_request_t));
 
// 复制父请求的字段
subrequest->connection = r->connection;
subrequest->pool = r->pool;
subrequest->headers_in = r->headers_in;
// ... 复制更多字段
 
// 调整必要的差异
subrequest->main = r->main;
subrequest->parent = r;

原型模式的思想在Nginx配置中体现为配置继承机制：

# 基础配置原型
server {
    listen 80;
    root /var/www/default;
    
    # 所有location共享的基础设置
    client_max_body_size 10m;
    keepalive_timeout 65;
    
    location / {
        index index.html;
    }
}
 
# 基于“原型”的特化配置
server {
    listen 80;
    server_name app1.example.com;
    
    # 继承并覆盖原型配置
    root /var/www/app1;  # 覆盖root设置
    
    # 继承了client_max_body_size和keepalive_timeout
    
    location /api {
        # 进一步特化：添加代理设置
        proxy_pass http://backend_app1;
    }
}

这种原型-特化的配置方式，大大减少了重复配置，提高了配置的可维护性。

06 访问者模式：安全的变量访问接口

Nginx的变量系统是它强大功能的重要组成部分，而这背后是访问者模式的应用。

访问者模式的核心是解耦数据结构与数据操作。在Nginx中，外界不能直接操作模块内部数据，只能通过变量提供的 get/set函数来间接访问。

// 变量访问接口的定义
typedef struct {
    ngx_str_t name;  // 变量名
    
    // 访问者函数：获取变量值
    ngx_http_variable_value_t *(*get_handler)(ngx_http_request_t *r,
        ngx_http_variable_value_t *v, uintptr_t data);
        
    // 设置函数（可选）
    void (*set_handler)(ngx_http_request_t *r,
        ngx_http_variable_value_t *v, uintptr_t data);
        
    uintptr_t data;  // 传递给处理函数的额外数据
} ngx_http_variable_t;

这种设计使得模块可以自由改变内部实现，而对外提供的变量接口保持不变。同时，新变量的添加也变得非常简单。

在Nginx配置中，变量系统提供了极大的灵活性：

# 使用内置变量
server {
    location /log {
        # $remote_addr是访问者模式的体现
        # 我们不知道它的内部实现，但可以通过统一接口访问
        return 200 "Your IP: $remote_addr
Time: $time_local
";
    }
    
    location /custom {
        # 自定义变量
        set $my_var "hello";
        set $backend "http://127.0.0.1:8080";
        
        # 变量可以组合使用
        proxy_set_header X-My-Var $my_var;
        proxy_pass $backend;
    }
}
 
# 变量作为访问者，可以“访问”请求的各种信息
map $http_user_agent $is_mobile {
    default 0;
    "~*mobile" 1;
}
 
server {
    location / {
        # 基于变量值做出决策
        if ($is_mobile) {
            root /var/www/mobile;
        }
        
        if ($scheme = "http") {
            # 访问协议信息
            return 301 https://$host$request_uri;
        }
    }
}

变量系统就像一个个标准化访问接口，让配置能够安全、一致地访问Nginx内部的各种状态和信息。

07 适配器模式：跨平台的统一接口

Nginx作为一个跨平台软件，必须处理不同操作系统的差异。适配器模式在这里发挥了关键作用。

Nginx的 event模块使用适配器模式，将 epoll、 kqueue、 select等不同的异步I/O接口统一适配为 ngx_event_actions_t结构体。这意味着，Nginx的核心代码只需要与统一的接口交互，而不需要关心底层是哪种I/O机制。

// 统一的事件操作接口
typedef struct {
    ngx_int_t  (*add)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
    ngx_int_t  (*del)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
    
    ngx_int_t  (*enable)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
    ngx_int_t  (*disable)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
    
    ngx_int_t  (*process_events)(ngx_cycle_t *cycle, ngx_msec_t timer,
                                 ngx_uint_t flags);
    
    // 其他操作...
} ngx_event_actions_t;
 
// 不同的平台提供不同的实现
#ifdef (NGX_HAVE_EPOLL)
    // Linux的epoll实现
    ngx_event_actions_t   ngx_event_actions = {
        ngx_epoll_add_event,      /* add */
        ngx_epoll_del_event,      /* del */
        // ... 其他函数
    };
#elif (NGX_HAVE_KQUEUE)
    // FreeBSD的kqueue实现
    ngx_event_actions_t   ngx_event_actions = {
        ngx_kqueue_add_event,     /* add */
        ngx_kqueue_del_event,     /* del */
        // ... 其他函数
    };
#endif

这种适配器设计在Nginx配置层面也有体现，特别是在处理不同协议或数据格式时：

# 适配不同的客户端协议
server {
    listen 80;
    
    # HTTP/1.1 客户端
    location /legacy {
        # 保持传统协议支持
        chunked_transfer_encoding on;
    }
    
    # HTTP/2 客户端
    listen 443 ssl http2;
    
    location /modern {
        # 新的协议，同样的配置接口
        gzip on;
        gzip_types text/plain application/json;
    }
}
 
# 适配不同的后端服务
upstream backends {
    server unix:/tmp/php-fpm.sock;  # PHP-FPM over Unix socket
    server 127.0.0.1:3000;          # Node.js over TCP
    server 127.0.0.1:8080 backup;   # Java app as backup
}
 
server {
    location ~ .php$ {
        # 通过FastCGI协议适配PHP-FPM
        fastcgi_pass unix:/tmp/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
    
    location /api {
        # 通过HTTP协议适配Node.js/Java后端
        proxy_pass http://backend;
        proxy_set_header Host $host;
    }
}

适配器模式让Nginx能够以统一的方式处理多样性，无论是底层系统API的差异，还是上层协议的不同。

08 装饰模式与代理模式：功能增强的两种策略

装饰模式和代理模式都是通过包装对象来增强功能，但目的不同。在Nginx中，这两种模式都有典型的应用。

装饰模式“装饰”原有对象，添加新功能。Nginx的 ngx_peer_connection_t结构体就是一个例子，它“装饰”了连接对象 ngx_connection_t，添加了后端服务器的地址、连接时间等信息。

而代理模式则控制对原始对象的访问。 ngx_str_t 和 ngx_buf_t 代理了一块内存空间， ngx_str_t是只读字符串代理，而 ngx_buf_t允许对数据块做更多操作。

这两种模式在Nginx配置中广泛应用：

# 装饰模式示例：逐步添加功能
server {
    listen 80;
    
    # 基础功能：静态文件服务
    location /static {
        root /var/www;
        
        # 装饰1：添加缓存控制
        expires 1y;
        add_header Cache-Control "public, immutable";
        
        # 装饰2：添加安全头
        add_header X-Content-Type-Options "nosniff";
        add_header X-Frame-Options "SAMEORIGIN";
    }
    
    # 装饰3：对特定路径添加额外功能
    location ~* .(js|css)$ {
        # 继承父location的配置，并添加gzip压缩
        gzip on;
        gzip_types text/css application/javascript;
        
        # 进一步装饰：添加版本查询参数支持
        location ~* .(js|css)$ {
            # 代理模式：控制对原始文件的访问
            try_files $uri $uri/ @rewrite;
        }
    }
    
    location @rewrite {
        # 代理模式：重写请求后再访问资源
        rewrite ^/(.*).(js|css)$ /$1.$2?v=$timestamp break;
    }
}
 
# 代理模式的典型应用：反向代理
server {
    listen 80;
    server_name gateway.example.com;
    
    location /service1 {
        # 代理模式：控制对后端服务的访问
        proxy_pass http://backend_service1;
        
        # 装饰功能：添加超时控制
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
        
        # 装饰功能：添加缓冲
        proxy_buffering on;
        proxy_buffer_size 4k;
        proxy_buffers 8 4k;
    }
    
    location /service2 {
        # 不同的代理策略
        proxy_pass http://backend_service2;
        
        # 装饰：添加重试机制
        proxy_next_upstream error timeout;
        proxy_next_upstream_tries 3;
    }
}

装饰和代理模式让Nginx能够灵活组合功能，为不同的场景提供恰到好处的解决方案。

Nginx的代码世界就像一座精心设计的建筑，设计模式是支撑它的钢筋结构。从工厂模式的生产流水线到观察者模式的智能通知系统，这八种模式共同构筑了Nginx高性能、高可用的基石。

真正的艺术在于，这些模式不是孤立存在的。在创建子请求时，Nginx同时使用了原型模式（克隆请求）和组合模式（构建请求树）。当子请求完成时，观察者模式又确保了父请求能被及时通知。

当你下次配置Nginx时，不妨思考一下：是使用装饰模式逐步增强功能，还是用代理模式控制访问？是在变量系统中应用访问者模式，还是在跨平台适配中应用适配器模式？

设计模式不是教条，而是一种思维工具。Nginx的C语言实现证明了这一点，优秀的软件设计超越了编程语言的限制。