发布的定义和目标
软件发布：将开发好的应用程序 正式公布 出来的过程
ITIL 中定义的发布管理目标包括
规划、协调软件和硬件的实施（或安排实施）
针对分发和安装对系统实施的变更而设计和实施有效的程序
确保与变更相关的硬件和软件是可追溯和安全的（正确的，经过批准和测试的版本才能被安装）
在新发布的规划和试运行期间与用户进行沟通并考虑他们的期望
保障发布软件的原始拷贝被安全地存放在最终软件库，配置信息存储在配置管理数据库
部署与发布的关系
部署：在特定的环境上安装指定版本的软件。部署可能与某个特性的发布有关，也可能无关
发布：把一个（组）特性提供给（所有或部分）客户
将部署和发布 解耦，实现低风险发布是非常必要的
代码和环境架构要满足：特性发布不需要变更应用的代码
如果混淆部署和发布，就很难界定谁对结果负责
解耦部署和发布，可以提升开发人员和运维人员快速且频繁部署的能力，同时产品负责人承担发布成功的责任
按需部署，让特性发布成为业务和市场决策，而不是技术决策
基于环境的发布模式关注两个或更多的环境，但只有一个环境正在接受实时客户流量
新代码部署在非生产环境中
该版本将流量切换至此环境
只需要很少或者不需要更改应用程序
eg：Blue-green 蓝绿部署、Canary 金丝雀发布、Cluster immune systems 集群免疫系统
基于应用的发布模式通过 Feature Toggle（特性开关）来启用特定应用程序功能的发布和展示
启用范围
开发团队
内部员工
1% 的客户
整个客户群
eg：Dark Launching
发布策略总览
基于应用的发布模式更安全
轻松回滚
缓解性能压力，优雅降级
采用面向服务架构提高恢复能力，服务解耦
将代码部署真正与特性发布解耦
实现假设驱动开发和 A/B 测试
实现 Dark Launch 黑启动（eg：Facebook 聊天功能，Baidu 关键字联想功能）
基于应用发布的缺点
有代码入侵
特性开关也是技术债务，需要定期清理
同时增加测试的复杂性，需要打开所有特性开关（也许需要排列组合），还需要测试特性开关功能本身是否正常
单服务器组发布传统数据中心中，机器资源比较紧张，应用机器基本是预先静态分配好的（一般由运维负责分配），原来应用 A 运行在这 n 台机器上，那么下次升级发布的应用 A 也运行在这 n 台机器上，所以称为 单服务器组发布
单服务器组发布策略有：蛮力发布、金丝雀发布、滚动发布
蛮力发布（单服务器组）
流程
完全靠手工完成软件的升级与发布，在发布过程中会进行人为的中断，进行应用升级（如果所示：先将老版本 v1 全部下掉，再将新版本发到机器上去）
优势
简单成本低
劣势
服务中断用户受影响，出了问题回退也慢
适用场合
开发测试环境
非关键应用（用户影响面小）
一般适用于初创公司，在业务闲时进行
金丝雀发布（单服务器组）
流程
金丝雀发布一般先发 1 台，或者一个小比例，例如 2% 的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试。如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败
优势
用户体验影响小，金丝雀发布过程出现问题只影响少量用户
劣势
发布自动化程度不高，发布期间可能引发服务中断
适用场合
对新版本功能或性能缺乏足够信心
用户体验要求较高的网站业务场景
缺乏足够的自动化发布工具研发能力
滚动发布（单服务器组）
滚动发布在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式
滚动式发布一般先发 1 台，或者一个小比例，如 2% 服务器，主要做流量验证
先将老版本 V1 流量从 LB（Load Balance，负载均衡） 上摘除
清除老版本，发新版本 V2
再将 LB 流量接入新版本，这样可以尽量保证用户体验不受影响
一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀10 分钟，后续间隔 2 分钟)
优势
用户体验影响小，体验较平滑
劣势
发布和回退时间比较缓慢
发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力
适用场合
用户体验不能中断的网站业务场景
有一定的复杂发布工具研发能力
双服务器组发布随着云计算和虚拟化技术的成熟，特别是容器等轻量级虚拟化技术的引入，计算资源受限和申请缓慢问题已经逐步解决，可以做到弹性按需分配
为一次发布分配 两组服务器，一组运行现有的 V1 老版本，一组运行待上线的 V2 新版本，再通过 LB 切换流量方式完成发布，这就是所谓的 双服务器组发布
双服务器组发布策略有：蓝绿发布、金丝雀发布、滚动发布、功能开关、A/B 测试、影子测试
蓝绿发布（双服务器组）
蓝绿发布仅适用于双服务器组发布，可以认为是对蛮力发布的一种简单优化发布方式
V1 版本称为蓝组，V2 版本称为绿组，发布时通过 LB 一次性将流量从蓝组直接切换到绿组，不经过金丝雀和滚动发布，蓝绿发布由此得名。出现问题回退也很直接，通过LB 直接将流量切回蓝组
发布初步成功后，蓝组机器一般不直接回收，而是留一个待观察期，视具体情况观察期的时间可长可短，观察期过后确认发布无问题，则可以回收蓝组机器
优势
升级切换和回退速度非常快
劣势
切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响
需要两倍机器资源
适用场合
对用户体验有一定容忍度的场景
机器资源有富余或者可以按需分配（AWS 云，或自建容器云）
暂不需要复杂滚动发布工具研发能力
金丝雀发布（双服务器组）
对蓝绿部署的一种简单优化，发布时先从绿组拉入 1 台金丝雀，待金丝雀验证通过再发全量
对比蓝绿发布，金丝雀发布方式的优势是有一个生产流量的金丝雀验证过程，可以减轻 V2 可能有问题的风险和影响面
优势
用户体验影响小，金丝雀发布过程出现问题只影响少量用户
劣势
发布自动化程序不够，发布期间可能引发服务中断
适用场合
对新版本功能或性能缺乏足够信心
用户体验要求较高的网站业务场景
缺乏足够的自动化发布工具研发能力
滚动发布（双服务器组）
滚动式发布是对上面的蓝绿和金丝雀发布的进一步优化，按批次增量滚动发布，提供更平滑的用户体验。发布前先申请一批新服务器，数量一般和 V1 版本相同，将 V2 版本应用发布到新服务器上
例如如果在 AWS 云上，则可以直接调用 API 申请一批新 VM，如果用容器云 Kubernetes，则可以直接启动一批新容器（使用 V2 版本容器镜像）
一般会先通过 LB 拉入 1 台 V2 版本的机器，这台机器也相当于金丝雀，用于 流量验证
逐步按批次完成发布，每批只需要通过 LB 拉入 V2 版本，再拉出对应数量的 V1 版本
批次之间留有观察间隔，通过手工或监控反馈确保没有问题再继续发布
发布有问题回退很快，直接通过 LB 将流量切回 V1 即可
完成发布后，一般 V1 版本要保留观察以备万一，比如留 1 天，1 天后没有问题则回收 V1 机器资源
优势
用户体验影响小，金丝雀发布过程出现问题只影响少量用户
劣势
发布自动化程序不够，发布期间可引发服务中断
适用场合
对新版本功能或性能缺乏足够信心
用户体验要求较高的网站业务场景
缺乏足够的自动化发布工具研发能力
功能开关 - Toggle/FeatureFlag/Switch
利用代码中的功能开关（Feature Flag/Toggle/Switch）来控制发布逻辑，一般不需要复杂的发布工具和智能 LB 配合，是一种相对比较低成本和简单的发布方式
这种方式也支持现代 DevOps 理念，研发人员可以灵活的定制和自主完成发布方式
需要一个 配置中心 或者 开关中心 这样的一个服务支持，通过配置中心运维或研发人员可以在运行期间动态配置功能开关的值
功能开关发布只是配置中心的一种使用场景，配置中心还能支持其他动态配置场景，功能开关服务一般提供客户端的SDK方便开发人员集成，在运行期客户的SDK会同步最新的开关值
技术实现有 推方式 也有 拉方式 或者 推拉结合方式，新功能和老功能住在同一代码中，新功能隐藏在开关后面，如果开关没有打开，则走老代码逻辑，如果开关打开则走新代码逻辑，技术实践上可以理解为一个简单的 if else逻辑
应用上线后开关先不打开，然后运维或研发人员通过开关中心打开新功能，经过流量验证新功能没有问题后，则发布完成，如果有问题，随时可以通过开关中心切回老功能逻辑
优势
升级切换和回退速度非常快
相对于复杂的发布工具，实施比较简单，成本相对低廉
研发能够灵活定制发布策略，支持 DevOps 自助发布
劣势
切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响
对代码有侵入，代码逻辑会变复杂，需要定期清理老版本逻辑，维护成本高
适用场合
对用户体验有一定容忍度的场景
已有配置中心或开关中心服务
暂不具备研发复杂发布工具能力
A/B 测试
A/B 测试是用来测试用户表现的方法（例如：可用性、受欢迎程度、可见性等等）
A/B 测试的目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信
原来的 PC 端和手机端都访问老版本 V1 服务（也称 A 组或控制组），当 V2 新版本（也称 B 组或实验组）发布以后，为了验证 V2 的功能正确性，同时也为了避免 V2 有问题时影响所有用户，先通过 LB 将手机端的流量切换到 V2 版本，经过一段时间的 A/B 比对测试和观察（主要通过用户和监控反馈），确保 V2 正常，则通过 LB 将全部流量切换到 V2
基于 LB 方式实现 A/B 测试，LB 需要能够通过某种条件做流量路由，例如通过 Client IP、设备类型、浏览器类型，甚至是定制的 HTTP Header 或查询字符串
功能开关和AB测试有点相似，但 功能开关 一般是 无状态 和 全量的 ，无法做到针对某类 特定用户 进行测试。而 A/B 测试 一般是 有状态的，能够根据事物和用户级别的状态，可以实现针对某类 特定用户 进行测试
优势
用户体验影响小
可以使用生产流量测试
可以做到针对某类特定目标用户进行测试
劣势
搭建复杂度相对高，有一定技术门槛
适用场合
核心关键业务，比如设计资金的
具备一定 A/B 测试平台研发能力
影子测试
对于一些涉及核心业务的遗留系统的升级改造，为了确保万无一失，使用影子测试，它采用比较复杂的流量复制、回放和对比技术实现
（如上图）目标实现老的 legacy 服务迁移升级到新的 experimental 服务。测试开始前，需要在测试环境部署一份 legacy 服务和 experimental 服务，同时将生产数据库复制两份到测试环境。同时需要将生产请求日志收集起来，将请求分发到 legacy 服务和 experimental 服务，收到响应后进行比对，如果所有响应比对成功，则可以认为 legacy 服务和 experimental 服务在功能逻辑上是等价的；如果有响应比对失败，则认为两者在功能逻辑上不等价，需要修复 experimental 并重新进行影子测试，直到全部比对成功。根据系统复杂度和关键性不同，比对测试时间短的可能需要几周，长的可达半年之久
影子测试因为旁路在独立测试环境中进行，可以对生产流量完全无影响
优势
对生产用户体验完全无影响
可以使用生产真实流量进行测试（复制比对）
劣势
搭建复杂度很高，技术门槛高，数据库的导出复制是难点
外部依赖不能太多，否则测试部署成本很高，且比对测试更加复杂和不稳定
适用场合
核心关键业务，比如设计资金的
具备一定影子测试平台研发能力，包括流量复制、数据库导出复制和分发比对系统
华为云 DevCloud 灰度发布的实践案例
整个DevCloud的产品中采取的灰度发布服务主要特色有三个
根据用户画像，精准分层用户，灰度逐步递进，全部保证能够检测到所有的用户分群
提供了多种灰度策略，如特性开关、A/B 测试、在线验收测试、友好用户测试等模式
精准把控灰度批次比例，借助 SLB 服务，严格按照 1%、9%、45%、45%，谨慎比例逐步放大灰度群体
iLearning 蓝绿部署案例 iLearning 实践背景问题与挑战
iLearning 在前期的敏捷转型中已经建立了基于 Scrum 流程的敏捷交付，两周一个迭代进行交付。然而如果每两周都要将产品部署到生产环境交付给用户，团队非常痛苦，因为每两周就需要周末加班熬夜进行部署，并赶在用户上班之前验证部署结果
因此即便团队可以两周交付一些特性，也很难每两周将其发布给用户，难以进一步缩短支付周期，对业务的响应能力不够快
iLearning 实践方案要进一步缩短交付周期，就必须做到生产环境部署发布的不停机，既要对用户无感知不影响用户体验，同时也要保证部署是成功和安全的。解决这个问题我们引入了 “蓝绿部署” 的实践，在华为也称为 “双活”
蓝绿部署使用两套一致的环境，一套在线提供服务，一套闲置准备用于下个版本的部署。有时也将两套环境都在线提供服务，可互为容灾，但注意这两种模式在部署过程中系统的容量会有波动，应避免在系统负载峰值时进行。iLearning 采用的后一种方式
通过路由切换，将流量都切换到 C 区服务器、G 区无流量
对数据库进行变更，保持对应用的向下兼容
对 G 区的 4 台服务器进行部署，启动第 4 台服务器进行验证，若验证不通过回滚 G 区的部署，如果验证通过启动 G 区集群
通过路由切换，将流量都切换到 G 区 C 区无流量，以同样方式，最后对 C 区进行部署和验证，最后启动集群
思考题
以下关于发布管理的说法，正确的是（）？
A. 任何情况下，都不建议采用蛮力发布
B. 利用代码中的功能开关来控制发布逻辑，即使新版本出现问题，也不会对用户体验造成太大的影响
C. 发布管理的目的的为了在不影响用户体验的情况下进行版本更新，同时保证版本质量
D. 影子测试对生产用户体验完全无影响，所有场合都可适用
答案：C
最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊
