4. 网络基础设施：机房互联专线、DNS智能解析、全局负载均衡(GSLB)原理
信用评分特征服务对延迟和可用性极为敏感。跨机房部署时，网络基础设施是决定请求能否在毫秒级内完成、故障能否自动逃逸的底层支撑。本章聚焦三大核心组件：机房互联专线提供高速私有通道，DNS智能解析实现用户就近接入，全局负载均衡(GSLB)完成流量调度与故障转移。
4.1 机房互联专线
专线是跨机房通信的物理基础。相比公网，专线提供低延迟、高稳定、无丢包的私有网络路径。信用评分特征服务通常采用双活或主备架构，特征数据需在机房间实时同步，专线质量直接决定数据一致性窗口。
| 对比项 | 公网互联 | 专线互联 |
|---|---|---|
| 延迟抖动 | ±10~50ms | ±1~3ms |
| 丢包率 | 0.1%~1% | <0.01% |
| 带宽保障 | 尽力而为 | 承诺带宽(CIR) |
| 安全隔离 | 共享通道 | 二层/三层隔离 |
| 故障恢复 | 依赖BGP路由收敛 | 支持BFD快速检测+主备切换 |
实践建议：至少部署两条不同物理路由的专线（如电信+联通，或不同光缆路径），避免单点物理故障导致跨机房通信中断。同时启用BFD（双向转发检测）将故障感知时间压缩到50ms以内。
4.2 DNS智能解析
DNS智能解析是用户流量进入系统的第一道关卡。它根据用户来源IP的地理位置、运营商、网络质量等条件，返回不同的机房入口IP，实现就近接入和流量分区。
- GeoDNS：基于IP地理库，将华东用户解析到上海机房，华南用户解析到深圳机房。
- 运营商识别：电信用户返回电信线路IP，联通用户返回联通线路IP，避免跨运营商延迟。
- 健康探测联动：当某机房整体故障时，DNS自动剔除该机房A记录，将流量导向健康机房。
注意：DNS缓存TTL通常设置为60~120秒，故障切换时存在生效延迟。对于信用评分这种高敏感业务，不能仅依赖DNS做故障转移，必须与GSLB配合形成多层保护。
4.3 全局负载均衡(GSLB)原理
GSLB工作在DNS之上或独立部署，通过实时监控各机房的负载、健康状态、响应延迟，动态决策流量分发策略。信用评分特征服务通常采用基于延迟或基于权重的调度算法。
4.3.1 GSLB核心工作流程
- 健康检查：GSLB定期向各机房的VIP（虚拟IP）发送HTTP/TCP探测，确认服务可用。
- 指标采集：收集各机房的当前连接数、CPU使用率、响应时间等负载指标。
- 调度决策：根据预设策略（如最低延迟、最少连接、权重轮询）选择最优机房。
- DNS响应改写：将用户请求的域名解析为选定机房的VIP地址。
- 会话保持：对同一用户的多次请求，尽量导向同一机房，避免特征数据跨机房反复同步。
关键指标：GSLB决策周期通常为5~10秒，信用评分场景下，建议将健康检查间隔设为3秒，故障转移阈值设为连续2次失败，确保在6秒内完成流量切换。
4.3.2 GSLB调度策略对比
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 轮询(RR) | 机房配置相同 | 简单公平 | 不考虑负载差异 |
| 加权轮询(WRR) | 机房容量不同 | 按权重分配 | 权重需人工调整 |
| 最低延迟 | 延迟敏感业务 | 用户体验最优 | 需持续探测延迟 |
| 最少连接 | 长连接服务 | 均衡连接数 | 对短连接效果一般 |
| 地理位置 | 合规/数据本地化 | 满足监管要求 | 可能忽略负载 |
4.4 整体架构关系
下图展示了DNS智能解析、GSLB、专线互联在信用评分特征服务跨机房部署中的协同关系：
4.5 关键设计要点
- 专线带宽规划：信用评分特征服务的数据同步流量通常为每秒数百KB到数MB，按峰值流量的1.5~2倍预留专线带宽，避免拥塞导致同步延迟。
- DNS与GSLB的TTL协调：DNS TTL设为60秒，GSLB内部探测周期设为5秒，确保故障时GSLB能先于DNS缓存过期完成流量调度。
- 跨机房会话保持：通过GSLB的一致性哈希或Cookie插入机制，将同一用户的请求始终导向同一机房，减少特征数据跨机房读取的频率。
- 专线质量监控：部署端到端延迟、丢包、吞吐量监控，当专线质量劣化到阈值（如延迟>10ms）时，GSLB自动降低该机房权重或将其摘除。
案例：某信用评分系统采用上海-深圳双活架构，专线延迟稳定在3ms以内。某日运营商光缆被挖断，BFD在40ms内检测到故障，GSLB在下一个决策周期（5秒）将所有流量切换到深圳机房，用户无感知。DNS TTL设置为60秒，在此期间DNS仍可能返回上海IP，但GSLB的健康检查已标记上海VIP为不可用，用户请求到达上海后由本地负载均衡直接返回503或重定向到深圳，形成多层容错。