容器云之灰度发布设计

灰度发布是应用服务从 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 版本。这通常是“应用 - 服务 - 实例”分层中的“应用”系统层，至少是“组件服务”层级，而不能是“实例”层次。

灰度发布和版本替换

灰度发布在灰度状态下，是两个版本的实例并存（多实例状态）。版本替换功能的目的是用新的版本来替换旧的版本，并不需要存在灰度状态的验证。虽然说灰度发布完成，也是实现了版本替换，最终结果版本一致（也存在回退可能），不过版本替换相对要简单一些，可以是单实例服务的替换，也可以是多实例服务的替换，其实就相当于是服务版本的替换，属于服务层的操作，它不关心服务有多少实例，一次性全部替换。有人说，应用也可以做版本替换，没错，不过需要考虑的是，是否影响到终端用户。很多人对应用和服务的定义是不一样的，所以可以用是否影响终端用户来判断。如果影响到终端用户，对用户来说就是版本升级，如果对用户透明，只是做后端服务的版本替换，比如服务的实现方法或连接配置等发生了改变，简单的如数据库地址迁移了，服务配置需要更新，服务版本就发生了变化，就需要用新的服务版本替换旧的服务版本

版本替换和灰度发布的区别在于是否有一个持续灰度的过程。如果没有持续灰度的过程，就是版本替换；如果有则是灰度发布。最终目的都会实现版本的替换。

灰度发布设计

厘清楚了上面的几个概念，我们讨论下在以应用管理为核心的容器云平台或容器化 PaaS 平台如何设计灰度发布功能。灰度发布是对服务的实例的替换过程，因此首先灰度发布是服务的一项功能，在应用服务的列表或详情页面需要有灰度发布的入口。

服务列表中灰度发布入口

在应用服务列表中，可以选择列表中的一个服务进行灰度发布操作。在灰度发布过程中的服务，其状态应该显示“灰度”。非灰度的服务，正常的服务显示“正常”，如果实例有异常，则显示“异常”。点服务名则进入服务详情页面。在服务操作栏，则可以选择：负载配置、灰度发布（灰度状态则显示“回滚”按钮）、弹性配置、治理配置、标签、告警、搜索等操作。

点“灰度发布”则打开服务灰度发布页面，进行灰度发布的策略配置。这里要说明的是，灰度发布的镜像名是不变的，所以可以自动获取；版本号会变化，需要选择一个新的版本号，默认可以自动填入最新的版本号。如果服务只有一个实例，则不可用灰度发布。固定 IP 方式也可以有多实例，也可以执行灰度发布，只不过其前面往往需要加一层负载分发能力，比如说用 Nginx 或 F5 来实现分发。

灰度策略配置

灰度策略配置主要设置灰度发布的策略。发布的策略可以定义很多种，最常用可以使用灰度发布的服务个数或灰度发布百分比。如果用灰度发布百分比，这里可能有个问题，就是百分比分数可能不合适，比如 3 个实例设置灰度替换策略 50% ，那灰度应该是发布几个实例呢？这种情况下建议下取整， 3 的 50% 是 1.5 ，向下取整为 1 。在实例数较少的情况下，尽量用具体的实例个数来设置，实例数比较多时，用百分比比较合适。灰度策略可以很简单，也可以很复杂，比如再引入时间变量，等时区间或不等时区间灰度设置、定时策略和不定时策略等就可能又带来很多灰度发布选项。比如前 24 小时发布 5% ，第 2 个 24 小时发布 10% ，第三个 24 小时发布 40% 等。还有异常回滚策略等，会使灰度发布策略配置复杂化。在实际的服务灰度发布中，可能需要支持不同的策略选择组合。 灰度发布时，不改变服务实例数。调整服务实例数用弹性伸缩功能。

灰度发布负载分发策略

服务运行在灰度状态时，也需要考虑服务的请求分发策略。服务不同的分发策略会使灰度服务实例接收处理不同量的请求。服务分发策略可能是轮询、权重、最小连接、响应时间、 Hash 法等。灰度通常可以使用 hash 方法，选择一些特定的请求来验证。在实现 Ingress 时候，就可以扩展来支持不同的分发策略。这是平台层的功能，就不属于 k8s 调度管理层的能力了，所以需要额外的能力扩展。

灰度发布实例列表

处于灰度状态的服务，进入服务详情页面，在服务实例列表中需要体现灰度实例和原实例之间的区别。可以通过实例的版本号和背景色等来体现。灰度状态的服务实例版本是不一样的，镜像版本也不一样，但灰度结束后最终版本会统一（无论回滚或滚动发布完成）。 实例详情页面需要在表之上显示服务的基本信息，包括服务名、应用名、命名空间、创建人、创建时间、状态、服务暴露方式、服务地址，资源分配和使用、负载策略、灰度策略、调度标签、备注等信息，这样一目了然当前服务的信息，也方便到服务、应用等的跳转，从而形成操作闭环。其实应用、服务、实例、 Pod 、容器、集群、分区、节点、命名空间等各对象之间都需要通过其关系关联起来，实现便利地跳转和排序，方便查询和统计。

灰度发布设计原则

针对当前容器云平台灰度发布的一些不足，从笔者使用体验角度提出了一些想法。灰度发布设计首先不能把多个功能糅合在一起，否则搞不清楚要做什么，也使功能设计复杂化；另外也不能把一个操作流程分为几个部分，否则操作体验会很差，做完一步不知道下一步在哪里。其实不只是灰度发布，容器云平台设计是为了用户使用的，而不是开发人员想当然的自以为是。基于经验和体会总结，建议灰度发布可以遵循以下原则：

原则 1 ：功能设计清晰

灰度发布功能设计需要先厘清概念，不能把多种概念混在一起，单一功能不能又能发布新版本又能做版本替换等等。不同的概念往往意味着不同的功能，在设计时需要明确区分，理解单一功能边界和区别。

原则 2 ：功能流程完整

灰度发布功能需要有完整的流程，能够形成闭环。从灰度发布入口，到策略配置，到自动执行灰度、异常回滚、提醒等，然后返回服务列表，显示服务状态（是否灰度状态）。灰度发布从服务列表回到服务列表，一个完成闭环流程结束。

原则 3 ：以用户体验为最高原则

灰度发布设计是为了方便用户完成自己的工作。在设计时需要从用户的角度来思考问题，不能仅仅从开发人员自身的角度为了完成开发功能而应付。所以需要换位思考下，把自己当作用户去设计和实现，才能做好并赢得客户。 容器云平台灰度发布在容器云平台上并不是一个核心的功能，不过如果能够支持，在某些场景下会便利很多。本文也只是表面的一些思考，具体设计实现时，还有很多细节的考虑，比如没有新版本的镜像，则不能去做灰度发布；单个实例的服务无法做灰度；服务的历史版本管理和版本回退问题等等。从一个产品功能的设计，也基本上可以看出该产品公司的产品设计能力和相关人员的态度。灰度发布设计不应该成为一个问题，如果它依然成为一个问题，那么一定是人的问题。容器云也发展了好几年了，产品功能不能只解决有无问题，而是需要考虑好不好用问题了。