Detailed explanation of nginx mirror instruction

Help me to the Internet cafe 2022-05-14 14:49:21 阅读数:910

detailedexplanationnginxmirrorinstruction

mirror Traffic replication

Nginx Of mirror Instruction from  ngx_http_mirror_module  modular Nginx Version > 1.13.4

mirror The core function provided by the instruction is traffic replication , As for what traffic replication should be used for , This is what they need .

  • Let's start with a sample configuration :
location / {
# Enable traffic replication
mirror /mirror;
proxy_pass http://backend;
}
# The copied traffic is forwarded here
location = /mirror {
# internal Mark the location Only for internal redirection service , Come back from outside 404
internal;
# $request_uri Need to show , Because the traffic will be lost after being copied request_uri
proxy_pass http://test_backend$request_uri;
}

What's the practical use ?

  • Take a practical example :

It was written in the first part Nginx Of map Instruction usage One of the mentioned uses cookie Examples of multi environment shunting , The same scene , be based on cookie One problem with shunting is : Support for third-party callback requests is unfriendly , Because it is impossible for a third party to carry our customized cookie Come back to us . It's not easy to understand that you may not be involved in the project , To put it simply : For example, I am in 3 The environment interacts with Tencent cloud , After that, Tencent cloud will call back 3 An interface to the environment ( Because multiple test environments use the same domain name ), It's over , Because Tencent cloud doesn't take us to divide the environment cookie, So I am 3 This interaction of the environment must be impossible .

So how to solve this problem ? mirror Instructions can solve .

- Nginx Will be discarded mirror Response  : This is important

In order to solve the problem of third-party callback , We turned on Nginx Of mirror, Copy the request of the callback interface to all the test environments , There is always a target environment ( From a business point of view, it doesn't matter if you call back to other environments , So mirror directly to all environments ), The configuration is roughly like this :

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;
# Add header information as appropriate / Delete
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 http://upstream_test-01$request_uri;
}
upstream upstream_test-01 {
server 1.1.1.1:80 weight=100 max_fails=10 fail_timeout=60s;
}
  • Another practical example

Gray scale verification

Provide an idea : For example, you need to change the online configuration , But when you're not sure if there's a problem , You can actually use it at this time mirror Traffic replication , First change in the gray environment , And then use mirror Image online traffic to grayscale verification , At this time, you only need to observe whether the gray request is normal .( Of course, a higher degree of Automation , Free play ), You can also use split_client Instructions to do part of the flow verification .

Be careful

  1. Nginx Will be discarded mirror Respond to , But if mirror Past requests have been unresponsive or slow , This will affect the response speed of the main request .
  2. We need to pay attention to , You don't usually put POST/PUT And other requests that will affect the data state , Unless you clearly know the impact and can accept .
版权声明:本文为[Help me to the Internet cafe]所创,转载请带上原文链接,感谢。 https://qdmana.com/2022/134/202205141436334352.html