企业官网建设流程全解析

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定位报文，它的旅程是：

1. 注册鉴权上线：新设备先走注册（0x0100）拿到鉴权码，之后每次上线鉴权（0x0102）。鉴权通过后，网关把"这台设备（tid）连在我这个网关实例上"写进 Redis 会话表——这行数据是后面下行路由的关键
2. Netty解码：808 网关的 IO 线程做拆包粘包（0x7e帧界）、转义还原（0x7d转义序列）、校验和验证，然后交给 codec jar 把字节解析成协议对象——IO线程到此为止，绝不多干一行活
3. MQ回环削峰：协议对象包进统一信封，投进 RocketMQ。定位洪峰（比如早高峰全城车辆同时苏醒）来了先进队列排队，而不是直接打爆业务线程池
4. 三路并行消费：业务线程拿到信封后分三路干活——轨迹入库（PG 月分区表）、围栏计算（在不在电子围栏里，越界就产生报警）、WS 推送（给正在看这台车的浏览器/小程序推实时位置）
5. 地图上动了一下：前端收到推送帧，经过第 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 播 FLV，H.265 走 WASM 软解——车载摄像头为了省流量大量采用 H.265，浏览器原生不支持，这是绕不过去的坎，第 3 篇细讲

整个技术栈里最特别的一个组件，是codec 纯 jar：808/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 直写，绕过拦截器链保吞吐。双轨制，各取所长，谁也不委屈。

九、四条设计纪律

三篇文章会反复回到这四条纪律，它们是这套平台的"宪法"，比任何单个技术选型都重要：

1. 协议与业务分离：网关只翻译协议，业务不碰字节流，中间只过 MQ 信封
2. codec红线：编解码唯一实现、零三方依赖、单测把守，四个进程共用
3. 坐标单一口径：全链路存储与计算用 WGS-84，只在渲染边界才转 GCJ-02（第 3 篇细讲这个坑有多深）
4. 看车不查库：实时状态全走 Redis + WS 推送，数据库只服务历史查询和快照

十、踩过的三个坑

坑一：惊群。早期网关和业务同进程，一次发版重启，几千台终端同时重连 + 补鉴权，瞬间把服务打挂，挂了就再重连，恶性循环。解法就是上面说的：连接和业务分进程，业务随便发版，连接纹丝不动。

坑二：把 MQ 当"可选项"。最初图省事，IO 线程解码完直接同步调业务。压测时一条慢 SQL 卡住业务线程，反压到 IO 线程，上千个连接的读事件全部延迟，终端判断超时开始批量断线重连。从此立下规矩：IO 线程零阻塞，一切慢操作过 MQ。

坑三：坐标混用。前端有人用终端原始坐标（WGS-84）直接上图，有人调了地图 SDK 的自动纠偏（GCJ-02），同一辆车在不同页面上能差出几百米。后来强制"单一口径"纪律：服务端只存只推 WGS-84，谁渲染谁负责最后一跳转换，混乱从此消失。

十一、本篇小结

五层架构、一条业务闭环、四条设计纪律，就是这套平台的骨架。没有一件武器是新造的，值钱的是组合方式和边界纪律——它们决定了平台从 100 台车长到 10000 台车，代码结构不用动，只需要加机器。

下篇《后端技术篇》，钻进网关内部看细节：Netty 管线怎么搭、MQ 回环为什么是线程模型的一部分、下行指令怎么在多个网关实例之间精准路由、1078 流媒体网关六个端口各干什么、94 张表怎么组织。

文中部署地址、密钥、域名等敏感信息均已脱敏；架构图为作者基于实际项目整理绘制。