在 .NET 中实现灰度部署

在 .NET 中实现灰度部署（又称金丝雀发布），核心是通过策略将部分流量引导到新版本服务，逐步验证稳定性后再全量切换。以下是几种常见的实现方式，适用于不同场景（如单体应用、微服务、容器化部署等）：

一、基于反向代理/网关的灰度（推荐）

通过反向代理或 API 网关层实现流量分流，无需修改应用代码，适合大多数场景（尤其微服务架构）。

1. Nginx 配置灰度

利用 Nginx 的 split_clients 或 map 模块按比例/规则分流：

# 按比例分流（例如 10% 流量到新版本）
split_clients "${remote_addr}" $app_version {
    10% "v2";
    * "v1";
}

server {
    listen 80;
    location / {
        # 根据 $app_version 转发到对应版本的服务
        if ($app_version = "v2") {
            proxy_pass http://new_service:5000;
        }
        proxy_pass http://old_service:5000;
    }
}

也可按用户 ID、IP、Header 等规则分流（更精准）：

# 按用户 ID 白名单分流（仅特定用户访问新版本）
map $http_user_id $app_version {
    default "v1";
    "~^(1001|1002|1003)$" "v2"; # 用户 ID 为 1001/1002/1003 访问 v2
}

2. 云原生网关（如 Kong、APISIX）

若使用云原生架构，可通过网关的插件机制实现更灵活的灰度策略：

• Kong：使用 request-transformer 插件标记流量，结合 route 路由到不同服务版本。
• APISIX：通过 traffic-split 插件按权重/条件分流，支持动态调整。

二、基于服务注册中心的灰度（微服务场景）

在微服务架构中，结合服务注册中心（如 Consul、Eureka、Nacos）实现服务版本的动态发现和路由。

1. Consul + 服务网格（如 Istio）

• 服务注册时携带版本标签（如 version=v1 或 version=v2）。
• 通过 Istio 的 VirtualService 配置流量规则：

  apiVersion: networking.istio.io/v1alpha3
  kind: VirtualService
  metadata:
    name: my-service
  spec:
    hosts:
    - my-service
    http:
    - route:
      - destination:
          host: my-service
          subset: v1
        weight: 90 # 90% 流量到 v1
      - destination:
          host: my-service
          subset: v2
        weight: 10 # 10% 流量到 v2
  

2. .NET 结合 Nacos 的元数据路由

Nacos 支持基于服务元数据的灰度：

• 服务注册时添加元数据（如 version=v2）。
• 客户端通过 Nacos SDK 过滤服务实例，例如：

  // 从 Nacos 获取服务实例时，指定版本过滤条件
  var instances = await _nacosClient.SelectInstancesAsync("my-service", true, 
      new Dictionary<string, string> { { "version", "v2" } });
  

  可结合配置中心动态调整过滤规则（如仅对特定用户开放 v2）。

三、应用内灰度（代码层控制）

在应用内部通过配置或规则判断流量走向，适合单体应用或无网关场景。

1. 基于配置中心的开关

使用配置中心（如 Apollo、Consul Config）动态配置灰度规则：

public class GrayMiddleware
{
    private readonly RequestDelegate _next;
    private readonly IConfiguration _config;

    public GrayMiddleware(RequestDelegate next, IConfiguration config)
    {
        _next = next;
        _config = config;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // 从配置中心获取灰度规则（如用户白名单）
        var whiteList = _config.GetSection("Gray:UserWhiteList").Get<List<string>>();
        var userId = context.Request.Headers["User-Id"].FirstOrDefault();

        if (whiteList.Contains(userId))
        {
            // 灰度流量：使用新版本逻辑
            context.Items["Version"] = "v2";
        }
        else
        {
            // 正常流量：使用旧版本逻辑
            context.Items["Version"] = "v1";
        }

        await _next(context);
    }
}

// 在控制器中根据版本区分逻辑
public IActionResult GetData()
{
    var version = HttpContext.Items["Version"].ToString();
    if (version == "v2")
    {
        return Ok(new V2DataService().GetData());
    }
    return Ok(new V1DataService().GetData());
}

2. 按比例随机分流

通过随机数实现流量比例分配（需注意分布式环境的随机性一致性）：

// 10% 流量进入灰度版本
var random = new Random();
if (random.Next(100) < 10)
{
    // 灰度逻辑
}

四、容器化部署的灰度（K8s 场景）

在 Kubernetes 中，可通过以下方式实现：

1. 滚动更新（Rolling Update）：逐步替换旧 Pod，通过 maxSurge 和 maxUnavailable 控制更新速度（默认策略）。
2. 金丝雀部署：先部署少量新版本 Pod（如 1 个），手动验证后扩展副本数。
3. 蓝绿部署：部署一套全新的“绿”环境（新版本），验证通过后切换 Service 指向。
4. 使用 Argo Rollouts：更高级的滚动更新工具，支持按比例、暂停、自动回滚等灰度策略。

关键注意事项

1. 数据隔离：灰度版本若涉及数据库变更，需确保新旧版本兼容（如先兼容后清理）。
2. 监控与回滚：实时监控灰度版本的错误率、性能，配置自动回滚触发条件（如错误率超过阈值）。
3. 流量一致性：确保同一用户/会话的请求始终路由到同一版本（避免数据不一致）。

根据架构选择合适的方案：网关层灰度最通用，服务注册中心适合微服务，应用内灰度适合简单场景，容器化部署则结合 K8s 工具更高效。