转转测试环境的标签域名实践
一、问题背景
公司现在访问测试环境方式,使用线上域名,本地配置 host,通过 host 控制访问不同的环境。这种使用方式,存在诸多问题,比如:
忘修改 host,或浏览器存在 socket 缓存,host 没生效。会访问更改线上数据,风险大。
需要频繁配置修改 host,产品,运营,测试在测试环境作业中效率较低。
与第三方联调时,每次更换测试环境,都需要运维同学更改 nginx 配置。
二、测试环境演进介绍
2.1 固定数量测试环境
交易服务多需求并行时,交易分支 1 和分支 2,所依赖的服务需要在环境都部署一份
优点:流量隔离。
缺点:如果我们有 500+的实例,如果靠简单的拉起实例,那么一个环境就需要拉起 500 个实例,5 套环境就有 2500+实例,机器资源浪费严重。所以我们需要让应用能在不同的环境复用。
2.2 多环境复用:动态环境 + 稳定环境
多需求并行时,只需要在动态环境,分别部署新需求分支
优点:既保证流量隔离,也能节约机器成本。
当前的缺点:联调,测试,产品验收时需要手动配置 host,访问动态环境。
三、解决方案
改造使用到的技术点:DNS 域名泛解析
3.1 原理
所谓“域名泛解析”是指:利用通配符* (星号)来做次级域名以实现所有的次级域名均指向同一 IP 地址。
3.2 泛解析的使用场景
让域名支持无限的子域名(这也是泛域名解析最大的用途)。
防止用户错误输入导致的网站不能访问的问题(对于大型网站,不太适用,一般用 URL 重定向,将网页重定向到错误页面)。
可以让直接输入网址登陆网站的用户输入简洁的网址即可访问网站。
3.3 DNS 泛解析配置
转转 DNS 平台:
四、 标签域名在转转后台系统的落地
一个公司系统多年迭代,当引入新的技术点,前端,后端,运维,架构,工程效率部等整条链路上各自负责的服务,或多或少都需要进行个性化改造,才能达到预期目标。下文是转转中台 OMS 后台管理系统使用标签域名的一些改造点,仅供参考!
4.1 OMS 协作平台标签域名改造点
DNS 配置域名泛解析和 ngx_lua 做流量分组(运维部负责)。
sso 服务扫码登录改造(架构部负责)。
CI 部署前端服务时,替换静态资源域名(工程效率部负责)。
多域名合一:前端和后端服务域名分别使用不同域名,废弃后端域名,只保留 SCP 前端域名。在 nginx 配置根据 uri 规则路由(后端 &前端负责)。
前端服务获取浏览器输入 host,动态拼接 url(前端负责)。
4.2 请求流程图
所谓一图胜千言,整个请求流程如下面这张图所描述的场景。
五、标签域名使用方式和效果
5.1 OMS 协作平台的使用方式
5.1 访问效果
如上图所示,无需繁琐的配置 host,通过域名访问即可。
高向阳,中台履约 OMS 研发负责人
转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」(综合性)、「大转转 FE」(专注于 FE)、「转转 QA」(专注于 QA),更多干货实践,欢迎交流分享~
评论