听过多泳道吗?赶紧进来看看它怎么建设的~

简介: 多泳道,顾名思义,就是像游泳一样,有多个游泳道,他们互相不影响。 测试环境多泳道,其实是有一个主泳道,多条次泳道,主泳道是作为稳定的泳道,它可以访问其他泳道的服务,其他泳道是不稳定的,这样的话,可*保证测试环境的稳定性

前言

多泳道听过吗?它为了解决什么问题?它又长什么样子?具体实现是怎么做的?

多泳道样子

多泳道,顾名思义,就是像游泳一样,有多个游泳道,他们互相不影响。 测试环境多泳道,其实是有一个主泳道,多条次泳道,主泳道是作为稳定的泳道,它可以访问其他泳道的服务,其他泳道是不稳定的,这样的话,可以保证测试环境的稳定性

多泳道解决什么问题

背景:在测试阶段,我们经常会听到测试同学经常抱怨,测试进度被某个流程卡住,某某背锅开发同学在排查。有时会导致多个测试任务卡住,影响整个流程正常运作,所以我们需要保证测试环境的稳定性

其次在同一时间,有多个需求同时进行,那么如果A同学改了一个代码,导致test环境炸了,是不是我们也需要等卑微的小A同学修完bug才能继续。多泳道可以解决抢占问题,提高开发效率,就是测试同学通过自己的泳道访问那条修改的代码。而其他同学访问稳定的test环境。

image.png

多泳道建设

多泳道长什么样子

image.png

如上图所示,测试环境作为稳定泳道来运作,这样就不会由于开发代码一直卡流程。如果我们只是特定的服务做更新的话,其他服务都是稳定的,我们只需要在特定节点路由到那个需要测试的服务,这样提高测试环境的稳定性。

怎么建设?


完整步骤

  1. 泳道创建:工单实现不同泳道的快速创建,比如说有个需求A,同一时间有个需求B,可以通过工单快速将dev1、dev2 开放平台两个版本跑起来 (稳定泳道:权限,经常变动泳道:开放平台..)
  2. 流量打标:网关进行改造,在工单创建泳道的时候顺便有个域名,dev1.com,dev2.com,同时指向稳定网关test环境,网关对流量进行打标tag。负载到对应环境的服务。
  3. RPC层负载:由于我们链路非常短,看不出这一层的负载,网关在调用权限模块之后,再调用开放平台服务,具体到哪个服务,这个也算rpc层负载。
  4. 数据隔离: dev1.com -> dev1 pod - >dev1数据库
为啥需要通过工单来创建?我们可以看下腾讯云方案,资源的自动化,弹性扩展。理想的话,我们也需要实现运维资源的自动化。

在二三点的时候,其实在上一篇文章讲过,大家感兴趣可以去看看~

数据隔离方面,可以做影子表、影子库。或者我们物理隔离统一5个环境,对应5个mysql实例。


测试流程

  1. 现在需求A、需求B来了,我们拉了两个分支,现在都提测了
  2. 创建工单,新建dev1、dev2环境,它会生成对应的域名指向test网关,然后我们通过全链路灰度,实现test网关通过域名维度,指向对应的服务
  3. 测试同事通过不同域名,来验证不同的逻辑,然后去不同的数据库验证数据准确性。
  4. 测试通过之后,将分支合并到test,构建test环境
  5. 泳道删除,资源回收

多泳道 VS 多物理环境

我们来对比下两个方案的优缺点,这样会有直观的比较。

形式 优点 缺点
多物理环境 物理隔离,操作快捷 资源浪费,测试环境会有不稳定的开发代码
多泳道 逻辑隔离,工单快速创建泳道,减少资源消耗 需要对中间件进行改造,比如说dev1、dev2 redis、mq、数据库都需要隔离

相对复杂一点的多泳道模型

image.png

参考 blog

本文借鉴以下文章:

相关文章
|
运维 Devops Java
阿里巴巴DevOps实践指南(十三)| 测试提效
分布式测试为测试速度插上了翅膀,精准测试有效的识别出了测试的范围,增量覆盖率又为测试的不断完备提供了有利的指引,线上覆盖率帮助我们有效的进行应用瘦身。充分利用好这些技术手段进行测试提效,可以让持续交付的过程更加的顺畅
阿里巴巴DevOps实践指南(十三)| 测试提效
|
网络安全
|
机器学习/深度学习 监控 Web App开发
SLS机器学习最佳实战:根因分析(一)
通过算法,快速定位到某个宏观异常在微观粒度的具体表现形式,能够更好的帮助运营同学和运维同学分析大量异常,降低问题定位的时间。
13255 0
|
缓存 NoSQL 关系型数据库
redis和缓存及相关问题和解决办法 什么是缓存预热、缓存穿透、缓存雪崩、缓存击穿
本文深入探讨了Redis缓存的相关知识,包括缓存的概念、使用场景、可能出现的问题(缓存预热、缓存穿透、缓存雪崩、缓存击穿)及其解决方案。
894 0
redis和缓存及相关问题和解决办法 什么是缓存预热、缓存穿透、缓存雪崩、缓存击穿
|
监控 前端开发 JavaScript
Sentry 监控部署与使用(详细流程)
Sentry 监控部署与使用(详细流程)
2982 0
|
Kubernetes 测试技术 微服务
结合阿里云ASM泳道与Kruise Rollout进行全链路灰度发布
本文将介绍如何结合阿里云ASM泳道与Kruise Rollout进行低成本,自动化的全链路灰度发布。
Java 异常处理:11 个异常处理最佳实践
本文深入探讨了Java异常处理的最佳实践,包括早抛出晚捕获、只捕获可处理异常、不忽略异常、抛出具体异常、正确包装异常、记录或抛出异常但不同时执行、不在finally中抛出异常、避免用异常控制流程、使用模板方法减少重复代码、抛出与方法相关的异常及异常处理后清理资源等内容,旨在提升代码质量和可维护性。
623 3
|
存储 缓存 关系型数据库
【如何选择Mysql服务器的CPU核数及内存大小】
【如何选择Mysql服务器的CPU核数及内存大小】
901 0
|
Cloud Native 容器 Kubernetes
基于阿里云服务网格流量泳道的全链路流量管理(三):无侵入式的宽松模式泳道
本文简要讨论了使用流量泳道来实现全链路流量灰度管理的场景与方案,并回顾了阿里云服务网格 ASM 提供的严格与宽松两种模式的流量泳道、以及这两种模式各自的优势与挑战。接下来介绍了一种基于 OpenTelemetry 社区提出的 baggage 透传能力实现的无侵入式的宽松模式泳道,这种类型的流量泳道同时具有对业务代码侵入性低、同时保持宽松模式的灵活特性的特点。同时,我们还介绍了新的基于权重的流量引流策略,这种策略可以基于统一的流量匹配规则,将匹配到的流量以设定好的比例分发到不同的流量泳道。
73759 16
基于阿里云服务网格流量泳道的全链路流量管理(三):无侵入式的宽松模式泳道
|
监控 前端开发 JavaScript
前端稳定性工具-Sentry
【11月更文挑战第9天】Sentry 是一个开源的错误和性能监控平台,支持多种编程语言和框架。它能够捕获前端应用中的各种错误和性能问题,提供详细的错误信息和用户行为关联,帮助开发团队快速定位和解决问题,优化应用性能。但需注意隐私保护、数据准确性和成本控制。
1589 3