前言
- 关于蓝绿部署、滚动升级、灰度发布的描述、区别、优缺点，网上有很多讨论，这里不做过多描述，比如：https://www.cnblogs.com/nulige/articles/10929182.html
- 蓝绿部署的场景，相对比较简单，这里也不做赘述
滚动升级（无损升级）
介绍
- 故名思议，就是逐步升级服务中的节点
场景
基于haproxy的四七层滚动升级：
- 方式：使用socat（unix套接字工具）管理haproxy上挂载服务的状态实现无损变更
- 场景：假如某服务有A、B两个节点，且挂载到了haproxy上
- 无损变更方式：
- 准备：首先haproxy需要配置生成套接字sock：stats socket /usr/local/haproxy/stats
- 变更前：使用socat连接该sock，
- 变更中：disable掉A节点（此时流量全部到B）
- 变更中：升级A节点
- 变更中：A节点升级完成后，enable A节点，验证A节点上流量是否正常，否则disable掉后回滚
- 变更中：disable掉B节点（此时流量全部到A）
- 变更中：升级B节点
- 变更中：B节点升级完成后，enable B节点，验证B节点上流量是否正常，否则disable掉B节点
- 验证
- 潜在问题：该场景前提是，升级的新版本没有bug，否则升级过程中，所有的用户请求都可能出现问题（包括VIP用户流量报障）
基于nginx的滚动升级
- 方式：修改nginx的upstream节点配置，并使用reload命令动态加载配置，实现节点的上线、下线，从而实现滚动升级
- 整个升级过程以及潜在问题，同上面的haproxy方式类似，这里不做赘述
- 备注：nginx的upstream模块可以配置weight权重，滚动升级时，一般先升级weight权重较小的节点
基于服务注册与发现的方式
- 场景：多用于大规模的微服务化场景下
- 开源解决方案有：springcloud场景下的Eureka、consul、zookeeper、etcd
- 方式：通过调用接口，实现节点在注册中心的上线与下线，从而达滚动升级的目的。整个升级过程以及潜在问题同上，这里不做赘述。比如Eureka的更改状态接口：
- PUT /eureka/apps/appID/instanceID/status？value=OUT_OF_SERVICE
基于k8s的滚动升级
- 背景：微服务化大行其道的今天，作为重要的微服务话的工具，k8s实现滚动升级可少不了
- 方式：待完善
- 扩展：https://www.cnblogs.com/justmine/p/8688828.html
灰度发布
- 实现版本的平滑升级，有效降低版本升级带来的风险，实现更高效的发布
- 此外，精细的灰度策略，可以选择特定的用户(ip/cookie等)参与新版本的试用，得到更快的业务反馈
灰度发布场景
自定义开发nginx+lua实现精细的灰度发布
- 方式：自定义开发lua脚本控制nginx的流量走向，从而实现灰度升级
- 实现1：集群内多节点间的灰度发布
- 实现2：不同集群间的灰度发布
- 常见的灰度流量策略：
- IP限制：将来源IP的流量送到特定节点上
- ID限制：将部分特定的租户ID的流量送到特定节点上
- 百分比：将流量按百分比划分，送到特定节点上
- 扩展：lua为开源的脚本语言，参见：https://www.runoob.com/lua/lua-tutorial.html
基于开源Kong(基于openresty(nginx+lua)）实现灰度发布
- 当然，社区有一套比较成熟的可直接用的开源框架：https://konghq.com/kong/
- 限流
- 熔断
- 认证
- … …
- 扩展：https://openresty.org/cn/download.html
- 扩展：lua为开源的脚本语言，参见：https://www.runoob.com/lua/lua-tutorial.html
基于云服务厂商的APIG实现灰度发布
- 可通过各大云服务厂商提供的APIG服务，实现灰度发布升级
- 比如华为云的：https://support.huaweicloud.com/productdesc-apig/apig-zh-pd-180307002.html