2. 特征服务架构设计：微服务架构选型、特征计算引擎、特征存储层、服务网关与负载均衡
信用评分特征服务是实时决策系统的核心数据管道。架构设计需同时满足毫秒级响应、高可用、数据一致性与弹性扩缩四大目标。本节从微服务选型、计算引擎、存储分层、网关与负载均衡四个维度展开，给出可落地的架构方案。
2.1 微服务架构选型：基于领域驱动的服务拆分
特征服务不适合单体架构，也不宜过度拆分。推荐采用领域驱动设计（DDD）结合业务能力进行服务边界划分，核心服务包括：
| 服务名称 | 核心职责 | 典型接口 | 部署实例数（基准） |
|---|---|---|---|
| 特征注册中心 | 特征元数据管理、版本控制、上线/下线 | RegisterFeature, GetFeatureMeta | 2～4 |
| 特征计算引擎 | 实时/批量特征加工、表达式执行、聚合计算 | ComputeFeature, BatchCompute | 4～8 |
| 特征存储服务 | 在线特征读写、缓存加速、冷热数据分离 | GetFeature, PutFeature, BatchGet | 6～12 |
| 特征路由网关 | 请求路由、限流、鉴权、协议转换 | RouteRequest, RateLimit | 2～4 |
| 特征监控与告警 | 延迟采集、错误率统计、数据漂移检测 | ReportMetric, AlertConfig | 2 |
选型建议： 服务间通信优先使用 gRPC（低延迟、强类型），异步事件使用 Kafka 解耦。服务注册与发现推荐 Consul 或 Nacos，配合健康检查实现自动摘除。
2.2 特征计算引擎：实时与批量双模架构
特征计算引擎需要同时支撑实时流计算和离线批量计算两种模式，避免两套代码维护成本。推荐采用 Flink + 自定义 UDF 作为统一计算底座。
2.2.1 实时计算链路
- 输入： Kafka 事件流（用户行为、交易流水、设备指纹）
- 处理： Flink 作业执行特征表达式（窗口聚合、滑动计数、比率计算）
- 输出： 写入 Redis Cluster（热数据）和 HBase（温数据）
- 延迟目标： P99 < 50ms（端到端）
2.2.2 批量计算链路
- 输入： Hive / HDFS 历史数据
- 处理： Spark 作业按 T+1 周期计算复杂特征（如 90 天滚动逾期率）
- 输出： 写入 HBase 和 MySQL（元数据与配置）
- 调度： Airflow DAG 编排，失败自动重试 + 告警
关键设计： 特征表达式采用 JSON 配置化 而非硬编码，支持热加载。计算引擎启动时从特征注册中心拉取最新表达式版本，无需重启作业即可更新特征逻辑。
2.3 特征存储层：Redis / MySQL / HBase 分层策略
不同特征对延迟、持久化、吞吐的要求差异巨大。单一存储无法满足所有场景，必须采用分层存储策略：
| 存储层 | 适用特征类型 | 延迟要求 | 数据量级 | 持久化策略 |
|---|---|---|---|---|
| Redis Cluster | 实时特征、高频访问特征（如近 1 小时交易次数） | < 5ms | GB 级 | AOF + RDB 混合，主从复制 |
| HBase | 温特征、历史特征、大宽表特征（如 90 天行为序列） | 20～100ms | TB 级 | WAL + HDFS 多副本 |
| MySQL | 特征元数据、配置信息、离线统计结果 | < 50ms | GB 级 | 主从同步 + 定期备份 |
2.3.1 读写路径设计
- 写路径： 计算引擎 → 同时写入 Redis（热）和 HBase（温），MySQL 仅存储元数据。
- 读路径： 特征路由网关 → 优先读 Redis（Cache-Aside 模式），未命中则回源 HBase，并异步回填 Redis。
- 一致性保障： 采用 Write-Through + 异步补偿 策略，Redis 与 HBase 之间通过 Binlog 或 Kafka 消息做最终一致。
避坑提示： 不要将 MySQL 用于在线特征查询，高并发下容易成为瓶颈。MySQL 只承担元数据与配置管理角色，在线查询路径必须经过 Redis 或 HBase。
2.4 服务网关与负载均衡
特征服务网关承担统一入口、流量治理和协议转换职责。推荐使用 Kong / APISIX 作为 API 网关，配合 Nginx + Lua 做七层负载均衡。
2.4.1 网关核心功能
- 路由分发： 根据特征 ID 哈希或业务线标识，将请求路由到对应计算引擎实例。
- 限流熔断： 基于令牌桶算法，按租户/接口维度限流；熔断采用 Hystrix 语义，快速失败。
- 鉴权与审计： 请求携带 JWT Token，网关校验签名并记录调用日志。
- 协议转换： 外部 HTTP/JSON 请求转换为内部 gRPC/Protobuf 调用，降低延迟。
2.4.2 负载均衡策略
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 一致性哈希 | 特征缓存亲和性要求高 | 减少缓存失效 | 节点增减时部分请求重路由 |
| 加权轮询 | 计算实例异构（不同规格） | 简单、公平 | 无法感知后端负载 |
| 最小连接数 | 请求处理时间差异大 | 动态感知负载 | 需要实时连接数统计 |
生产建议： 特征计算服务采用 一致性哈希 + 虚拟节点 策略，保证相同特征 ID 的请求始终路由到同一计算实例，最大化本地缓存命中率。网关层与计算层之间部署 Nginx 做反向代理，实现健康检查与自动摘除。
2.4.3 网关高可用部署
- 多活部署： 网关实例跨可用区部署，前端挂载云负载均衡（SLB/ELB）。
- 健康检查： 每 5 秒探测网关 /health 端点，连续 3 次失败自动摘除。
- 配置热更新： 路由规则、限流阈值通过 etcd 或 Consul 动态下发，无需重启网关。
关键指标： 网关层 P99 延迟应控制在 2ms 以内（不含后端计算时间），若超过 5ms 需排查路由规则复杂度或 TLS 握手开销。