开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：云原生持续交付的4大原则-上（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1278
云原生持续交付的4大原则-上（二）
云研发时代主流的软件发布形态让持续发布成为可能。
持续发布的前提是做到持续部署
灰度发布的实践建议：
（1）应用需要保证对前一个（或数个）版本的兼容。版本的兼容数量取决于应用的一个线上情况。有时候线上会同时存在几个版本的应用，要保证对这几个版本的兼容性。
（2）创建一个新的 deployment，提供同样的 service，通过调整 pod 数或者ingress 流量来进行灰度。这种灰度情况下其实可以很精细的去控制它，所以这里建议是如果有这种手段的话通过流量去控制。
（3）定义灰度批次以及每一批的比例和观察时间（保证监控有足够的数据可以发现问题）。灰度批次应该设计的合理，而且保证每一个批次之间的间隔有足够的时间去发现，并且去做处理，如果它的灰度特别快，它时间特别短，但有可能这个监控还没有来得及告警，它就进入下一个更大的一个批次了，很有可能会带来一个非常大的一个风险。
（4）除了关注基础监控和应用监控外，也需要关注业务监控，发现异常应立即暂停发布。从这个发布的角度讲，最终目的是要避免说发布带来的业务损失。业务损失可能包含很多，比如简单点，就是发布导致业务不可用或者导致业务出现错误，但是更严重的确实可能是业务发布带来业务的某些观测指标产生大的一个变化，比如用户转化率或者是其他的一些用户的登录成功次数，这种事情发生大的变化，那这种情况下就是一个异常的数据，而这个异常的数据应该及时被发现，并且当这种情况发生的时候，应该立即暂停掉。
（5）先切换流量，观察一段时间后，再清理 Pod。
（6）记录下发布的版本，方便进行回滚。能做到一键回滚。
（7）回滚≠重新发布，可能与发布有不同的策略。
（8）如果系统为多租户，可以基于租户进行流量隔离和 AB 测试。AB 测试会很方便。
蓝绿部署和灰度其实是差不多类似的，只是所需要的资源一个会更的多一点，非 A即 B。
这当然取决于本身的一个软件的部署形态和一个机器的资源的数量，而且做相应决定，当然除了这些，像金丝雀其实也是类似的这种灰度方式，不过蓝绿比灰度要对软件的要求会更低一点，就是可以保证整个所有的业务都布上去之后，再去切的，但灰度是不行，必须持续能够上去，所以蓝绿说切相对来说风险是比较高的。但是如果说要做到不影响线上的服务，除了部署的一些策略之外，有的时候会遇到相应的一些其他的问题，比如软件只开发了一半，或者这个服务部署上去，需要跟别的服务配合在一起，才能够作为一个完整的一个系统服务提供给用户。那这个时候可能会用相应一些特性开关的这样的一些方式，其实就是相应的一些配置文件，一般都是动态配置的形式下发的。
其实这个可能很有体感就是，移动端跟 sap 端的配合，很有可能用移动端的那个更新是比较固定的，只是要应用市场去推，它可能一个月才推了一次，那这种情况下，服务端就早上去了，但是有些特性开不了，这个业务端，它放上去之后才能去开某特性，所以说这个时候一般会采用动态配置的方式，然后给它一个特性开关。那么平时可以做相应的一些测试部署的一些动作，但是真正的特性是等到客户端或者前端发布上去之后，通过相应的一些动态的这个特性开关配置，然后反应过去了。
所以严格上来说，特性开关的一个打开本身其实也是一次发布，而且特性开关本身也是一个版本能力。所以其实做到这种不中断线上服务的话，对部署的过程做到不中断现场服务，希望达到一个目标，就是任何时候任何人都可以放心的发布软件。几个字但是要求特别高，任何时候意味着什么？就是服务可能任何时候都会有很多人在访问，也有很多时候没有很多人在，但是不管任何时候都能发，还有任何人都可以发，也就是发布的这一个操作是特别简单的，不需要掌握的。什么技能？只要点一下它就发上去了，而且还有另外一个放心的发布，意味着发布了之后不会出现什么大漏，或者说出现漏子能给兜住，对他有一个兜底的一个方式。其实给了一个愿景，就是任何时候任何应用都可以发布上线。其实也是有，很多紧急发布的，开始遇到的问题，它可能发布上线，所以这里需要有非常完整的技术保障，包括相应一些实践来去保证发布的一个安全性和可靠性，因为一旦出现问题的时候，这个时候可能故障，而且越是这种时候越可能产生一些雪崩效应就可能会带来一系列的故障和问题可能最后整个系统会瘫痪掉了。
