整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
網通過K8S搭建多個分支測試環境，可是如果外網需要訪問而且域名都是一致的情況下，這個時候變得麻煩了。如何通過不同的請求參數訪問不同的后端環境呢，答案是可以的，通過lua可以達到。
入口:
http://fengwan.blog.51cto.com/?envs=branches #branches環境
http://fengwan.blog.51cto.com/?envs=branchesv2 #branchesv2環境
另外考慮到APP請求的時候無法通過參數來處理，我們可以添加統一的請求header: envs
curl --header "envs:branches" http://fengwan.blog.51cto.com
curl --header "envs:branchesv2" http://fengwan.blog.51cto.com
我們通過Openresty判斷頭部然后選擇不同的后端環境
Nginx配置:
upstream branches {
server 10.254.220.47:80;
}
upstream branchesv2 {
server 10.254.60.225:80;
}
upstream default {
server 10.254.220.47:80;
}
server {
listen 80;
server_name fengwan.blog.51cto.com;
location / {
lua_code_cache on;
set $upstreamhost "";
rewrite_by_lua_file /etc/nginx/conf.d/html/proxy.lua;
proxy_redirect off ;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 50m;
client_body_buffer_size 256k;
proxy_connect_timeout 30;
proxy_send_timeout 30;
proxy_read_timeout 60;
proxy_buffer_size 256k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
proxy_max_temp_file_size 128m;
proxy_pass http://$upstreamhost;
}
}
lua腳本內容
/etc/nginx/conf.d/html/proxy.lua;
論使用Nginx URL中攜帶的變量，并根據變量值進行轉發的實現方式。
在Web開發中，URL參數經常用于傳遞信息和控制行為。例如，一個URL可能包含?from=spic這樣的參數，表示請求的來源為“spic”，可以根據這些參數值進行轉發。
1. 安裝Nginx
請參考官方文檔或其他資源完成安裝步驟。
2. 編輯Nginx配置文件
打開Nginx的配置文件（通常是`nginx.conf`），添加如下配置：
server {
listen 80;
server_name example.com;
location / {
# 檢查from參數是否為spic，如果是，則轉發到192.168.1.101:8080/spic
if ($arg_from="spic") {
proxy_pass http://192.168.1.101:8080/spic;
}
# 默認轉發到192.168.1.102:8080/
proxy_pass http://192.168.1.102:8080/;
}
}
在上述配置中，使用$arg_from變量來獲取URL中的from參數，并根據參數值進行轉發。如果參數值為“spic”，則請求會被轉發至http://192.168.1.101:8080/spic；否則，請求將轉發至默認的http://192.168.1.102:8080/。
3. 重啟Nginx
保存配置文件后，使用以下命令重啟Nginx使配置生效：
sudo nginx -t;sudo nginx -s reloadnginx配置
server {
listen 9090;
location / {
# 如果from參數等于spic，則設置不同的后端服務器
if ($arg_from="spic") {
proxy_pass http://10.2.2.215:8090;
}
proxy_pass http://10.2.2.162:8090/;
}
}
### 模擬請求
[root@localhost conf.d]# curl -I http://10.2.2.227:9090
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 May 2024 09:17:54 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 995
Connection: keep-alive
[root@node1 ~]# python -m http.server 8090
Serving HTTP on 0.0.0.0 port 8090 (http://0.0.0.0:8090/) ...
10.2.2.227 - - [07/May/2024 17:17:54] "HEAD / HTTP/1.0" 200 -
[root@localhost conf.d]# curl -I http://10.2.2.227:9090/?from=spic
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 May 2024 09:18:32 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1274
Connection: keep-alive
[root@node2 ~]# python -m http.server 8090
Serving HTTP on 0.0.0.0 port 8090 (http://0.0.0.0:8090/) ...
10.2.2.227 - - [07/May/2024 17:18:32] "HEAD /?from=spic HTTP/1.0" 200 -
測試結果配置生效
想寫這篇文章，是因為最近在 GA 中發現了一些問題。
EmarSys 是公司新簽約的 EDM 服務商，在 GA 中已經可以看到最新一期 EDM 帶來的流量。但它的媒介參數似乎不正確，理論上應該設置為 email。
運營部的同學認為提供給 EDM 的鏈接不會有錯，于是我深入分析之后便有了這篇文章。寫完它，我以后應該就不需要口頭再解答很多問題了。
UTM 參數的作用這里暫不贅述。我們先看一個正常的、加了 UTM 參數的鏈接（URL），它通常是這樣的：
http://www.foobar.com/?utm_source=google&utm_medium=cpc&utm_campaign=test&utm_term=test
簡單小結一下參數規則：
實際工作中，建議使用專門的鏈接生成工具來為鏈接添加 UTM 參數，避免手工失誤。
當有人用瀏覽器訪問這個 URL 時，UTM 參數就會發揮作用。
好的，如果你只是提供一個最終鏈接給一個靠譜的 Agency，那么直接提供上面的鏈接就可以了。但是如果是自己制作 EDM，情況會稍稍復雜一些。
EDM 的本質實際上是一個 HTML 頁面（或一段 HTML 代碼），理論上它需要遵守 HTML 規范。
我們在上面提到的 & 字符在 HTML 代碼中是一個特殊字符，有特殊用途，它不能直接代表它自己。如果要在 HTML 頁面中表達這個字符時，你需要在源代碼中把它寫成 &。這種寫法叫做“HTML 實體”，其它一些字符也需要以實體的形式來寫入 HTML 代碼中（比如大于號 > → >、人民幣符號 ￥ → ￥ 等等）。
所以，如果要把鏈接加到 EDM 中的某個元素身上，在 HTML 源碼中就需要這樣寫（摘自 EDM 源文件）：
當然，用戶并不會接觸到源代碼。用戶通常是使用郵件客戶端（比如 FoxMail、Outlook 等）或瀏覽器來查看郵件，這些程序都是遵循 HTML 規范來開發的，它們可以正確地解析實體，將其轉換為本來的字符。
所以，雖然我們在源代碼中看到鏈接使用的是 & 實體，但郵件在顯示的時候，這些實體會被解讀為 & 字符。也就是說，用戶在查看郵件的時候，會得到一個正確的鏈接。如下圖（EDM 源文件在瀏覽器中的效果）：
好，文章正文到此已經結束。不過文章開頭的問題還沒有解決，所以我們繼續。
到目前為止，事情看起來都還不錯，對吧？
可是，我們并不是直接發送 HTML 文件，而是通過 EDM 投放系統（比如目前剛剛開始使用的 EmarSys）來完成郵件的發送。一封 EDM 從我們做好的 HTML 頁面到發送到用戶的郵箱中，經歷了一些處理。其中一個相當重要的處理步驟，是把頁面中原有的鏈接（通常已經加上了 UTM 參數）“包裝”起來。也就是說，并不會把原鏈接直接提供給用戶，而是把原鏈接替換成一個“中轉鏈接”（格式大約是 http://link2.foobar.com/u/nrd.php?p=XXX）。
我們觀察一下收到的 EDM 郵件，可以發現這一點：
這個中轉鏈接會把用戶帶到真正的目標頁面。（為什么 EmarSys 要使用這種中轉鏈接？其實幾乎所有成熟的 EDM 服務商都會這樣做，這樣做有一些好處，不過這里也不贅述了。）
鋪墊了這么久，終于要發現真相了——問題就出在 EmarSys 的系統和這個中轉鏈接。
這個系統并不能正確識別 HTML 頁面中的實體，在生成中轉鏈接的過程中，并不能把原鏈接中的 &實體解析為它的本意 & 字符，而是直接理解為實體的字面。這樣一來，用戶會被中轉鏈接帶到一個錯誤的、不是我們本意的地址。
下圖是我對中轉鏈接的跟蹤，它通過 HTTP 重定向（302）實現跳轉，跳轉目標由 Location 字段指定：
發現問題了吧？如果點擊 EDM 中的鏈接，用戶真正到達的地址是這樣的：
不要小看這幾個字符的差異，這個 URL 的實際效果已經不是我們最初期望的那樣了。如果你分析一下，會發現這個頁面（除了 utm_source 參數以外）真正接收到的是 amp;utm_media 這樣的參數，而不是原本的 utm_media 等等。參數傳錯了，GA 當然也就收不到正確的值，所以實際上不僅媒介參數有問題，活動、內容、關鍵字參數都沒有收到：
目前我們所能做的：
點贊+轉發，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓-_-）
關注 ｛我｝，享受文章首發體驗！
每周重點攻克一個前端技術難點。更多精彩前端內容私信 我 回復“教程”
原文鏈接：https://mp.toutiao.com/profile_v3/graphic/publish
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
