YARP 全面详解

原创于 2025-10-23 18:50:55 发布 · 977 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#YARP

中间件专栏收录该内容

1 篇文章

订阅专栏

YARP 全面详解：.NET 平台的现代化反向代理库

一、核心定义：它是什么？

YARP 是 “Yet Another Reverse Proxy” 的缩写。顾名思义，它是一个“反向代理”。但其核心本质需要精确理解：

它是一个库，而非独立产品：YARP 以 NuGet 包的形式提供，你需要将它嵌入到你自己的 .NET 应用程序中。这与 Nginx 或 Envoy 等开箱即用的独立软件有根本区别。
它基于现代 .NET 构建：完全使用 C# 和 .NET 运行时，天生与 ASP.NET Core 生态无缝集成。
它被设计为高度可扩展的平台：其架构允许你通过标准的 .NET 代码和模式来定制几乎每一个环节，从路由决策到协议处理。

简单的比喻：如果说 Nginx 是一辆功能齐全的成品汽车，那么 YARP 就是一个模块化的汽车底盘和发动机，让你可以基于它制造出最适合自己需求的专用车辆（如方程式赛车、越野车或卡车）。

二、诞生背景与设计哲学：为什么是 YARP？

YARP 的诞生源于微软内部和现代云原生架构中遇到的实际挑战：

传统代理的僵化性：Nginx 等配置依赖于文件，动态变更和深度逻辑集成通常需要借助 Lua 等脚本语言，对于 .NET 团队来说，开发和调试流程割裂，不够灵活。
微服务网关的定制需求：在微服务架构中，网关需要理解业务逻辑，例如基于 JWT Token 中的声明进行路由、与特定服务发现系统集成、实现复杂的 A/B 测试策略等。通用代理的静态配置难以满足这些动态需求。
对性能和控制力的追求：微软需要一个能充分发挥 .NET 性能优势、并能通过代码进行细粒度控制的解决方案，避免为不需要的通用功能付出性能代价。
填补技术空白：在“重量级”服务网格（如 Istio，通常包含 Envoy）和“轻量级但不可编程”的传统代理之间，提供一个轻量级、可编程、与 .NET 深度集成的中间件。

设计哲学：将反向代理的能力 democratize（民主化），让普通 .NET 开发者能够使用熟悉的工具链（Visual Studio, C#, DI, Logging）来构建和运维一个高性能的代理组件。

三、核心架构与关键概念

要掌握 YARP，必须理解其架构中的几个核心抽象：

代理管道
YARP 自身是作为 ASP.NET Core 中间件 实现的。当你调用 app.MapReverseProxy() 时，就将 YARP 的管道插入到了 ASP.NET Core 的请求处理流程中。这意味着：
- 你可以在 YARP 之前添加认证、日志等中间件。
- YARP 之后可以接其他中间件（尽管不常见）。
- 它完全受益于 .NET 的底层性能优化（如 HttpClient 池化、Span<T> 操作）。
路由
一个路由规则定义了“哪些请求应该被代理”以及“匹配后怎么做”。
- 匹配条件：可以基于 Path（路径）、Host（主机头）、Methods（HTTP 方法）、Headers（请求头）、Query Parameters（查询字符串）等进行复杂匹配。
- 关联：每个路由必须关联一个集群。
- 顺序：路由按配置顺序评估，第一个匹配的路由将被执行。
集群
集群是一组逻辑上相同的后端服务（称为“目的地”）的集合。
- 目的地：后端服务的实际地址（URL）。一个集群可以有一个或多个目的地。
- 负载均衡：YARP 内置了多种算法：
  - PowerOfTwoChoices（默认）：选择两个随机目的地，然后向其中负载更轻的一个发送请求。在性能和公平性间取得最佳平衡。
  - RoundRobin：轮询。
  - LeastRequests：选择当前活跃请求最少的目的地。
  - FirstAlphabetical：按目的地地址字母顺序选择（主要用于测试）。
  - 可扩展：你可以轻松实现 ILoadBalancingPolicy 接口来自定义算法。
- 会话亲和性：基于 Cookie 确保来自同一客户端的请求落到同一后端实例。
目的地健康检查
YARP 可以主动探测后端服务的健康状态，自动从负载均衡池中移除不健康的实例。
- 主动健康检查：YARP 定期向配置的端点（如 /health）发送探测请求。
- 被动健康检查：YARP 会记录转发请求的失败情况（如连接超时、返回 5xx 错误），当失败次数超过阈值时，自动将目的地标记为不健康。
转换
这是 YARP 非常强大的功能，允许在转发请求前和返回响应后修改其内容。
- 请求转换：修改路径、添加/删除/修改请求头、变更 HTTP 版本等。
- 响应转换：修改状态码、添加/删除响应头等。
- YARP 提供了一系列内置的转换，也支持通过代码实现完全自定义的转换逻辑。

四、核心特性深度解析

1. 极致的可配置性
- 配置文件：可通过 appsettings.json 进行静态配置，非常适合初始设置和环境相关配置。
- 代码配置：在 Program.cs 中通过代码流畅地配置路由和集群。
- 动态配置：这是 YARP 的精髓。你可以通过实现 IProxyConfigProvider 和 IProxyConfig 接口，从任何来源（如数据库、Apollo、Consul、Azure App Configuration）动态加载配置。这意味着你可以在不重启代理服务的情况下，实时更新路由规则和目的地列表。
2. 深入骨髓的可扩展性
几乎每一个环节都是可插拔的：
- 自定义代理中间件：你可以在 YARP 的管道中添加自己的中间件，在路由发生前后执行逻辑。
- 自定义配置提供程序：实现动态配置。
- 自定义负载均衡器：实现特定业务逻辑的负载均衡。
- 自定义目的地选择器：完全接管目的地选择过程。
- 与服务发现集成：通过实现自定义配置提供程序，可以轻松地从 Consul、Eureka 或 Kubernetes API 中动态获取目的地列表。
3. 原生 .NET 生态集成
- 依赖注入：YARP 的所有组件都通过 DI 容器管理，你可以轻松地替换默认实现。
- 日志：使用标准的 ILogger 接口，与你的应用程序日志完美统一。
- 配置：使用 IOptions 模式。
- 健康检查：YARP 自身可以暴露健康检查端点，方便编排系统（如 Kubernetes）探测其状态。
- 认证与授权：你可以在 YARP 中间件之前轻松添加 UseAuthentication 和 UseAuthorization 中间件，实现网关级别的统一安全管控。

五、典型使用场景

微服务 API 网关：这是 YARP 的首要场景。构建一个统一入口，处理认证、授权、限流、熔断、日志聚合、路由转发等所有横切关注点。
渐进式应用迁移：将大型单体应用拆分为微服务时，使用 YARP 将 /api/orders 路由到新的订单服务，而其他请求仍导向旧单体，实现平滑迁移。
复杂的部署策略：
- 金丝雀发布：将 5% 的流量根据特定头信息路由到新版本服务。
- A/B 测试：基于用户 ID 或 Cookie 将用户定向到不同功能版本的后端。
协议桥接与请求重塑：在内部 gRPC 服务和外部 RESTful API 之间进行转换（需要额外处理），或为前端应用统一 API 路径。
开发环境代理：为前端开发人员提供一个统一代理，解决跨域和多服务联调问题。

六、快速入门与进阶示例

基础配置示例 (Program.cs):

var builder = WebApplication.CreateBuilder(args);

// 1. 添加YARP服务
builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("Yarp")); // 从配置节加载

var app = builder.Build();

// 2. 映射反向代理
app.MapReverseProxy();

app.Run();

对应 appsettings.json 配置:

{
  "Yarp": {
    "Routes": {
      "route-order-service": {
        "ClusterId": "cluster-order-service",
        "Match": {
          "Path": "/order/{**catch-all}"
        },
        "Transforms": [
          { "PathPattern": "/api/{**catch-all}" } // 将 /order/ 路径重写为 /api/
        ]
      },
      "route-user-service": {
        "ClusterId": "cluster-user-service",
        "Match": {
          "Path": "/user/{**catch-all}"
        }
      }
    },
    "Clusters": {
      "cluster-order-service": {
        "LoadBalancingPolicy": "LeastRequests",
        "Destinations": {
          "order-service-1": { "Address": "https://order-service-1:7001/" },
          "order-service-2": { "Address": "https://order-service-2:7002/" }
        },
        "HealthCheck": {
          "Active": {
            "Enabled": true,
            "Path": "/health",
            "Interval": "00:00:10",
            "Timeout": "00:00:05"
          }
        }
      },
      "cluster-user-service": {
        "Destinations": {
          "user-service": { "Address": "https://user-service:7003/" }
        }
      }
    }
  }
}

进阶：代码动态配置示例

builder.Services.AddReverseProxy()
    .LoadFromMemory(GetRoutes(), GetClusters()); // 从内存中加载

// ... 在代码中定义路由和集群
private static RouteConfig[] GetRoutes() => new[]
{
    new RouteConfig
    {
        RouteId = "dynamic-route",
        ClusterId = "dynamic-cluster",
        Match = new RouteMatch { Path = "/dynamic/{**catch-all}" }
    }
};

private static ClusterConfig[] GetClusters() => new[]
{
    new ClusterConfig
    {
        ClusterId = "dynamic-cluster",
        Destinations = new Dictionary<string, DestinationConfig>
        {
            { "destination1", new DestinationConfig { Address = "https://example.com" } }
        }
    }
};

七、与其他技术的对比与定位

维度	YARP	Nginx	Envoy
形态	.NET 库	独立二进制	独立二进制 / C++ 库
配置模式	代码即配置、JSON、任何动态源	静态文本文件 + Lua	静态文件 + xDS API
扩展方式	.NET 代码（C#）	C 模块、Lua 脚本	C++ 过滤器、Lua 脚本
.NET 集成度	原生、完美	无	无
性能	极优（与 Envoy 同级）	极优	极优
学习成本	对 .NET 团队极低	学习新语法和模式	概念复杂，曲线陡峭
核心优势	定制化、灵活性、.NET 亲和性	成熟、稳定、功能全面	云原生、服务网格、动态配置

定位总结：

选择 YARP：当你需要构建一个高度定制化的网关，你的团队是 .NET 技术栈，并且希望网关逻辑与业务代码深度集成、使用统一工具链进行开发调试时。
选择 Nginx：当你需要一个功能全面、稳定可靠、开箱即用的通用 Web 服务器/代理，且静态配置足以满足需求时。
选择 Envoy：当你深度投入服务网格（如 Istio），或者需要其强大的 xDS API 生态进行复杂的流量管理时。