Nginx中的mirror指令具体有哪些功能应用？
- 内容介绍
- 文章标签
- 相关推荐
本文共计705个文字，预计阅读时间需要3分钟。
使用Nginx的mirror指令实现流量复制，该指令源自ngx_http_mirror_module模块。在Nginx 1.13.4版本中，mirror指令的核心功能是流量复制。若需要流量复制功能，则必须使用该指令。以下是一个示例配置：
mirror 流量复制Nginx的 mirror 指令来自于 ngx_backend; } # 复制的流量转发到这里 location = /mirror { # internal 标志该location只为内部的重定向服务， 外面来的返回404 internal; # $request_uri 需要显示指明，因为流量复制过来之后会丢掉request_uri proxy_pass test_backend$request_uri; } 有什么实际用处？
- 举个实际使用的例子:
上篇写了Nginx的map指令用法其中提到的一个使用cookie进行多环境分流的例子，同样的场景， 基于cookie分流遇到的一个问题是：对于第三方的回调请求支持不友好， 因为第三方不可能携带我们自定义的cookie来回调我们。这样说可能没参与项目的不太好理解， 简单说是这样的： 比如我在3环境和腾讯云做了交互， 之后腾讯云会回调3环境的一个接口(因为测试多环境使用同一个域名)，完犊子了吧，因为腾讯云没有带我们分环境的cookie， 因此我在3环境的这个交互一定是无法完成的。
那么如何解决这个问题？ mirror 指令可以解决。
- Nginx 会丢弃 mirror 的响应 ： 这一点很重要
为了解决第三方回调的问题，我们开启了Nginx的mirror， 把回调接口的请求复制到测试所有环境内，总有一个是目标环境(从业务上说即使回调到其他环境也无所谓，所以直接镜像到所有环境)， 配置大致是这样：
location /notify/v1.0/ {
mirror /test-01;
mirror /test-02;
mirror /test-03;
mirror /test-04;
mirror /test-05;
mirror /test-06;
mirror /test-07;
mirror /test-08;
mirror /test-09;
mirror /test-10;
}
location = /test-01 {
internal;
# 头信息视情况添加/删除
proxy_pass_header Server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass upstream_test-01$request_uri;
}
upstream upstream_test-01 {
server 1.1.1.1:80 weight=100 max_fails=10 fail_timeout=60s;
}
- 再举个实际的例子
灰度验证
提供给一个思路： 比如你需要改动线上的都个配置，但是不确定是不是有问题的时候， 这个时候其实可以使用一下mirror的流量复制, 先在灰度环境改掉，然后使用mirror镜像线上流量到灰度验证,这时候你只需要观测灰度的请求是否正常即可。（当然可以自动化程度高一些，自由发挥）, 也可以使用 split_client 指令做部分流量的验证。
注意点- Nginx会丢弃mirror响应，但是如果mirror过去的请求一直无响应或响应慢的时候，这时会影响主请求的响应速度的。
- 需要注意，一般不会把POST/PUT等会影响数据状态的请求做镜像的， 除非你明确清楚的知道这样产生的影响并且可以接受.
本文共计705个文字，预计阅读时间需要3分钟。
使用Nginx的mirror指令实现流量复制，该指令源自ngx_http_mirror_module模块。在Nginx 1.13.4版本中，mirror指令的核心功能是流量复制。若需要流量复制功能，则必须使用该指令。以下是一个示例配置：
mirror 流量复制Nginx的 mirror 指令来自于 ngx_backend; } # 复制的流量转发到这里 location = /mirror { # internal 标志该location只为内部的重定向服务， 外面来的返回404 internal; # $request_uri 需要显示指明，因为流量复制过来之后会丢掉request_uri proxy_pass test_backend$request_uri; } 有什么实际用处？
- 举个实际使用的例子:
上篇写了Nginx的map指令用法其中提到的一个使用cookie进行多环境分流的例子，同样的场景， 基于cookie分流遇到的一个问题是：对于第三方的回调请求支持不友好， 因为第三方不可能携带我们自定义的cookie来回调我们。这样说可能没参与项目的不太好理解， 简单说是这样的： 比如我在3环境和腾讯云做了交互， 之后腾讯云会回调3环境的一个接口(因为测试多环境使用同一个域名)，完犊子了吧，因为腾讯云没有带我们分环境的cookie， 因此我在3环境的这个交互一定是无法完成的。
那么如何解决这个问题？ mirror 指令可以解决。
- Nginx 会丢弃 mirror 的响应 ： 这一点很重要
为了解决第三方回调的问题，我们开启了Nginx的mirror， 把回调接口的请求复制到测试所有环境内，总有一个是目标环境(从业务上说即使回调到其他环境也无所谓，所以直接镜像到所有环境)， 配置大致是这样：
location /notify/v1.0/ {
mirror /test-01;
mirror /test-02;
mirror /test-03;
mirror /test-04;
mirror /test-05;
mirror /test-06;
mirror /test-07;
mirror /test-08;
mirror /test-09;
mirror /test-10;
}
location = /test-01 {
internal;
# 头信息视情况添加/删除
proxy_pass_header Server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass upstream_test-01$request_uri;
}
upstream upstream_test-01 {
server 1.1.1.1:80 weight=100 max_fails=10 fail_timeout=60s;
}
- 再举个实际的例子
灰度验证
提供给一个思路： 比如你需要改动线上的都个配置，但是不确定是不是有问题的时候， 这个时候其实可以使用一下mirror的流量复制, 先在灰度环境改掉，然后使用mirror镜像线上流量到灰度验证,这时候你只需要观测灰度的请求是否正常即可。（当然可以自动化程度高一些，自由发挥）, 也可以使用 split_client 指令做部分流量的验证。
注意点- Nginx会丢弃mirror响应，但是如果mirror过去的请求一直无响应或响应慢的时候，这时会影响主请求的响应速度的。
- 需要注意，一般不会把POST/PUT等会影响数据状态的请求做镜像的， 除非你明确清楚的知道这样产生的影响并且可以接受.