兑现 Service Mesh 的新价值：精确控制“爆炸半径”

软件是以持续迭代的方式去不断演进的。某种程度上，我们并不担心软件不完善，但担心软件的迭代速度太慢而影响了完善的速度。在分布式软件领域，如何快速、安全地验证新的软件版本一直是大家所关心并探索的。服务网格（Service Mesh）的出现将这个领域的探索推向了新的高度。“泳道”这一概念在分布式软件领域并非新词，只不过，这次我们是以服务网格为基础技术去构建，充分发挥云原生技术天然具备灵活治理流量的优势。

本文分享了阿里云内部所沉淀的全链路流量打标与路由的能力，做出服务网格技术新体验的同时，很好地兑现了服务网格的新价值。

概念与场景

图 1 以 Istio 官方所提供的 Bookinfo 示例程序为例示例说明了使用场景中的关键概念。其中紫色的圆边方框代表了 Envoy。图中所有泳道的性质是一样的，不同的命名只是为了区分细分场景或用户。

• 基线（baseline）：指业务所有服务都部署到了这一环境中。基线可以来自真实的生产环境，也可以专为开发工作而构建的与生产环境完全独立的环境。
• 流量泳道（traffic lane）：代表了一个与基线环境相隔离的软环境，通过给机器（即 Kubernetes 中的 Pod）打标签的方法，将机器加入到该泳道中。显然，加入泳道的机器在网络层面与基线中的机器是互通的。
• 流量回退（traffic fallback）：泳道中所部署的服务数量并非要求与基线环境完全一致，当泳道中并不存在调用链中所依赖的其他服务时，流量需要回退至基线环境，进一步在必要的时候返流泳道。比如，图 1 中 dev1 泳道中并不存在 productpage 服务所依赖的 reviews 服务，因此需要让流量回退到基线中的 reviews 服务（图中深蓝色线所示），紧接着基线中的 reviews 服务需要将流量打回 dev1 泳道中的 ratings 服务。
• 流量标识透传（traffic label passthrough）：所有服务边上的 Sidecar 都需要有能力将调入请求中所携带的流量标签自动放到由这一请求所分叉出的每一个调出请求中去，以便实现全链路流量标识透传和按流量标识路由，否则泳道与基线间的流量无法来回穿梭。
• 入口服务（entrance service）：指流量进入泳道时所触达的第一个服务。图 1 中代表服务的图形在左边框边上打上三角形标识的就代表它是一个入口服务。

图1

泳道技术可以运用于如下场景：

• 单个服务的日常开发或多个服务间的日常开发联调。开发者建立泳道，将增加了新功能的服务部署到泳道中，基于流量的特征通过定义规则将测试流量引入泳道中进行验证。由于泳道只需部署被测试服务的新版本，省去了搭建全链路测试环境的麻烦。在这一场景中，需要注意测试流量所存在的数据落盘问题，处理好开发与联调过程中所留下的脏数据。
• 全链路灰度。对于涉及重大功能上线中的多个服务，可以通过泳道以全链路灰度的方式做更为全面的功能验证。全链路功能验收通过后，再将服务的新版本发布至基线。
• 关键业务重保。类似零售场景的业务（比如 POS 机收银），我们不希望因为软件的故障而引发巨大的舆情，这时可以通过泳道对业务流量进行隔离实现重保。

技术实现

流量打标方案与实现

在运用泳道技术时，根据流量打标的位置不同而存在三种不同的方案。值得指出，虽然方案有所不同，但就服务网格而言的技术实现是完全一致的，将方案罗