如何理解全链路蓝绿灰度发布
蓝绿发布 Blue-Green Deployment
① 概念
不停机旧版本，部署新版本，通过用户标记将流量在新版本和老版本切换。属无损发布
② 优点
新版本升级和老版本回滚迅速。用户可以灵活控制流量走向
③ 缺点
成本较高，需要部署两套环境（蓝/绿）
灰度发布 Gray Release（又名金丝雀发布 Canary Release）
① 概念
不停机旧版本，部署新版本，高比例流量（例如：95%）走旧版本，低比例流量（例如：5%）切换到新版本，通过监控观察无问题，逐步扩大范围，最终把所有流量都迁移到新版本上。属无损发布
② 优点
灵活简单，不需要用户标记驱动。安全性高，新版本如果出现问题，只会发生在低比例的流量上
③ 缺点
成本较高，需要部署稳定/灰度两套环境
滚动发布 Rolling Release
① 概念
每次只升级一个或多个服务，通过观察无问题，不断执行这个过程，直到集群中的全部旧版本升级到新版本。属有损发布
② 优点
成本较低，只需要部署一套环境。出现问题影响范围，只限于发生在若干台正在滚动发布的服务上
③ 缺点
停止旧版本的过程中，无法精确计算旧版本是否已经完成它正在执行的工作，需要靠业务自身去判断。旧版本不保留，一旦全部升级完毕后才发现问题，无法快速回滚，必须重新降级部署。发布和回滚需要较长的时间周期
- 越级管控
- 链路隔离
- 规则策略统一编排
- 推送一次
- 管控下一级
- 链路不隔离
- 规则策略分散编排
- 推送多次
经典场景：当调用请求从网关或者服务发起的时候，通过Header | Parameter | Cookie一种或者几种参数进行驱动，在路由过滤中，根据这些参数，选择在配置中心配置的蓝路由 | 绿路由 | 兜底路由的规则策略（Json格式），并把命中的规则策略转化为策略路由Header（n-d-开头），实现全链路传递。每个端到端服务接收到策略路由Header后，执行负载均衡时，该Header跟注册中心的对应元数据进行相关比较，不符合条件的实例进行过滤，从而实现全链路蓝绿发布
实施概要：只涉及当前正在发布的服务，例如，对于 〔网关〕->〔A服务〕->〔B服务〕->〔C服务〕->〔D服务〕调用链来说，如果当前只是B服务和C服务正在实施发布，那么，只需要把B服务和C服务配置到规则策略中，其它则不需要配置。发布结束后，即B服务和C服务的所有实例都完全一致，例如，版本号都只有唯一一个，那么清除掉在配置中心配置的规则策略即可，从而进行下一轮全链路蓝绿发布
全链路蓝绿发布，包括
- 全链路版本匹配蓝绿发布
- 全链路区域匹配蓝绿发布
- 全链路地址匹配蓝绿发布
- 全链路版本条件匹配蓝绿发布
- 全链路区域条件匹配蓝绿发布
- 全链路地址条件匹配蓝绿发布
经典场景：当调用请求从网关或者服务发起的时候，通过Header | Parameter | Cookie一种或者几种参数进行驱动，在路由过滤中，根据在配置中心配置的随机权重值，执行权重算法，选择灰度路由 | 稳定路由的规则策略（Json格式），并把命中的规则策略转化为策略路由Header（n-d-开头），实现全链路传递。每个端到端服务接收到策略路由Header后，执行负载均衡时，该Header跟注册中心的对应元数据进行相关比较，不符合条件的实例进行过滤，从而实现全链路灰度发布
实施概要：只涉及当前正在发布的服务，例如，对于 〔网关〕->〔A服务〕->〔B服务〕->〔C服务〕->〔D服务〕调用链来说，如果当前只是B服务和C服务正在实施发布，那么，只需要把B服务和C服务配置到规则策略中，其它则不需要配置。发布结束后，即B服务和C服务的所有实例都完全一致，例如，版本号都只有唯一一个，那么清除掉在配置中心配置的规则策略即可，从而进行下一轮全链路灰度发布
全链路灰度发布，包括
- 全链路版本权重灰度发布
- 全链路区域权重灰度发布
- 全链路版本条件权重灰度发布
- 全链路区域条件权重灰度发布
- 全链路地址条件权重灰度发布
2017-2050 ©Nepxion Studio Apache License
