共计 4033 个字符，预计需要花费 11 分钟才能阅读完成。
作者：京东物流 赵勇萍
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 标所示。
- 认证核心接管到申请会到 cookie 生成器中获取用户认证的 cookie, 如图中 2 标所示
- Cookie 生成器会到数据库中读取灰度白名单信息，来确定是否在 cookie 中打灰度标签。如图中 3 标所示。
- 认证核心拿到 cookie 后返回给前端用户，如图中 4，5 标所示。
- 用户带着 cookie 申请业务申请到虚构服务 A. 虚构服务 A 中存在 istio 控制面板下发的的灰度配置信息，通过配置信息，决定以后的申请流量是流入正式环境实例 A 还是灰度环境实例 A。如图中 6，7 标所示。
- 服务 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 基于用户白名单的灰度计划策略
- cookie 中打标签。
通过认证核心，能够实现业务维度的灰度管制，cookie 中会依据用户白名单，进行灰度打标签。Cookie 格局如下：
cookie:tenantGray=0;rememberMe=;channel=*
当 tenantGray= 0 时，示意以后用户不是灰度用户，当 tenantGray= 1 时，示意以后用户是灰度用户。
- 当抉择依据 cookie 动静配置灰度服务时，依据选中的服务，virtualService 配置如下：
如图所示，当申请的 cookie 信息匹配到 tenantGray= 1 时，依据 istio 的虚构服务规定，走 test-A.gray.svc.cluster.local 路由，而后申请会打到灰度环境的服务实例上。当 tennatGray= 0 时，依据 istio 的虚构服务规定，走 test-A.prod.svc.cluster.local 的路由，而后申请会打到正式环境的服务实例上。
- 如果用户抉择依据灰度标签进行灰度计划抉择，配置计划如下：
在 k8s 集群中咱们之前创立灰度服务的 deployment 时，过后减少过一个标签，标签为 profile: pray，用来标记该服务为灰度服务。
如图所示配置，match 条件为，当申请起源是来自带有灰度标签的 deployment 服务时，走 test-A.gray.svc.cluster.local 路由，而后申请会打到灰度环境的服务实例上。反之，走 test-A.prod.svc.cluster.local 的路由，而后申请会打到正式环境的服务实例上。
- 而后把所有须要灰度公布的服务对应的 vistualService 的配置信息通过 jenkins 的自动化流程下发到 k8s 集群中。
2.4 依照流量百分比的灰度计划
当咱们的业务场景不须要针对具体的用户进行灰度时，尤其是咱们只是在肯定范畴内做 A /Btest, 这样的话，咱们能够更改配置信息，实现业务的依照流量比例进行灰度管制，具体的配置 virtualService 计划如下：
2.5 灰度拉平线上的负载平衡计划
该灰度计划比拟明确，就是当该服务不再须要灰度时，为了不节约服务器资源，将灰度服务跟线上服务代码拉平，而后通过流量治理，正式环境的流量实现负载平衡的目标。假如灰度服务跟正式服务的服务实例数比率为 1:1，具体 virtualService 配置如下：
2.6 微服务灰度公布治理计划
家喻户晓，对于单体利用来说，灰度公布只须要对繁多服务进行灰度管制就会要了。然而到了微服务框架下，会存在泛滥服务，服务之间存在简单的网络拓扑关系，所以当咱们进行服务的灰度公布时，须要管制服务之间的灰度调用关系，实现灰度公布的服务治理性能，解决了微服务框架下动静治理多服务之间的灰度计划串联问题。
以下举例三种不同的灰度治理场景。
下图实例场景是，服务 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 的流量治理。
灰度拉平 ：是指将正式环境的服务代码跟灰度环境的服务代码拉成统一的。