路由基础概念：路由表、路由规则、静态路由与动态路由、路由匹配算法

好，咱们今天来聊聊路由的基础概念。说实话，很多做SaaS的同学一开始都觉得路由不就是转发请求吗？有什么好讲的？嗯，我当年也是这么想的。直到有一次线上事故，一个路由规则配错了，导致某个租户的请求全打到了另一个租户的实例上……那场面，真是冷汗直冒。

所以，路由这件事，看似简单，实则门道很深。咱们今天就把这几个核心概念掰开揉碎了讲清楚。

路由表：网关的“交通地图”

路由表是什么？说白了，它就是一张映射表。这张表告诉网关：当某个请求进来时，你应该把它送到哪里去。

我习惯把路由表想象成一张交通地图。地图上标明了每个目的地（后端服务）的路径和规则。网关拿到请求后，第一件事就是查这张地图。

一个典型的路由表条目，通常包含以下几个字段：

字段 说明 示例
路由ID 唯一标识一条路由规则 route_001
匹配条件 请求需要满足的条件（路径、方法、Header等） GET /api/v1/users/**
目标服务 请求转发到的后端服务地址 http://user-service:8080
优先级 多条规则匹配时的生效顺序 100
过滤器链 请求经过的预处理或后处理逻辑 auth_filter, rate_limit_filter

核心要点：路由表是网关的“大脑”。没有它，网关就是个摆设。我见过不少团队，路由表设计得一团糟，结果每次加新服务都要改半天配置，还容易出错。

路由规则：定义“怎么走”

路由规则，就是路由表里那些具体的“交通规则”。它告诉网关：什么样的请求，走什么样的路。

我个人习惯把路由规则拆成三部分来看：

  • 匹配条件：请求长什么样？比如路径是 /api/orders/**，方法是 POST，Header 里带了 X-Tenant-ID。
  • 转发动作：匹配上了之后怎么办？是直接转发到某个服务，还是先做点别的？
  • 附加行为：比如要不要加鉴权、要不要限流、要不要记录日志。

举个例子，一个常见的路由规则配置（我用 YAML 格式展示，因为可读性好）：

routes:
  - id: order_service_route
    uri: http://order-service:8080
    predicates:
      - Path=/api/orders/**
      - Method=GET,POST
    filters:
      - StripPrefix=1
      - AddRequestHeader=X-Source, gateway
    order: 1

你看，这条规则说：所有 /api/orders/** 的 GET 和 POST 请求，都转发到 order-service，同时去掉路径前缀 /api，再给请求头加个标记。

我的经验：路由规则一定要设计得“可读性强”。我曾经接手过一个项目，路由规则全是正则表达式，密密麻麻的，看得我头皮发麻。后来我花了两周时间，把所有规则改成了清晰的条件组合，团队效率直接翻倍。

静态路由 vs 动态路由

这两个概念，我当年刚接触时也迷糊过。其实区别很简单：

  • 静态路由：路由规则是写死的，改一次要重启网关。
  • 动态路由：路由规则可以运行时修改，网关自动生效。

你想想看，在 SaaS 系统里，租户是动态变化的。今天加一个新租户，明天上线一个新服务，如果每次都要重启网关……那运维同学怕是要骂娘了。

所以，生产环境里，我强烈建议用动态路由。静态路由只适合开发环境或者极其稳定的内部系统。

动态路由的实现方式，常见的有两种：

  1. 基于配置中心：路由规则存在 Nacos、Consul 或 Etcd 里，网关监听变化，实时更新。
  2. 基于数据库：路由规则存在数据库里，网关定期拉取或通过事件通知更新。

我个人更倾向于第一种。为什么呢？因为配置中心天生就是为了干这个的，高可用、强一致、实时推送，省心不少。

注意：动态路由虽好，但也要小心“配置漂移”。我曾经遇到过，运维同学在配置中心里改了一条规则，结果没通知任何人，导致某个服务突然收不到请求了。所以，动态路由一定要配合变更审计和灰度发布机制。

路由匹配算法：谁先命中谁先走

好了，路由表有了，规则也配好了。现在问题来了：一个请求进来，可能同时匹配多条规则，到底走哪条？

这就涉及到路由匹配算法了。说白了，就是决定规则优先级和匹配顺序的逻辑。

常见的匹配算法有这么几种：

算法 原理 适用场景
最长前缀匹配 路径匹配时，选择匹配路径最长的规则 RESTful API 路由
优先级排序 每条规则配一个优先级数字，数字越小越优先 通用场景，最灵活
首次匹配 按规则定义的顺序，第一个匹配上的就生效 简单场景，规则少时
权重匹配 按权重随机选择，常用于灰度发布 流量分发、A/B 测试

在实际的 API 网关里，比如 Spring Cloud Gateway 或 Kong，用的都是优先级排序 + 最长前缀匹配的组合。先按优先级排序，优先级相同的再按路径长度匹配。

举个例子：

规则A: Path=/api/users/**  优先级=100
规则B: Path=/api/users/123  优先级=100

请求: GET /api/users/123

匹配结果：规则B 胜出。因为路径更长，更具体。

你看，这就是最长前缀匹配的妙处。它让更具体的规则优先生效，避免了“一刀切”的问题。

避坑指南：我曾经犯过一个错误——把所有规则的优先级都设成了默认值。结果两条规则路径不同但优先级相同，匹配结果完全取决于加载顺序，导致线上出现了随机性的路由错误。所以，优先级一定要显式设置，不要依赖默认值。

小结

好了，今天的内容就到这里。咱们把路由的四个基础概念捋了一遍：

  • 路由表：网关的交通地图，存着所有规则。
  • 路由规则：具体的“怎么走”的指令。
  • 静态 vs 动态：生产环境用动态，开发环境用静态。
  • 匹配算法：优先级 + 最长前缀，最常用也最靠谱。

下一章，咱们会深入讲路由表的存储与更新机制。到时候我会分享一个我在生产环境里踩过的坑——路由表更新延迟导致的全站雪崩。嗯，那故事可精彩了，咱们下次聊。

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