2、核心概念与架构设计：元数据、数据血缘、服务注册与发现、整体架构分层
好，咱们进入正题。上一章聊了为什么要做实时数据服务目录，这一章咱们把地基打牢。说白了，你得先搞清楚几个核心概念，再看整体架构怎么搭。我见过不少团队，一上来就撸代码，结果概念没对齐，架构改了三轮——嗯，那滋味不好受。
2.1 元数据：目录的灵魂
元数据是什么？就是「关于数据的数据」。你想想看，一个数据表叫什么名字、谁建的、什么时候更新的、字段类型是什么——这些都是元数据。没有元数据，你的目录就是个空壳子。
核心要点：元数据是数据目录的「骨架」和「血液」。没有它，目录无法运转。
我个人习惯把元数据分成三类：
| 类型 | 说明 | 举例 |
|---|---|---|
| 技术元数据 | 描述数据的技术属性 | 表结构、字段类型、分区信息、存储位置 |
| 业务元数据 | 描述数据的业务含义 | 字段中文名、业务定义、数据owner、SLA |
| 操作元数据 | 描述数据的流转过程 | ETL任务日志、访问记录、更新时间戳 |
我在项目中遇到过一个问题：技术元数据很全，但业务元数据几乎为零。结果就是，工程师知道这个表有100个字段，但没人知道「user_status」到底代表什么状态。后来我们强制要求每个字段必须有业务描述，才把坑填上。
我的建议：元数据采集要「先全后精」。先把能采的都采了，再逐步清洗和补全。别想着一步到位，那不现实。
2.2 数据血缘：追踪数据的来龙去脉
数据血缘，说白了就是「数据从哪里来，经过什么处理，最终去了哪里」。你想想看，一个报表数据对不上，你总得知道它是从哪个原始表来的吧？
我曾经接手过一个项目，数据出了问题，排查了三天才发现是上游一个ETL脚本改了字段名。如果有数据血缘，十分钟就能定位。从那以后，我坚持每个数据目录必须包含血缘信息。
数据血缘的粒度通常分三级：
- 表级血缘：表A → 表B → 表C，知道数据流向
- 字段级血缘：字段A1 + 字段A2 → 字段B1，精确到列
- 任务级血缘：哪个ETL任务、什么时间、什么参数执行的转换
注意：字段级血缘采集成本很高，不是所有场景都需要。我建议先从表级做起，等团队成熟了再往下钻。
2.3 服务注册与发现：让目录「活」起来
元数据和血缘是静态的，但数据服务是动态的。今天新增一个API，明天下线一个数据源——怎么让目录实时感知这些变化？答案就是服务注册与发现。
核心机制很简单：
- 注册：数据服务启动时，把自己的信息（地址、端口、元数据）注册到目录
- 心跳：定期发送心跳，告诉目录「我还活着」
- 发现：消费者查询目录，找到可用的服务
- 注销：服务下线时，自动从目录中移除
我习惯用这样的数据结构来存储服务实例：
{
"service_id": "ds_api_001",
"service_name": "用户画像查询服务",
"version": "2.1.0",
"host": "10.0.1.100",
"port": 8080,
"status": "online",
"metadata": {
"owner": "数据平台组",
"sla": "99.9%",
"last_heartbeat": "2024-01-15T10:30:00Z"
}
}避坑指南：我曾经遇到过心跳超时设置太短，导致服务频繁上下线。建议心跳间隔设为30秒，超时阈值设为90秒，这样既及时又稳定。
2.4 整体架构分层
好，概念讲完了，咱们看看架构怎么搭。我习惯把实时数据服务目录分成三层：接入层、存储层、服务层。每一层各司其职，互不干扰。
下面这张图是我常用的架构：
2.4.1 接入层
接入层是系统的「大门」。所有客户端请求都从这里进来。我习惯用统一的API网关来做，好处是：认证鉴权、限流熔断、协议转换都可以在这一层搞定。
举个例子，有的客户端用HTTP，有的用gRPC，还有的走WebSocket。接入层负责把这些协议统一转换成内部RPC调用，后端服务完全不用关心客户端是什么。
我的经验：接入层一定要做限流。我曾经没做限流，结果一个爬虫把目录服务打挂了，整个团队被拉去复盘。现在我的接入层默认配置：单IP每秒100次请求，超了直接返回429。
2.4.2 服务层
服务层是核心。元数据管理、血缘分析、服务注册与发现、搜索索引——所有业务逻辑都在这里。这一层我要求必须无状态，这样才能水平扩展。
服务层内部我习惯拆成多个微服务：
- 元数据服务：负责元数据的增删改查和版本管理
- 血缘服务：负责血缘关系的构建和查询
- 注册中心：负责服务实例的注册与发现
- 搜索服务：负责全文索引和搜索
- 通知服务：负责变更事件的推送
2.4.3 存储层
存储层是数据的「家」。不同数据用不同的存储，别想着一个数据库打天下。
| 数据类型 | 推荐存储 | 理由 |
|---|---|---|
| 元数据（结构化） | PostgreSQL / MySQL | 强一致性，支持事务，查询灵活 |
| 血缘关系（图结构） | Neo4j / JanusGraph | 图遍历效率高，血缘查询快 |
| 全文搜索 | Elasticsearch | 分词、模糊搜索、聚合分析 |
| 缓存 | Redis | 热点数据加速，降低DB压力 |
注意：不要把所有元数据都塞进Elasticsearch。ES适合搜索，不适合作为主存储。我见过有人把元数据全放ES，结果数据一致性出了问题，查了半天才发现是ES的最终一致性在作怪。
好了，核心概念和架构设计就聊到这儿。记住一句话：元数据是灵魂，血缘是脉络，服务注册是心跳，三层架构是骨架。把这四个东西搞清楚了，后面的实战才能走得稳。