4. 时序数据平台总体架构

时序数据平台的总体架构通常被划分为六个层次：边缘层、接入层、存储层、计算层、服务层和应用层。这种分层并非简单的技术堆叠，而是围绕“数据从哪里来、怎么进来、放在哪里、怎么加工、如何对外提供、最终为谁所用”这条主线，对职责边界和集成契约做出的系统性安排。理解每一层“必须做什么”和“不应该做什么”，是后续架构设计、选型与排障的基础。

一、六层职责的边界定义

边缘层位于数据产生侧，直接面对设备、传感器、PLC、SCADA、网关或采集代理。它的核心职责是：以尽可能小的资源开销完成数据采集、时间戳对齐、本地缓存、断点续传和必要的边缘预处理（如去噪、限幅、单位换算、简单阈值判断）。边缘层不承担全局计算，也不保存长期历史数据，它的价值在于“把现场数据可靠地送出去”，并在网络不稳定时保证不丢数。

接入层是数据进入平台的第一道关口，负责协议适配、连接管理、鉴权、限流、消息缓冲与格式归一。典型能力包括 MQTT、OPC UA、Modbus、HTTP/HTTPS、Kafka 等协议接入，以及将不同来源的数据统一为带设备标识、测点标识、时间戳和质量码的标准事件。接入层不解释业务语义，也不做复杂聚合，它关注的是“高并发、低延迟、可水平扩展地收进来”。

存储层解决时序数据的持久化问题。它通常由时序数据库（如 TDengine、InfluxDB、TimescaleDB 等）承担主存储，配合对象存储保存原始文件、冷数据或备份，必要时引入缓存层（Redis）加速最新值查询。存储层的职责包括：按时间分区、按设备/测点建索引、设置保留策略与降采样策略、保证写入吞吐与查询效率。它不负责业务计算，但必须为计算层提供稳定的读写接口。

计算层是平台的“加工车间”，负责流式计算与批处理。流计算处理实时窗口聚合、异常检测、状态识别、告警触发；批处理完成历史回补、离线指标生成、模型训练样本构建。计算层从存储层或消息队列读取数据，将结果写回存储层或直接推送给服务层。它的关键约束是：计算逻辑与存储解耦，计算任务可编排、可重试、可观测。

服务层将数据与计算能力封装为标准化 API，供上层应用调用。典型服务包括：时序查询服务、最新值服务、聚合指标服务、告警服务、元数据服务、设备影子服务等。服务层需要处理鉴权、限流、缓存、分页、错误码规范等横切关注点，并保证接口的稳定性和版本兼容性。它不直接面向最终用户界面，而是面向应用层提供“可编程的数据能力”。

应用层是最终用户直接接触的部分，包括监控大屏、设备健康管理、能耗分析、预测性维护、报表系统、移动端告警等。应用层通过服务层获取数据，不直接连接存储层或计算层。它的职责是业务逻辑呈现、交互设计和用户价值交付，而不是数据处理本身。

二、层间集成关系与数据流

六层之间通过明确的接口契约进行集成，形成“自下而上数据流动、自上而下控制反馈”的双向关系。边缘层到接入层以消息协议为主，强调可靠投递；接入层到存储层以标准事件流为主，强调格式统一；存储层到计算层以读写接口为主，强调吞吐与一致性；计算层到服务层以结果写回或推送为主，强调时效性；服务层到应用层以 API 为主，强调稳定与安全。

需要特别注意的是，应用层不得绕过服务层直接访问存储层或计算层。一旦绕过，鉴权、限流、缓存、版本兼容等能力全部失效，后续存储结构变更会直接冲击应用。同理，计算层不应直接连接边缘设备，否则实时计算逻辑会与现场协议耦合，难以扩展和维护。

三、一个可落地的集成示例

假设某工厂有 200 台设备，每台设备 50 个测点，采样周期 1 秒，则每秒产生 10000 个数据点。边缘网关以 MQTT 协议将数据发往接入层；接入层通过 Kafka 缓冲后，由消费者写入 TDengine，按“设备ID+测点ID”建标签索引，按天分区，保留策略设为 365 天；计算层以 Flink 消费 Kafka 中的原始流，做 10 秒滑动窗口均值计算，并将结果写回 TDengine 的另一张聚合表；服务层提供 /api/v1/ts/query 接口，支持按设备、测点、时间范围查询原始值与聚合值；应用层的大屏每 5 秒轮询一次最新值接口，告警模块订阅服务层的 WebSocket 推送。

边缘网关 → MQTT Broker → Kafka Topic(raw) → Flink(10s窗口) → TDengine(聚合表)
                                    ↓
                              TDengine(原始表) ← 消费者写入
                                    ↓
                              服务层 API → 应用层大屏/告警

在这个示例中，各层职责清晰：边缘层只负责采集和发送，接入层只负责缓冲和归一，存储层只负责持久化和索引，计算层只负责窗口聚合，服务层只负责接口封装，应用层只负责展示和告警。任何一层出现性能瓶颈，都可以独立扩容或替换，而不会牵动全局。

四、常见误区与判断依据

实际工程中，最常见的误区是把计算逻辑塞进接入层，或在应用层直接写 SQL 查询数据库。前者会导致接入层变得臃肿、难以水平扩展；后者会导致数据权限失控、查询压力直接打到存储层。判断分层是否合理，可以问三个问题：该层是否只做自己职责内的事？层与层之间是否只通过约定接口通信？替换某一层的实现是否不需要修改其他层的代码？如果三个答案都是“是”，说明分层是健康的。

总结来说，六层架构的核心不是“画成六层”，而是通过职责划分把变化隔离开：设备协议会变，所以边缘层和接入层要适配；存储技术会变，所以存储层要可替换；计算逻辑会变，所以计算层要可编排；业务需求会变，所以服务层要稳定、应用层要灵活。理解这层“变化隔离”的设计意图，比记住六层的名字更重要。