前端項目開發一個模塊,上線前需要灰度一部分用戶,實現一個臨時的灰度方案。
現有項目狀況:
一個前端項目1.0.0版本
后端服務1.0.0版本
后端灰度服務2.0.0版本
一個域名解析到前端服務80、443端口
前端通過nginx轉發靜態文件
1、打包一份前端項目2.0.0版本,上傳服務器,部署不同端口
2、通過nginx獲取文件中攜帶的請求頭remote_user,在nginx代理靜態文件的時候判斷當前用戶是否灰度中,請求不同的靜態資源
3、前端打包的時候,給請求的接口增加版本號2.0.0,請求接口,通過版本號判斷訪問的后端灰度服務。
實現簡單,易于理解
通過nginx可以灰度到具體人員 缺點:
維護兩套程序,不適合長時間的灰度方案
灰度人數有限,nginx參數不能過長(可分開配置避免這個問題)
正常請求域名 https://www.demo.com
test.lv
san.zhang
人員名單配置nginx
server { listen 80; server_name www.demo.com; location / { if ($http_remote_user ~* (test\.lv|san.zhang)){ proxy_pass http://localhost:8081; } root /data/demo; index index.html index.htm; } location ^~/api/ { if ($http_version = "2.0.0"){ # 代理到新的服務 proxy_pass http://10.11.12.234:9001; } proxy_pass http://10.11.12.234:9002; } } 復制代碼
underscores_in_headers on; 復制代碼
// 以go為例,增加自定義header c.Header("Access-Control-Allow-Headers", "Content-Type, remote_user, api_version")
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/127950.html
摘要:基于的前端灰度發布方案灰度發布和測試簡介灰度發布將某個功能灰度發布逐漸放量給特定線上人群,避免新功能全量上線帶來的風險。如果我們把這些版本信息管理起來,并且通過特定的手段對用戶請求應用測試就可以完成前端不同版本的灰度發布。 基于Nodejs的前端灰度發布方案 1. 灰度發布和A/B測試簡介 灰度發布 將某個功能灰度發布(逐漸放量)給特定線上人群,避免新功能全量上線帶來的風險。 show...
摘要:本文將結合馬蜂窩容器化平臺賦能前端應用構建的實踐經驗,介紹整個平臺背后的設計和實現原理,取得的一些效果及問題的優化方案。如果使用容器化平臺就不會出現這方面的擔憂。 容器對前端開發真的有用嗎?答案是肯定的。 最初當我向公司的前端同學「安利」容器技術的時候,很多人都會說:「容器?這不是用在后端的技術嗎?我不懂啊,而且前端開發用不上吧。」 showImg(https://segmentfau...
摘要:本文將結合馬蜂窩容器化平臺賦能前端應用構建的實踐經驗,介紹整個平臺背后的設計和實現原理,取得的一些效果及問題的優化方案。如果使用容器化平臺就不會出現這方面的擔憂。 容器對前端開發真的有用嗎?答案是肯定的。 最初當我向公司的前端同學「安利」容器技術的時候,很多人都會說:「容器?這不是用在后端的技術嗎?我不懂啊,而且前端開發用不上吧。」 showImg(https://segmentfau...
摘要:本文將結合馬蜂窩容器化平臺賦能前端應用構建的實踐經驗,介紹整個平臺背后的設計和實現原理,取得的一些效果及問題的優化方案。如果使用容器化平臺就不會出現這方面的擔憂。 容器對前端開發真的有用嗎?答案是肯定的。 最初當我向公司的前端同學「安利」容器技術的時候,很多人都會說:「容器?這不是用在后端的技術嗎?我不懂啊,而且前端開發用不上吧。」 showImg(https://segmentfau...
閱讀 284·2024-11-07 18:25
閱讀 130363·2024-02-01 10:43
閱讀 868·2024-01-31 14:58
閱讀 828·2024-01-31 14:54
閱讀 82766·2024-01-29 17:11
閱讀 3047·2024-01-25 14:55
閱讀 1985·2023-06-02 13:36
閱讀 3032·2023-05-23 10:26