3. 架构总览：分层架构设计
信用评分特征服务的高可用架构采用经典的四层分层设计：接入层、计算层、存储层和调度层。每一层职责清晰、独立扩展，通过标准化的接口协议进行交互，从而在保障高吞吐、低延迟的同时，实现故障隔离与弹性伸缩。
设计原则：分层架构的核心优势在于“关注点分离”。接入层负责协议适配与流量管控，计算层专注特征逻辑与资源隔离，存储层保证数据一致性与持久化，调度层统筹任务编排与资源分配。任何一层的变更不应影响其他层的稳定性。
3.1 分层架构总览
下图展示了信用评分特征服务的完整分层架构及各层之间的核心交互关系。该架构支撑日均亿级特征计算请求，P99 延迟控制在 50ms 以内。
3.2 核心组件与交互流程
每一层由若干核心组件构成，组件之间通过定义良好的接口进行同步或异步通信。下表总结了各层的关键组件及其职责：
| 架构层 | 核心组件 | 主要职责 | 高可用策略 |
|---|---|---|---|
| 接入层 | API Gateway、负载均衡器（Nginx/Envoy）、限流组件（Sentinel） | 协议转换、流量分发、鉴权、限流熔断 | 多活部署、健康检查、熔断降级 |
| 计算层 | 特征计算引擎、算子容器、规则引擎、本地缓存 | 特征逻辑执行、模型推理、结果缓存 | 线程池隔离、超时控制、优雅降级 |
| 存储层 | Redis Cluster、MySQL/TiDB、HBase/S3、元数据服务 | 特征数据存储、元数据管理、缓存加速 | 主从复制、分片集群、读写分离 |
| 调度层 | 任务调度器（XXL-Job/Quartz）、资源管理器（K8s）、注册中心（Nacos） | 任务编排、资源分配、服务发现、弹性伸缩 | 分布式调度、故障转移、自动扩缩容 |
3.3 一次完整的特征请求交互流程
以一次实时信用评分特征请求为例，完整的交互流程包含以下步骤：
- 客户端发起请求：业务系统通过 HTTP/gRPC 协议将用户标识（如身份证号、手机号）及上下文信息发送至接入层。
- 接入层处理：API Gateway 完成鉴权、参数校验后，根据路由规则将请求转发至计算层对应特征组实例。若 QPS 超过阈值，触发限流并返回降级结果。
- 计算层执行特征逻辑：特征计算引擎解析特征 DAG（有向无环图），按依赖顺序执行算子。优先从本地缓存（Caffeine）读取热特征数据，未命中则向存储层发起查询。
- 存储层数据查询：计算层根据特征元数据，分别从 Redis Cluster（热数据）、MySQL（近线数据）或 HBase（冷数据）获取原始数据。存储层返回结果后，计算层完成特征加工。
- 结果返回与缓存：计算层将最终特征向量返回给接入层，同时将结果写入本地缓存（TTL 按特征类型配置，通常为 30s-5min）。接入层将响应返回给客户端。
- 调度层持续监控：调度层通过健康检查感知各组件状态，若计算层实例出现延迟升高或错误率增加，自动摘除异常节点并触发弹性扩容。
关键交互时序：整个请求链路要求在 50ms 内完成（P99）。其中，接入层耗时 < 2ms，计算层耗时 < 30ms（含本地缓存命中），存储层查询耗时 < 15ms，网络开销 < 3ms。若任一环节超时，计算层应返回降级特征或默认值，避免级联阻塞。
3.4 分层交互的详细时序图
下图以时序图形式展示一次特征请求在四层架构中的完整交互过程，重点标注了缓存命中与未命中两种路径：
3.5 分层设计的容错与隔离机制
分层架构不仅带来结构上的清晰性，更是实现高可用容错的基础。每一层都内置了独立的容错策略：
- 接入层容错：多活部署 + 健康检查，单节点故障自动摘除；限流组件基于令牌桶算法，突发流量下优先保障核心业务特征请求。
- 计算层容错：每个特征组拥有独立的线程池和熔断器（基于 Hystrix/Resilience4j）。当某个特征组因依赖存储超时而导致错误率超过 50% 时，熔断器打开，直接返回降级特征值，避免阻塞其他特征组。
- 存储层容错：Redis Cluster 采用主从切换 + 分片冗余，单分片故障仅影响 1/16384 的槽位；MySQL/TiDB 通过半同步复制保障数据不丢失。
- 调度层容错：调度器采用 Leader-Follower 模式，Leader 宕机后自动选举新 Leader；资源管理器（K8s）通过 ReplicaSet 保证计算层实例数不低于最小副本数。
避坑指南：分层架构虽然隔离了故障域，但层与层之间的网络调用可能成为新的脆弱点。务必为所有跨层调用配置合理的超时时间（建议接入层→计算层 100ms，计算层→存储层 50ms）和重试策略（幂等接口最多重试 1 次，非幂等接口不重试）。同时，避免在计算层直接依赖存储层的强一致性事务，优先采用最终一致性 + 补偿机制。
3.6 架构演进与扩展性
四层架构设计充分考虑了未来的扩展需求：
| 扩展维度 | 实现方式 | 对现有架构的影响 |
|---|---|---|
| 新增特征组 | 在计算层注册新的特征 DAG，配置独立的线程池和缓存策略 | 无影响，仅需更新路由规则 |
| 接入新协议 | 在接入层增加协议适配器（如新增 GraphQL 端点） | 无影响，计算层无需感知协议变化 |
| 存储引擎替换 | 在存储层增加新的数据源适配器，通过元数据服务动态切换 | 计算层通过统一数据访问接口（DAO）调用，无需修改特征逻辑 |
| 计算资源扩容 | 调度层自动增加计算层 Pod 副本数，注册中心自动发现新节点 | 无影响，接入层自动负载均衡 |