本次分享是站在 DevOps 视角的灰度发布 实践概述，主要内容包括以下四个方面： 第一，灰度发布要解决的问题；
第二，灰度发布的四种典型场景；
第三，如何把灰度发布融入到应用的研发流程中，即把灰度发布与 DevOps 工作融合；
第四，对于外部流量灰度场景，演示如何通过工具将其落地。
在早期的金融、电信等软件研发时，是不存在灰度发布的概念的，因为他们大多是全量上生产，测试过程耗时很长，且测试的单元不是各个微服务 ，而是整个的系统，以保证业务到达生产阶段后要尽可能的安全，不产生安全风险。在这种情况下，当业务到达生产阶段后，要回退或撤销成本很高也很难实现。 因此，在传统软件的研发过程中，开发者大量的心智负担在于如何保证新版本进入生产阶段后风险足够低。
在微服务架构下，多数开发者工作于 Web 应用的研发场景，其需求的交付过程已经产生了巨大的变革。交付的单元变小，一次交付往往是一个或几个小需求，通常仅涉及到几个应用的改造，且这些改造无需同时上线，可以按需部署。如下图所示：
在收到业务方的需求后，经过拆解发现有三个应用需要改造，且这三个应用会分别提交代码、开发测试、生产发布，期间还会存在灰度的环节，即提前将线上应用流量打过来，检查版本是否存在问题。如果没有问题，即部署该应用。当三个应用都部署成功后，开启特性开关，业务需求就对用户可见了。 相对于传统软件研发，尤其是金融和电信的场景，微服务架构下典型的需求交付最大的区别在于有了能够小范围真实验证的机制，且交付单位较小，风险可控。
线下测试很难覆盖线上的所有场景，即便是测试设计得非常完善，但仍旧会有差别，简单来说，线下测试与线上至少存在四个方面的不同。
第一，配置不同。线下环境与线上环境的应用版本保持一致不难，但配置方面往往存在差异，如服务规格、调试开关等。 第二，数据不同。线上的数据更真实、更丰富，场景也更多样。比如做网络开发，即使在线下模拟了各种各样的场景，但在线上可能还会出现问题。 第三，依赖不同。依赖的外部服务，比如某些金融软件会依赖人行的接口，这种情况线下环境无法满足，必须使用模拟接口。 第四，负载不同。线上负载更高，且波动性的特征也更真实。如某个时间点产生突增流量，流量峰谷值不同。在线下环境，考虑到资源成本，一般负载较低，高负载的压测会单独考虑。而压测时，场景的覆盖度也会比正常测试有所降低。
由于线下、线上环境存在的差异，线下测试很难覆盖线上的所有场景，我们需要通过灰度发布或线上测试弥补线下测试的不足，其本质是为了降低开发者的心智负担。
但是否真的需要灰度测试仍需要从业务场景等方面进行多番考虑。
第一，我们是否允许做线上灰度验证，比如对于某些有明确监管要求的行业，无法使用线上灰度验证。 第二，我们是否确实需要做线上灰度验证。因为线上线下的不一致无法消除，且成本较高，若在考虑成本的基础上，认为不进行灰度验证带来的风险可以接受，则可以不做灰度验证； 第三，我们是否有条件做线上灰度验证，即是否有自主运维的能力。此外，若验证的请求量非常低，服务访问量也很少，则相对来说，做灰度验证成本较高，此时可不做灰度验证； 第四，我们能够做线上灰度验证，还需要具备相应的工程和技术的能力，以及相应工具的准备等。
灰度发布有四种常见场景，即简单分批、外部流量灰度、外部+内部流量灰度、全链路（流量+数据）灰度。四种场景依次递进。
简单分批不带任何的流量特征，只是把新旧两个版本的应用程序同时在环境中被请求和调用。请求会随机被路由到新版本或旧版本。假设一个服务由 10 个 pod 支撑，在服务路由到 pod 时。如果均匀分布，每个 pod 上约有 10% 的流量。简单分批的特征之一是部署时有批次，通过分批，使得每批有一定数量的流量；其次，批次之间有一段观测和验证时间。因此，对于简单分批，分批间的观测手段是必须的。当应用存在两个版本时，应用是否可以正常运行，是否存在故障风险，都需要通过观测手段来识别。 简单分批是最简单的一种灰度的方式，其不考虑流量的路由问题，只是简单地将两个版本在线上并存。当然，它也有一些要求。首先，需要保证应用对前一版本的兼容，即当 v1、v2 同时存在时，新版本的 v2 应兼容 v1，否则当用户先调用 v1，再调用 v2 时，会因为版本不兼容产生不一致问题。其次，建立观测能力，包括基础设施监控、应用监控及业务监控等，监控越完善，对分批的验证越充分，越有把握保证新版本没有问题。最后，批次以及每批的比例和观察时间需要明确定义，并且要让监控可以采集到足够的数据，确保可以发现问题。因此，要尽量在每个批次之间留出足够的观测时间。
简单分批最大的问题在于其完全没有流量特征，如果新版本质量较差，线上很大概率会出现一定比例的质量风险。为了解决这一问题，我们需要对灰度的流量进行隔离，只把特定的流量路由到灰度服务中，尽量不让正常流量受影响，这便是接下来要介绍的外部流量灰度场景。
对于 K8s 上的工作负载，流量从 ingress 进入后，会通过特定的标识控制流量进入到指定的应用。标识可以是百分比，如 20% 的流量进入 service v1，80% 的流量进入 service v2。也可以是请求特征，如指定 header 标识进入 service v2，其他流量进入 service v1。外部流量灰度相较于简单分批，最大的区别在于有了入口的流量特征。比如按请求标识进行流量分批时，只有指定的 header、cookie 或地域特征的请求才会进入到灰度版本。外部流量灰度场景也有一定的要求。首先，要保证对前一版本的兼容，因为该场景对内部的流量调用没有约束。其次，必须存在监控系统。同时，对批次和观测时间也需要明确定义。最后，建议先流量切换，再清理工作负载，且两者之间应留有观察时间，即流量从灰度切到正式版本后，应有一定的观测时间，再清理灰度的工作负载。 外部流量灰度场景的问题在于，其只在入口处做了路由标识，一旦进入到内部服务间的调用，则无法再通过流量标识进行路由区分。 1）设置客户端灰度标识的常见思路
对于外部流量灰度场景，还有一个问题不可避免，即对入口流量分发起控制作用的灰度标识如何设置，以下是几种常见的思路：
第一种，使用客户端特征属性。这是一种常见的设置方式，如客户端来自于哪个运营商，是移动、电信，或是联通；再如客户端的地址是哪里，是浙江、江苏，或是上海；再如浏览器版本等。这些特征可以帮助我们做特定的识别。比如把中国某省的移动用户作为灰度的用户集，并将流量路由到灰度版本上。使用这种方式其灰度特征非常明确，观测灰度用户数据难度较低。 第二种，通过客户 ID 做哈希分组。这种相对离散的方式可以避免幸存偏差，如前面案例中使用浙江省或移动客户进行测试，可能在其他运营商之间存在问题，这种方式可以避免这种偏差。 第三种，通过 cookie、header 或 query 参数携带灰度标识做验证。这是一种在 ingress 中经常用到的方式，如在线上的灰度服务中通过一些 cookie 将其路由到灰度的环境中。 第四种，指定灰度的标识码进行验证，可以提前准备一些标识码，通过发放标识码的方式进行。 2）基于流量策略的灰度验证流程
客户端读取灰度策略，灰度策略返回配置 _env:grey 或其他灰度标识，在请求业务接口时，根据是否带有灰度标识，把符合标识的请求路由到新版本服务中，不含有灰度标识的请求路由到老版本中，实现灰度的验证。
前面提到的外部流量灰度场景无法解决应用内部微服务之间的流量问题，此时就需要用到外部+内部流量灰度的实践。
首先，入口处与前一种场景相同，当流量进入后会通过流量策略携带灰度标识。进入应用内部时，应用内部同样有流量的路由策略。如，grey 的流量流入到 app-B grey 版本服务以及 app-C grey 版本服务中。prod 流量路由到其他 app 的 prod 中。当然，实际的流量策略会更加复杂，如 app-C 只有一个版本，则无论是 grey 或是 prod 都会路由到该版本上。 在这个过程中，会牵涉到一个问题，如何尽量少地对应用进行改动使其支持内部的流量灰度。对于内部的 RPC 流量灰度，可以引入类似于 istio、ASM、MSE 等工具来完成，借助其提供的机制做流量的路由。 第二，要保证版本的兼容性，因为除了应用间调用，还有数据、消息等，在这个场景下并没有进行灰度区分。 第三，应用版本更新和流量的调整要串行处理。比如，有些团队在部署时，希望能控制各个应用的部署顺序，且每次的顺序不一定相同，要保证存在依赖关系的几个应用按正确的顺序部署，如 a 依赖 b 和 c，当 b、c 更新完成后，才把服务部署到 a 上。如果顺序有误，在 b、c 未更新时，流量就进入 a，则会产生预测外的风险。对此，开发者有较重的心智负担。此时可以转换思路，将灰度验证时的流量进入延后，先同时把 a，b，c 应用的灰度环境都部署完，再把灰度流量载入，摆脱应用更新时的依赖关系，把流量调整和版本更新分开处理。 第五，数据库和中间件需要保持兼容。如果 c 的灰度和生产都用了同样缓存会存在干扰；或者两者都消费了同样消息，灰度的产生的消息有可能会被生产消费。这个过程是否能保持兼容是需要考虑的问题。至此，除中间件之外在流量侧已基本实现了灰度，而在数据侧仍未处理。
该场景在于如何处理流量+数据的灰度，其不只包含全链路流量的灰度，还包括中间件（如消息、缓存）和数据库等，也能对流量标识进行处理。这种场景非常依赖中间件的建设，对团队工程能力要求较高。 对于该场景，我们的建议是，首先，按优先级逐步建设；其次，先解决数据库之外的中间件问题；第三，尽量寻求专业的技术团队获取实施方案，如 MSE 团队。 四种灰度发布场景，逐渐由简单到复杂，简单分批最简单，成本也最低。
接下来，我们需要在应用研发流程中将灰度发布串联起来。这部分将围绕如何把灰度发布固化为研发流程的一部分展开介绍。
首先，我们建议将灰度环境作为独立的环境，与正式环境隔离，降低环境管理和权限控制的复杂度。其次，为应用定义不同的角色如开发、运维等，不同的角色拥有不同的环境权限。
我们建议把镜像更新与流量调整分离成不同的步骤，在镜像更新前把流量切零，更新之后再调整镜像灰度流量，这样的好处在于，灰度镜像更新过程中无需关心服务是否可用，按照批量下发的思路一次性更新即可，这样可以避免复杂的部署顺序编排问题。
如果配置变更和数据变更对灰度发布有关键影响，我们要对其进行整合。
一般情况下，数据变更会先于应用部署完成，甚至早于整个流程，也可以串进研发流程中，如在数据变更的发布单中完成数据变更。当灰度流量调整前后，完成配置变更，这样就可以把配置和数据变更整合起来，保证灰度验证前整个环境的完整性。根据以往遇到的灰度验证案例，很多灰度验证流程只进行了镜像更新，但实际上还有很多准备工作，如数据库操作、配置操作等。但这些操作往往会散落在不同的地方，这会对灰度验证带来两方面的不良影响，一是整个的过程的自动化程度低，效率低，二是容易产生误操作等各方面的风险，导致即便完成镜像更新，在不进行数据变更和配置变更的情况下还会产生其他风险。
在灰度发布过程完成之后，应加入验证节点。首先，可以进行最简单、最通用的自动化验证，或者人工的卡点，人工确认灰度无误，保证在灰度验证成功之后才进入生产过程。
灰度验证通过后的清理过程，主要包括两个目的，第一，降低灰度环境中的负载和资源消耗，还可以避免部分流量进入灰度环境产生的风险。当然，该流程取决于实际情况，很多情况下可能不会将其全部清理，可以缩成一个副本，使其在和其他服务进行灰度部署时，也可以验证。
演示是基于 K8s ingress 灰度发布场景。
首先，入口域名会配置两条路由策略，一条是灰度策略，当它带有 _env:grey 的 header 标识时，进入到灰度的 ingress，再进入到灰度的 service 和 deployment，共同组成独立的灰度环境。另一条是不带该标识，则会进入正式环境的 ingress、 service 和 deployment，共同组成正式环境。为了便于展示，各个环境均只有一个 deployment。 在研发流程到生产阶段，首先设置准入条件，且准入条件在经过前面测试阶段的验证后才能开始生产阶段的部署。其次，会从 master 分支构建镜像。然后会经过运维审批的节点，如果不通过，整个流程停止。接下来部署灰度环境，进行灰度验证，如果灰度验证失败，则不进入生产阶段，不做灰度变更，直接进行灰度的清理，如果灰度验证通过，则依次进行生产部署、灰度清理、关闭变更，关闭变更意味着前面的步骤都是成功的。灰度清理包含两种情况，一种是生产部署结束之后，一种是灰度验证失败后。接下来进入真实环境展示整个流程。
登录进入云效的 AppStack，演示在真实的 K8s 应用中进行 ingress 灰度流量的过程。 Q1： 全链路灰度如何实现？
A1： 全链路灰度场景分为几层。首先考虑外部流量场景是否足以满足需求，接下来拓展到外部+内部 RPC 层面，如果还不能满足实际需求，再考虑架设全链路灰度。但全链路灰度成本较高，可以先了解阿里云 MSE 等专门做全链路灰度的产品和方案，再结合社区的方案，如 istio 等工具。因为中间件涉及的内容很多，与自身的技术栈有很大关系，很难有标准的实现，如果是 JAVA 或 golang，MSE 是一个很好的选择。 Q2： 假设某系统中有十个微服务，本次版本发布只发布 A、B、C、F 四个，如何保证内部调用时都是最新的？ A2： 可以把目前例子做简单调整。首先，在现在的流程中，最后会清理灰度环境，这里可以不作清理，保留的灰度环境与生长环境使用不同的 service 集群，则 10 个微服务的灰度版本永远是最新的。当把 A、B、C、F 更新到灰度环境时，内部调用仍是灰度环境的 A、B、C、F，服务之间调用则是 namespace 内部的服务调用，即从 K8s 设备路由访问，而不跨 namespace 访问。在这种情况下，就可以保证在灰度 namespace 下调用的是灰度下的服务，而不会调用到生产的服务。如果不基于 K8s 的服务发现，采用独立的注册中心，也需要保证在注册中心有对应的 namespace 等机制来区分灰度和生产环境。 A3： 这个问题较为复杂。首先，我们建议尽量不要让灰度有数据库的差异，或者将数据库的差异在灰度发布处理，实现兼容。因为在灰度发布中，如果数据库层面存在差异，难度会非常大，且容易出现一些问题。其次，数据库的变更不一定要融入到整个研发流程中，甚至多数情况下其实不需要融入其中，若有数据库的变更要提前完成，因为数据库变更相对于应用变更或配置变更风险更大。 Q4： 用同一应用还是给客户分配不同的 namespace？ A4： 如果客户有类似于租户的概念，如云效，有很多客户企业，每个企业都有自己的企业 id，企业间的数据逻辑上是隔离的。从这个角度，如果客户是逻辑隔离，则不需要分配不同的 namespace。如果隔离粒度要更高，一般先考虑数据上的隔离。 A5： 可以，在原有的研发流程中把函数计算的步骤编排进去即可。 A6： 云效目前存储在系统，即云效本身的环境配置中，也可以放在代码库、IaC 库或配置中心等。但可能存入应用的环境更为合适，因为在定义环境时就定义了其灰度策略。 A8： 目前没有更好地处理办法，若是数据问题，只能靠本身数据层的逻辑，如灰度数据标等，由于偏测试数据，可以保证数据有办法清理和恢复的。如果真的产生了多余的数据，只能重新修复。 Q9： 如果有 Zookeeper 注册中心，是在注册中心增加头部信息吗？ A9： 如果是有 ZK，取决于微服务架构的形式。如果服务都通过 ZK，则建议在 ZK 完成。如果不是，则可以简单一些在 K8s 中完成即可。 A10： 对代码依赖不算高，但其中的关键点 RPC 部分/流量的部分是否使用通用的标准协议，如果是 Dubbo 或部分框架，它有相应的要求，如要求有注册中心，就会有一定的影响。从另一个侧面，建议尽量避免这种依赖。在最后的 demo 场景中没有这种依赖的，当然，对基础设施有依赖，即基于 K8s 的 YAML 编排能力，当然其他方式也能做到类似的效果。 A11： 没有固定的要求。从个人角度讲，如果 K8s 足以，使用 K8s 即可，无需引入注册中心，但如果有其他方面的要求，或要跟不同的环境中的服务做联动，可以使用注册中心。因为注册中心的特性更丰富，而且也与是否 K8s 没有耦合性。 Q12： Flow 的 YAML 语法和 Jenkins file 的差异？ A12： 两者的差别较大。jenkinsfile 基于 Groovy 语法，Flow 的 YAML 更像 Github Actions。 A13： 刚刚的演示中有简要的介绍。我们使用了 condition 语句的方式，生产步骤何时执行限制了条件，如清理环境，只有当条件满足时才执行，反之则不执行。选择性的构建可以使用这种方式。 Q14： 原来使用的是 Nacos，是否有必要更换为 K8s？
本文仅供学习！所有权归属原作者。侵删！文章来源： 阿里云云原生 -子丑 :http://mp.weixin.qq.com/s/NeQKG_AWHZVCzMmwngVbmw
