技能合集(Skill合集)的架构设计与最佳实践：从技术选型到生产环境落地

3次阅读

共计 1448 个字符，预计需要花费 4 分钟才能阅读完成。

在现代应用中，技能合集系统需要处理来自不同来源（如用户简历、岗位需求、课程体系等）的异构数据。这些数据通常存在以下痛点：

数据结构差异大：有的使用自由文本，有的采用标准分类体系
查询复杂度高：需要支持多条件组合筛选（如「Python+ 机器学习 + 5 年经验」）
实时性要求高：人才匹配场景需要毫秒级响应

REST：
优点：标准化程度高，缓存友好
缺点：多次往返请求（Over-fetching/Under-fetching）
GraphQL：
优点：按需查询，类型系统完善
缺点：缓存实现复杂，需防范复杂查询攻击

关系型数据库：
适合：强事务要求的核心数据
示例：用户 - 技能关联关系
文档数据库：
适合：技能详情等非结构化数据
示例：MongoDB 中的技能定义文档
搜索引擎：
必须：Elasticsearch 实现复杂搜索
典型场景：标签组合查询

# schema 定义示例
type Skill {
  id: ID!
  name: String!
  category: String
  synonyms: [String]  # 同义词处理
  relatedSkills: [Skill]  
}

type Query {
  skills(
    search: String
    categories: [String]
    first: Int = 10
    after: String
  ): SkillConnection!
}

// 索引映射示例
{
  "mappings": {
    "properties": {"normalizedName": { "type": "keyword"},  // 标准化后的名称
      "rawName": {"type": "text"},          // 原始名称
      "categories": {"type": "keyword"},
      "boostFactor": {"type": "float"}      // 权重因子
    }
  }
}

热点缓存：Redis 存储前 20% 高频查询结果
TTL 策略：
基础数据：24 小时
实时关联数据：5 分钟
失效机制：
主动失效：写操作触发
被动失效：LRU 淘汰

// DataLoader 使用示例
@Configuration
public class DataLoaderConfig {
    @Bean
    public DataLoader<Long, Skill> skillDataLoader(SkillService service) {return DataLoaderFactory.newDataLoader(service::batchGetSkills);
    }
}