本文转载自微信公众号《我的脑子是炸鱼》，作者陈建宇。转载本文请联系脑筋急转弯公众号。大家好，我是炸鱼。我有一个好朋友，小鲜鱼。他们在经历了servicesplitting《微服务的灾难：拆的很爽，但服务太小》颠簸之后，因为一个人负责N多个service，又开了更多的IDE，加班到深夜。如果服务中写错了操作和逻辑，就会发生事故。然后，在小闲鱼的Leader的带领下，在会议室里吵了好几轮之后。最后重新编排设计了一个版本的服务边界，分分合合，把原来拆掉的合并起来，增加新的服务组合。于是，小咸鱼又可以开开心心的helloworld了。这就是意外驱动发展的力量吗！然而，这两天我并不开心。遇到新问题了。。。服务依赖一般来说，拆分成微服务后。经过一段时间的业务规模化发展，我们的服务有了更多的依赖。例如：一个服务依赖于其他多个服务。我们发现业务最初依赖ServiceA，但是运行一段时间后。服务依赖越来越多，依赖更进一步。服务A依赖于B和C，他们背后又调用了很多服务。同时，ServiceA所依赖的服务也存在跨业务组的情况，即一次普通的业务调用，这可能与多个业务组的协调有关：一次调用涉及3个业务组，虽然从图上看，只有3个业务组。然而，一个月前，他们还都是自食其力。说明小鲜鱼是A业务组的维护者，他所依赖的业务团队在不断增加，每个人都在尝试产生新的服务依赖。久而久之，这个服务的依赖必然会变得非常大（不过小闲鱼并没有意识到这一点）。开发环境终于好了，经过小闲鱼维护了一段时间。该业务产品已顺利通过试用期。他有几个新同事，在迭代过程中，出现了联合委托的要求。小闲鱼很快利用组织内的公共开发环境搭建服务：公共开发环境小闲鱼努力找了其他几个群，让大家推自己的服务来解决这个迭代问题。联调问题。然而，好景不长。业务压力总是很大，每个人都维护着多个f分支。这时候又遇到了一个新的问题：不同的业务组期望依赖不同的业务组A，他们期望依赖：ServiceA:v0.1.0。服务B：v0.2.0。服务C：v0.3.0。业务组B期望依赖于：ServiceA：v1.1.0。服务B：v1.2.0。服务C：v1.3.0。好家伙，在同一个集成开发环境下，大家期望依赖的服务版本是完全不一样的。联调相当费力，甚至存在一定的风险。例如：在开发环境中，联调时认为依赖的ServiceBv0.2.0版本运行良好。结果其他商家晚上居然把他更新到v0.5.0版本。接口还是兼容的，只是内部逻辑变了。当然，你没有发现这个问题，因为它是一个“微妙”的修改。但是去了测试环境之后，很快就会出现测试同学给你回电话的情况。如果你和这个互动多了，你就会成为团队中质量差的头号人物。。。这个问题怎么解决？解决方案针对的是微服务架构下的开发环境，核心还是要看公司的基础设施建设的怎么样。如果公有的dev分支只是底子和财力不够深，一般会采用合并dev分支的方式。即在ServiceA上创建一个dev分支，专门用于集成开发环境。开发同学配合脚本等进行维护和应用。虽然很容易出现不同的分支，影响同一个block的内容。但是由于同一个Service一般由1到3个人（小团队）维护，都坐在附近，所以冲突基本可以控制。甚至有些朋友，为了谨慎起见。合并前会反向合并到自己的f分支，再次运行自己的自动化接口测试，确保无误。当然，测试环境也是一样的问题。在业务迭代过程中，往往会同时开发多个功能，会拉取多个分支。如果只有一套开发和测试环境，那就意味着时间必须在团队内部协商。轮流使用测试环境，需要将不同功能的分支代码合并到某个分支中，然后统一解决冲突，然后联调联测。这个方案只能治标不治本。说白了，多车道的环境，可能还是需要多个环境来解决。当您期望使用某个泳道来发布某个功能分支时。对应的发布系统会为其关联的组件打上泳道标记，自然知道依赖的是谁。如下图所示：一个服务中有多个泳道。一般client会带上header和laneidentification，然后一路透传。将根据标头中的标识符选择所有相关代理。考虑到部分服务的功能特性没有改变，master和functionalswimlane会有区别，会根据Proxy的规则进行选择。当然这也可以结合服务发现机制来做，就看技术选型的差距了。总结了微服务后，如何联合调试N个服务是开发者比较头疼的问题。但是，当人多，业务压力大的时候，很可能一个服务会被多个分支机构同时并行开发。也会导致开发和测试环境同时遇到这个恼人的问题。我们可以通过公共分支机构或者多条泳道来解决。但两者都有不同程度的劣势：公共环境需要公共分支，需要一定程度的人为干预。多车道环境需要更多的基础设施建设。同时，MySQL、Redis等公有媒体也是一个问题，成本也是运维的考虑。没有解决方案是绝对的灵丹妙药。
