微服务的灾难：折磨人的环境！

  一般来讲，在拆分为微服务后。经历一段时间的业务规模发展后，我们的服务都是具有比较多的依赖。像是：

  我们发现业务初始依赖的是 ServiceA，结果跑了一段时间后。服务依赖慢慢的变多，还出现了更进一步依赖，Service A 依赖 B、C，他们背后又调用了一大堆的服务。

  同时 ServiceA 依赖的服务，还存在跨业务组的情况，也就是一个普通的业务调用，可能关系到多个业务组的协调：

  说明小咸鱼作为业务组 A 的维护方，他所依赖的业务团队正在不断地增大，大家都在用力产生新的服务依赖。

  假以时日，这个服务的依赖必然变的非常多（不过，小咸鱼并没意识到这一点）。

  终于，在小咸鱼维护了一段时间后。这一个业务产品，成功走过了尝试期。他有了好几位新同事，在迭代的过程中，联调的诉求出现了。

  小咸鱼辛辛苦苦的找了其他几个组，让大家都往上面 Push 自己的服务，解决了这一个迭代的联调的问题。

  但，好景不长。业务压力总是大的，大家都维护着复数的 f 分支。这时候就遇到了新问题：

  好家伙，在同一个集成开发环境中，大家期望依赖的服务版本压根不一样。联调起来挺费劲，甚至存在一些风险。

  例如：你在开发环境，联调时你以为你依赖的 ServiceB 的 v0.2.0 版本，跑的也好好的。结果其实别的业务在晚上把他更新为 v0.5.0 版本了，接口还是兼容的，但内在逻辑是变了的。当然，你也未曾发现这样的一个问题，因为是 “细微” 的修改。

  但上到测试环境后，很快就会出现被测试同学打回来的情况。以此往来多了，你就会成为团队里质量不好的那一位 TOP1 了...

  若只是基础底蕴不够深厚，钞能力也不够的，一般会采取 dev 分支合并的方式。也就是在 ServiceA 上建立 dev 分支，专门用于集成开发环境。由开发同学配合脚本等，来维护和应用。

  虽然有可能会出现不同分支，影响到同一块的内容。但由于同一个 Service 一般会由 1~3 个人（小团队）经手维护，都坐在附近，基本能控制冲突。

  甚至有的小伙伴，为了谨慎起见。合并前会反向合并到自己 f 分支，再跑一遍自己的自动化接口测试，以确保正确。

  当然，测试环境是相同的问题。在业务迭代的过程中，常常有多个功能在同时开发，会拉多个分支。

  轮流使用测试环境，要把不同功能的分支代码合到某个分支再统一解冲突，再联调和测试。

  说白了，可能还要多套环境来解决。当你期望是某一个泳道用来发布某一个特性分支时。对应的发布系统就会给其相关联的组件打上泳道标识，自然也就能知道依赖的是谁了。

  一般客户端会带上泳道标识的 Header，再一路透传下去。所有相关 Proxy 会根据 Header 内的标识进行选择。

  考虑到有的服务在功能特性中并没有变更，因此会有 master 和功能泳道的区别，会再根据 Proxy 的规则进行选择。

  微服务化后，N 个服务如何联调，就是开发人员的一个大头疼问题。而人一多，业务压力一大，非常有可能会出现一个服务同时多个分支并行开发的情况。

  也就会导致开发、测试环境同一时间遇到这个烦人问题，我们大家可以通过公共分支，又或是多泳道的方式解决。

  多泳道环境，需要的基础设施建设较多，同时 MySQL、Redis 等公共介质也是一个问题，成本也是运维的一个考虑因素。