容器云之灰度发布设计.docxVIP

灰度发布是应用服务从0到1完全发布的过程。在容器云平台上，一个服务往往部署有很多个实例以根据业务流量实现弹性伸缩。为了验证某个服务或应用的某一特性，或者验证某一服务的功能，在发布一个新的服务版本时，先发布1个或少量实例，通过对新特性的反馈分析或新功能的验证分析来决定是否继续发布实例（或替换实例）或回滚。灰度发布和A/B测试、发布新版本和版本替换有相同点也有区别。

软件版本控制

要说清楚灰度发布和A/B测试、发布新版本、版本替换等概念差别，先说下软件版本控制问题。软件产品对外发布版本号有Alpha、Beta、Released版本等。Alpha、Beta是对外发布的测试版本，Released指的是对外发布的正式版本。每个发布的版本号中通常包括为Major（主版本号）、Minor（小版本号）、Patch（补丁版本号）、Hotfix（热修复版本号）、internal（内部版本号）版本号等。，比如Released版本v1.2.3.4.10，其中1为主版本号，通常软件架构重构或升级才会调整主版本号；2为小版本号，通常重要特性发布需要调整小版本号；3为补丁版本号，通常是为了修复已发布的版本中的系列漏洞而发的一个补丁版本或补丁包；4为热修复版本号，通常用于紧急修复一些有重大影响的问题，多个的hotfixes可以打包成一个patch补丁包；10为内部控制版本号，通常可用于内部代码或功能进度控制等。我们暂借用软件版本控制来说明下服务版本的灰度发布问题。

灰度发布和A/B测试

灰度发布的目的和A/B测试的目的类似，但并不等同。A/B测试的目的是为了选择A或B而进行的调研性测试；灰度发布的目的是验证某版本中某项功能能否满足需求，比如某功能做了优化，可能没有时间进行详细深入的测试，需要部署到生产环境进行实际生产验证，但又不能全部替换掉原来的版本（服务多实例部署，灰度发布是在服务实例级别，同一服务版本，不同实例版本），就可以发布一个灰度版本的实例，引部分流量进行验证。如果没有问题，则一步步替换掉原来全部实例（只有一个实例无法做灰度发布），如果有问题则回退。区分灰度发布和A/B测试，通常需要区分面向前端用户的特性测试还是后端功能的验证。A/B测试通常是面向前端用户的特性的调研选择性测试，A/B测试通常有两个入口（如下图A/B测试）；后端功能的验证对用户不可见，面向用户的是一个入口（如下图灰度发布），通过流量的分发策略来分发部分流量进行验证。如果用户的请求在使用灰度版本功能时出现异常或错误就需要立刻回滚。如果没有问题，则可以逐步扩展实例数，直到全部替换。

A/B测试的版本相当于两个Alpha或Beta版本，等调研测试之后选择两个中的一个正式发布为Released版本。灰度发布的版本相当于发hotfix版本，或者也可以是patch版本，主要用于敏捷修复和验证功能。

灰度发布和发布新版本

发布新版本是全新发布一个新的服务版本或应用版本或系统版本。它跟灰度没有关系，是一个全新的发布。不管是否存在一个旧服务版本，也不管新版本和旧版本之间是否存在功能或（和）性能等之间的差别，所以可以看作是两个独立的版本。比如在部署了一个通用版本基础上，为“大客户甲”单独发布部署了一个版本“v甲”。或者如APP可能同时有很多个版本并行运行。举个最容易理解的例子，比如微软在维护Windows7操作系统版本时，又开发发布了Windows10。你用Windows10，我可能还在用Windows7，两个版本同时都需要支持。发布新版本的目的并不是为了验证版本中功能或性能，也不是为了测试两个版本的受欢迎或受认可等的程度从而选择一个更好的版本。所以发布新版本和灰度发布以及A/B测试都是不一样的。

发布新版本相当于发布一个新的Relased版本。这通常是“应用-服务-实例”分层中的“应用”系统层，至少是“组件服务”层级，而不能是“实例”层次。

灰度发布和版本替换

灰度发布在灰度状态下，是两个版本的实例并存（多实例状态）。版本替换功能的目的是用新的版本来替换旧的版本，并不需要存在灰度状态的验证。虽然说灰度发布完成，也是实现了版本替换，最终结果版本一致（也存在回退可能），不过版本替换相对要简单一些，可以是单实例服务的替换，也可以是多实例服务的替换，其实就相当于是服务版本的替换，属于服务层的操作，它不关心服务有多少实例，一次性全部替换。有人说，应用也可以做版本替换，没错，不过需要考虑的是，是否影响到终端用户。很多人对应用和服务的定义是不一样的，所以可以用是否影响终端用户来判断。如果影响到终端用户，对用户来说就是版