路由设计原则：从混乱到有序的必经之路
路由设计这件事，我做了十几年网关，踩过的坑比走过的路还多。说实话，很多团队一开始都不重视路由设计，觉得「能通就行」。结果呢？系统一膨胀，路由表乱成一锅粥，改一个接口要排查半天。
今天咱们聊聊路由设计的四个核心原则：粒度、优先级、分组、版本管理。这四个点搞明白了，你的API网关至少能撑到百万级流量。
一、路由粒度设计：粗了不行，细了也不行
路由粒度，说白了就是「一个路由规则管多宽」。我见过有人把整个微服务的所有接口都映射到一条路由上，也见过有人给每个HTTP方法都单独写一条路由。这两种极端，都不对。
核心原则：路由粒度应该与业务边界对齐，而不是与技术实现对齐。
举个例子。假设你有一个用户服务，包含登录、注册、获取用户信息三个接口。你会怎么设计路由？
// 方案A：粗粒度（不推荐）
/api/user/* -> user-service
// 方案B：中粒度（推荐）
/api/user/login -> user-service:login
/api/user/register -> user-service:register
/api/user/info -> user-service:info
// 方案C：细粒度（过度设计）
/api/user/login -> user-service:login:POST
/api/user/register -> user-service:register:POST
/api/user/info -> user-service:info:GET
方案A的问题很明显：所有请求都打到同一个服务，你没法针对登录接口做限流，也没法单独升级获取用户信息的逻辑。方案C呢？维护成本太高，每加一个HTTP方法就要改路由表。
我个人习惯用中粒度。按业务操作来划分路由，一个操作对应一条路由。这样既保留了灵活性，又不会让路由表膨胀到失控。
避坑指南：我曾经在一个项目中，把路由粒度设计得特别细，每个参数组合都对应一条路由。结果路由表从50条膨胀到2000条，每次发布都要等半小时才能同步完。后来我学乖了——路由粒度，够用就好。
二、路由优先级：谁先匹配，谁说了算
路由优先级，这是个容易踩坑的地方。你想想看，如果两条路由都能匹配同一个请求，到底走哪条？
我见过最典型的错误：
// 路由表
1. /api/user/* -> user-service
2. /api/user/vip/* -> vip-service
如果请求是 /api/user/vip/info，理论上应该走第二条路由。但如果网关按「先注册先匹配」的规则，第一条路由先匹配到了，请求就被转发到user-service了。vip用户的数据就丢了。
路由优先级的设计原则：
- 精确匹配优先于通配符匹配：
/api/user/vip/info比/api/user/*更精确，应该优先匹配 - 长路径优先于短路径：路径越长，匹配优先级越高
- 特殊规则优先于通用规则：比如黑名单路由应该优先于白名单路由
注意：很多网关框架默认是按注册顺序匹配的。如果你用的是这类框架，一定要把精确路由放在通配路由前面。我曾经因为这个坑，导致线上vip用户的数据全部走错了服务，排查了整整一个下午。
我建议的做法是：在路由设计阶段就明确优先级规则，并且在路由表中显式标注优先级数值。比如：
// 优先级数值越小，优先级越高
1. /api/user/vip/* (priority: 10) -> vip-service
2. /api/user/* (priority: 20) -> user-service
这样不管路由怎么排序，优先级都不会乱。
三、路由分组：让混乱变得有序
当你的路由表超过100条时，不分组就是灾难。你想想看，一个文件里躺着几百条路由，你要找一个接口对应的路由，得翻半天。
路由分组的原则：
- 按业务域分组：用户相关的路由放一组，订单相关的放一组
- 按版本分组：v1版本的路由放一组，v2版本的放一组
- 按环境分组：测试环境的路由和正式环境的路由分开
我常用的分组方式是这样的：
// 用户服务 - v1版本
group: user-v1
/api/user/login -> user-service-v1:login
/api/user/register -> user-service-v1:register
// 用户服务 - v2版本
group: user-v2
/api/user/login -> user-service-v2:login
/api/user/register -> user-service-v2:register
/api/user/logout -> user-service-v2:logout
// 订单服务
group: order
/api/order/create -> order-service:create
/api/order/query -> order-service:query
分组的好处是什么？隔离性。某个分组出问题了，不会影响其他分组。而且分组可以独立配置中间件，比如用户分组可以加认证中间件，订单分组可以加幂等中间件。
小技巧：我习惯在分组名称中加入版本号，比如 user-v1、user-v2。这样一眼就能看出哪个分组是哪个版本，不会搞混。
四、路由版本管理：向前兼容的艺术
路由版本管理，这是SaaS系统绕不开的话题。你的API不可能永远不变，但你又不能强迫所有客户端立刻升级。
常见的版本管理策略：
| 策略 | 实现方式 | 优点 | 缺点 |
|---|---|---|---|
| URL路径版本 | /api/v1/user, /api/v2/user | 直观，容易理解 | URL会变长，不够优雅 |
| 请求头版本 | Accept: application/vnd.myapp.v1+json | URL保持简洁 | 调试不方便，需要额外解析 |
| 参数版本 | /api/user?version=1 | 实现简单 | 容易被忽略，缓存不友好 |
我个人推荐URL路径版本。虽然看起来不够「优雅」，但胜在直观。你想想看，一个运维人员在排查问题时，看到 /api/v2/user/login 就知道是v2版本的接口，不需要去查文档。
版本管理的核心原则：
- 向后兼容：新版本不能破坏旧版本的逻辑
- 平滑迁移：旧版本要保留足够长的过渡期
- 版本淘汰机制：设定版本的生命周期，到期后自动下线
我曾经踩过的坑：有一个项目，我们同时维护了v1、v2、v3三个版本。结果v1版本的用户越来越少，但没人敢下线。最后v1版本成了技术债务，每次升级都要兼容v1的逻辑。后来我定了一个规则：每个版本最多维护18个月，到期后强制升级。虽然客户一开始有意见，但长期来看，对大家都好。
总结一下
路由设计这四个原则，说白了就是：
- 粒度：按业务操作划分，别太粗也别太细
- 优先级：精确匹配优先，长路径优先
- 分组：按业务域分组，实现隔离和独立配置
- 版本管理：URL路径版本最直观，记得设定版本生命周期
嗯，这些原则看起来简单，但真正落地的时候，你会发现每个点都有不少细节。下一章咱们聊聊路由的动态配置和热更新，那才是真正考验网关设计能力的地方。