openrestyphp路由技巧_决定努力学NginxOpenResty详解location路由规则设备详解了

实战案例解释

本节的配置实例处于源码工程的nginx-location-demo.conf配置文件中。
在运行本节的实例前，须要修正openresty-start.bat（或openresty-start.sh）脚本中的PROJECT_CONF配置文件变量的值，将其修正为nginx-location-demo.conf，然后重启OpenRestry/Nginx。

location语法详解

Nginx配置文件中，location配置项的语法格式如下：

location [=|~|~|^~] 模式字符串 { ...}

按照匹配的符号不同，location路由匹配紧张分成精准匹配、普通匹配、正则匹配、默认根路径匹配。
下面逐一进行先容。

1.精准匹配

精准匹配的符号标记为“=”，下面是一个大略的精准匹配location的例子。

#精准匹配 location = /lua { echo "hit location: =/Lua";}

如果要求URI和精准匹配的模式字符串/lua完备相同，那么精准匹配通过。

在所有的匹配类型中，精准匹配的优先级最高。

运行本文的配套案例，在同时存在多个/lua匹配模式location的情形下，在浏览器中给Nginx发送http://localhost/lua的要求地址，输出的是精准匹配的结果，如图7-12所示。

图7-12 输出精准匹配

2.普通匹配

普通匹配的符号标记为“^~”，下面是一个大略的普通匹配location的例子。

location ^~ /lua { echo "hit location: ^~ /lua"; }

普通匹配属于字符串前缀匹配，详细来说：如果要求路径URI头部匹配到location的模式字符串，那么匹配成功。
如果匹配到多个前缀，那么最长模式匹配优先。

本文配套实例中配置了以下两个普通匹配类型的location，详细配置如下：

#普通匹配一location ^~ /lua { echo "普通匹配: ^~ /lua";}#普通匹配二，长一点location ^~ /lua/long { echo "普通匹配: ^~ /lua/long";}

在浏览器中给Nginx发送http://localhost/lua/long/path的要求地址，输出了普通匹配location的结果，如图7-13所示。

图7-13 输出普通匹配

把稳

普通匹配是前缀匹配，也是Nginx默认的匹配类型。
也便是说，类型符号“^~”可以省略，如果location没有任何匹配类型，就为普通的前缀匹配。
如果一个URI命中多个location普通匹配，则最长的location普通匹配得胜。

为了对以上结论进行论证，这里举一个例子，在配置文件中配置两个同样字符串模式的location，一个不带类型符号，一个带“^~”符号，详细如下：

#不带类型符号，默认为普通匹配location /demo { echo "hit location: /demo ";}#带“^~”符号，普通匹配location ^~ /demo { echo "hit location: ^~ /demo";}

实行重启Nginx的脚本openresty-restart.bat，创造Nginx不能启动，查看error.log缺点日志，报错信息如下：

... 17:33:39 [emerg] 18760#25944: duplicate location "/demo" in .../nginx-location-demo.conf:115

从缺点信息可以看出，在配置文件中有两个重复的location配置。

3.正则匹配

正则匹配的类型按照类型符号的不同可以细分为以下4种：

（1）~：标准正则匹配，区分字母大小写，进行正则表达式测试，若测试成功，则匹配成功。

（2）~：标准正则匹配，不区分字母大小写，进行正则表达式测试，若测试成功，则匹配成功。

（3）！
~：反向正则匹配，区分字母大小写，进行正则表达式测试，若测试不堪利，则匹配成功。

（4）！
~：反向正则匹配，不区分字母大小写，进行正则表达式测试，若测试不堪利，则匹配成功。
下面是一个正则匹配的例子，可以匹配以hello.php或hello.asp结尾的URL要求。

#正则匹配 location ~hello\.(asp|php)$ { echo "正则匹配: hello.(asp|php)$ "; }

在浏览器中给Nginx发送http://localhost/1/2/hellp.php的要求地址，输出的要求结果如图7-14所示。

图7-14 输出的要求结果

如果配置文件中存在多个正则匹配location，那么它们之间的规则是顺序优先的，只要匹配到第一个正则类型的location，就停滞后面的正则类型的location测试。

例如，这里有两个正则匹配的location规则：\.（do|jsp）$和hello\.（do|jsp）$，详细如下：

#正则匹配类型location ~\.(do|jsp)$ { echo "正则匹配: .(do|jsp)$ "; } #正则匹配类型 location ~hello\.(do|jsp)$ { echo "正则匹配: hello.(do|jsp)$ ";}

在浏览器中给Nginx发送http://localhost/1/2/hellp.do的要求地址，输出的结果是由配置在前面的location输出的，如图7-15所示。

图7-15 输出结果

4.默认根路径匹配

根路径的路径规则便是利用单个“/”符号，示例如下：

location / { echo "默认根路径匹配: /"; }

通过浏览器随便访问一个地址，如http://localhost/foo，使之不能匹配到其他的location，只能匹配到“/”根路径，返回的结果如图7-16所示。

图7-16 返回的结果

表面看上去，location/{...}根路径匹配非常类似普通匹配，但实际上该规则自成一类，虽然只有唯一的一个路径，但是此类规则优先级是最低的。

末了总结一下4种location之间的匹配次序，大致如下：

（1）类型之间的优先级：精准匹配>普通匹配>正则匹配>“/”默认根路径匹配。

（2）普通匹配同类型location之间的优先级为最长前缀优先。
普通匹配的优先级与location在配置文件中所处的先后顺序无关，而与匹配到的前缀长度有关。

（3）正则匹配同类型location之间的优先级为顺序优先。
只要匹配到第一个正则规则的location，就停滞后面的正则规则的测试。
正则匹配与location规则定义在配置文件中的先后顺序强干系。

第一个该当配置的属于“/”根路由规则。
“/”根路由规则可以路由到一个静态首页：

location / { root html; index index.html index.htm;}

表示在要求URI匹配到“/”根路由规则时，首先Nginx会在html目录下查找index.html文件，如果没有找到，就查找index.htm文件，将找到的文件内容返回给客户端。

“/”根路由规则也可以路由到一个访问很频繁的上游做事，比如Spring Cloud微做事架构中的做事网关：

location / { proxy_pass http://127.0.0.1:7799/ ;}

这里的127.0.0.1：7799假定为Zuul网关的IP和端口，当要求匹配到“/”根路由规则时，将直接转发给上游Zuul运用网关做事器。

第二个该当配置的属于静态文件路由规则。
对静态文件要求进行相应，这是Nginx作为HTTP做事器的强项。
静态文件匹配规则有两种配置办法：目录匹配（前缀匹配）和后缀匹配（正则匹配），可以任选其一，也可以搭配利用。

目录匹配（前缀匹配）配置实例如下：

root /www/resources/static/; #前缀匹配location ^~ /static/ { root /www/resources/;}

所有匹配/static/...规则的静态资源要求（如/static/img/1.png）都将路由到root指令所配置的文件目录/www/resources/static/下对应的某个文件（如/www/resources/static/img/1.png）。

后缀匹配（正则匹配）配置实例如下：

location ~\.(gif|jpg|jpeg|png|css|js|ico)${ root /www/resources/;}

所有匹配到以上正则规则的静态资源要求（如/static/img/2.png）都将路由到root指令所配置的文件目录/www/resources/static/下对应的某个文件（如/www/resources/static/img/2.png）。