作者：京东物流 赵勇萍
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的流量治理。
灰度拉平：是指将正式环境的服务代码跟灰度环境的服务代码拉成统一的。