简而言之，”金丝雀 “发布Canary Releases的理念就是只向一部分用户发布新的软件版本，分析结果，然后决定是否继续发布。如果结果与预期不符，就退回；如果结果与预期相符，就增加用户数量，直到所有用户都从新版本中受益。在这篇文章中，我将简要介绍这一介绍的细节，解释定义分数的不同方法，并展示如何使用 Apache APISIX 执行该操作。

“金丝雀 “发布简介
金丝雀 “一词源于煤炭开采业。采矿时，释放有毒气体的情况并不少见。在狭小的封闭空间内，这可能意味着快速死亡。更糟糕的是，这些气体可能是无味的，因此矿工会吸入这些气体，直到来不及离开。一氧化碳在煤矿中很常见，人类的感官无法检测到。

因此，矿工们在井下都带着金丝雀。如果金丝雀突然死亡，就很有可能是瓦斯袋被攻破了，这时就应该离开这个地方。多年前，我们将这种方法用于发布新的软件版本。这个比喻是这样的：矿工是部署版本的运营团队，金丝雀由所有测量发布影响的工具组成，而毒气则是一个（关键）错误。最关键的部分是，您需要衡量版本发布的影响，包括失败率、HTTP 状态代码等，并将它们与之前版本的影响进行比较。这不在本篇文章的讨论范围之内，但如果想从金丝雀版本中获益，这一点同样至关重要。第二个最重要的部分是在新版本出现错误时快速回滚的能力。

金丝雀发布与特性标志

请注意，金丝雀发布并不是管理新代码发布风险的唯一方法。例如，功能标志就是另一种常用的方法：

功能标志也会部署组件，但专用的配置参数允许单独激活或停用每个功能。 功能标志代表了一种更敏捷的回滚方法（真正意义上的回滚）。如果 10 个功能中有一个有问题，你不需要撤销部署新版本，只需停用有问题的功能即可。然而，这种超强功能是以增加代码库的复杂性为代价的，不管你是依赖第三方产品还是自己实现它。另一方面，canary 需要一个成熟的部署管道，以便能够随意部署和撤销部署。

金丝雀发布的方法
金丝雀版本背后的理念是只允许一部分用户访问新版本。大多数金丝雀定义仅将 “部分 “定义为用户的百分比。然而，这其中还有更多含义。

第一步可能是只允许经过审核的用户检查生产环境中的部署是否按预期运行。在这种情况下，您可以只将一组特定的内部用户（如测试人员）转发到新版本。如果你事先知道这些人，而且系统会验证用户身份，你就可以通过身份进行配置；如果不知道，你就需要退而求其次，使用一些通用方法，例如 HTTP 头信息 – X-Canary： Let-Me-Go-To-v2。请记住，我们必须监控新旧系统，以发现差异。如果什么都没发现，那就是增加转发到新版本的用户数量的大好时机。我假设你吃自己的狗粮，即团队成员使用他们开发的软件。如果你不这样做，例如，一个豪华汽车的电子商务网站，欢迎你跳过这一部分。为了在限制风险的同时扩大用户数量，我们现在可以不加选择地向内部用户提供新版本。为此，我们可以配置系统，根据客户 IP 转发到新版本。在现场工作时，这很容易，因为他们的 IP 都在特定范围内。由于用户可能通过 VPN 访问公司网络，因此远程不会有太大变化。在这一点上，还是要进行监控和比较。 目前，对于内部用户（少数或全部）来说，一切都应按预期运行。但是，正如任何计划都不可能在与敌人的接触中幸存一样，任何使用方式都不可能模仿生产工作负载的全部多样性。简而言之，我们需要让普通用户访问新版本，但要采取有控制的方式，就像我们迄今为止逐步增加用户数量一样：从一小部分开始，对其进行监控，如果一切正常，再增加一小部分。

下面是使用 Apache APISIX 的方法。Apache APISIX 提供了一个基于插件的架构，并提供了一个满足我们需求的插件，即流量分割插件。

流量拆分插件可用于动态地将部分流量导向各种上游服务。

这是通过配置匹配（用于分割流量的自定义规则）和加权上游（用于引导流量的一组上游）来实现的。

– 流量拆分


让我们从一些基本的上游开始，每个版本各一个：

upstreams:
– id: v1
nodes:
“v1:8080”: 1
– id: v2
nodes:
“v2:8080”: 1

我们可以使用流量分割插件，将大部分流量转发到 v1，一小部分转发到 v2：

routes:
– id: 1
uri: “*” #1
upstream_id: v1
plugins:
traffic-split:
rules:
– weighted_upstreams: #2
– upstream_id: v2 #3
weight: 1 #3
– weight: 99 #3

1) 定义总括路由 配置如何分割流量；

2) 这里，权重将 99% 的流量转发到 v1，1% 转发到 v1。

3)要实现 50/50 的比例，可以设置权重 1 和 1、3 和 3、50 和 50 等。

然后，我们可以增加转发到 v2 的流量比例，例如:

routes:
– id: 1
uri: “*”
upstream_id: v1
plugins:
traffic-split:
rules:
– weighted_upstreams:
– upstream_id: v2
weight: 5 #1
– weight: 95 #1

1）将 v2 的流量增加到 5%

注意Apache APISIX 每秒都会重新加载对上述文件的更改。因此，您可以近乎实时地拆分流量。或者，您也可以使用管理 API 来实现同样的效果。

更可控的发布 在上文中，我从内部用户转向了部分外部用户。也许在你的组织中，向每个内部用户发布风险太大，你需要更多的控制。请注意，在这种情况下，您可以进一步配置流量分割插件。

routes:
– id: 1
uri: /*
upstream_id: v1
plugins:
traffic-split:
rules:
– match:
– vars: [[“http_X-Canary”,”~=”,”Let-Me-Go-To-v2″]] #1
– weighted_upstreams:
– upstream_id: v2
weight: 5
– weight: 95

只有当 X-Canary HTTP 标头具有配置值时，才会分割流量。

以下命令始终转发到 v1：

curl http://localhost:9080

以下命令也总是转发到 v1：

curl -H ‘X-Canary: Let-Me-Go-To-v1’ http://localhost:9080

以下命令根据配置的权重（即 95/5）分割流量：

curl -H ‘X-Canary: Let-Me-Go-To-v2’ http://localhost:9080

Nacos实现

后端服务提供一个查询当前版本的接口/version，并且当前版本为v1。云原生网关深度集成Nacos注册中心，可以实时动态地从Nacos实例中获取服务信息，方便通过云原生网关将该后端服务暴露给外部用户。

结论

本篇文章介绍了金丝雀版本以及如何通过 Apache APISIX 配置金丝雀版本。您可以先配置几个具有不同优先级的路由，然后再配置流量分割插件。后者甚至可以进一步配置，以实现更复杂的用例。文章的完整源代码， 从这儿下载。链接：https://pan.baidu.com/s/10oKjukFUZ3Es47H706QT3Q 提取码：fv5q

docker-compose.yml

version: ‘3’
services:
apisix:
image: apache/apisix:3.7.0-debian
volumes:
– ./config/apisix/config.yml:/usr/local/apisix/conf/config.yaml:ro
– ./config/apisix/routes.yml:/usr/local/apisix/conf/apisix.yaml:ro
ports:
– “9080:9080”
v1:
image: busybox:1.36
command: [“/bin/busybox”, “httpd”, “-f”, “-p”, “8080”]
volumes:
– ./config/httpd/httpd.conf:/etc/httpd.conf
– ./config/httpd/v1:/www
v2:
image: busybox:1.36
command: [“/bin/busybox”, “httpd”, “-f”, “-p”, “8080”]
volumes:
– ./config/httpd/httpd.conf:/etc/httpd.conf
– ./config/httpd/v2:/www


更多参考：

  • CanaryRelease on Martin Fowler’s bliki
  • traffic-split
  • Implementation of canary release solution based on Apache APISIX
  • Canary Release in Kubernetes With Apache APISIX Ingress
  • Smooth Canary Release Using APISIX Ingress Controller with Flagger
  • Apache APISIX Canary Deployments

今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管管，团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。