3、.NET 生态下的网关选型：Ocelot、YARP、Kong、Azure API Management 对比

做微服务，网关是绕不开的坎。说白了，它就是整个系统的“大门”，所有请求都得从这儿过。选错了，后面改起来真要命。

今天咱们就聊聊 .NET 生态里最常见的四个网关：Ocelot、YARP、Kong 和 Azure API Management。我挨个用过，踩过坑，也尝过甜头。希望能帮你少走弯路。

3.1 Ocelot：.NET 老牌网关，社区成熟

Ocelot 算是 .NET 圈子里最早火起来的网关之一。我记得 2018 年那会儿，公司要搞微服务，第一个想到的就是它。

核心特点：

  • 纯 .NET 实现，部署简单，直接 NuGet 包引用
  • 配置驱动，路由、限流、负载均衡全写在 JSON 里
  • 支持服务发现（Consul、Eureka）
  • 内置限流、缓存、认证、请求聚合

举个例子，Ocelot 的限流配置长这样：

{
  "Routes": [
    {
      "DownstreamPathTemplate": "/api/users/{id}",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        { "Host": "localhost", "Port": 5001 }
      ],
      "RateLimitOptions": {
        "ClientWhitelist": [],
        "EnableRateLimiting": true,
        "Period": "1s",
        "PeriodTimespan": 1,
        "Limit": 5
      }
    }
  ]
}

嗯，这里要注意：Ocelot 的限流是基于内存的，单机部署没问题。但如果你搞多实例，就得自己想办法共享状态。我曾经在项目里踩过这个坑——两台 Ocelot 实例，限流各自为政，结果用户刷了 10 次请求才被拦住。

避坑指南： Ocelot 的限流不支持分布式。多实例部署时，建议配合 Redis 做计数器，或者直接用 YARP 替代。

3.2 YARP：微软亲儿子，性能怪兽

YARP 是微软官方出的反向代理库。说实话，我第一次看到它的性能测试数据时，有点不敢相信——比 Ocelot 快了好几倍。

为什么快？

  • 底层直接操作 ASP.NET Core 管道，没有额外抽象层
  • 支持 HTTP/2、gRPC、WebSocket
  • 动态路由，运行时可以改配置
  • 可扩展性强，中间件随便插

YARP 的限流需要自己写中间件，或者配合 AspNetCoreRateLimit 使用。我个人习惯用中间件方式，灵活度高：

public class RateLimitingMiddleware
{
    private readonly RequestDelegate _next;
    private static readonly ConcurrentDictionary<string, int> _counters = new();

    public RateLimitingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var clientIp = context.Connection.RemoteIpAddress?.ToString();
        var key = $"{clientIp}:{DateTime.UtcNow.Minute}";

        _counters.AddOrUpdate(key, 1, (_, count) => count + 1);

        if (_counters[key] > 100)
        {
            context.Response.StatusCode = 429;
            await context.Response.WriteAsync("Too Many Requests");
            return;
        }

        await _next(context);
    }
}

你想想看，YARP 的定位其实很明确——它不是一个“开箱即用”的网关，而是一个“造网关的框架”。如果你团队有 .NET 高手，愿意自己封装，YARP 绝对是最佳选择。

我的建议： 中小团队选 Ocelot，省心。大团队或者对性能有极致要求的，上 YARP。

3.3 Kong：非 .NET 选手，但生态强大

Kong 是用 Lua 写的，基于 OpenResty（Nginx + LuaJIT）。虽然跟 .NET 没关系，但很多 .NET 项目也在用。

Kong 的优势：

  • 插件生态丰富：限流、认证、日志、监控，应有尽有
  • 性能极高，毕竟底层是 Nginx
  • 支持声明式配置（DB-less 模式）
  • 企业版有 GUI 管理界面

Kong 的限流插件配置很简单：

# 启用限流插件
curl -X POST http://localhost:8001/services/my-service/plugins \
  --data "name=rate-limiting" \
  --data "config.second=5" \
  --data "config.hour=10000"

我曾经在一个高并发项目里用过 Kong，单机扛住了 10 万 QPS。但说实话，维护成本不低——你得单独部署 Kong 集群，还得管 PostgreSQL 或 Cassandra 做数据存储。对于纯 .NET 团队来说，学习曲线有点陡。

注意： Kong 的限流默认是本地计数器，多节点需要配置 Redis 做同步。别问我怎么知道的——线上被 DDoS 那次，我到现在还记得。

3.4 Azure API Management：云原生首选，但贵

如果你公司已经上了 Azure，那 Azure API Management（简称 APIM）几乎是必选项。它不只是网关，更是一个完整的 API 管理平台。

APIM 的亮点：

  • 全托管服务，不用自己运维
  • 内置限流、配额、缓存、转换、版本管理
  • 支持 OpenAPI/Swagger 自动导入
  • 开发者门户，方便第三方接入

APIM 的限流策略通过 Policy 配置，用 XML 写：

<policies>
  <inbound>
    <rate-limit calls="10" renewal-period="60" />
    <quota calls="1000" renewal-period="86400" />
  </inbound>
</policies>

嗯，这里要吐槽一下：APIM 的价格是真的贵。基础版一个月就要几百美金，高级版更是天价。我建议中小项目别碰，除非你预算充足。

避坑指南： APIM 的限流是分布式且精确的，但注意——它不支持秒级限流，最小单位是分钟。如果你需要精细到每秒，还是得自己写中间件。

3.5 横向对比：一张表说清楚

维度 Ocelot YARP Kong Azure APIM
语言 C# C# Lua/C 托管服务
性能 中等 高 极高 中等
限流能力 基础（内存） 需自实现 强大（插件） 强大（托管）
分布式限流 需扩展 需扩展 支持（Redis） 原生支持
运维成本 低 中 高 无（托管）
学习曲线 低 中 高 中
适用场景 中小项目 高性能需求 高并发、多语言 Azure 生态

3.6 我的选型建议

说了这么多，到底怎么选？我总结几条经验：

  • 团队全是 .NET 人，项目不大： 无脑 Ocelot。配置简单，社区资料多，出问题好排查。
  • 团队有 .NET 高手，性能要求高： 上 YARP。自己封装限流、认证，灵活度拉满。
  • 公司有运维团队，多语言微服务： 考虑 Kong。插件生态无敌，但别指望 .NET 程序员去维护 Lua 插件。
  • 公司上云，预算充足： Azure APIM。省心省力，但钱包会哭。

最后说一句：没有完美的网关，只有适合你的网关。选型时多想想团队能力、运维成本和业务场景，别盲目追新。

下一章，咱们手把手用 Ocelot 搭一个带限流的网关，到时候见。

← 上一章 📖 返回目录 下一章 →