作者：京东物流 赵勇萍

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 的流量管理。

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