1、实时监控2、轨迹查询3、告警管理4、围栏设置5、看板与报表JT/T 808部标车辆监控平台实战第 1 篇 · 业务与架构做车联网绕不开三个国标JT/T 808终端怎么跟平台说话、JT/T 1078车载视频怎么传、JT/T 809平台怎么向上级监管平台汇报。去年我们基于芋道yudao-cloud微服务骨架做了一次深度二开自研了覆盖这三个协议族的监控平台外加两台以假乱真的终端模拟器。从第一行代码到支撑全城车辆在线踩了不少坑也沉淀了一套还算经得起推敲的架构。计划用三篇文章把它讲透-第 1 篇本篇业务与架构——平台到底解决什么问题五层骨架怎么搭关键取舍是什么-第 2 篇后端技术——Netty 协议网关、MQ 信封、Redis 路由、月分区-第 3 篇前端与测试工程——万级车辆实时地图、两台终端模拟器一、先花两分钟把三个国标说清楚很多做互联网后台的同学第一次接触车联网最懵的就是协议。先把三个国标的关系捋清楚后面的架构图才看得懂。JT/T 808是定位与控制协议。全称《道路运输车辆卫星定位系统终端通讯协议》规定车载终端装在车上的那个黑盒子和监控平台之间怎么通信。核心就两类消息上行终端定时上报定位消息 ID0x0200包含经纬度、速度、方向、里程、报警位以及油量、工时、信号强度等二十来类附件还有注册、鉴权、心跳、各类报警事件下行平台下发指令消息 ID0x8xxx系列——设置终端参数、下发文本通知、要求拍照、限速、查询属性终端收到后必须应答协议本身不难难在两点一是长连接规模成千上万台车同时挂着 TCP 连接每 5~30 秒来一帧二是版本兼容市面上同时跑着 2011/2013/2019 三个版本的终端报文格式细节差异不小解码器必须全部兼容。JT/T 1078是视频协议。808管定位1078 管音视频终端把摄像头画面用 RTP 打包通过 TCP 或 UDP 推到平台平台收流后转封装成 FLV分发给浏览器和小程序播放。实时预览、历史录像回放、双向对讲、云台控制全在这一族里。这是整个平台带宽最重、状态最多的部分——一路视频流就是一条需要全生命周期管理的有状态会话。JT/T 809是平台对平台协议。你的平台不是数据终点——按规定两客一危、重型货车的数据要向上级监管平台省厅、部平台转发。809 规定了平台之间的数据交换格式采用主从双链路设计主链路传业务数据从链路传应答和链路检测断链要自动重连、自动补传。为什么绕不开这三个国标因为这是合规要求两客一危、重货、出租、网约车辆终端必须过检、平台必须对接监管否则车辆无法上牌运营。所以这不是要不要做的问题是怎么做才不把自己坑死的问题。二、为什么基于芋道二开而不是从零写先说结论车联网平台 80% 的代码和车联网没关系。组织权限、角色菜单、租户隔离、操作日志、定时任务、文件存储、代码生成……这些后台管理系统的标配功能任何一套监控平台都跑不掉。从零写团队前三个月全在造轮子买商业平台源码不在手里协议层想改改不动。我们选了芋道yudao-cloud微服务骨架做深度二开留下system 模块用户/角色/菜单/租户、infra 模块代码生成/文件/日志、gateway 网关、Nacos 注册配置中心这套骨架。芋道的 RBAC 权限模型和租户拦截器是现成的直接复用砍掉与车辆业务无关的业务模块全部裁掉骨架保持精简自研三个协议网关808/1078/809、业务服务 jt-server、协议契约模块 jt-core、编解码 jar jt-codec——这些是平台的心脏全部自己写这个决策后来被反复验证是对的管理端功能车辆档案、组织树、报警处理、报表大量借用芋道的脚手架生成团队得以把 80% 的精力投在协议、链路和性能这些真正值钱的地方。三、业务全景这套平台到底给谁用架构是为业务服务的动手之前先看清业务角色调度员盯着大屏看全城车辆实时位置处理超速、疲劳驾驶、围栏越界报警必要时下发指令发文本、要求拍照、限速安全员事后取证——调历史轨迹还原事发过程、调事发时段的车载视频录像车务管车辆档案、设备台账、SIM 卡流量、保险年审提醒司机/车主小程序上随时看自己的车在哪儿、有没有报警第三方系统通过开放 API 拉取位置、报警数据接进他们自己的 ERP 或调度系统上级监管平台809 链路把我们的数据定时搬上去接受监管抽查一句话总结业务闭环车在跑 → 数据上来 → 人看得见 → 事有人管 → 指令下得去 → 上级查得到。整套架构就是让这条闭环在万级车辆规模下依然转得动。四、一张图看懂平台五层架构图1-1 业务架构图平台从下往上看是五层每层的职责严格单一终端层真车终端各家厂商、三个协议版本混跑外加我们自己做的两台模拟器——PC 版JavaFX和 Android 版Compose。模拟器不是玩具它和后端共用同一个协议编解码 jar模拟器行为 真终端行为这是整个测试体系的根基第 3 篇细讲。接入层三个独立的 Netty 网关进程一个协议一个只做翻译——808 网关收 TCP 长连接1078 流媒体网关收 RTP 视频流809 网关作为客户端去连上级监管平台。接入层不认识业务它把字节流解码成协议对象包进统一信封扔进 RocketMQ 就完事。服务层一个 jt-server 装下全部业务按四个域组织基础域档案/组织树、核心域轨迹/监控/报警/围栏、动作域指令/视频/推送、外延域开放 API/报表/车务/转发。服务层不碰字节它消费 MQ 信封里的协议对象干完活把结果再包成信封扔回 MQ。应用层Vue3 Web 管理端监控大屏/轨迹回放/视频墙、uni-app 小程序 H5移动看车、开放 API第三方对接。前端与后端走 REST WebSocket 双通道REST 管快照和历史WS 管实时推送。用户层上面说的六类角色。注意这张图里最重要的不是框是箭头——每种箭头都是一种协议或契约终端上行走 808 TCP 报文和 RTP 视频流平台下行走 0x8xxx 指令前端与后端走 REST WebSocket网关与业务之间只过 RocketMQ 信封。任何一层内部可以随便改只要箭头上的契约不变其他层完全无感。五、关键取舍为什么网关必须独立成进程很多 808 平台的开源实现把 Netty 解码和业务逻辑写在同一个 Spring Boot 应用里。几十台车没问题规模上来必死原因有三变化频率不同。协议侧的变化新版本终端、新厂商的私有扩展、解码 bug 修复和业务侧的变化新报表、新页面、新审批流完全不在一个节奏上。合在一起意味着改个报表要重启进程几千台车的 TCP 连接全断终端批量重连形成的惊群能把网关打挂好几分钟期间数据全丢。资源特征不同。网关是 IO 密集 长连接密集要的是稳定的内存和极少的 GC 停顿业务是 CPU DB 密集要的是吞吐。挤在一个 JVM 里互相抢资源谁都跑不好出了问题还没法定位是谁拖累谁。扩容粒度不同。车多了先扛不住的是连接数和流量——加网关实例就行订单量、查询量大了加业务实例。两者独立伸缩互不影响。所以我们把协议面和业务面切成两个进程中间只允许一种东西通过RocketMQ 信封。这是整个平台的第一条设计纪律第 2 篇会展开讲这条边界怎么落地。六、一条定位帧的旅程业务闭环图1-2 流程架构图架构图是静态的跑起来才是系统。跟一条最常见的定位帧走一遍全程。车载终端每 5~30 秒上报一帧0x0200定位报文它的旅程是注册鉴权上线新设备先走注册0x0100拿到鉴权码之后每次上线鉴权0x0102。鉴权通过后网关把这台设备tid连在我这个网关实例上写进 Redis 会话表——这行数据是后面下行路由的关键Netty解码808 网关的 IO 线程做拆包粘包0x7e帧界、转义还原0x7d转义序列、校验和验证然后交给 codec jar 把字节解析成协议对象——IO线程到此为止绝不多干一行活MQ回环削峰协议对象包进统一信封投进 RocketMQ。定位洪峰比如早高峰全城车辆同时苏醒来了先进队列排队而不是直接打爆业务线程池三路并行消费业务线程拿到信封后分三路干活——轨迹入库PG 月分区表、围栏计算在不在电子围栏里越界就产生报警、WS 推送给正在看这台车的浏览器/小程序推实时位置地图上动了一下前端收到推送帧经过第 3 篇要讲的四级节流管线这辆车的图标在地图上平滑地挪了个位置反向是指令闭环调度员在页面上点拍照→ 后端组装0x8801指令 → 查 Redis 会话表确认这台车的 TCP 连接在哪个网关实例上→ 信封投进下行 topic只有目标网关实例真正消费并下发 → 终端拍照应答 → 照片与应答记录落库台账。看车 → 处警 → 下发 → 应答每一步都有据可查这是监管行业的硬要求出事故时要能拿出完整证据链。七、技术选型常规武器打出组合拳图1-3 技术架构图没有黑科技全是主流栈。选型逻辑一句话车联网的难点不在新在稳和杂——协议杂、版本杂、数据冷热杂、终端厂商杂。所以每个组件选的都是生态最成熟、团队最熟悉的那个Spring Boot 3.5 JDK 17芋道骨架本身就基于这套二开成本最低Netty 4.2三种协议的长连接全扛在它身上808 的 TCP、1078 的 RTP 收发久经考验社区资料齐全RocketMQ网关与业务之间的唯一通道。选它没选 Kafka图的是延迟稳定、运维简单、和 Spring 生态集成顺滑团队没人需要现学PostgreSQL轨迹与报警的主库。两个决定性理由分区表按月分区、整月归档DDL 一把梭和空间索引围栏判断、范围查车这类地理查询这两件事在 MySQL 上都要绕路Redis在线会话、鉴权码、每台车的最后位置快照——看车不查库监控页面上万辆车的状态全靠它XXL-Job每月自动预建分区表、定时归档、809 断链补传重试——这些没人记得住但忘了就出事故的活全部交给调度中心前端Vue3 Vite Element Plus Pinia TS 的常规组合地图用MapLibre 天地图——没选高德/百度一是天地图有官方测绘资质背书政企项目合规无争议二是 MapLibre 开源可控矢量瓦片渲染上限高万级点位压得住视频浏览器端 mpegts.js 播 FLVH.265 走 WASM 软解——车载摄像头为了省流量大量采用 H.265浏览器原生不支持这是绕不过去的坎第 3 篇细讲整个技术栈里最特别的一个组件是codec 纯 jar808/1078 的编解码只有一份实现打成零三方依赖的 jar被网关、业务服务、PC 模拟器、Android 模拟器四处共用。还专门写了一个依赖扫描单测把守红线——谁给这个模块加了三方依赖单测直接红。一份实现四处复用模拟器永远不会出现能过但真车不能过的灵异问题。八、数据怎么放热的进 Redis冷的进分区表图1-4 数据架构图车联网的数据有个鲜明特点最新一条值万金历史数据是档案。平台 99% 的实时查询只关心车现在在哪儿但历史轨迹一条都不能丢监管要求留存备查。冷热如此分明存储就必须分两条线实时线进 Redis看车不查库。终端会话tid → 网关实例、鉴权码、每台车的最后位置快照全在 Redis。监控页面打开上万辆车的状态一次快照拉取之后靠 WS 增量推送数据库全程无感。这条纪律救过我们——早期版本监控页直接轮询数据库查最新位置两千台车在线时 DB 的 CPU 就顶到了 80%改成 Redis 快照 WS 推送后同规模下 DB 几乎无负载。历史线进 PostgreSQL分区管住体量。业务库共 94 张jt_*表按前缀分域管理档案、轨迹、报警、指令、视频、报表各有前缀。轨迹表、报警表这两张增长最猛的大表按月分区每月 1 号凌晨 XXL-Job 自动预建下月分区查历史只扫当月超期的老分区整月 detach 归档——比分批 DELETE 清数据快几个数量级而且不撑爆 WAL、不产生表膨胀。写入也分快慢两轨低频的档案、组织、规则走 MyBatis-Plus图它租户隔离插件和 CRUD 便利高频的轨迹写入走 JdbcTemplate 直写绕过拦截器链保吞吐。双轨制各取所长谁也不委屈。九、四条设计纪律三篇文章会反复回到这四条纪律它们是这套平台的宪法比任何单个技术选型都重要协议与业务分离网关只翻译协议业务不碰字节流中间只过 MQ 信封codec红线编解码唯一实现、零三方依赖、单测把守四个进程共用坐标单一口径全链路存储与计算用 WGS-84只在渲染边界才转 GCJ-02第 3 篇细讲这个坑有多深看车不查库实时状态全走 Redis WS 推送数据库只服务历史查询和快照十、踩过的三个坑坑一惊群。早期网关和业务同进程一次发版重启几千台终端同时重连 补鉴权瞬间把服务打挂挂了就再重连恶性循环。解法就是上面说的连接和业务分进程业务随便发版连接纹丝不动。坑二把 MQ 当可选项。最初图省事IO 线程解码完直接同步调业务。压测时一条慢 SQL 卡住业务线程反压到 IO 线程上千个连接的读事件全部延迟终端判断超时开始批量断线重连。从此立下规矩IO 线程零阻塞一切慢操作过 MQ。坑三坐标混用。前端有人用终端原始坐标WGS-84直接上图有人调了地图 SDK 的自动纠偏GCJ-02同一辆车在不同页面上能差出几百米。后来强制单一口径纪律服务端只存只推 WGS-84谁渲染谁负责最后一跳转换混乱从此消失。十一、本篇小结五层架构、一条业务闭环、四条设计纪律就是这套平台的骨架。没有一件武器是新造的值钱的是组合方式和边界纪律——它们决定了平台从 100 台车长到 10000 台车代码结构不用动只需要加机器。下篇《后端技术篇》钻进网关内部看细节Netty 管线怎么搭、MQ 回环为什么是线程模型的一部分、下行指令怎么在多个网关实例之间精准路由、1078 流媒体网关六个端口各干什么、94 张表怎么组织。文中部署地址、密钥、域名等敏感信息均已脱敏架构图为作者基于实际项目整理绘制。 JT/T 808 部标车辆监控平台实战（第 1 篇 · 业务与架构）
1、实时监控2、轨迹查询3、告警管理4、围栏设置5、看板与报表JT/T 808部标车辆监控平台实战第 1 篇 · 业务与架构做车联网绕不开三个国标JT/T 808终端怎么跟平台说话、JT/T 1078车载视频怎么传、JT/T 809平台怎么向上级监管平台汇报。去年我们基于芋道yudao-cloud微服务骨架做了一次深度二开自研了覆盖这三个协议族的监控平台外加两台以假乱真的终端模拟器。从第一行代码到支撑全城车辆在线踩了不少坑也沉淀了一套还算经得起推敲的架构。计划用三篇文章把它讲透-第 1 篇本篇业务与架构——平台到底解决什么问题五层骨架怎么搭关键取舍是什么-第 2 篇后端技术——Netty 协议网关、MQ 信封、Redis 路由、月分区-第 3 篇前端与测试工程——万级车辆实时地图、两台终端模拟器一、先花两分钟把三个国标说清楚很多做互联网后台的同学第一次接触车联网最懵的就是协议。先把三个国标的关系捋清楚后面的架构图才看得懂。JT/T 808是定位与控制协议。全称《道路运输车辆卫星定位系统终端通讯协议》规定车载终端装在车上的那个黑盒子和监控平台之间怎么通信。核心就两类消息上行终端定时上报定位消息 ID0x0200包含经纬度、速度、方向、里程、报警位以及油量、工时、信号强度等二十来类附件还有注册、鉴权、心跳、各类报警事件下行平台下发指令消息 ID0x8xxx系列——设置终端参数、下发文本通知、要求拍照、限速、查询属性终端收到后必须应答协议本身不难难在两点一是长连接规模成千上万台车同时挂着 TCP 连接每 5~30 秒来一帧二是版本兼容市面上同时跑着 2011/2013/2019 三个版本的终端报文格式细节差异不小解码器必须全部兼容。JT/T 1078是视频协议。808管定位1078 管音视频终端把摄像头画面用 RTP 打包通过 TCP 或 UDP 推到平台平台收流后转封装成 FLV分发给浏览器和小程序播放。实时预览、历史录像回放、双向对讲、云台控制全在这一族里。这是整个平台带宽最重、状态最多的部分——一路视频流就是一条需要全生命周期管理的有状态会话。JT/T 809是平台对平台协议。你的平台不是数据终点——按规定两客一危、重型货车的数据要向上级监管平台省厅、部平台转发。809 规定了平台之间的数据交换格式采用主从双链路设计主链路传业务数据从链路传应答和链路检测断链要自动重连、自动补传。为什么绕不开这三个国标因为这是合规要求两客一危、重货、出租、网约车辆终端必须过检、平台必须对接监管否则车辆无法上牌运营。所以这不是要不要做的问题是怎么做才不把自己坑死的问题。二、为什么基于芋道二开而不是从零写先说结论车联网平台 80% 的代码和车联网没关系。组织权限、角色菜单、租户隔离、操作日志、定时任务、文件存储、代码生成……这些后台管理系统的标配功能任何一套监控平台都跑不掉。从零写团队前三个月全在造轮子买商业平台源码不在手里协议层想改改不动。我们选了芋道yudao-cloud微服务骨架做深度二开留下system 模块用户/角色/菜单/租户、infra 模块代码生成/文件/日志、gateway 网关、Nacos 注册配置中心这套骨架。芋道的 RBAC 权限模型和租户拦截器是现成的直接复用砍掉与车辆业务无关的业务模块全部裁掉骨架保持精简自研三个协议网关808/1078/809、业务服务 jt-server、协议契约模块 jt-core、编解码 jar jt-codec——这些是平台的心脏全部自己写这个决策后来被反复验证是对的管理端功能车辆档案、组织树、报警处理、报表大量借用芋道的脚手架生成团队得以把 80% 的精力投在协议、链路和性能这些真正值钱的地方。三、业务全景这套平台到底给谁用架构是为业务服务的动手之前先看清业务角色调度员盯着大屏看全城车辆实时位置处理超速、疲劳驾驶、围栏越界报警必要时下发指令发文本、要求拍照、限速安全员事后取证——调历史轨迹还原事发过程、调事发时段的车载视频录像车务管车辆档案、设备台账、SIM 卡流量、保险年审提醒司机/车主小程序上随时看自己的车在哪儿、有没有报警第三方系统通过开放 API 拉取位置、报警数据接进他们自己的 ERP 或调度系统上级监管平台809 链路把我们的数据定时搬上去接受监管抽查一句话总结业务闭环车在跑 → 数据上来 → 人看得见 → 事有人管 → 指令下得去 → 上级查得到。整套架构就是让这条闭环在万级车辆规模下依然转得动。四、一张图看懂平台五层架构图1-1 业务架构图平台从下往上看是五层每层的职责严格单一终端层真车终端各家厂商、三个协议版本混跑外加我们自己做的两台模拟器——PC 版JavaFX和 Android 版Compose。模拟器不是玩具它和后端共用同一个协议编解码 jar模拟器行为 真终端行为这是整个测试体系的根基第 3 篇细讲。接入层三个独立的 Netty 网关进程一个协议一个只做翻译——808 网关收 TCP 长连接1078 流媒体网关收 RTP 视频流809 网关作为客户端去连上级监管平台。接入层不认识业务它把字节流解码成协议对象包进统一信封扔进 RocketMQ 就完事。服务层一个 jt-server 装下全部业务按四个域组织基础域档案/组织树、核心域轨迹/监控/报警/围栏、动作域指令/视频/推送、外延域开放 API/报表/车务/转发。服务层不碰字节它消费 MQ 信封里的协议对象干完活把结果再包成信封扔回 MQ。应用层Vue3 Web 管理端监控大屏/轨迹回放/视频墙、uni-app 小程序 H5移动看车、开放 API第三方对接。前端与后端走 REST WebSocket 双通道REST 管快照和历史WS 管实时推送。用户层上面说的六类角色。注意这张图里最重要的不是框是箭头——每种箭头都是一种协议或契约终端上行走 808 TCP 报文和 RTP 视频流平台下行走 0x8xxx 指令前端与后端走 REST WebSocket网关与业务之间只过 RocketMQ 信封。任何一层内部可以随便改只要箭头上的契约不变其他层完全无感。五、关键取舍为什么网关必须独立成进程很多 808 平台的开源实现把 Netty 解码和业务逻辑写在同一个 Spring Boot 应用里。几十台车没问题规模上来必死原因有三变化频率不同。协议侧的变化新版本终端、新厂商的私有扩展、解码 bug 修复和业务侧的变化新报表、新页面、新审批流完全不在一个节奏上。合在一起意味着改个报表要重启进程几千台车的 TCP 连接全断终端批量重连形成的惊群能把网关打挂好几分钟期间数据全丢。资源特征不同。网关是 IO 密集 长连接密集要的是稳定的内存和极少的 GC 停顿业务是 CPU DB 密集要的是吞吐。挤在一个 JVM 里互相抢资源谁都跑不好出了问题还没法定位是谁拖累谁。扩容粒度不同。车多了先扛不住的是连接数和流量——加网关实例就行订单量、查询量大了加业务实例。两者独立伸缩互不影响。所以我们把协议面和业务面切成两个进程中间只允许一种东西通过RocketMQ 信封。这是整个平台的第一条设计纪律第 2 篇会展开讲这条边界怎么落地。六、一条定位帧的旅程业务闭环图1-2 流程架构图架构图是静态的跑起来才是系统。跟一条最常见的定位帧走一遍全程。车载终端每 5~30 秒上报一帧0x0200定位报文它的旅程是注册鉴权上线新设备先走注册0x0100拿到鉴权码之后每次上线鉴权0x0102。鉴权通过后网关把这台设备tid连在我这个网关实例上写进 Redis 会话表——这行数据是后面下行路由的关键Netty解码808 网关的 IO 线程做拆包粘包0x7e帧界、转义还原0x7d转义序列、校验和验证然后交给 codec jar 把字节解析成协议对象——IO线程到此为止绝不多干一行活MQ回环削峰协议对象包进统一信封投进 RocketMQ。定位洪峰比如早高峰全城车辆同时苏醒来了先进队列排队而不是直接打爆业务线程池三路并行消费业务线程拿到信封后分三路干活——轨迹入库PG 月分区表、围栏计算在不在电子围栏里越界就产生报警、WS 推送给正在看这台车的浏览器/小程序推实时位置地图上动了一下前端收到推送帧经过第 3 篇要讲的四级节流管线这辆车的图标在地图上平滑地挪了个位置反向是指令闭环调度员在页面上点拍照→ 后端组装0x8801指令 → 查 Redis 会话表确认这台车的 TCP 连接在哪个网关实例上→ 信封投进下行 topic只有目标网关实例真正消费并下发 → 终端拍照应答 → 照片与应答记录落库台账。看车 → 处警 → 下发 → 应答每一步都有据可查这是监管行业的硬要求出事故时要能拿出完整证据链。七、技术选型常规武器打出组合拳图1-3 技术架构图没有黑科技全是主流栈。选型逻辑一句话车联网的难点不在新在稳和杂——协议杂、版本杂、数据冷热杂、终端厂商杂。所以每个组件选的都是生态最成熟、团队最熟悉的那个Spring Boot 3.5 JDK 17芋道骨架本身就基于这套二开成本最低Netty 4.2三种协议的长连接全扛在它身上808 的 TCP、1078 的 RTP 收发久经考验社区资料齐全RocketMQ网关与业务之间的唯一通道。选它没选 Kafka图的是延迟稳定、运维简单、和 Spring 生态集成顺滑团队没人需要现学PostgreSQL轨迹与报警的主库。两个决定性理由分区表按月分区、整月归档DDL 一把梭和空间索引围栏判断、范围查车这类地理查询这两件事在 MySQL 上都要绕路Redis在线会话、鉴权码、每台车的最后位置快照——看车不查库监控页面上万辆车的状态全靠它XXL-Job每月自动预建分区表、定时归档、809 断链补传重试——这些没人记得住但忘了就出事故的活全部交给调度中心前端Vue3 Vite Element Plus Pinia TS 的常规组合地图用MapLibre 天地图——没选高德/百度一是天地图有官方测绘资质背书政企项目合规无争议二是 MapLibre 开源可控矢量瓦片渲染上限高万级点位压得住视频浏览器端 mpegts.js 播 FLVH.265 走 WASM 软解——车载摄像头为了省流量大量采用 H.265浏览器原生不支持这是绕不过去的坎第 3 篇细讲整个技术栈里最特别的一个组件是codec 纯 jar808/1078 的编解码只有一份实现打成零三方依赖的 jar被网关、业务服务、PC 模拟器、Android 模拟器四处共用。还专门写了一个依赖扫描单测把守红线——谁给这个模块加了三方依赖单测直接红。一份实现四处复用模拟器永远不会出现能过但真车不能过的灵异问题。八、数据怎么放热的进 Redis冷的进分区表图1-4 数据架构图车联网的数据有个鲜明特点最新一条值万金历史数据是档案。平台 99% 的实时查询只关心车现在在哪儿但历史轨迹一条都不能丢监管要求留存备查。冷热如此分明存储就必须分两条线实时线进 Redis看车不查库。终端会话tid → 网关实例、鉴权码、每台车的最后位置快照全在 Redis。监控页面打开上万辆车的状态一次快照拉取之后靠 WS 增量推送数据库全程无感。这条纪律救过我们——早期版本监控页直接轮询数据库查最新位置两千台车在线时 DB 的 CPU 就顶到了 80%改成 Redis 快照 WS 推送后同规模下 DB 几乎无负载。历史线进 PostgreSQL分区管住体量。业务库共 94 张jt_*表按前缀分域管理档案、轨迹、报警、指令、视频、报表各有前缀。轨迹表、报警表这两张增长最猛的大表按月分区每月 1 号凌晨 XXL-Job 自动预建下月分区查历史只扫当月超期的老分区整月 detach 归档——比分批 DELETE 清数据快几个数量级而且不撑爆 WAL、不产生表膨胀。写入也分快慢两轨低频的档案、组织、规则走 MyBatis-Plus图它租户隔离插件和 CRUD 便利高频的轨迹写入走 JdbcTemplate 直写绕过拦截器链保吞吐。双轨制各取所长谁也不委屈。九、四条设计纪律三篇文章会反复回到这四条纪律它们是这套平台的宪法比任何单个技术选型都重要协议与业务分离网关只翻译协议业务不碰字节流中间只过 MQ 信封codec红线编解码唯一实现、零三方依赖、单测把守四个进程共用坐标单一口径全链路存储与计算用 WGS-84只在渲染边界才转 GCJ-02第 3 篇细讲这个坑有多深看车不查库实时状态全走 Redis WS 推送数据库只服务历史查询和快照十、踩过的三个坑坑一惊群。早期网关和业务同进程一次发版重启几千台终端同时重连 补鉴权瞬间把服务打挂挂了就再重连恶性循环。解法就是上面说的连接和业务分进程业务随便发版连接纹丝不动。坑二把 MQ 当可选项。最初图省事IO 线程解码完直接同步调业务。压测时一条慢 SQL 卡住业务线程反压到 IO 线程上千个连接的读事件全部延迟终端判断超时开始批量断线重连。从此立下规矩IO 线程零阻塞一切慢操作过 MQ。坑三坐标混用。前端有人用终端原始坐标WGS-84直接上图有人调了地图 SDK 的自动纠偏GCJ-02同一辆车在不同页面上能差出几百米。后来强制单一口径纪律服务端只存只推 WGS-84谁渲染谁负责最后一跳转换混乱从此消失。十一、本篇小结五层架构、一条业务闭环、四条设计纪律就是这套平台的骨架。没有一件武器是新造的值钱的是组合方式和边界纪律——它们决定了平台从 100 台车长到 10000 台车代码结构不用动只需要加机器。下篇《后端技术篇》钻进网关内部看细节Netty 管线怎么搭、MQ 回环为什么是线程模型的一部分、下行指令怎么在多个网关实例之间精准路由、1078 流媒体网关六个端口各干什么、94 张表怎么组织。文中部署地址、密钥、域名等敏感信息均已脱敏架构图为作者基于实际项目整理绘制。