3. 跨机房架构总览：主备模式、双活模式、多活模式对比与选型
信用评分特征服务对延迟、一致性和可用性有极高要求。跨机房部署架构的选择直接决定了系统的容灾能力、数据一致性模型以及运维复杂度。本节从架构原理、数据流、故障切换三个维度，对比三种主流模式，并给出信用评分场景下的选型建议。
3.1 三种架构模式核心对比
| 对比维度 | 主备模式 (Active-Standby) | 双活模式 (Active-Active) | 多活模式 (Multi-Active) |
|---|---|---|---|
| 机房数量 | 2 个（1 主 + 1 备） | 2 个（同时承载流量） | ≥3 个（全活） |
| 流量分布 | 100% 流量在主中心 | 按比例或按用户分片 | 全部分片 + 流量就近接入 |
| 数据一致性 | 强同步复制（备机只读） | 最终一致性（双向同步） | 最终一致性（多向同步） |
| 故障切换时间 | 30s – 120s（需人工确认） | < 10s（自动流量调度） | < 5s（自动剔除故障分片） |
| 资源利用率 | 低（备机闲置 50%） | 高（双中心均承载流量） | 极高（N 中心均承载流量） |
| 运维复杂度 | 低 | 中 | 高 |
| 适用场景 | 监管要求强一致、低频变更 | 读多写少、可接受最终一致 | 高并发、全球部署、弹性扩缩 |
3.2 主备模式：强一致性的基石
主备模式是最经典的容灾架构。所有写请求必须经过主中心，主中心通过同步复制将数据实时同步到备中心。备中心不对外提供写服务，仅作为冷备或只读副本。
信用评分场景适配： 特征服务中的「用户基础画像」和「黑名单库」要求强一致性，主备模式可以保证主中心故障后，备中心的数据与主中心完全一致，避免评分结果出现「数据回滚」或「特征丢失」。
风险提示： 主备模式下，备机长期处于空闲状态，资源浪费约 50%。且故障切换依赖人工确认，切换期间特征服务不可用，可能影响在线评分时效。
3.3 双活模式：高可用与资源利用的平衡
双活模式下，两个机房同时承载读写流量。数据通过双向同步机制保持最终一致性。信用评分特征服务通常采用「按用户 ID 哈希分片」或「按特征类型分片」的方式，将流量均匀分布到两个中心。
最佳实践： 双活模式适用于「用户行为特征」和「设备指纹特征」等对实时性要求高、但对短时不一致容忍度较高的场景。例如，用户在一机房写入行为特征后，另一机房在 1-2 秒内即可同步完成。
3.4 多活模式：全球部署的终极方案
多活模式是双活模式的扩展，通常用于 3 个及以上机房的全球部署。每个机房独立承载流量，数据通过多向同步机制保持最终一致。信用评分特征服务在多活模式下，需要引入「全局特征版本号」或「时间戳仲裁」机制，解决多机房并发写入时的冲突问题。
关键设计： 多活模式必须解决「写冲突」问题。信用评分场景中，同一用户的特征可能同时在两个机房被更新。推荐使用「最后写入者获胜 (LWW)」策略，配合全局单调递增的时间戳服务（如 TrueTime 或全局时钟），确保特征值最终收敛。
3.5 选型决策矩阵
信用评分特征服务的选型需要综合考虑监管合规、业务容忍度、成本预算和运维能力。以下决策矩阵可以帮助架构师快速定位适合的模式：
| 决策条件 | 主备模式 | 双活模式 | 多活模式 |
|---|---|---|---|
| 监管要求强一致性 | ✅ 推荐 | ⚠️ 需评估 | ❌ 不推荐 |
| RTO < 30s | ❌ 不满足 | ✅ 满足 | ✅ 满足 |
| RPO = 0 | ✅ 满足 | ❌ 不满足 | ❌ 不满足 |
| 日均请求量 > 1 亿 | ❌ 单点瓶颈 | ✅ 可扩展 | ✅ 最佳 |
| 运维团队 < 5 人 | ✅ 推荐 | ⚠️ 需培训 | ❌ 不推荐 |
| 全球多区域部署 | ❌ 不适用 | ⚠️ 仅限双区域 | ✅ 推荐 |
推荐路径： 对于大多数信用评分特征服务，建议从「双活模式」起步。双活模式在一致性和可用性之间取得了较好的平衡，且后续可以平滑演进到多活模式。如果监管要求严格（如银行核心风控），则优先选择主备模式，并接受资源利用率较低的代价。