883 lines
17 KiB
Markdown
883 lines
17 KiB
Markdown
# 实时设备数据网关最终方案
|
||
> 文档版本：v1.0
|
||
> 最后更新：2026-04-02
|
||
|
||
|
||
本文档用于收敛当前关于 GPS 模拟、中转、监控、规则判定、回放、通知分发等讨论，给出一版可直接进入实现设计的最终方案。
|
||
|
||
---
|
||
|
||
## 1. 目标与定位
|
||
|
||
本系统不再定义为“GPS 模拟器”，而定义为：
|
||
|
||
- 一个独立部署的实时设备数据网关
|
||
- 负责实时接入、标准化、路由、订阅、最新状态同步
|
||
- 默认不依赖数据库，不承担历史存储职责
|
||
- 通过插件扩展规则判定、通知分发、回放、归档等能力
|
||
|
||
一句话定义：
|
||
|
||
> 一个以实时中转为核心、以插件扩展业务能力的轻量遥测网关。
|
||
|
||
---
|
||
|
||
## 2. 设计原则
|
||
|
||
### 2.1 核心优先级
|
||
|
||
核心目标按优先级排序如下：
|
||
|
||
1. 实时性能
|
||
2. 稳定性
|
||
3. 低耦合
|
||
4. 易扩展
|
||
5. 易观测
|
||
|
||
### 2.2 核心边界
|
||
|
||
核心服务只负责：
|
||
|
||
- 长连接接入
|
||
- 消息标准化
|
||
- 路由转发
|
||
- 订阅管理
|
||
- latest state 缓存
|
||
- 连接管理
|
||
- 心跳和断线清理
|
||
- 基础鉴权
|
||
- 限流与基本防护
|
||
|
||
核心服务不负责：
|
||
|
||
- 历史存储
|
||
- 业务报表
|
||
- 复杂规则引擎
|
||
- 第三方通知发送
|
||
- 业务数据库查询
|
||
- 面向家长端或场控端的专属业务逻辑
|
||
|
||
---
|
||
|
||
## 3. 总体架构
|
||
|
||
### 3.1 拓扑关系
|
||
|
||
```text
|
||
Producer
|
||
├─ 手机客户端
|
||
├─ 外部模拟器
|
||
├─ 回放器
|
||
└─ 设备接入器
|
||
|
|
||
v
|
||
Realtime Device Gateway
|
||
├─ Connection Manager
|
||
├─ Protocol Layer
|
||
├─ Session Manager
|
||
├─ Router / Fanout
|
||
├─ Latest State Cache
|
||
└─ Plugin Bus
|
||
|
|
||
+--> Consumer
|
||
| ├─ 小程序 / App
|
||
| ├─ 家长端
|
||
| ├─ 场控端
|
||
| └─ 调试端 / 大屏
|
||
|
|
||
+--> Plugins
|
||
├─ Rule Engine
|
||
├─ Dispatcher
|
||
├─ Recorder
|
||
├─ Replayer Adapter
|
||
└─ Webhook / Bridge
|
||
|
||
Business Server
|
||
├─ 用户与设备关系
|
||
├─ 配置管理
|
||
├─ 历史归档
|
||
└─ 业务接口
|
||
```
|
||
|
||
### 3.2 在整个系统中的定位
|
||
|
||
实时网关在整个系统中，不是主业务服务器的替代品，而是一层独立的实时中枢。
|
||
|
||
职责分工建议固定为：
|
||
|
||
- 设备、模拟器、回放器
|
||
- 负责产出实时数据
|
||
- 实时网关
|
||
- 负责接入、路由、订阅、latest state、实时分发、运行态观察
|
||
- 业务服务器
|
||
- 负责用户、设备归属、配置、历史存档、业务查询
|
||
- 插件
|
||
- 负责规则、通知、归档、回放等异步能力
|
||
|
||
一句话理解：
|
||
|
||
> 主业务服务器负责“谁是谁”，实时网关负责“现在发生了什么，发给谁看”。
|
||
|
||
### 3.3 服务角色
|
||
|
||
- `Producer`
|
||
- 实时数据生产者
|
||
- 包括真实设备、模拟器、回放器
|
||
|
||
- `Consumer`
|
||
- 实时数据消费者
|
||
- 包括家长端、场控端、调试端、大屏
|
||
|
||
- `Controller`
|
||
- 可向 Producer 或 Gateway 下发控制命令
|
||
- 包括调试控制台、场控后台、回放控制器
|
||
|
||
### 3.4 角色使用流程
|
||
|
||
#### 开发模拟
|
||
|
||
1. Controller 在管理台创建 `channel`
|
||
2. 网关返回 `channelId / producerToken / consumerToken`
|
||
3. 老模拟器作为 Producer 加入 channel 并开始发 `telemetry.location / telemetry.heart_rate`
|
||
4. 管理台和调试 Consumer 实时观察数据
|
||
5. 业务服务器此时可以不参与，或仅做低频归档
|
||
|
||
#### 家长端监控
|
||
|
||
1. 真机设备作为 Producer 向网关持续上报位置和状态
|
||
2. 家长端作为 Consumer 订阅某个 `deviceId` 或 `groupId`
|
||
3. 网关负责实时分发
|
||
4. 业务服务器负责账号关系、历史数据和业务页面
|
||
|
||
#### 场控
|
||
|
||
1. 场控端作为 Consumer 订阅多个设备或一个分组
|
||
2. 网关持续推送实时位置、状态和事件
|
||
3. 如果有控制需求，场控端再以 Controller 身份下发命令
|
||
4. 规则插件可基于同一条实时流做违规判定
|
||
|
||
#### 归档
|
||
|
||
1. Producer 只向网关上报实时数据
|
||
2. Recorder 插件异步消费网关流
|
||
3. Recorder 再按 `10-30s` 批量写入业务服务器
|
||
|
||
这样可以保证：
|
||
|
||
- 实时链路和归档链路解耦
|
||
- 客户端可以逐步从双写演进到单写网关
|
||
- 实时数据和历史数据口径更一致
|
||
|
||
---
|
||
|
||
## 4. 部署原则
|
||
|
||
### 4.1 独立部署
|
||
|
||
实时网关必须独立于主业务服务器部署。
|
||
|
||
这样做的原因：
|
||
|
||
- 不占用主业务服务器的实时长连接资源
|
||
- 不让实时 fanout 干扰主业务接口
|
||
- 实时服务可独立扩容
|
||
- 便于分离故障和性能问题
|
||
|
||
### 4.2 与主业务服务的关系
|
||
|
||
主业务服务只提供控制面能力：
|
||
|
||
- 用户与设备归属关系
|
||
- 权限配置
|
||
- 策略配置
|
||
- 历史存档入口
|
||
|
||
实时网关处理数据面：
|
||
|
||
- 高频 telemetry
|
||
- 最新状态同步
|
||
- 实时下行通知和控制
|
||
|
||
原则上，不允许每条实时上报都回主业务服务查库。
|
||
|
||
---
|
||
|
||
## 5. 0 数据库方案
|
||
|
||
### 5.1 可行性
|
||
|
||
第一版核心网关可以做到 0 数据库依赖。
|
||
|
||
这里的含义是：
|
||
|
||
- 不接 MySQL
|
||
- 不接 PostgreSQL
|
||
- 不接业务持久化存储
|
||
- 不存历史轨迹
|
||
- 不做持久化 session
|
||
|
||
### 5.2 保留的内存态
|
||
|
||
即使 0 数据库，网关仍然必须保留以下运行时内存数据：
|
||
|
||
- 连接表
|
||
- 订阅关系
|
||
- 设备 latest state
|
||
- 会话元数据
|
||
- 限流计数
|
||
- 心跳状态
|
||
|
||
### 5.3 重启语义
|
||
|
||
网关重启后允许丢失：
|
||
|
||
- 当前连接
|
||
- 当前订阅
|
||
- latest state
|
||
- 临时限流计数
|
||
|
||
系统恢复方式：
|
||
|
||
- 客户端自动重连
|
||
- 重新鉴权
|
||
- 重新订阅
|
||
- Producer 继续上报最新点
|
||
|
||
这对实时网关是可接受的。
|
||
|
||
---
|
||
|
||
## 6. 性能目标
|
||
|
||
### 6.1 第一版容量目标
|
||
|
||
第一版至少满足：
|
||
|
||
- `1000-2000` 设备同时在线上报
|
||
- 默认 `1 Hz` 实时上报能力
|
||
- 支持部分调试设备升频到 `2-5 Hz`
|
||
- 端到端实时链路延迟目标 `< 500 ms`
|
||
- 插件故障不阻塞核心中转
|
||
|
||
### 6.2 带宽认知
|
||
|
||
实时中转一定消耗网关所在服务器的带宽，但不会占用主业务服务器带宽。
|
||
|
||
不做历史存储，只能减少：
|
||
|
||
- 磁盘 IO
|
||
- 存储成本
|
||
- 数据库压力
|
||
|
||
不能减少：
|
||
|
||
- 长连接压力
|
||
- 实时 fanout 压力
|
||
- 网关入口和出口带宽
|
||
|
||
### 6.3 核心优化原则
|
||
|
||
- 不允许全量广播
|
||
- 必须按设备或组定向订阅
|
||
- payload 尽量小
|
||
- latest state 只保留当前值
|
||
- 插件必须异步消费
|
||
- 高频调试源必须可限流
|
||
|
||
---
|
||
|
||
## 7. 消息模型
|
||
|
||
### 7.1 统一信封
|
||
|
||
所有进入网关的数据统一使用一个标准信封：
|
||
|
||
```json
|
||
{
|
||
"schemaVersion": 1,
|
||
"messageId": "uuid",
|
||
"timestamp": 1711267200000,
|
||
"topic": "telemetry.location",
|
||
"source": {
|
||
"kind": "producer",
|
||
"id": "watch-001",
|
||
"mode": "real"
|
||
},
|
||
"target": {
|
||
"deviceId": "child-001",
|
||
"groupId": "class-a"
|
||
},
|
||
"payload": {}
|
||
}
|
||
```
|
||
|
||
### 7.2 topic 分类
|
||
|
||
建议只保留四类顶级 topic：
|
||
|
||
- `telemetry.*`
|
||
- `state.*`
|
||
- `event.*`
|
||
- `command.*`
|
||
|
||
示例：
|
||
|
||
- `telemetry.location`
|
||
- `telemetry.heart_rate`
|
||
- `telemetry.motion`
|
||
- `state.device`
|
||
- `event.rule_violation`
|
||
- `event.sos`
|
||
- `command.replay.start`
|
||
- `command.simulation.stop`
|
||
|
||
### 7.3 source mode
|
||
|
||
建议显式区分数据来源模式：
|
||
|
||
- `real`
|
||
- `mock`
|
||
- `replay`
|
||
- `control`
|
||
|
||
这样业务侧可以明确识别是真实数据还是模拟/回放数据。
|
||
|
||
---
|
||
|
||
## 8. 主要数据载荷
|
||
|
||
### 8.1 位置 telemetry
|
||
|
||
```json
|
||
{
|
||
"lat": 31.2304,
|
||
"lng": 121.4737,
|
||
"altitude": 12.3,
|
||
"speed": 1.5,
|
||
"bearing": 90,
|
||
"accuracy": 8,
|
||
"coordSystem": "GCJ02"
|
||
}
|
||
```
|
||
|
||
最少保留字段：
|
||
|
||
- `timestamp`
|
||
- `lat`
|
||
- `lng`
|
||
- `speed`
|
||
- `bearing`
|
||
- `accuracy`
|
||
- `coordSystem`
|
||
|
||
### 8.2 心率 telemetry
|
||
|
||
```json
|
||
{
|
||
"bpm": 142,
|
||
"confidence": 0.92
|
||
}
|
||
```
|
||
|
||
### 8.3 运动 telemetry
|
||
|
||
```json
|
||
{
|
||
"cadence": 168,
|
||
"stepCount": 3201,
|
||
"calories": 248.5,
|
||
"movementState": "run"
|
||
}
|
||
```
|
||
|
||
### 8.4 设备状态
|
||
|
||
```json
|
||
{
|
||
"online": true,
|
||
"battery": 76,
|
||
"network": "4g",
|
||
"charging": false
|
||
}
|
||
```
|
||
|
||
### 8.5 事件
|
||
|
||
```json
|
||
{
|
||
"eventType": "rule_violation",
|
||
"ruleId": "geo-fence-01",
|
||
"severity": "high",
|
||
"text": "leave allowed area"
|
||
}
|
||
```
|
||
|
||
### 8.6 控制命令
|
||
|
||
```json
|
||
{
|
||
"command": "simulation.start",
|
||
"args": {
|
||
"sessionId": "sim-001",
|
||
"speedRate": 2
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 9. 订阅与路由模型
|
||
|
||
### 9.1 路由单位
|
||
|
||
实时网关按以下维度路由：
|
||
|
||
- `deviceId`
|
||
- `groupId`
|
||
- `topic`
|
||
|
||
### 9.2 推荐订阅粒度
|
||
|
||
- 订阅某个设备全部实时消息
|
||
- 订阅某个设备某类消息
|
||
- 订阅某个组某类消息
|
||
|
||
示例：
|
||
|
||
- `device:child-001`
|
||
- `device:child-001/topic:telemetry.location`
|
||
- `group:class-a/topic:event.*`
|
||
|
||
### 9.3 latest state
|
||
|
||
每个设备保留一个最新状态快照，不存历史。
|
||
|
||
用途：
|
||
|
||
- 新订阅者刚连上时立即获得当前状态
|
||
- 页面重连后快速恢复
|
||
- 插件可从最新态快速计算
|
||
|
||
---
|
||
|
||
## 10. 鉴权策略
|
||
|
||
### 10.1 不建议完全不鉴权
|
||
|
||
如果完全不鉴权，会带来两个高风险问题：
|
||
|
||
- 任意客户端都能伪造位置或心率
|
||
- 任意客户端都可能下发控制命令
|
||
|
||
### 10.2 推荐分级鉴权
|
||
|
||
- `Producer`
|
||
- 必须强鉴权
|
||
- 防止伪造上报
|
||
|
||
- `Controller`
|
||
- 必须强鉴权
|
||
- 防止误操作和恶意控制
|
||
|
||
- `Consumer`
|
||
- 可轻鉴权
|
||
- 可按内网、白名单、临时 token、短期票据放宽
|
||
|
||
### 10.3 第一版推荐方式
|
||
|
||
第一版建议：
|
||
|
||
- Producer 使用签名 token 或短期接入 token
|
||
- Controller 使用管理 token
|
||
- Consumer 使用轻量订阅 token
|
||
|
||
网关本身不查数据库，只做：
|
||
|
||
- token 基本校验
|
||
- 角色识别
|
||
- 权限范围校验
|
||
|
||
复杂鉴权可以由独立鉴权服务承担。
|
||
|
||
---
|
||
|
||
## 11. 插件体系
|
||
|
||
### 11.1 原则
|
||
|
||
事件处理不是核心同步主链路的一部分，而是插件。
|
||
|
||
同步主链路只做：
|
||
|
||
`ingest -> normalize -> route -> fanout -> update latest state`
|
||
|
||
然后异步投递到插件总线：
|
||
|
||
`publish -> plugin bus -> plugin async consume`
|
||
|
||
### 11.2 第一批插件类型
|
||
|
||
- `Rule Engine`
|
||
- 实时规则判定
|
||
- `Dispatcher`
|
||
- 通知和下行分发
|
||
- `Recorder`
|
||
- 归档与历史写入
|
||
- `Replayer`
|
||
- 文件或历史流回放
|
||
- `Webhook`
|
||
- 向外部系统桥接
|
||
|
||
### 11.3 插件要求
|
||
|
||
- 不能阻塞主链路
|
||
- 失败必须隔离
|
||
- 可独立启停
|
||
- 最好支持单独部署
|
||
|
||
---
|
||
|
||
## 12. 规则判定与通知分发
|
||
|
||
### 12.1 规则不进核心
|
||
|
||
规则判定必须在插件层执行，不进入中转核心。
|
||
|
||
原因：
|
||
|
||
- 规则计算不稳定
|
||
- 容易引入复杂状态
|
||
- 容易放大 CPU 和 IO 消耗
|
||
- 不应影响实时转发
|
||
|
||
### 12.2 推荐规则类型
|
||
|
||
- 阈值规则
|
||
- 心率过高
|
||
- 速度异常
|
||
- 电量过低
|
||
|
||
- 时空规则
|
||
- 离开围栏
|
||
- 进入禁区
|
||
- 停留超时
|
||
- 偏离路线
|
||
|
||
- 行为规则
|
||
- 长时间静止
|
||
- 轨迹跳变
|
||
- 设备离线
|
||
|
||
### 12.3 动作分发
|
||
|
||
规则命中后由 Dispatcher 插件执行动作：
|
||
|
||
- 下发终端警告
|
||
- 推送给家长端
|
||
- 推送给场控端
|
||
- 上报业务服务
|
||
- 触发 Webhook
|
||
|
||
### 12.4 规则系统必须处理的问题
|
||
|
||
- 去重
|
||
- 冷却时间
|
||
- 恢复事件
|
||
- 幂等
|
||
|
||
---
|
||
|
||
## 13. 客户端上报策略
|
||
|
||
### 13.1 当前推荐的第一阶段方案
|
||
|
||
客户端保留两条链路：
|
||
|
||
- 实时链路
|
||
- 有需要时实时上报到网关
|
||
- 归档链路
|
||
- 每 `10-30s` 打包一次发给业务服务器存档
|
||
|
||
这个方案的优点：
|
||
|
||
- 改造快
|
||
- 实时与归档解耦
|
||
- 主业务服务器不承受高频位置流
|
||
|
||
### 13.2 双写风险
|
||
|
||
客户端双写存在天然风险：
|
||
|
||
- 两边成功率不同
|
||
- 数据口径可能不一致
|
||
- 客户端逻辑更复杂
|
||
- 重试和去重更难
|
||
|
||
### 13.3 推荐演进方向
|
||
|
||
推荐第二阶段改成：
|
||
|
||
- 客户端只向网关实时上报
|
||
- `Recorder` 插件按 `10-30s` 批量归档到业务服务器
|
||
|
||
这样可以保证：
|
||
|
||
- 实时和归档数据同源
|
||
- 客户端逻辑更轻
|
||
- 后续回放、规则、告警直接复用同一条实时流
|
||
|
||
### 13.4 客户端升频策略
|
||
|
||
建议客户端支持策略切换：
|
||
|
||
- `normal`
|
||
- 低频或关闭实时上报
|
||
- `monitor`
|
||
- `1-5s` 实时上报
|
||
- `debug`
|
||
- `1 Hz`
|
||
- `alert`
|
||
- 临时升频
|
||
|
||
---
|
||
|
||
## 14. 模拟与回放
|
||
|
||
### 14.1 模拟器定位
|
||
|
||
模拟器不再是一个独立特殊系统，而是一个标准 Producer。
|
||
|
||
它可以上报：
|
||
|
||
- `telemetry.location`
|
||
- `telemetry.heart_rate`
|
||
- `telemetry.motion`
|
||
- `state.device`
|
||
|
||
### 14.2 回放器定位
|
||
|
||
回放器也是 Producer。
|
||
|
||
区别只是：
|
||
|
||
- source mode 为 `replay`
|
||
- 输入来源是文件或历史流
|
||
- 支持播放、暂停、倍速、循环
|
||
|
||
### 14.3 地图模拟器要求
|
||
|
||
地图拖点时不应直接瞬移发点，至少要支持：
|
||
|
||
- 时间戳
|
||
- 插值
|
||
- 平滑
|
||
- 速度和朝向生成
|
||
|
||
否则业务侧会看到不真实的轨迹。
|
||
|
||
---
|
||
|
||
## 15. 技术选型建议
|
||
|
||
### 15.1 技术选型原则
|
||
|
||
本系统技术选型必须遵守以下原则：
|
||
|
||
- 轻量
|
||
- 健壮
|
||
- 性能优先
|
||
- 少依赖
|
||
- 易部署
|
||
- 易排障
|
||
|
||
目标形态应更接近：
|
||
|
||
- 软路由插件
|
||
- 轻量代理
|
||
- 边缘网关
|
||
- 单二进制网络服务
|
||
|
||
而不是典型的重业务后台服务。
|
||
|
||
### 15.2 第一版推荐
|
||
|
||
核心网关建议明确采用以下技术栈：
|
||
|
||
- 服务端语言：`Go`
|
||
- 实时协议：`WebSocket`
|
||
- 管理接口：`HTTP`
|
||
- 消息格式：`JSON`
|
||
- 运行态存储：纯内存
|
||
- 配置方式：本地配置文件加环境变量
|
||
- 部署形态：单二进制
|
||
- 日志：结构化日志
|
||
|
||
推荐原因：
|
||
|
||
- 更适合长连接、低延迟、fanout 场景
|
||
- 内存和 CPU 占用更可控
|
||
- 二进制部署简单
|
||
- 依赖少，更接近基础设施服务风格
|
||
- 后续扩到更高在线数更稳
|
||
|
||
如果目标是先稳定支撑 `1000-2000` 在线连接，推荐优先考虑：
|
||
|
||
- 服务端：`Go`
|
||
- 实时协议：`WebSocket`
|
||
- 管理接口：`HTTP`
|
||
- 配置来源：本地配置文件或环境变量
|
||
- latest state：进程内内存
|
||
|
||
原因：
|
||
|
||
- 长连接和 fanout 场景更贴近 Go 的强项
|
||
- 资源占用更稳
|
||
- 后续扩到更高并发成本更低
|
||
|
||
### 15.3 网关内部建议模块
|
||
|
||
为了保持“轻量但可扩展”，建议核心网关内部拆为以下模块：
|
||
|
||
- `listener`
|
||
- 管理 WebSocket 和 HTTP 入口
|
||
- `session manager`
|
||
- 管理连接、身份、心跳、会话元数据
|
||
- `router`
|
||
- 负责 topic、device、group 维度路由
|
||
- `fanout hub`
|
||
- 负责多订阅者分发
|
||
- `state cache`
|
||
- 保存设备 latest state
|
||
- `auth verifier`
|
||
- 校验 Producer、Consumer、Controller 的 token
|
||
- `rate limiter`
|
||
- 限制异常高频上报
|
||
- `plugin bus`
|
||
- 异步发布给规则、通知、归档等插件
|
||
|
||
这些模块都应保持进程内实现，避免第一版引入外部组件。
|
||
|
||
### 15.4 第一版不建议引入的依赖
|
||
|
||
第一版不建议引入：
|
||
|
||
- 数据库
|
||
- 消息队列
|
||
- 服务注册中心
|
||
- 复杂配置中心
|
||
- 脚本型规则执行器
|
||
- 重型 RPC 框架
|
||
|
||
这些能力都可以在后续容量和业务复杂度真正需要时再补。
|
||
|
||
### 15.5 可接受的替代方案
|
||
|
||
如果团队更熟悉 TypeScript，也可以先用：
|
||
|
||
- `Node.js + TypeScript + WebSocket`
|
||
|
||
但要注意：
|
||
|
||
- 网关层应保持非常薄
|
||
- 不要过早塞业务逻辑
|
||
- 一开始就准备好以后拆分插件
|
||
|
||
但如果核心目标明确是“像软路由一样稳定跑实时中转”，仍然优先推荐 Go。
|
||
|
||
---
|
||
|
||
## 16. MVP 范围
|
||
|
||
第一版只做以下内容：
|
||
|
||
### 16.1 核心网关
|
||
|
||
- WebSocket 接入
|
||
- Producer / Consumer / Controller 三类角色
|
||
- 统一消息信封
|
||
- 按设备订阅
|
||
- latest state 缓存
|
||
- 心跳和断线处理
|
||
- 基础限流
|
||
- 基础鉴权
|
||
|
||
### 16.2 模拟器接入
|
||
|
||
- 地图拖点
|
||
- 轨迹文件导入
|
||
- 播放 / 暂停 / 倍速 / 循环
|
||
- 输出位置和心率等标准 telemetry
|
||
|
||
### 16.3 观察端
|
||
|
||
- 订阅设备位置和状态
|
||
- 查看最新点
|
||
- 接收实时事件
|
||
|
||
### 16.4 插件最小集
|
||
|
||
- Recorder
|
||
- 可选启用
|
||
- Rule Engine
|
||
- 先做最简单几条规则
|
||
- Dispatcher
|
||
- 先支持网关内消息通知
|
||
|
||
### 16.5 明确不做
|
||
|
||
- 业务数据库耦合
|
||
- 复杂多租户
|
||
- 大报表系统
|
||
- 历史查询中心
|
||
- 集群调度系统
|
||
|
||
---
|
||
|
||
## 17. 第二阶段演进
|
||
|
||
第二阶段建议逐步增加：
|
||
|
||
- 归档从客户端双写迁移到 Recorder
|
||
- 多实例网关
|
||
- Redis 作为共享状态和实例间消息桥
|
||
- 更细粒度权限
|
||
- 完整规则库
|
||
- 回放服务独立化
|
||
- 外部通知集成
|
||
|
||
第三阶段再考虑：
|
||
|
||
- 数据库落盘
|
||
- 历史检索
|
||
- 统计分析
|
||
- 高可用和地域分布
|
||
|
||
---
|
||
|
||
## 18. 最终结论
|
||
|
||
最终方案建议如下：
|
||
|
||
- 以“实时设备数据网关”作为系统核心，而不是继续围绕“GPS 模拟器”扩展
|
||
- 网关独立部署，不占主业务服务器的实时带宽和连接资源
|
||
- 第一版采用 0 数据库设计，仅保留运行时内存态
|
||
- 核心只做实时接入、标准化、路由、订阅和 latest state
|
||
- 规则判定、通知分发、回放、归档全部插件化
|
||
- 第一版先支撑 `1000-2000` 在线上报
|
||
- 当前客户端可继续采用“实时发网关 + 10-30 秒批量发业务服”的过渡方案
|
||
- 中期应演进为“客户端单写网关，归档由 Recorder 插件完成”
|
||
|
||
这套方案能同时覆盖：
|
||
|
||
- 开发模拟
|
||
- 家长端监控
|
||
- 场控
|
||
- 规则判定
|
||
- 通知分发
|
||
- 数据回放
|
||
- 后续更多传感器接入
|
||
|
||
同时又能把实时性能放在系统设计的首位。
|
||
|
||
|