设计原则

在设计热门排名系统时，遵循正确的设计原则是确保系统可扩展性、可靠性和可维护性的关键。本章将详细介绍我们在架构设计中遵循的核心原则。

一、核心设计原则

1. 单一职责原则 (SRP)

每个模块应该只有一个引起它变化的原因。在热门排名系统中：

┌─────────────────────────────────────────────────────────────┐
│                    热门排名系统                              │
├─────────────┬─────────────┬─────────────┬─────────────────┤
│   数据采集   │   分数计算   │   排名生成   │    缓存服务      │
│   模块      │   模块      │   模块      │    模块         │
└─────────────┴─────────────┴─────────────┴─────────────────┘

实践要点：

• 数据采集模块只负责从各数据源收集原始数据
• 分数计算模块专注于算法实现，不关心数据来源
• 排名生成模块只处理排序逻辑
• 缓存服务独立管理缓存生命周期

2. 开闭原则 (OCP)

系统应对扩展开放，对修改封闭。这意味着：

• 新增数据源时，只需实现新的采集器接口
• 调整排名算法时，不影响现有数据处理流程
• 添加新的排名维度时，无需重构核心代码

3. 依赖倒置原则 (DIP)

高层模块不应依赖低层模块，两者都应依赖抽象：

┌────────────────────────────────────────────────────────────┐
│                    业务逻辑层                               │
│              (依赖抽象接口，不依赖具体实现)                   │
├────────────────────────────────────────────────────────────┤
│                      抽象接口                               │
│         (ScoreCalculator, DataFetcher, RankStore)          │
├────────────────────────────────────────────────────────────┤
│                    具体实现层                               │
│    (RedisScoreCalculator, APIDataFetcher, MySQLRankStore)  │
└────────────────────────────────────────────────────────────┘

二、系统架构原则

1. 分层架构

采用清晰的分层结构，确保各层职责明确：

2. 事件驱动架构

使用事件驱动模式解耦系统组件：

数据采集 ──→ [内容发布事件] ──→ 消息队列 ──→ 分数计算服务
                                         ──→ 排名更新服务
                                         ──→ 通知服务

优势：

• 组件间松耦合
• 易于水平扩展
• 支持异步处理
• 提高系统容错性

3. CQRS 模式

将读取和写入操作分离：

┌─────────────────────────────────────────────────────────────┐
│                        写入端                                │
│   内容发布 → 事件存储 → 更新读模型 → 缓存失效                 │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                        读取端                                │
│   查询请求 → 读模型 (优化) → Redis 缓存 → 返回结果            │
└─────────────────────────────────────────────────────────────┘

三、性能设计原则

1. 缓存优先策略

请求处理流程：
1. 检查本地缓存 (L1) → 命中则返回
2. 检查分布式缓存 (L2) → 命中则返回并更新 L1
3. 查询数据库 → 返回并更新两级缓存

缓存策略：

• 热门数据：永不过期，手动失效
• 普通数据：TTL 30 分钟
• 实时数据：TTL 5 秒，支持主动刷新

2. 预计算原则

对于计算密集型的排名操作，采用预计算策略：

┌─────────────────────────────────────────────────────────────┐
│                   定时预计算任务                             │
│                                                             │
│  每 5 分钟 → 计算全局热门榜单 → 存入缓存                       │
│  每 1 分钟 → 计算分类热门榜单 → 存入缓存                       │
│  实时触发 → 计算个性化推荐 → 存入用户缓存                     │
└─────────────────────────────────────────────────────────────┘

3. 分级存储原则

根据数据访问频率采用不同的存储策略：

四、可靠性设计原则

1. 冗余设计

关键组件必须有多副本：

                    ┌──────────────┐
                    │   负载均衡    │
                    └──────┬───────┘
           ┌───────────────┼───────────────┐
           ↓               ↓               ↓
    ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
    │  服务实例 1  │ │  服务实例 2  │ │  服务实例 3  │
    └─────────────┘ └─────────────┘ └─────────────┘
           ↓               ↓               ↓
    ┌─────────────────────────────────────────────┐
    │              Redis Cluster                   │
    │         (3 Master + 3 Slave)                │
    └─────────────────────────────────────────────┘

2. 降级策略

当系统压力过大时，按优先级降级：

正常状态 → 关闭实时计算 → 关闭个性化 → 返回静态榜单 → 返回错误页
   ↓          ↓             ↓            ↓            ↓
 100%       80%          50%          20%         服务不可用

降级措施：

• 一级降级：停止非核心功能（如个性化推荐）
• 二级降级：延长缓存时间，减少计算频率
• 三级降级：返回预计算的静态榜单
• 四级降级：返回友好错误提示

3. 熔断机制

使用熔断器保护下游服务：

五、可扩展性原则

1. 水平扩展设计

所有服务应支持无状态水平扩展：

                  ┌─────────────┐
                  │   K8s       │
                  │  Controller │
                  └──────┬──────┘
                         │ 自动扩缩容
         ┌───────────────┼───────────────┐
         ↓               ↓               ↓
    ┌─────────┐     ┌─────────┐     ┌─────────┐
    │  Pod 1  │     │  Pod 2  │     │  Pod N  │
    └─────────┘     └─────────┘     └─────────┘

2. 分片策略

对于大规模数据，采用分片存储：

内容分片策略：
┌─────────────────────────────────────────────────────────────┐
│  分片 0: content_id % 100 = 0-19  →  MySQL Shard 1          │
│  分片 1: content_id % 100 = 20-39 →  MySQL Shard 2          │
│  分片 2: content_id % 100 = 40-59 →  MySQL Shard 3          │
│  分片 3: content_id % 100 = 60-79 →  MySQL Shard 4          │
│  分片 4: content_id % 100 = 80-99 →  MySQL Shard 5          │
└─────────────────────────────────────────────────────────────┘

3. 模块化设计

系统应按业务模块划分，支持独立部署和扩展：

┌─────────────────────────────────────────────────────────────┐
│                      API Gateway                            │
└─────────────────────────────────────────────────────────────┘
         │              │              │              │
         ↓              ↓              ↓              ↓
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│  内容服务   │ │  排名服务   │ │  用户服务   │ │  统计服务   │
│  (独立部署)  │ │  (独立部署)  │ │  (独立部署)  │ │  (独立部署)  │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘

六、可维护性原则

1. 配置外部化

所有配置应存储在外部配置中心：

配置要点

• 配置表达的是环境差异和运行参数，不是业务规则本身。

2. 可观测性

系统必须具备完善的监控和日志：

┌─────────────────────────────────────────────────────────────┐
│                    可观测性三层                              │
├─────────────────────────────────────────────────────────────┤
│  Metrics:  Prometheus + Grafana (指标监控)                  │
│  Logging:  ELK Stack (日志收集与分析)                        │
│  Tracing:  Jaeger/Zipkin (分布式追踪)                        │
└─────────────────────────────────────────────────────────────┘

3. 文档化

• API 文档：使用 OpenAPI/Swagger 自动生成
• 架构文档：使用 C4 模型描述系统结构
• 运行文档：包含部署、运维、故障处理指南

七、安全性原则

1. 数据验证

所有输入数据必须经过严格验证：

2. 访问控制

• 接口层：基于 JWT 的身份认证
• 服务层：基于角色的访问控制 (RBAC)
• 数据层：行级权限控制

3. 数据安全

• 传输加密：全站 HTTPS
• 存储加密：敏感数据加密存储
• 数据脱敏：日志中脱敏敏感信息

八、总结

遵循上述设计原则，我们可以构建一个：

在后续章节中，我们将基于这些原则详细设计系统的具体组件和实现方案。

相关阅读：

• 01-系统概述
• 02-需求分析
• 04-核心组件

下一步： 继续学习 04-核心组件设计