如何理解灰度发布

服务升级机制
  在项目敏捷开发的过程当中，不可避免须要快速、安全的更新应用，目前比较流行的几种部署方案有: 滚动发布、灰度发布/金丝雀发布和蓝绿部署。

滚动发布（目前某银行内部生产环境交易系统的发布方式）：

  通常是取出一个或者多个服务器中止服务，执行更新，并从新将其投入使用。周而复始，直到集群中全部的实例都更新成新版本。

  这种部署方式相对于蓝绿部署，更加节约资源——它不须要运行两个集群、两倍的实例数。咱们能够部分部署，例如每次只取出集群的20%进行升级。

这种方式也有不少缺点，例如：

没有一个肯定OK的环境。使用蓝绿部署，咱们可以清晰地知道老版本是OK的，而使用滚动发布，咱们没法肯定。

修改了现有的环境。

若是须要回滚，比较麻烦。举个例子，在某一次发布中，咱们须要更新100个实例，每次更新10个实例，每次部署须要5分钟。当滚动发布到第80个实例时，才发现问题，须要回滚。此时，脾气很差的运维人员极可能想掀桌子，由于回滚是一个痛苦，而且漫长的过程。

有的时候，咱们还可能对系统进行动态伸缩，若是部署期间，系统自动扩容/缩容了，咱们还需判断到底哪一个节点使用的是哪一个代码。尽管有一些自动化的运维工具，可是依然使人心惊胆战。

并非说滚动发布很差，滚动发布也有它很是合适的场景。

灰度发布（又名金丝雀发布）

 

PS：矿井中的金丝雀
17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会中止歌唱；而当瓦斯含量超过必定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀做为“瓦斯检测指标”，以便在危险情况下紧急撤离。

 

是指在黑与白之间，可以平滑过渡的一种发布方式。 在其上能够进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，若是用户对B没有什么反对意见，那么逐步扩大范围，把全部用户都迁移到B上面来。–维基百科

  灰度发布中，经常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。不一样版本应用共存，常常与A/B测试一块儿使用，用于测试选择多种方案。这里举一个灰度发布比较典型的例子：

  咱们但愿上线一个PLMP系统的新的功能，须要修改dlp-personal服务，可是只有咱们本身的用户limoumou验证经过后才能给全部用户使用。

线上正在运行服务 dlp-personal-A，新部署一个服务 dlp-personal-B，使用新版本的Image和ConfigMap

去负载均衡器页面修改转发规则，新增 header 转发规则将 token=liweiwu 的流量分配给 dlp-personal-B，剩余流量给 dlp-personal-A

登陆 liweiwu 用户进行相关测试，发现问题进行修改并更新 dlp-personal-B 的Image和ConfigMap，直至验证经过

修改 dlp-personal-A 的Image和ConfigMap与 dlp-personal-B 一致

删除负载均衡器上的转发规则，全部流量指向服务 dlp-personal-A

删除服务 dlp-personal-B

Blue/Green Deployment（蓝绿部署）

蓝绿部署无需停机，而且风险较小。

旧版本的应用（一开始的状态）

全部外部请求的流量都打到这个版本上。

部署新版的应用

新版本的Image或ConfigMap和旧版本不一样

将流量所有从旧切换到新版本上。

测试

如新版本测试正常，就删除旧版本正在使用的资源（例如实例），今后正式用新版本。

从过程不难发现，在部署的过程当中，咱们的应用始终在线。而且，新版本上线的过程当中，并无修改老版本的任何内容，在部署期间，老版本的状态不受影响。这样风险很小，而且，只要老版本的资源不被删除，理论上，咱们能够在任什么时候间回滚到老版本。可是须要指出的是，这种方式会占有更多的资源。

我司的灰度发布
发布策略的设定由规则和权重分配组成。具体功能描述以下：

 

 

图 1 灰度发布的策略和规则

规则集：

转发规则和服务分离

每一个 policy 分为两部分，第一部分为匹配规则集合部分，第二部分为权重部分，每一个请求当知足第一部分的匹配规则后按照第二部分的权重将流量转发到多个服务，若是权重部分只有一个服务则百分之百转发到一个服务。

一条 policy 中能够有多个规则，规则之间是 and 关系

不一样 policy 之间存在优先级，请求匹配了第一个 policy 则不会再匹配第二个 policy

我司的蓝绿发布
  蓝绿部署能够做为灰度发布权重规则的一种特殊形式，经过调整两个服务的请求量比例来控制线上是蓝版本仍是绿版本。经过设置权重 X 为 100 或者 0 来达到蓝绿切换。

 

 

目前支持的策略集合
域名分配：

域名值能够是单个域名或者一个域名列表

权重分配：

A 服务分配 X% 流量，B 服务分配剩余 （1-X）% 流量

URL 分配：

URL 值能够是一个单独字符串，或者一个字符串列表，或者正则表达式

IP 分配：

    源 IP 属于某一指定 IP 集合的流量分配给服务 A，其他流量分配给服务 B，能够为单个 IP，IP 列表或者 IP 范围

URL param 分配：

    根据 url 某一个参数值的范围进行分配，例如 url 包含参数 uid=1 的流量分配给服务 A，其他流量分配给服务 B，param 值能够为单个值或者字符串列表

Header 分配：

    根据某一 header 值的范围进行分配，例如 header 包含 agent=chrome 流量分配给服务 A，其他流量分配给服务 B，header 值能够为单个值或者字符串列表

客户场景的灰度发布

 

 

说明：

应用管理员提交本身应用的灰度发布 双人复核工单。
复核人员，审批经过。
应用管理员在工单列表里找到审批经过的工单，页面中点击继续，进入应用更新的页面，提交后当即更新应用。回到双人复核工单页面。
应用管理员在工单列表里找到刚刚操做的工单，页面中点击继续，进入ALB的设置页面，提交修改后，立刻更新ALB。
测试新的应用（项目组一块儿确认，由复核人员确认是否无误）
如确认版本无误，由应用管理员在双人复核工单列表里找到刚刚操做的工单，页面中点击继续，最后一次更新应用；如版本有误，由应用管理员在双人复核工单列表里找到刚刚操做的工单，页面中点击继续，回到第3步。
删除ALB的转发规则
结束流程。

 

 

 

 

————————————————原文连接：https://blog.csdn.net/xialingming/article/details/83348382