背景与挑战
为了支撑业务的飞速发展，分布式系统架构不断演进，业务链路日趋复杂，服务间相互调用,增加了服务联调的复杂性;
在如此研发背景下，作为研发过程中不可或缺的一环业务链路联调，面临越来越多的挑战：
联调涉及应用服务多，导致环境构建和维护的成本都非常高，手工搭建一套可用联调环境，少则1-2天，部分情况下甚至可能花费1到2周。因此，如何降低联调环境构建成本，让研发同学专注于业务联调本身？
联调链路上下游依赖应用服务多，为每一个联调链路都全量搭建一套独立环境，资源消耗太大，需要对没有变更的应用服务进行复用。但是复用又带来了新的问题，每周上N个的并行研发活动，同一个应用服务可能为了支持不同需求在研发阶段存在多个并行研发，如何在资源复用的基础上，解决并行研发带来的干扰
联调过程中出现了问题，排查的链路往往比较长，一般研发同学对自己负责的应用服务比较了解，如果问题出在依赖的下游，往往需要联系对应负责的同学排查，过程中有很多的沟通成本，排查效率比较低。如何协助研发同学快速定位联调问题，提升业务联调的效率?
联调环境复用与隔离
一般操作
假如研发团队有 3套开发环境用于联调; 每套环境都部署了一套完整的N个服务；
这时候公司同时有4个需求开发联调;feature_1~4 ;那么环境占用情况如下
每个feature占用了一个环境,而feature_4却被阻塞联调了，只能等待环境空闲出来,或者再让运维增加一套环境 dev4 来使用;但是新增一套环境不仅增加了运维的工作量；而且又增加了研发成本;
难道就没有解决方法吗？
将多个需求合并到一个分支
为了解决上述问题,小企业最常用最省事的方法是:
拉一个新的分支 feature_1_2, 将多个分支都一起合并到这个分支上来进行联调；共用一套环境;
确实,这是最省事的方法,但是这个方法存在它的局限性
代码冲突, 需求冲突
每次修改了bug都要将代码合并到合并分支feature_1_2
代码污染, 修改bug的时候没有写在需求分支而写在的合并分支feature_1_2
正常来说,严格按照约定操作,也不会出现什么问题,但是我们有更好的解决方案
联调环境复用与隔离
上面的方法虽然可以操作，但是使用太复杂;我们可以将没有收到需求迭代而变更的服务复用起来;
全量部署所有服务的master稳定分支
首先我们把所有服务都部署在一套环境里面;跟stable环境(或者生产环境)保持一致;
这些服务永远都是部署master稳定分支,这些服务就是用来被复用的;
假设我们有4个需求并行开发联调,那调用链就是下面这种
上图假设的feature_1只变更了 S1 S3 S4 的服务，那么没有变更的S2 S5就可以直接复用master的稳定服务 M2 M5
上图假设feature_2 只变更了 S3;其余的服务都可以服务稳定版本的服务;
理论可以并行开发联调N个需求
看到上面服务复用的模型,我们来算一个账;
假设最初的时候 一个需求占用一套环境; 一套环境可能部署了N套服务;
想要并行联调Y个需求,那么就需要 N*Y个服务器资源;
用了服务重用之后;同样支持Y个需求占用的服务器资源要远远少的多；
因为每个需求中服务变更的是少数,假如一套环境100个服务,一次需求的变更服务数目一般不超过10个，我们只需要提供变更服务的部署资源就行;
而且不需要完整的重新搭建一套环境,只需要部署变更服务
服务路由隔离
上面介绍的是实现的思路，同一个环境下(指的是同一个zk下注册的服务)
我们要怎么复用这个稳定服务呢？
同一个服务被注册了多个提供者;如何准确的调用对应需求的服务呢？
因为不同的RPC的实现不一样,我这里主要讲解Rpc为dubbo的情况下，如何实现上述需求;
因为文字篇幅过长,故新开一篇文章讲解 Dubbo下的多版本并行开发测试解决方案
调用入口处理
http请求访问
统一网关访问
中间件隔离
配置管理(Nacos、Apollo等等)
消息系统(kafka、RocketMq 等等)
【kafka】kafka的服务复用与隔离设计方案
DB隔离
先占个坑 有空再写 TODO…
