小编点评

**2.1 基于用户白名单的灰度方案策略** 1. 创建cookie中打标签。通过认证中心，可以实现业务维度的灰度控制，cookie中会根据用户白名单，进行灰度打标签。 **2.2 按照流量百分比的灰度方案** 1. 当我们的业务场景不需要针对具体的用户进行灰度时，尤其是我们只是在一定范围内做A/Btest,这样的话，我们可以更改配置信息，实现业务的按照流量比例进行灰度控制。 **2.3 灰度拉平线上的负载均衡方案** 2. 假设灰度服务跟正式服务的服务实例数比率为1:1，具体virtualService配置如下： ``` virtualService: ... selector: matchCondition: ... ... ``` **2.4 按照流量百分比的灰度方案** 2. 具体virtualService配置如下： ``` virtualService: ... selector: matchCondition: ... ... ... ``` **2.5 微服务灰度发布治理方案众所周知** 对于单体应用来说，灰度发布只需要对单一服务进行灰度控制就会要了。但是到了微服务框架下，会存在众多服务，服务之间存在复杂的网络拓扑关系，所以当我们进行服务的灰度发布时，需要控制服务之间的灰度调用关系，实现灰度发布的服务治理功能，解决了微服务框架下动态管理多服务之间的灰度方案串联问题。 **2.6 总结** 通过本次基于Istio的灰度方案的实践，最大感触就是基于服务网格的第二代微服务架构的优秀潜力。Service Mesh对流量的管理可以下沉至运维维度，并且灵活度是第一代微服务架构不可比拟的。通过这次时间，很好的解决了笔者现实业务中的灰度发布问题，实现了通过配置自动化下发，无代码侵入，实现动态切换等多种灵活策略。

正文

作者：京东物流 赵勇萍

1. 背景介绍

灰度发布，又名金丝雀发布，是指能够平滑过渡的一种发布方式。基于系统稳定性和快速业务迭代的综合考虑，业务应用开发团队采取了新版本服务灰度上线的方式，即新版本服务并非全量发布到线上环境，而是发布少数几个实例进行灰度验证，没有问题后再全量发布。在部分核心服务进行接口升级和逻辑迁移时，还会通过在业务逻辑代码中增加黑白名单或者流量百分比控制的方式，逐步将旧版本接口实现迁移至新版本接口实现。尤其是对于toB业务和SAAS类平台，很多情况需要根据租户或用户维度进行灰度控制，实现业务上的A/Best功能。

对于之前我们业务中实现的传统的灰度发布， 较好地权衡了服务稳定性和业务迭代效率，但仍存在以下问题：

a. 系统侵入性强，业务开发人员在服务接口中编码大量与业务逻辑无关的黑白名单或流量百分比控制代码。

b. 当新版本接口出现波动或异常，通常需要业务团队通过紧急修改代码和紧急发布，来更新黑白名单和流量百分比控制策略，时间较长，业务影响较大。

c. 调整黑白名单或流量控制百分比，需要业务团队发布代码或者接入动态配置中心，过程复杂、可复用性差、操作灵活性差.

d. 对于单体应用来说，灰度发布方案实现还算简单，但对于微服务应用，每次发布版本可能不是全部服务需要灰度发布，实现微服务灰度发布的原子维度控制，也是导致微服务框架下灰度方案不能很好落地的原因。

笔者实际业务项目（采灵通系统）采用的是微服务的架构设计，总计服务个数60+，技术底座采用K8s+Istio的服务治理方案。如果采用传统的灰度发布方案，每个服务上下游依赖过多，相对于传统的灰度发布方案，并不能很好满足业务诉求。因此，探索了一条基于Istio的服务流量治理方案下的灵活可配置的灰度发布方案。

2. 方案详情

先上一个方案简介图：

 

本发明的技术方案以k8s服务部署为基础，以istio服务流量治理为核心，以Mysql为数据存储，同时结合jenkins的自动化部署方案，可以实现低成本动态的高效微服务发布方案，并且带业务服务无代码侵入。

本发明的技术方案以activiti开源工作流引擎为基础, 以Mysql作为数据存储, 通过自定义的一套规则引擎框架, 可以实现流程规则的的快速搭建和动态修改功能.

a. 如图所示，k8s management实现对服务的pod管理，在k8s管理中，正式环境和灰度环境分别隶属两个命名空间，通过deployment实现服务的创建，创建中，灰度和正式的pod实例会打上prod或gray的标签。Deployment创建过程通过jenkins管理，可以实现部署的自动化流程。具体deployment配置方案详情请跳转至3.2.2

b. 如图所示，istio控制平面可以创建虚拟服务，通过对虚拟服务的路由策略的配置不同，可以实现不同的灰度策略，配置下发通过jenkins管理，可以实现配置的自动化下发。具体策略详情请跳转至2.1

c. 如图所示，具体业务请求实现流程如上：

1. 用户首先需要登录请求，请求发动到我们自建的认证中心服务中。如图中1标所示。

2. 认证中心接收到请求会到cookie生成器中获取用户认证的cookie,如图中2标所示

3. Cookie生成器会到数据库中读取灰度白名单信息，来确定是否在cookie中打灰度标签。如图中3标所示。

4. 认证中心拿到cookie后返回给前端用户 ，如图中4，5标所示。

5. 用户带着cookie请求业务请求到虚拟服务A.虚拟服务A中存在istio控制面板下发的的灰度配置信息，通过配置信息，决定当前的请求流量是流入正式环境实例A还是灰度环境实例A。如图中6，7标所示。

6. 服务A中存在调用服务B的业务逻辑，所以服务A会请求到虚拟服务B中，虚拟服务B中存在istio控制面板下发的的灰度配置信息，通过配置信息，决定当前的请求流量是流入正式环境实例B还是灰度环境实例B。如图中8标所示。

通过以上8个步骤,我们完成了灰度方案下的流量管控，该方案对于业务服务A和业务服务B无任何代码侵入，同时，灰度的配置方案可以实时快速的通过jenkins管理页面进行自动化下发，实现灰度发布的动态灵活切换.

至于灰度环境的低成本，当代码完成灰度拉平线上后，通过更改灰度下发策略，可以实现灰度环境和正式环境的负载均衡，共同承担正式环境的业务流量，保证了灰度环境的主机资源不会被浪费。

2.1 k8s Management管理

在k8s管理方面，要创建两个命名空间，一个是prod环境，一个是gray环境，通过命名空间隔离正式环境和灰度环境资源，主要原因是可以更好的管理。当然此处并不强制。同时，需要配置一下deployment的标签项，在标签项增加一个profile键，根据场景，profile可以配置为prod和gray，具体配置demo如下图所示。

 

2.2 基于istio灰度整体配置方案

 

灰度整体方案流程图如上图所属，该流程图中主要分为三大整体方案，包括：基于用户白名单的灰度方案，按照流量百分比灰度方案，灰度拉平线上的负载均衡方案。以上灰度环境可以满足之前提到的多场景，低成本，动态，无侵入的灰度方案要求。

以下2.3，2.4，2.5将分别详细介绍三种灰度方案的具体配置策略。

2.3 基于用户白名单的灰度方案策略

 

1. cookie中打标签。

通过认证中心，可以实现业务维度的灰度控制，cookie中会根据用户白名单，进行灰度打标签。Cookie格式如下：

cookie:tenantGray=0;rememberMe=*************;channel=****

当tenantGray=0时，表示当前用户不是灰度用户，当tenantGray=1时，表示当前用户是灰度用户。

2. 当选择根据cookie动态配置灰度服务时，根据选中的服务，virtualService配置如下：

 

如图所示，当请求的cookie信息匹配到tenantGray=1时，根据istio的虚拟服务规则，走test-A.gray.svc.cluster.local路由，然后请求会打到灰度环境的服务实例上。当tennatGray=0时，根据istio的虚拟服务规则，走test-A.prod.svc.cluster.local的路由，然后请求会打到正式环境的服务实例上。

3. 如果用户选择根据灰度标签进行灰度方案选择，配置方案如下：

 

在k8s集群中我们之前创建灰度服务的deployment时，当时增加过一个标签，标签为profile: pray，用来标记该服务为灰度服务。

如图所示配置，match条件为，当请求来源是来自带有灰度标签的deployment服务时，走test-A.gray.svc.cluster.local路由，然后请求会打到灰度环境的服务实例上。反之，走test-A.prod.svc.cluster.local的路由，然后请求会打到正式环境的服务实例上。

4. 然后把所有需要灰度发布的服务对应的vistualService的配置信息通过jenkins的自动化流程下发到k8s集群中。

2.4 按照流量百分比的灰度方案

 

 

 

当我们的业务场景不需要针对具体的用户进行灰度时，尤其是我们只是在一定范围内做A/Btest,这样的话，我们可以更改配置信息，实现业务的按照流量比例进行灰度控制，具体的配置virtualService方案如下：

 

2.5 灰度拉平线上的负载均衡方案

 

该灰度方案比较明确，就是当该服务不再需要灰度时，为了不浪费服务器资源，将灰度服务跟线上服务代码拉平，然后通过流量管理，正式环境的流量实现负载均衡的目的。假设灰度服务跟正式服务的服务实例数比率为1:1，具体virtualService配置如下：

 

2.6 微服务灰度发布治理方案

众所周知，对于单体应用来说，灰度发布只需要对单一服务进行灰度控制就会要了。但是到了微服务框架下，会存在众多服务，服务之间存在复杂的网络拓扑关系，所以当我们进行服务的灰度发布时，需要控制服务之间的灰度调用关系，实现灰度发布的服务治理功能，解决了微服务框架下动态管理多服务之间的灰度方案串联问题。

以下举例三种不同的灰度治理场景。

a.以下实例场景是，服务A采用基于灰度白名单的灰度策略，服务B采用灰度拉平线上的灰度策略，然后服务A访问服务B，可以实现服务A的灰度发布，服务B为正式环境。

 

b. 下图实例场景是，服务A采用基于灰度白名单的灰度策略，服务B采用基于服务灰度标签的访问策略，然后服务A访问服务B，可以实现灰度服务A的流量访问灰度服务B，正式服务A的流量访问正式服务B。

 

 

c. 图实例场景是，服务A采用基于流量比率的灰度策略正式环境和灰度环境的比率为8:2，服务B采用基于灰度白名单的灰度策略，然后服务A访问服务B时，在灰度白名单中的用户，在灰度服务B，不在灰度白名单中的用户，走正式服务B。

 

3. 总结

通过本次基于Istio的灰度方案的实践，最大感触就是基于服务网格的第二代微服务架构的优秀潜力。Service Mesh对流量的管理可以下沉至运维维度，并且灵活度是第一代微服务架构不可比拟的。通过这次时间，很好的解决了笔者现实业务中的灰度发布问题，实现了通过配置自动化下发，无代码侵入，实现动态切换等多种灵活策略。

4. 名词解释

k8s：kubernates的简称。k8s是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制

istio：Istio 是一个开源服务网格，它透明地分层到现有的分布式应用程序上。

负载均衡：意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行

virtualService：istio内置的一种配置类型，叫做虚拟服务，可以设置单独的路由指向。通过virtualService可以实现istio的流量管理。

灰度拉平：是指将正式环境的服务代码跟灰度环境的服务代码拉成一致的。