Ocelot 网关与 Consul 服务发现初探

2026-09-12 · .NET / 微服务

练手项目拆成了几个后端服务之后，第一个问题就是：前端该调谁？总不能让浏览器记住每个服务的地址。这篇整理用 Ocelot 做统一网关的学习笔记。

一、网关解决什么问题

• 统一入口：外部只认识一个地址，路由转发到内部各服务；
• 横切关注点收口：JWT 认证、限流、跨域在网关做一次，内部服务不用重复实现；
• 屏蔽内部结构：服务怎么拆、怎么迁移，对外部透明。

二、Ocelot 的路由模型

核心就两个概念：Upstream（对外暴露的路径）和 Downstream（内部真实服务的地址）。一条路由就是把「外面的什么请求」映射到「里面的哪个服务」：

{
  "UpstreamPathTemplate": "/api/store/{everything}",
  "DownstreamPathTemplate": "/api/store/{everything}",
  "DownstreamHostAndPorts": [ { "Host": "store-service", "Port": 8080 } ]
}

写的时候踩过一个顺序问题：路由是按配置顺序匹配的，精确路由必须放在通配路由前面，否则永远命不中。

三、静态路由还是服务发现？

Ocelot 两种玩法都支持：静态路由直接写死下游地址，简单直接；配合 Consul 可以按服务名自动发现实例，服务扩缩容不用改网关配置。我的体会是：容器编排里服务名本身就是稳定的（compose 网络的服务名解析），小规模先静态路由完全够用，等实例数真正动态变化再上服务发现，不要为了架构图好看引入组件。

四、反向代理 WebSocket 的两个请求头

网关后面的服务里有 SignalR 长连接，开始怎么都连不上。原因是 HTTP → WebSocket 的升级握手需要两个头原样透传：

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

缺了任何一个，握手请求会被当成普通 HTTP 处理，长连接直接失败。这是反向代理 WebSocket 的通用配置，Nginx 上同理。

小结

网关的价值在「收口」，但组件本身要克制——路由匹配顺序、请求头透传这类细节才是日常踩坑的主战场。服务发现等流量规模到了再上。