2. 实时特征API架构设计：分层架构、数据流与选型对比
实时特征API的架构设计直接决定了系统的响应延迟、吞吐能力、可维护性与扩展性。本章从分层架构、数据流架构以及微服务与单体架构的选型对比三个维度展开，帮助你在不同业务场景下做出合理的架构决策。
2.1 分层架构设计
分层架构是实时特征API最基础的架构模式，它将系统划分为多个职责清晰的层次，每一层只与相邻层交互，从而降低耦合、提升可测试性。
| 层次 | 职责 | 典型组件 | 关键指标 |
|---|---|---|---|
| 接入层 | 协议适配、请求校验、限流熔断 | API Gateway、Nginx、Envoy | QPS、P99延迟、拒绝率 |
| 编排层 | 特征路由、上下文组装、降级策略 | BFF、Feature Router | 路由耗时、降级触发次数 |
| 计算层 | 特征逻辑执行、实时聚合、模型推理 | Flink、Spark Streaming、自定义算子 | 计算延迟、CPU/内存水位 |
| 存储层 | 特征数据持久化、缓存加速、状态管理 | Redis、HBase、TiKV、本地LRU | 读写P99、缓存命中率 |
| 监控层 | 指标采集、链路追踪、告警 | Prometheus、Jaeger、Grafana | 采集延迟、告警准确率 |
架构原则：每一层只依赖下一层的抽象接口，不跨层调用。例如，编排层不应直接访问存储层的Redis客户端，而应通过计算层的特征服务接口获取数据。
2.2 数据流架构
实时特征API的数据流架构决定了特征数据从产生到消费的完整路径。典型的数据流包含实时采集、流式处理、特征存储和在线服务四个阶段。
2.2.1 数据流核心阶段
- 实时采集：通过Kafka/Pulsar等消息队列接入业务日志、埋点数据或CDC变更流。
- 流式处理：使用Flink/Spark Streaming进行窗口聚合、特征变换、模型打分。
- 特征存储：将计算结果写入在线特征存储（Redis/HBase），同时可选写入离线数仓。
- 在线服务：API网关接收请求后，从特征存储中拉取最新特征值，组装后返回。
最佳实践：数据流中应设置特征新鲜度监控，当某个特征超过阈值未更新时，自动触发降级或告警，避免模型使用过期特征。
2.3 微服务与单体架构的选型对比
在实时特征API场景中，架构选型直接影响开发效率、运维成本和性能上限。以下从多个维度对比微服务架构与单体架构的适用性。
| 对比维度 | 微服务架构 | 单体架构 |
|---|---|---|
| 部署粒度 | 每个特征服务独立部署 | 所有特征逻辑打包为一个进程 |
| 延迟表现 | 网络开销 + 序列化开销，P99增加 2~5ms | 进程内调用，延迟最低 |
| 扩展性 | 按特征维度独立扩缩容 | 整体扩缩容，资源浪费 |
| 开发效率 | 团队并行开发，但需处理分布式问题 | 初期开发快，后期耦合严重 |
| 运维复杂度 | 服务发现、配置中心、链路追踪 | 单进程运维，简单直接 |
| 故障隔离 | 单服务故障不影响其他特征 | 全量故障，影响面大 |
| 适用场景 | 特征数量 > 20、多团队协作、高变更频率 | 特征数量 < 10、初创期、延迟敏感型 |
避坑提示：不要为了“微服务”而微服务。当特征数量少于10个且团队人数少于5人时，单体架构的延迟优势和运维简洁性远大于微服务带来的灵活性。建议从单体+模块化起步，待特征数量和团队规模增长后，按特征域逐步拆分为微服务。
2.3.1 选型决策流程
- 评估特征数量：当前 < 10 个 → 单体架构；≥ 10 个 → 进入下一步评估。
- 评估变更频率：每周变更 > 3 次 → 微服务；否则 → 单体+模块化。
- 评估延迟要求：P99 < 10ms → 优先单体；P99 ≥ 10ms → 微服务可接受。
- 评估团队规模：单团队 → 单体；多团队 → 微服务。
架构演进案例：某金融风控团队初期使用单体架构，支持5个实时特征，P99延迟3ms。半年后特征增长至30个，团队扩展至4个小组，遂按“欺诈特征”、“信用特征”、“设备特征”、“行为特征”拆分为4个微服务，P99延迟上升至8ms，但部署频率从每周1次提升至每天5次，故障影响面缩小80%。