利用灰度方式解决微服务测试环境共用问题

背景

先简单交代下背景，好引出为什么要做这个事情，当项目团队大了之后我们经常会遇到的问题就是git流程的管理，以及遇到使用某套git管理流程之后所带来的成本和问题，例如：如果你使用gitflow 流程你就会发现你对开发人员对git操作本身就需要很高的水准，不利于不同层次的人员协同，第二你有可能生产版本不稳定经常需要修bug，不断拉取hotfix，然后走一套流程过于复杂。中间我们省略过release，或者使用pr模式，最终都以各种各样得问题彻底放弃了所谓得最佳实践，所以我决定走出一条自己得路，最后发现自己得路才是真正得最佳实践。
我们得流程非常简单如下

• master-feature
• 从生产到开发环境全部部署master或者tag版本。
• feature在未上线前始终保持feature状态不合并。
• feature每天rebase master，上生产前将自己commit 合并成一个commit id提交合并请求。此时不会产生任何冲突，谁开发feature有谁负责rebase，那么会产生一个非常好的良性循环，因为开发者对自己的代码非常熟悉，并且master的代码绝对是都要的。所以rebase出错的可能性降低了非常多，然后合并请求不存在冲突所以不会出错。而且操作极简 不会使用git的小白也能使用。

但是以上流程存在一个问题，当多个需求并行开发的时候测试环境如何处理？开发环境如何处理？于是就衍生出了如下方案。因为我的服务可能有上百个但是我本次需求只涉及了2个服务。

根据上图我做的解决方案就是通过灰度的策略将测试人员的ip绑定到version上。并通过重写loadblance负载规则将测试人员ip的版本号与服务发现的版本号进行绑定，没有绑定的用户将通过默认规则会走原本的稳定环境。同样这套理论可以应用到开发环境。
所以这里需要提供的支持如下
1、提供个方便快捷的nginx 页面配置路由规则
2、注册中心提供应用级别版本管理
3、服务间负载组件提供从注册中心获取版本并提供版本策略

文章描述都是文字看起来很复杂的样子，其实如果你实践起来之后你会发现非常简单。可以参考我的另一篇文章【dubbo扩展解决开发环境共用问题】目前正在努力构建这套体系，先贴个理论基础出来。也希望有大牛能把这套体系做的更好。