作者：凯文 @开源Favorer

在单体应用时代，我们进行应用的灰度发布一般都是通过负载均衡器（例如Nginx、Haproxy等）分发10%-20%的流量进行一段时间的业务功能验证，当然，同时也关注非功能的运行情况。

我们为什么需要流量染色技术

随着近些年微服务的兴起，大量的单体应用被重构为若干个微服务，这些微服务通常需要协同工作才能完成某一业务流程。在这种情况下，原有的单纯依靠负载均衡器分发流量就变得不够用了。

流量染色示意图

如上图所示，假定我们的微服务有4个，存在1到4的顺序调用关系，当我们对其中的服务2和服务4升级时，需要确保流经了服务2升级版本的请求也要流经服务4的升级版本，这种情况下，我们显然无法单独依靠分拨流量来达成目标。那么怎么做到呢？对请求打标机就是一个很自然的想法，我们把这一行为称之为流量染色。

如何进行流量染色

从负载均衡器到微服务

要达成这一目标的办法有很多，这里我们介绍主流的做法。从外部请求访问微服务，我们通常基于cookie、header、body体参数来进行标记，通过cookie信息和header头信息进行流量分发，是我们的负载均衡器和微服务都能做到的事情，通过body体参数进行流量分发，负载均衡器则无能为力。

从微服务到微服务

从微服务到微服务，我们一般有两种体系，即restful与rpc两种。

基于restful的微服务要进行流量标记转发，通常需要做两件事情，一是对服务进行标记，一是对流量进行标记。对服务进行标记通常的做法是引入ribbon-discovery-filter-spring-cloud-starter，在服务配置上声明TAG标签，这是我们从同一个名称的新旧两个服务中挑出新服务的依据。对流量进行标记即在请求中添加标识，通过openfeign组件的@feignClient注解时，对调用服务指明TAG标签即可挑选出对应的服务。

对于rpc 框架的微服务，我们以grpc为例，其做法是通过metadata来标识微服务，从而在请求方和服务方上进行关联。小编听说“网易轻舟微服务”对grpc框架进行流量染色进行了很好的封装，有用过的请告诉小编体验如何。

从微服务到数据库

从微服务到数据库这一块基本没什么太多麻烦的，关键看如何处理染色的请求，通常做法包括落到专用库或同库对记录打标签，这在代码处理上没有任何难度。

当然，流量染色作为一项基本功能，应属于基础设施，与业务人员的编码相剥离才算理想，于是我们就迎来了serviceMesh时代，想要和小编一起学习serviceMesh框架吗？欢迎留言。