前端项目开发一个模块，上线前需要灰度一部分用户，实现一个临时的灰度方案。
现有项目状况：
一个前端项目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")
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/127950.html
摘要：基于的前端灰度发布方案灰度发布和测试简介灰度发布将某个功能灰度发布逐渐放量给特定线上人群，避免新功能全量上线带来的风险。如果我们把这些版本信息管理起来，并且通过特定的手段对用户请求应用测试就可以完成前端不同版本的灰度发布。 基于Nodejs的前端灰度发布方案 1. 灰度发布和A/B测试简介 灰度发布 将某个功能灰度发布（逐渐放量）给特定线上人群，避免新功能全量上线带来的风险。 show...
摘要：本文将结合马蜂窝容器化平台赋能前端应用构建的实践经验，介绍整个平台背后的设计和实现原理，取得的一些效果及问题的优化方案。如果使用容器化平台就不会出现这方面的担忧。 容器对前端开发真的有用吗？答案是肯定的。 最初当我向公司的前端同学「安利」容器技术的时候，很多人都会说：「容器？这不是用在后端的技术吗？我不懂啊，而且前端开发用不上吧。」 showImg(https://segmentfau...
摘要：本文将结合马蜂窝容器化平台赋能前端应用构建的实践经验，介绍整个平台背后的设计和实现原理，取得的一些效果及问题的优化方案。如果使用容器化平台就不会出现这方面的担忧。 容器对前端开发真的有用吗？答案是肯定的。 最初当我向公司的前端同学「安利」容器技术的时候，很多人都会说：「容器？这不是用在后端的技术吗？我不懂啊，而且前端开发用不上吧。」 showImg(https://segmentfau...
摘要：本文将结合马蜂窝容器化平台赋能前端应用构建的实践经验，介绍整个平台背后的设计和实现原理，取得的一些效果及问题的优化方案。如果使用容器化平台就不会出现这方面的担忧。 容器对前端开发真的有用吗？答案是肯定的。 最初当我向公司的前端同学「安利」容器技术的时候，很多人都会说：「容器？这不是用在后端的技术吗？我不懂啊，而且前端开发用不上吧。」 showImg(https://segmentfau...
阅读 130091·2024-02-01 10:43
阅读 758·2024-01-31 14:58
阅读 733·2024-01-31 14:54
阅读 82539·2024-01-29 17:11
阅读 2821·2024-01-25 14:55
阅读 1896·2023-06-02 13:36
阅读 2771·2023-05-23 10:26
阅读 835·2023-05-23 10:25
