網通過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 reload
nginx配置
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小時內與您取得聯系。