HarmonyOS 鸿蒙Next nginx基础模块解读

HarmonyOS 鸿蒙Next nginx基础模块解读 nginx映像有2个最基础的模块：Location和Rewrite。

这两个模块可以说是平时开发过程中用到的最多的两个模块了，主要通过一些案例来说说这两个模块是如何工作的，本文主要聚焦这两个模块，可能会在文中对其它模块也会有所提及。

Location模块

Location这个模块主要是用来进行路径匹配的，在将nginx作为7层负载均衡使用时使用的最多，其语法满足如下模式。

location [@match-rule](/user/match-rule) /URI {}

@match-rule包括这么几种：

• 空表示前綴匹配
• =表示精准匹配且成功立刻停止
• ^~和空是一样的效果但匹配后会立即处理不再继续匹配
• ~表示区分大小写的正则匹配
• ~*表示正则不区分大小写匹配
• @表示一个命名location可以用在error_page和try_files中

它们的用法很简单，像下面这样，其中~就是匹配规则中的一种，这个配置会针对css、images等资源的请求先在本地匹配文件和目录，若没有匹配，则通过一个命名location来将请求代理到上游服务端https://server-name:8080。

location ~ ^/(css|images|home) {
    try_files $uri $uri/ @server-side-render;
}
location @server-side-render {
    proxy_pass https://server-name:8080;
}

不同的匹配命令@match-rule会有不同的优先级。

匹配时不是完全按先后顺序来匹配的，还有下面的一些优先级规则。

它们的优先级规则是这样的，首先精准匹配(=)，匹配成功立刻处理且停止匹配，如果没有精准匹配到，那么会进行前缀匹配(^~或空)，^~匹配成功也会立刻处理且停止匹配，而空会先暂存结果并继续去做匹配，包括正则匹配。

在前面精确匹配和前缀匹配都没有匹配项时，会进行正则匹配，区分大小写比不区分大小写的匹配规则优先级高，匹配到立刻处理且不再匹配，如果还没匹配到，那就匹配空暂存的结果。

下面两个案例可以帮助我们理解。

案例1

server {
    listen 80;
    server_name lanyage.com;
    location /hello {
        return 200 "hello!";
    }
    location ~ ^/helloworld$ {
        return 200 "hello world!";
    }
}

$curl -I http://lanyage.com/helloworld
# HTTP/1.1 200 "hello world!"

上面这个案例1中，由于前缀匹配/hello成功匹配后内容会暂存，但仍然会继续匹配，匹配到正则匹配后立即处理不再匹配，所以最终将会返回正则匹配的内容。

案例2

server {
    listen 80;
    server_name lanyage.com;
    location ^~ /hello {
        return 200 "hello";
    }
    location ~ ^/helloworld$ {
        return 200 "hello world!";
    }
}

$curl -I http://lanyage.com/helloworld
# HTTP/1.1 200 "hello!"

而案例2中由于在前缀匹配/hello已经成功匹配，^~会立即处理并停止向下匹配，/helloworld的正则匹配策略将不再匹配。

案例3

server {
    listen 80;
    server_name lanyage.com;
    location /hello {
        return 200 "hello";
    }
    location /helloworld {
        return 200 "hello world!";
    }
}

$curl -I http://lanyage.com/helloworld
# HTTP/1.1 200 "helloworld!"

在案例3中，两个匹配规则都采用前缀匹配，那么会匹配更长的那条。

案例4

server {
    listen 80;
    server_name lanyage.com;
    location ~ ^/hello[a-z]+ {
        return 200 "hello";
    }
    location ~ ^/helloworld[a-z]+ {
        return 200 "hello world!";
    }
}

$curl -I http://lanyage.com/helloworld
# HTTP/1.1 200 "hello!"

若在多个正则匹配中，会返回提前匹配的那个，也就是在前面配置的匹配规则。

在使用Location时，个人经验有下面几个。

1. 尽量不要使用if语句，因为这个语法经常会造成一些意向不到的效果很难排查，使用try_files来匹配文件或目录。

location /static/ {
    root /root/static/;
    try_files $uri $uri/;
}

1. 如要匹配根路径，使用精准匹配，这样会起到加速效果。

location = / {...}

1. 静态资源服务器是nginx的强项，匹配静态文件目录，建议使用前缀匹配或正则匹配或两者混合。

location ^~ /static/ {
    root /root/static/;
    try_files $uri $uri/;
}
location ~ \.(png|css)$ {
    try_files $uri ;
}

Rewrite模块

下面就来说说Rewrite这个基础模块，这个模块用于修改匹配的URI，从而达到美化URL或重定向等目的，通常和Location模块一同使用。

它的使用满足下面这种模式。

rewrite [@regex](/user/regex) [@replacement](/user/replacement) [@flag](/user/flag);

其中，@regex部分是用来匹配URI，@replacement是替换的部分，而@flag表示的是重定向策略。

除了rewrite这个关键字，还有return关键字也是属于该模块的部分，比如。

return 200 "ok";

表示响应HTTP/1.1 200 “ok”。

下面来看看@flag,它包括下面几个值：last表示停止后续的rewrite但仍然会再进行一次location匹配；break则是直接停止重定向;redirect表示302临时重定向;permanent表示301永久重定向。

当@flag没有指定时，rewrite语句会顺序执行。

有一点要注意的是，当rewrite的替换部分是http或https或$schema开始时，这个重定向会直接返回给客户端而不会继续发起内部重定向。

案例1

location ^~ /redirect {
    rewrite ^/redirect/(.*)$ https://www.$1.com;
    return 200 "ok";
}

$curl -I http://lanyage.com/redirect/jd
# 会将用户重定向到https://www.jd.com，而后面的return则不会再执行。

案例2

location ^~ /redirect {
    rewrite ^/redirect/(.*)$ www.$1.com;
    return 200 "ok";
}

$curl -I http://lanyage.com/redirect/jd
# "ok"

这个案例中，由于会顺序执行rewrite和return指令，因此最终响应给用户的内容是"ok"。

案例3

upstream upstream-servers{
    ...
}

location ^~ /users/1 {
    return 200 "hello" break;
    return 200 "world";
    proxy_pass http:upstream-servers;
}

$curl -I http://lanyage.com/users/1
# 会将请求代理到upstream-servers等上游服务上

上面的案例中，第2个return将不会执行，整个请求会直接被代理到上游, 因为break只会终止rewrite模块，而不会影响proxy_pass这样的rewrite模块之外的指令。

总结

基于这两个基础模块，配合其它一些可选配的模块，你将有能力搭建非常灵活的代理层，比如你可以使用gzip来开启响应压缩，使用tcp_nodelay开启Nagle算法防止大量小包导致的网络拥塞，使用sendfile来开启linux的零拷贝功能，等等，nginx还有支持集成lua模块，这样可以进一步提升nginx的灵活性, 当然这些内容不再本文聚焦的范围内，可以选择性涉猎。