云网关路由技术解析 - 知用网网络运维专栏

云网关不是简单的转发器

很多人以为云网关就是把请求从外网转到内网，像小区门卫一样递个话就完事。其实没那么简单。在复杂的微服务架构里，一个请求进来，得知道它该去哪个服务、走哪条链路、有没有权限、要不要限流。这些决策都靠云网关的路由技术来完成。

比如你用手机点外卖，点击“提交订单”那一刻，请求并不是直奔订单系统的。它先撞上云网关，网关一看路径是 /api/v1/order，再查一下路由表，发现这应该交给 order-service 处理，于是悄悄把请求转发过去，整个过程用户毫无感知。

路由规则怎么定？

路由的核心是匹配规则。常见的有基于路径、域名、请求头甚至参数的匹配。比如：

{
  "route": "order-route",
  "uri": "http://order-service:8080",
  "predicates": [
    "Path=/api/v1/order/**",
    "Host=api.mall.com"
  ],
  "filters": [
    "AddRequestHeader=Service-Name,order-gateway"
  ]
}

上面这段配置的意思是：只要请求的路径符合 /api/v1/order/**，并且 Host 是 api.mall.com，那就转发到 order-service:8080。同时，网关还会自动加个请求头，方便后端做日志追踪。

动态路由：不停机也能改路径

传统做法是把路由写死在配置文件里，改一次就得重启。但在云环境下，服务可能随时扩容、下线，路由也得跟着变。这时候就得靠动态路由。

比如结合 Nacos 或 Consul 这类注册中心，服务一上线，网关立刻感知到，自动生成对应的路由规则。你不需要手动添加一条 /user/** → user-service，系统自己就配好了。相当于你家快递柜能自动识别新搬来的邻居，不用物业挨个登记。

灰度发布靠路由策略

上线新功能时，没人敢直接全量推送。通常先让一部分用户试用，看有没有问题。这个“一部分”，就是靠网关路由控制的。

比如根据请求头里的 User-Tag: beta，把这部分流量引向新版本的服务实例：

"predicates": [
  "Header=User-Tag,beta",
  "Path=/api/v1/recommend"
],
"uri": "http://recommend-service-v2"

普通用户继续走老版本，内测用户走新逻辑。出了问题，关掉这条路由就行，不影响整体服务。

性能和高可用不能妥协

网关是所有流量的必经之路，一旦挂了，整个系统对外就失联了。所以部署时通常会做集群，配合负载均衡，比如用 Kubernetes 的 Ingress Controller 挂多个网关实例。

同时，路由匹配要快。如果每来一个请求都要遍历几十条规则，延迟立马就上去了。优秀的网关会把路由表构建成树形结构或哈希索引，做到 O(1) 查找。

像 Spring Cloud Gateway 就用了 Reactor 模型，非阻塞异步处理，单机扛几万 QPS 没问题。你在直播间抢券，背后可能就是这类网关在撑着。

安全也在路由里体现

有些路径需要鉴权，有些则公开访问。路由配置可以直接绑定过滤器，比如：

"filters": [
  "AuthenticationFilter",
  "RateLimiter=100,1s"
]

意思是这个路由下的接口必须通过身份验证，并且每秒最多调用 100 次。相当于小区大门只认业主卡，访客还得登记，高峰期还限流放行。