Nginx流量控制
流量復制
項目進行遷移上雲,如何在不影響現有項目的情況下,進行驗證測試,平滑遷移。理論上分割部分流量到雲上進行驗證,確定沒有問題逐漸遷移,如果nginx不好分割流量的情況,其實不太好做遷移,風險太大。
nginx支持流量復制,在接收請求時,可以復制流量到另外的服務器而不關心響應,對原本的項目不會產生任何影響。
復制的流量轉發到雲上的服務跑動,驗證數據流程沒有問題,就可以對其整體切換。
ngx_http_mirror_module
implements mirroring of an original request by creating background mirror subrequests. Responses to mirror subrequests are ignored.
通過創建后台鏡像子請求實現原始請求的鏡像。對鏡像子請求的響應將被忽略;
場景:可以做流量復制,不關心響應。作為機房遷移上雲的過渡挺合適的,或者說是作為復制請求測試。
location / {
mirror /mirror;
proxy_pass http://backend;
}
location = /mirror {
internal;
proxy_pass http://test_backend$request_uri;
}
參考:http://nginx.org/en/docs/http/ngx_http_mirror_module.html
流量分割
服務的流量壓力巨大,並且個別接口有時候因為訪問量暴漲,會影響到其他的接口服務;單個接口也可能因為某個維度爆量,影響其他維度的服務。所以就有必要對流量進行切割,使他們相互獨立,隔離,達到解耦的效果。
舉個實際項目中的應用列子,雖然使用k8s中的ingress處理的,但理論上沒啥差別。
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
namespace: bigdata
name: adc-ingress
annotations:
ingress.kubernetes.io/rewrite-target: /
kubernetes.io/ingress.class: "nginx" # ingress指定nginx
nginx.ingress.kubernetes.io/server-snippet: | # 設置nginx 服務腳本配置
set $flag 0;
if ( $uri = /click) {
set $flag 1;
}
if ( $args ~ project=ios ) {
set $flag 1$flag;
}
if ( $flag = 11 ) {
rewrite ^/(.*) $uri-ios break;
}
spec:
rules:
- host: walking.sun.com
http:
paths: # path對應nginx path
- path: /click/google
backend:
serviceName: google-srv # 指定path 請求會轉發到對應的svc
servicePort: 8080
- path: /click-ios
backend:
serviceName: web-ios-srv
servicePort: 8080
- path: /click
backend:
serviceName: web-srv
servicePort: 8080
- host: walking.sun123.com
http:
paths:
- path: /click/google
backend:
serviceName: google-srv
servicePort: 8080
tls: # 開發tls
- hosts:
- walking.sun.com
secretName: sun.com
- hosts:
- walking.sun123.com
secretName: sun123.com
可以看到有根據接口路徑進行拆分,有根據解析參數進行切割,其實就是nginx的語法。