泳道特性
对服务调用链按需求进行分组，并实现逻辑、物理隔离，使得不同分组的服务调用链运行在互相隔离的机器上，互不影响。每一条调用链就好像游泳池中间的泳道。
image.png
1.请求根据泳道标识，在服务发现的时候，优先调用本泳道内的实例，如果本泳道内没有该服务的实例，则fallback回主泳道
2.泳道之间是一定不会互相调用的
泳道的价值和优势
价值：
1.硬件成本：比如部署3套测试环境，我们就能提供一套稳定的测试环境+2套分支测试环境，支持一个服务的2个需求同时测试。这意味着需要有3套完整的测试环境。在泳道环境下，只有和被测需求相关的调用链上的服务才需要在泳道中额外部署，大部分服务不需要额外部署。而且需求测试完成后，泳道可以被回收。因而增加的成本较部署完整的测试环境要少的多。
2.运营成本：多套环境中运行的服务和依赖的数据是需要维护的。特别是数据，多套环境中的数据维护成本是巨大的。
优势：
1.并行测试。（因此可以根据测试需要，部署不同分支的服务分组，多个泳道并行，多个服务/多个版本可同时提测）
2.提供稳定的骨干链路。（保证整个测试流程始终能正常运行）
3.错误隔离。（泳道内的服务发生异常，不会影响其他泳道）
泳道搭建关键点
1.流量路由机制
2.环境管理【需要有一个面板，看到整个系统中存在哪几个泳道，哪个泳道下有哪几个服务】
3.资源回收【要设置合理的回收机制，否则忘记释放资源将导致极大的浪费，某团是每次申请给一个固定时间，到期自动删除，可以按需续期】
4.底层存储是否需要隔离，比如mysql，redis等，一般场景下是不需要隔离的
1.特殊路由标识：header：x-rpc-lane
2.需要基础的支持：包括网关，rpc【包括服务发现】，存储，消息队列，按需支持
泳道搭建方式
现在开源的服务发现组件，比如etcd，consul，都是支持在服务注册的时候进行打tag的，在rpc框架进行调用的时候，加一个判断，优先找同tag的实例进行调用就好了，实现起来不是很难。
比较困难的是做一个直观的管理平台，以及资源的及时回收。
泳道强依赖公司基建，一般公司基建都是支持跨集群调用的，如果实在不行，只能手动配置多集群,手动管理，手动回收释放
