这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
就近路由
场景
多地域部署后，需要智能路由。
现状：
- 所有用户都解析到同一 IP
- 无法自动路由到最近地域
- 跨地域访问延迟高
目标：
- 北京用户 → 北京服务器
- 上海用户 → 上海服务器
- 广州用户 → 广州服务器
解决方案
1. GeoDNS 智能解析
域名：api.kuaiyizhi.cn
地域映射：
- 华北地区 → 北京 IP：1.2.3.4
- 华东地区 → 上海 IP：5.6.7.8
- 华南地区 → 广州 IP：9.10.11.12
实现方式：
1. 使用 DNS 服务商的 GeoDNS 功能
2. 自建 BIND 服务器
3. 使用智能 DNS 服务选型边界
为什么优先用 GeoDNS
- 触发问题
- 多地域部署后，用户仍可能被解析到远端机房，导致跨地域延迟高。
- 候选方案
- GeoDNS、应用层重定向、CDN 智能路由、全局负载均衡服务。
- 选择理由
- GeoDNS 对客户端透明，接入成本低，可以在用户发起请求前就把流量导向更近的地域。
- 代价
- DNS 有缓存和 TTL，地域故障时切换不会像应用层路由那样即时；解析结果也无法精确到每一次请求。
- 暂不解决
- 暂不做全局流量调度平台，先用 DNS 层解决“明显跨区访问”的问题。
2. HTTP 重定向
设计流程
2. HTTP 重定向
- 步骤 1：选择合适地域并路由用户请求
- 步骤 2：选择合适地域并路由用户请求
- 步骤 3：确认用户来源、目标地域和可用区健康状态
- 步骤 4：根据延迟、健康状态和一致性要求调整地域策略
关注点：路由准确性、跨区延迟、一致性和故障切换。
3. CDN 全球加速
使用 CDN 的全球加速功能：
1. 接入 CDN 服务（Cloudflare, Akamai 等）
2. 配置源站地址
3. 启用智能路由
4. 配置边缘节点
架构：
用户请求
↓
CDN 边缘节点（就近）
↓
判断是否有缓存
├─ 有 → 返回缓存
└─ 无 → 回源到最近地域监控和优化
延迟监控
设计流程
延迟监控
- 步骤 1：检查健康状态并触发告警
- 步骤 2：采集健康状态并触发告警
- 步骤 3：确认用户来源、目标地域和可用区健康状态
- 步骤 4：根据延迟、健康状态和一致性要求调整地域策略
关注点：路由准确性、跨区延迟、一致性和故障切换。
效果验证
优化前
全国访问北京服务器：
- 北京用户：20ms
- 上海用户：100ms
- 广州用户：150ms
- 平均：90ms优化后（就近路由）
就近访问：
- 华北用户（北京服务器）：20ms
- 华东用户（上海服务器）：30ms
- 华南用户（广州服务器）：25ms
- 平均：25ms
提升：72%