单体应用依赖比较少，大部分情况我们只需要启动一个应用就可以开始测试工作。架构升级到服务化后，每个应用依赖比较多，任何一个依赖有问题都会影响测试结果；如果服务化环境中多项目并行测试，测试效率会更差 。 为此，我们给出服务化多项目并行测试方案。
版本号隔离
首先能想到的方法就是利用版本号的特征「类dubb的RPC框架都有版本号属性」，对不同的项目给出不同的版本号; 比如有如下调用关系:
1 | Client -> SA |
在启动SA的时候对不同的项目指定不同的版本号,Client在调用SA的时候根据不同的项目指定与SA相匹配的版本号.
- 优点: 简单，无需额外开发，类dubbo的RPC框架都支持
多项目开发测试现状
实际项目中的调用关系：
1 | Client -> SA -> SB -> SC -> SD |
有两个项目在并行开发：
- project1「以下简称P1」代码变更部分是SA, SC
- project2「以下简称P2」代码变更部分是SB, SD
如果我们采用「版本号隔离」方案; 对于P1, 不但需要部署SA和SC，还需要部署Client和SB，因为Client调用SA，SB调用SC的版本号分别指向新部署的SA和SC 。P2也需要类似的部署方法；这样我们发现，几乎所有的服务在每个项目中都需要部署一套；造成资源大量浪费，显然不现实。 因此，我们有了下面的方案「动态路由」 。
动态路由
动态路由的思路是环境分一套稳定环境和每个项目对应一套项目测试环境,其中稳定环境包括所有的服务，项目测试环境仅包括该项目代码变更部分的服务,各个环境的所有服务采用同一注册中心；方案如下图所示
- 稳定环境: 部署所有的服务，保证稳定环境作为完整的系统；可以利用CI/CD每日从Master拉稳定版本的代码完成自动部署
- P1: project1测试环境，仅部署有代码变更的SA1和SC1
- P2: project2测试环境，仅部署有代码变更的SB2和SD2
- 路由策略： Client发起调用的时候携带该调用链路所有测试环境的路由规则，如果没有指定路由规则请求默认环境的服务
实现要点
- 每个服务启动时候在注册中心注册服务所在节点测试环境类型(P1，P2或者默认环境)，默认情况注册为默认环境
- 自定义loadbalance，根据路由规则将RPC请求路由到指定节点上
- 每次RPC调用将该调用链路的路由规则隐士传递到下层服务
- 每个测试环境需要一个独立的入口，以WEB项目为例可以将nginx作为入口，路由规则可以配置在nginx的配置文件中
- 对接发布系统，有变更的服务发布到测试环境时候，该测试环境的路由规则自动写入测试环境的入口配置文件