1. 灰度公布的原理

互联网业务的研发提倡“小步快跑，疾速迭代”。这要求在保障 7 *24 小时不中断服务的前提下，能够高频度的降级服务，这就对“灰度公布”提出了需要。

灰度公布（又名金丝雀公布，Canary Release）是指在黑与白之间，可能平滑过渡的一种公布形式（来自百度百科）。

从流量转发的角度，灰度公布的原理如图 1 所示。用户流量由负载均衡器转发给服务。服务的部署分为正式服务和测试服务。由负载均衡器执行灰度公布策略，将符合条件的灰度流量转发给测试服务。

图 1 灰度公布的原理

灰度策略可能包含两类：

1. 依照 肯定的流量特色 来抉择灰度流量。可能作为流量抉择的特色包含：用户起源地，非凡的申请标签等。
2. 依照 肯定的流量比例 来抉择灰度流量。例如，能够管制抉择 1% 的流量作为灰度流量。

2. BFE 对于灰度公布的反对

BFE 对 基于流量特色 和基于流量比例 这两种灰度策略都提供了反对。

2.1 基于流量特色的灰度策略反对

利用 BFE 的路由转发表，能够实现基于特色的灰度策略。

在 BFE 中，对于每个租户都能够独立设置 根底转发表 、 高级转发表 和默认转发规定。图 2 和图 3 展现了利用高级转发表来实现基于特色的灰度策略的例子。

在本例中，包含 A、B、C、D、E 共 5 种服务。其中 A、B、C、D 这四种服务都应用根底转发表中的配置来实现匹配，E 服务作为默认的服务（如图 2 所示）。

图 2 在灰度公布前的转发配置

对于服务 D，本来只在根底转发表中进行了配置。起初因为要进行灰度测试，于是在根底转发表中将 www.c.c.com 对应的指标集群设置为保留字“ADVANCED_MODE”（意为透传至高级转发表持续解决）；同时在高级转发表中减少 2 条规定（基于 BFE 的条件表达式来形容匹配条件），将在 cookie 中 key 为 deviceid、值的前缀为“x”的申请转发到 D1 这个灰度试验集群，将其它 Host 为 www.c.com 的流量依然转发至 D 集群（如图 3 所示）。

图 3 实现基于特色的灰度公布

除了利用 cookie 外，也常常应用 Header 和 query 中的信息来辨别测试流量。对于这些字段，在 BFE 中也有专用的条件原语用于形容相干的特色。能够在上面的链接中查看 BFE 反对的条件原语。
https://github.com/bfenetwork…

2.2 基于流量比例的灰度策略反对

利用 BFE 提供的内网流量调度机制，能够实现基于流量比例的灰度策略。

图 4 基于流量比例的灰度策略

为了配合基于比例的灰度公布，能够常态筹备 2 个子集群 D1 和 D2。在 BFE 中，将 2 个子集群的分流比例设置为 1% 和 99%。

在做新性能上线的时候，新版本的程序首先在 D1 子集群上线。应用 1% 的流量，通过一段时间的验证无误之后，再将新版本的程序上线至 D2 子集群。

能够在上面的链接中查看对子集群设置分流权重的办法
https://github.com/baidu/bfe-…

3. 基于 BFE 管制面的操作

目前 BFE 的管制面组件曾经开源公布。在装置 BFE 的管制面组件后，对于基于流量特色的灰度公布和基于流量比例的灰度公布，都能够间接登录 BFE 的 dashboard 来操作，或者通过调用 BFE API 提供的接口来操作。

在 BFE 的 Dashboard 上操作的阐明，见上面的链接：

• 对于路由转发规定的配置：

  • https://github.com/bfenetwork…

• 对于子集群分流比例的配置：

  • https://github.com/bfenetwork…

图 5 应用 BFE Dashboard 配置路由转发规定

BFE API 的接口阐明，见上面这个链接：
https://github.com/bfenetwork…

4. 总结

“灰度公布”是互联网业务研发所需的重要能力。BFE 对于灰度公布的两种形式（基于流量特色的灰度公布、基于流量比例的灰度公布）都提供了反对。联合曾经开源的 BFE 管制面组件，能够应用 BFE Dashboard 或 BFE API 实现灰度公布的相干配置。

欢送关注“BFE 开源我的项目”微信公众号，取得本我的项目的更多更新。谢谢！