C# 中的金丝雀部署：无停机安全发布

什么是金丝雀部署以及它为何能拯救你的生产环境？

你是否曾在午夜发布更新，祈祷一切不会崩溃？很熟悉吧。那如果我告诉你，可以在真实用户身上测试新代码，但不会让任何人受到影响呢？这就是金丝雀部署——一种部署策略，新版本的应用首先只接收一小部分流量。如果一切顺利，流量就会增加。如果不顺利，几秒钟内即可回滚。

在 .NET 和 C# 的世界中，这一点尤为重要：微服务、高负载、稳定性要求。我们将编写代码，配置金丝雀部署，并分析真实案例。开始吧！

为什么金丝雀不仅仅是一个流行词？

传统的蓝绿部署会立即切换所有流量。滚动更新是逐步进行的，但缺乏精细控制。金丝雀部署赋予你超能力：你发布新版本，但只将例如 5% 的用户流量导向它。其余 95% 的用户仍在旧稳定版本上工作。你监控指标、错误和延迟。如果一切正常，就逐步将百分比提高到 100%。如果不正常，只需关闭金丝雀。

对于 C# 开发者来说，这尤其方便：我们可以使用 ASP.NET Core 的内置工具、Kubernetes、功能开关，甚至简单的负载均衡器。关键是正确的架构。

.NET 应用程序的金丝雀部署架构

假设我们有一个基于 ASP.NET Core 的 Web API，用于处理订单。我们想发布一个新的折扣计算逻辑。与其立即更新所有 Pod，不如：

\n
• 运行两个版本的服务：stable (v1) 和 canary (v2)。
\n
• 配置负载均衡器（例如 Nginx 或 Kubernetes Service），使 95% 的流量流向 v1，5% 流向 v2。
\n
• 在 canary 版本的响应中添加 HTTP 头 X-Canary: true 以进行标识。
\n
• 收集指标（200/500 状态码、延迟、订单数量）。
\n
• 如果在 30 分钟内错误率不超过 v1，则将 canary 的权重增加到 50%，然后增加到 100%。
\n

C# 实现：从简单到复杂

方法 1：通过 HTTP 头和负载均衡器实现金丝雀

最简单的方法是使用 ASP.NET Core 中的中间件层来标记请求。但首先，让我们看看区分金丝雀版本的代码是什么样的。

// Startup.cs 或 Program.cs\npublic class CanaryMiddleware\n{\n    private readonly RequestDelegate _next;\n    private readonly string _version;\n\n    public CanaryMiddleware(RequestDelegate next, string version)\n    {\n        _next = next;\n        _version = version;\n    }\n\n    public async Task InvokeAsync(HttpContext context)\n    {\n        // 添加用于标识版本的头部\n        context.Response.Headers.Add("X-App-Version", _version);\n        await _next(context);\n    }\n}\n\n// 注册\napp.UseMiddleware<CanaryMiddleware>("v2-canary");\n

现在，在负载均衡器层面（例如 Nginx），我们决定将多少百分比的流量发送到金丝雀 Pod：

upstream backend {\n    server app-stable:5000 weight=95;\n    server app-canary:5000 weight=5;\n}\n

优点：简单。缺点：没有程序化控制，难以按用户进行 A/B 测试。

方法 2：C# 中的功能开关

更灵活的方法是使用功能开关。你只为特定用户组启用新逻辑。ASP.NET Core 内置支持：

// 安装 Microsoft.FeatureManagement.AspNetCore 包\n// 在 Program.cs 中添加\nbuilder.Services.AddFeatureManagement();\n\n// 在 appsettings.json 中定义开关\n{\n  "FeatureManagement": {\n    "NewDiscountLogic": false\n  }\n}\n\n// 在控制器中使用\n[ApiController]\n[Route