文章首或尾句需要带关键词“ 本文正在参加「金石计划」 ”
前言
1、洗完澡，我打开某王者准备happy一下，忽然想起最近想写的一篇文章，还是忍住了放下文章，好好写手机，哈哈～ 之前搞过全链路灰度，没想到可以啃老本用来建设开发环境多泳道，有意思。
2、在个人成长中，我觉得自己不是一个天赋选手，但是是一个成长很快的人，未来应该是一个大器晚成的家伙哈哈哈，我认为里面悟性还是起到很大的作用，触类旁通，里面的坚持也是不可或缺。
3、最近跟朋友聊技术，当我介绍了一个相对比较大型的技术项目的时候，我说整个项目都是我一个人完成，那一瞬间他很惊讶，是啊干有意义的事可以带来成就感。我的理念是从一个功能点，然后去拓展成体系，再根据实际场景进行细化调整。
多泳道建设
之前是有写过类似的文章： 听过多泳道吗？赶紧进来看看它怎么建设的~ ，但是实际应用起来有很多很多细节。就像王阳明的知行合一，即使你了解很多，但是在实践的时候会发现很多细节需要调整，又或者实际应用场景不同导致细节不一样。
我大概讲下之前的内容，目的就是建设多个泳道，其中包括基础环境，主要是多个项目并行测试、联调，一些公共服务则放在基础环节，这样可以节省服务资源。里面涉及的技术点：流量染色、流量规则、流量负载、变量透传、服务治理。
流量染色：这个可以实现很多功能，比如说灰度流量，还有流量录制回放的那种测试流量染色，还有压测流量染色，ab test流量染色，这项技术应用很广泛，难点其实是规则治理，就是这么多场景他们染色规则怎样的。
流量规则：这里需要参考阿里的openSergo规范，就是3块，what+how+rollback，举个灰度的例子：什么是灰度流量（可以是某些用户、某个组织、某些平台），灰度流量怎么走（南北流量从网关到a服务那个版本，再到b服务哪个版本），如果没有对应的服务节点或者说没有配置流量走向，默认走回基础环境。
流量负载：这个比较重要的是算法，比如随机、轮训、权重、根据服务节点性能负载、还有dubbo根据启动时间去负载，（服务起来的时候因为边执行边编译，所以起来那会没有响应那么快，所以给的流量也会少一些）。这里也涉及到服务注册中心，比如说zk、nacos，从里面拿到对应的服务列表（serviceid、IP：port、metadata）对这些进行筛选负载。
变量透传：这玩意是apm的东西，所以思想是能被迁移的，但是技术可能会被颠覆，触类旁通蛮重要的。
服务治理：当多泳道的时候，服务就会有多个版本，对应的接口也会多个版本，前端应用也可以切换不同的调试版本，那么这个版本号是怎么设计的，服务怎么分组的，这些都是重点。
业界方案
我之前搞全链路灰度的时候，看了很多很多文章，其中很多公司都是基于阿里MSE微服务引擎来搞，我谈下我的理解，MSE是流量网关+服务治理，它集成cicd，就是我们上面讲的服务治理那块，在构建的时候会把节点打上对应的标签，其次在网关层已经把流量染色、流量规则做得挺完善的了，然后变量透传，再到本地服务改造通过agent挂载来改变字节码进行流量负载。
有钱当然还是买买买，实践比较香的，成熟的产品谁不喜欢呢，哈哈哈
开发环境多泳道建设
前面介绍了大部分的多泳道建设，接下来讲讲我搞的开发环境多泳道吧。
背景是这样的，就是我们在联调阶段，一般是前端本地跟后端云节点联调，一旦出现问题，后端需要频繁改代码联调，那么我的想法是直接把流量导入到你本地进行调试，这样效率最高的。
我们做法：参照上面的实现，首先服务治理方面，我们本地节点会有特定标识，这里可以是对应研发同学英文简称，如果是v1、v2那这样会导致冲突情况，流量负载方面，我们是在网关层基于nacos去做流量染色、流量负载，这是前后端联调场景。如果是后端跟后端联调，我们采用简单的方式，就是直接通过环境变量来配置ip：port来联调。当然我也想过通过sdk来集成到服务，当时有个同学提醒我说：如果方案太麻烦或者比较复杂，就会越少同学去使用，所以我们前期主打简单快捷好用，哈哈哈
不足：我们方案没有集成cicd，也就是说本地关机了，那这个调试版本的服务就没了，当然在我们目前的调试场景可以接受的，比如说建设测试环境的多泳道，应用场景就不同，技术方案也会不一样。第二个不足是简化后端的联调，我们场景是点对点的联调，但实际上链路上会有很多点，这时就需要把染色进行rpc上透传，这个在我们方案目前没有做，主要考虑简化快捷效果。
最后总结
洋洋洒洒又是输出了快2k字，哈哈，业界的方案基本基于k8s节点打标，还有ingress、istro来流量负载、灰度，但是呢里面细的功能，比如说流量规则，灰度流量具体怎么走，还是需要在应用层去实现，所以MSE比较好的结合两者，它的通用性比较强的。
那么我们自研的方案对具体场景做了细化，考虑到用户体验，当然我们也从中学习到很多技术，满满的成就感，最后读万卷书，不如行千里路，撸起袖子干吧少年～
