测试环境路由可以这么做（一）

架构师吕师傅
152 阅读5分钟

你们还在用这样的研发模式吗？

运行环境通常至少一套开发（dev）、测试环境（test），一套集成环境（试情况定），一套预发环境（pre），再加上一套线上环境（online）

图片

测试环境与分支直接对应的，固定的。

  1. 有新需求时从master分支拉取一个新的需求分支，开发完成后，合并至dev分支，并部署在dev环境自测

  2. 自动完成后，合并至test-project分支，并部署在相应的环境，给测试人员测试

  3. 预期内要一起上线的需求分支，QA验证完成后合并至pre分支，部署在pre环境，由QA和需求方验证

  4. pre环境验证成功后，合并到master，发布到online环境

这个模式在开发人员规模较小，业务需求量小、微服务少的情况下，是比较顺的

随着业务规模的扩大，开发人员的扩大，必然会遇到如下的问题：

  1. 业务的快速发展，必然要求有并行开发的能力和需求，维护了10数套开发测试环境，以降低环境的影响，但依然不够用

  2. 测试资源维护耗费大量的成本：每套环境都需要部署全套服务和基础设施，需要大量的物理资源；创建一套新环境需要耗费数天的时间

  3. 各环境的配置、数据库同步也需要进行持续维护，也较耗费开发时间

  4. 不同发布周期的任务相互影响：因为环境不足，不同发布时间的代码合并在一起测试，互相影响

  5. 测试的内容与需求，与上线验证的内容不同，带来较大的不确定性

  6. 合并上去的代码难以剔除

  7. 分支合并冲突过多，解决冲突的时间增多

  8. 各固定分支代码差异大

  9. 环境不稳定，经常要解决各种问题

  10. 。。。。。。。。

《阿里巴巴DevOps实践指南》中提到了“测试环境与路由”，给出了一套行之有效的解决方案。

测试环境路由在微服务架构系统的开发阶段是非常实用的功能，能够大大降低测试环境的维护成本、资源成本，同时能够极大的提高研发效率。

什么是测试环境路由

测试环境路由是一种基于服务路由的开发测试环境治理策略，核心思想是维护一套稳定的基础环境（也叫做基线环境） ，仅需要部署需要变更的微服务以构成特性环境。 在流量入口染色，通过一定的路由规则，优先由特性环境中相应的微服务处理，否则由基础环境处理。

以特性为核心的持续交付

为了解决以上在企业规模增长和新技术应用中的种种交付痛点，阿里巴巴不断探索和尝试，逐步摸索出一 种适合这种业务发展快、软件迭代快、架构依赖复杂场景的交付方法和实践

1、以特性为核心

特性是一个用户能体验到的产品能力的最小单元，其代码可能涉及到多个应用，因此特性也是协同多个开 发团队完成一个能力的最小单元。以特性为核心的交付过程管理可以有效地将开发、测试等角色连接起来并统一推进

2、以应用为载体

应用可以直接对应一个服务，是提供一种业务能力的最小单元，也是软件交付和运维的最小单元。以独立应用为载体的交付流程可以实现软件交付的原子化，并强迫开发降低应用间的耦合性，同时避免系统级集中式交付模式的惯性

虚拟特性环境

测试环境路由的核心是隔离、打通、复用，隔离特性环境，打通本地和测试环境网络，复用基础环境，根据一定的路由规则，构建出给这个特性专用的虚拟环境

图片

                                      隔离、打通、复用

图片

                                    虚拟特性环境

图片

                               虚拟特性环境之全链路视角

实现要点

  1. 业务代码无侵入，否

  2. 全链路调用关系跟踪：调用链路不能断、链路可视化

  3. 链路追踪

    1. 全端：PC、App、H5、小程序、WebView等
    2. RPC：Dubbo、http协议等
    3. 消息：ActiveMQ、RocketMQ等
    4. 三方回调
    5. 异步线程

  5. 特性环境回收：

实现的关键点

  1. 业务代码无侵入：JavaAgent功能增强

  2. 部署平台：基础镜像、启动参数自动生成、统一配置，开发人员无需关注

  3. 部署平台：基础环境的自动更新

  4. 部署平台：特性环境及时回收：特性功能上线后，环境要能及时回收

  5. 线上与开发环境的增强功能区分：只有开发环境才需要环境路由

  6. 链路透传， 不中断：可以考虑基于SkyWalking做环境标的透传

  7. 统一web入口实现：统一使用tomcat，javaagent增强tomcat servlet，根据header中的环境标生成带环境信息的traceId

  8. 日志自动增加traceId信息：增强logback/log4j/log4j2

  9. 最外层入口环境路由：nginx-ingress使用nginx + lua的方式，根据请示头，动态路由到相应的环境。无匹配的环境时，路由到基础环境

  10. RPC服务消费者：根据traceId中的环境标，优先消费对应环境提供的服务

  11. RPC服务提供者：注册自己的环境信息

  12. 异步：增强ThreadPoolExecuter和ForkJoin，使traceId继续透传下去

  13. 消息消费路由：ActiveMQ、RocketMQ

  14. 三方回调后回到原特性环境

如果你觉得这篇文章对你有帮助，请不要吝惜你的“关注”、“点赞”、“评价”，我们可以进一步讨论实现方案和细节。你的支持永远是我前进的动力~~~

avatar
文章
阅读
粉丝