3. 系统总体架构设计：分层架构与核心组件概览
实时评分系统对低延迟、高并发和数据一致性有严格要求。为满足这些非功能性需求，系统采用经典的四层分层架构：接入层、计算层、存储层和展示层。每一层职责清晰，通过轻量级协议解耦，便于独立扩展与维护。
3.1 分层架构总览
下图展示了四层架构的整体拓扑与核心组件之间的数据流向。请求从客户端进入，依次经过接入层、计算层、存储层，最终通过展示层将结果推送给用户。
3.2 各层职责与核心组件
下表详细列出了每一层的核心组件、技术选型参考及其主要职责。
| 架构层 | 核心组件 | 技术选型参考 | 主要职责 |
|---|---|---|---|
| 接入层 | API 网关、WebSocket 代理、负载均衡器 | Kong / Nginx / HAProxy | 统一入口、协议转换、限流熔断、安全认证、请求路由 |
| 计算层 | 评分引擎、流处理引擎、消息队列、缓存 | Flink / Kafka / Redis / 自研规则引擎 | 实时评分计算、规则匹配、状态管理、异步消息驱动 |
| 存储层 | 关系数据库、时序数据库、对象存储 | MySQL / PostgreSQL / InfluxDB / MinIO | 持久化评分结果、存储历史数据、保存原始事件日志 |
| 展示层 | 实时看板、REST API 服务、推送服务 | WebSocket / Server-Sent Events / React | 数据可视化、实时推送、历史查询、多端适配 |
3.3 核心组件交互流程
一次典型的评分请求从产生到展示，经历以下关键步骤：
- 客户端请求：用户或上游系统通过 HTTP/REST 或 WebSocket 向接入层发送评分事件。
- 接入层处理：API 网关完成身份校验、限流检查，并将请求路由到计算层的消息队列。
- 异步解耦：Kafka 等消息队列暂存事件，实现流量削峰，保证计算层不被打满。
- 实时计算：Flink 作业消费队列消息，结合 Redis 中的规则与状态，执行评分逻辑。
- 结果存储：评分结果写入 MySQL 持久化，同时更新 Redis 缓存，并发送到时序数据库用于监控。
- 实时推送：计算层将结果通过 WebSocket 直接推送给展示层，看板秒级刷新。
设计要点： 接入层与计算层之间强制使用消息队列解耦，避免计算层抖动直接阻塞客户端。同时，Redis 在计算层承担“状态缓存”和“规则缓存”双重角色，显著降低数据库读取压力。
3.4 分层架构的优势
采用分层架构并非偶然，它直接解决了实时评分系统的三大核心挑战：
- 高并发：接入层无状态，可水平扩展；计算层通过消息队列削峰填谷。
- 低延迟：计算层内使用 Redis 缓存热数据，流处理引擎在内存中完成计算，避免频繁 I/O。
- 可维护性：各层职责单一，可独立部署、升级、扩缩容。例如，替换评分规则只需更新计算层，不影响其他层。
3.5 关键设计决策：同步 vs 异步
在实时评分系统中，并非所有场景都适合异步。我们根据业务特性做了如下区分：
| 场景 | 模式 | 原因 |
|---|---|---|
| 用户主动查询评分结果 | 同步 (REST) | 需要即时返回，用户体验要求高 |
| 后台批量评分任务 | 异步 (消息队列) | 数据量大，允许秒级延迟，避免阻塞 |
| 实时看板数据推送 | 异步 (WebSocket) | 服务端主动推送，客户端被动接收 |
| 规则热更新 | 异步 (发布/订阅) | 不中断正在执行的评分流程 |
架构陷阱： 不要试图让所有接口都变成异步。对于用户直接触发的评分查询，如果强制异步化，会增加前端轮询复杂度，且延迟未必优于同步。正确的做法是：读同步、写异步、推全量。