nginx map配置根據請求頭不同分配流量到不同後端服務，nginx版本為：nginx version: nginx/1.17.9
配置nginx.conf檔案
}}當在電腦上hosts檔案裡配置了aa.hc.harmonycloud.cn網域名稱解析後，訪問時(即server的server_name和listen、location的配置)，nginx將會把請求**到http://$svc_upstream，這個$svc_upstream具體是什麼，就是通過map配置來賦值的。這裡map配置如下：
其中$http_x_group_env可以是nginx內建變數，也可以是自定義的header的key、請求引數名；$svc_upstream即為自定義變數名。這裡的配置含義為：當請求頭里的x-group-env的值為old時，$svc_upstream被賦值為zxl-test-splitflow-old-version；當請求頭里的x-group-env的值為new時，$svc_upstream被賦值為zxl-test-splitflow-new-version；預設賦值為zxl-test-splitflow-old-version；
（其中正規表示式如果以 「~」 開頭，表示這個正規表示式對大小寫敏感。以 「~*」開頭，表示這個正規表示式對大小寫不敏感，很多時候map使用正則匹配）。而zxl-test-splitflow-new-version和zxl-test-splitflow-old-version表示兩個upstream名稱。
因此nginx將會把請求**到http://$svc_upstream，這裡的$svc_upstream會被替換為upstream的名稱，最終將得到upstream中的後端服務ip和port。
注意：如果我們自定義header為x-real-ip，nginx獲取該header時需要這樣：$http_x_real_ip; (一律採用小寫，而且前面多了個http_，且中間用_替換）
3、分流測試
以下測試是用springboot寫了兩個demo服務，即url訪問方式一樣，都是get請求，uri為/testdemo/test，只是響應內容有區別。將兩個demo服務做成docker映象部署到了kubernetes集群裡，請求通過ingress-nginx**到後端demo服務。
當請求頭裡加x-group-env為new時，訪問後端列印出的是i am new version
當請求頭裡加x-group-env為old時，訪問後端列印出的是i am old version
最終通過請求頭不同實現了將流量分配到不同的後端服務。
將請求頭的key變為x-group-env，value變為old或者new也沒關係：
map配置根據請求頭不同分配流量到不同後端服務
nginx根據cookie分流
nginx根據cookie分流 眾所周知，nginx可以根據url path進行分流，殊不知對於cookie分流也很強大，同時這也是我上篇提到的小流量實驗的基礎。二話不說，先看需求，兩台伺服器分別定義為 apache001 192.168.1.1 8080 apache002 192.168.1.2...
nginx根據cookie分流
nginx根據cookie分流 眾所周知，nginx可以根據url path進行分流，殊不知對於cookie分流也很強大，同時這也是我上篇提到的小流量實驗的基礎。二話不說，先看需求，兩台伺服器分別定義為 apache001 192.168.1.1 8080 apache002 192.168.1.2...
nginx根據cookie分流
nginx根據cookie分流 眾所周知，nginx可以根據url path進行分流，殊不知對於cookie分流也很強大，同時這也是我上篇提到的小流量實驗的基礎。二話不說，先看需求，兩台伺服器分別定義為 apache001 192.168.1.1 8080 apache002 192.168.1.2...