📚 课程目录第2章路由策略基础

2. 路由策略基础：什么是路由策略，核心要素

好，我们正式进入这门课的核心区域了。讲多活部署，绕不开一个话题：流量到底怎么走？这个问题，说白了就是路由策略要干的活。

我记得刚接触多活那会儿，觉得路由不就是配个DNS解析嘛，把用户指向最近的数据中心就行。结果呢？第一次做灰度发布时，流量全打到新版本上去了，差点把线上搞崩。从那以后我意识到——路由策略可不是简单的“指路”，它是整个多活系统的神经中枢。

2.1 路由策略到底是什么？

我个人的理解，路由策略是一套决定流量如何分发、如何路由、如何隔离的规则体系。它不是一个单一的配置项，而是一个组合拳。

从技术层面拆解，路由策略至少包括三层含义：

流量入口层：用户请求从哪进？是DNS就近解析，还是通过Global Load Balancer分配？
应用路由层：请求到达网关后，该去哪个Region？哪个Cluster？哪个Pod？
数据路由层：读写操作该路由到哪个数据库分片？是否要做读写分离？

为什么要分层？你想想看，如果这三层混在一起管理，出问题的时候你根本不知道是DNS没配好，还是网关规则写错了，或者缓存穿透了数据库。

核心观点：路由策略的本质是可控的流量调度。不可控的调度叫“流量乱窜”，可控的才叫“策略”。

2.2 路由策略的核心要素

这些年摸爬滚打下来，我总结了四个核心要素，缺一不可。咱们一个一个聊。

2.2.1 流量来源与特征

这是路由策略的输入。你得先知道是谁在发请求，才能决定怎么路由。常见的流量来源包括：

用户终端：App、浏览器、IoT设备。特征包括IP归属地、用户ID、国家码、语言偏好。
内部服务：微服务间的RPC调用。特征通常是Header里的traceId、服务名、环境标识。
定时任务/批处理：这类流量往往对延迟不敏感，但对带宽和稳定性要求高。

我在项目中遇到过一个大坑：把内部服务调用的流量和外部用户流量混在一起做路由。结果内部服务重试风暴，直接把网关打挂了。后来我们给内部服务单独加了个Header标记，路由规则里优先识别这个标记。

2.2.2 目的地与映射关系

这是路由策略的输出。流量最终要去哪？核心是建立流量特征到目的地的映射关系。

目的地可以按粒度分：

粒度	描述	例子
Region级	跨地域流量调度	华东用户 -> 上海Region
AZ级	同一地域内的可用区切换	上海Region -> 可用区B
Cluster级	Kubernetes集群间的分流	灰度用户 -> 新版本Cluster
实例级	负载均衡到具体Pod/VM	按权重分发到3个Pod

个人建议：映射关系不要写死在代码里。一定要做成可配置、可动态加载的。我曾经在代码里硬编码了路由映射，结果一次机房迁移，改了一周的代码才搞定。

2.2.3 规则与条件

这是路由策略的大脑。规则到底怎么写？常见的条件类型有：

基于地理位置：IP归属地匹配，比如cn-north -> 北京Region。
基于用户属性：VIP用户路由到高配集群；测试用户路由到灰度环境。
基于时间窗口：白天流量走线上环境，凌晨做数据同步。
基于负载指标：当前Region负载超过80%，自动迁移流量到其他Region。

嗯，这里要注意一个很隐晦的问题：规则执行的先后顺序。我遇到过的情况是，同时配置了“地理位置优先”和“灰度用户优先”，结果地理位置规则先执行，灰度用户永远匹配不上。所以，规则一定要有明确的优先级和短路机制。

避坑指南：我曾经在规则引擎里用了“取最低优先级”策略，结果所有规则都生效，流量被分到了四个不同的Region。测试环境一片混乱。从那以后，我统一用“匹配即终止”模式。

2.2.4 动作与副作用

规则匹配之后，得执行动作。动作不只是“转发”这么简单，我归纳了四种常见动作：

直接转发：把请求转发到指定实例。
重写/改造：修改请求Header、Path，甚至把HTTP转成gRPC。
拒绝/限流：当目的地不可达时，返回503或降级响应。
记录/审计：记录路由决策的日志，用于事后分析。

你想想看，如果没有“重写”这个动作，灰度发布怎么隔离？用户请求打到新版本，但Header里没有灰度标识，新版本就不知道该怎么处理。所以，路由策略的每个动作都得考虑清楚副作用。

2.3 路由策略的决策流程

光讲要素有点抽象。来，我画个图，把四个要素串起来。

这个流程，说白了就是：流量进来 → 识别你是谁 → 查规则表 → 决定你去哪 → 执行动作。每一步都依赖上面讲的四个要素。

2.4 路由策略的分类维度

为了方便理解和选型，我把常见的路由策略按两个维度分类：

2.4.1 按决策时机分类

静态路由：规则在部署时确定，运行期不变。比如“所有来自南方的流量都走深圳Region”。好处是简单、性能好，坏处是不够灵活。我建议刚起步的多活系统先用静态路由，踩坑成本低。
动态路由：规则根据实时数据（如负载、延迟、错误率）自动调整。比如“当上海Region延迟超过100ms时，开始迁移流量到杭州”。好处是自适应，坏处是复杂度高，容易产生震荡。

我个人经验是：能用静态解决的，就别上动态。动态路由的调优周期太长，而且测试很难覆盖所有场景。

2.4.2 按路由层级分类

层级	典型技术	决策粒度
全局路由	DNS、GSLB	用户 → Region
网关路由	API Gateway、Ingress	请求 → Service
服务路由	Service Mesh、RPC框架	上游 → 下游实例
数据路由	ShardingSphere、Vitess	SQL → 数据库分片

嗯，这里要注意：不同层级的路由策略是叠加的，不是互斥的。一个请求，可能先经过GSLB路由到Region，再经过网关路由到Service，最后经过Service Mesh路由到具体Pod。每一层都得配策略，而且策略必须保持一致。

2.5 一个简单示例

光说不练假把式。我们来看一个最简配置——基于地理位置的路由策略示例。

# 简化版路由规则（YAML风格）
routing_rules:
  - name: "华南用户走深圳"
    condition:
      ip_location: "cn-south"
    action:
      target_region: "sz-region"
      weight: 100

  - name: "华东用户走上海"
    condition:
      ip_location: "cn-east"
    action:
      target_region: "sh-region"
      weight: 100

  - name: "默认降级"
    condition:
      match_all: true
    action:
      target_region: "fallback-vip"
      weight: 100

这个例子看起来很简单吧？但在实际项目中，光这个“ip_location”怎么拿准，就能折磨你几天。我记得有一次，用户使用的是双栈网络（IPv4+IPv6），IP归属地表对IPv6的支持不完善，结果所有IPv6用户都被路由到了降级区域。所以，条件判断的核心是数据源的质量。

2.6 本章小结

回头看看，路由策略不是一个技术点，而是一套思维框架：

四个核心要素：流量来源、目的地映射、规则条件、执行动作。
决策流程：识别 → 匹配 → 选择 → 执行。
分类维度：静态 vs 动态；全局、网关、服务、数据四层。
一个原则：规则要可配、可观测、可回滚。

说白了，路由策略就是多活系统的交通规则。规则写得好，流量跑得顺；规则写不好，天天就是事故现场。这章的基础打好，后面讲具体实战才能听得有滋味。