JT/T 808 协议网关的设计与实现（第 2 篇 · 后端技术） - Sam Xiao
内容提要
文章介绍JT/T 808平台后端设计：jt-gateway负责808/1078/809协议接入，jt-server承载业务，两者仅通过RocketMQ信封通信。808网关用Netty管线解码，1078流媒体网关设六端口收流分发，809对接监管平台。下行靠Redis会话路由，数据层采用统一信封、月分区和双轨ORM，自研模块无状态以保障高可用。
延伸解读
协议与业务分离的实际收益
jt-gateway只负责协议翻译，jt-server只处理业务，两者通过RocketMQ信封通信。这种严格分离让协议变更不影响业务逻辑，业务迭代也不干扰协议接入。例如新增消息类型时，只需在网关codec中添加协议类，业务侧增加消费者，网关代码无需改动。同时，网关和业务可独立扩容，发版不断连，提升了系统可用性和迭代效率。
1078流媒体网关的端口设计与资源回收
1078网关用六个端口分别处理实时视频、历史回放、对讲、浏览器播放、小程序播放和内部API。收流与播放分离，支持一路流被多个消费者同时拉取。为避免资源浪费，设置30秒无消费者自动回收流并通知终端停流。这一规则解决了测试环境中忘关流导致流量大量消耗的问题，体现了对视频流这种昂贵资源的精细管理。
下行路由与水平扩容的巧妙实现
下行指令需要找到终端连接的网关实例。网关在鉴权通过后，将tid到网关实例ID的会话写入Redis。jt-server发送指令时，先查Redis获取目标实例，再通过RocketMQ定向投递。这套机制天然支持水平扩容：新增网关实例只需注册到Nacos，新终端会话自动写入新实例，下行路由无需配置变更或数据迁移，简化了运维。
数据层设计：信封、分区与双轨ORM
统一信封JtMessageEnvelope消除了网关与业务间的数据方言，新增消息类型只需扩展codec和消费者。PostgreSQL月分区管理轨迹和报警表，通过XXL-Job预建分区，查询自动裁剪，归档高效。ORM采用双轨制：低频CRUD用MyBatis-Plus保留租户拦截器，高频轨迹写入用JdbcTemplate直写绕过拦截器链，以匹配不同频率的数据操作需求。
Q&A
JT/T 808 协议网关中，jt-gateway 和 jt-server 是如何划分职责的？
jt-gateway 负责协议接入，包含 808、1078、809 三个独立进程，只翻译协议，不处理业务；jt-server 承载全部业务，分为基础域、核心域、动作域和外延域，不接触字节流。两者仅通过 RocketMQ 信封通信。
为什么 808 网关解码后不直接调用业务，而要经过 RocketMQ？
因为 MQ 在这里是线程模型的一部分，不是单纯的跨进程通信。三个理由：IO 线程零阻塞，慢操作扔进 MQ 或异步线程池；MQ 起到缓冲作用，避免业务处理堵塞网络层；消费线程池可以并行处理轨迹入库、围栏计算、WS 推送等任务。
1078 流媒体网关为什么需要六个端口？分别有什么用途？
六个端口各司其职：6802 实时视频收流，6803 历史录像回放收流，6805 双向对讲，6899 浏览器播放（WebSocket-FLV），6810 小程序/H5 播放（HTTP-FLV），6809 对内 API（jt-server 来要流、关流）。收流和播放分开是因为一路车载流可能被多方消费，收流端只收一份，分发端各拉各的。
jt-server 如何将下行指令路由到正确的网关实例？
通过 Redis 会话路由：终端鉴权通过时，网关会往 Redis 写一条会话记录（tid → 网关实例 ID）。jt-server 发送下行指令时，先查 Redis 获取终端所在的网关实例 ID，然后通过 MQ 广播消息，各网关实例根据消息中的网关实例 ID 过滤，只有目标实例会处理并下发指令。
JT/T 808 平台的数据层采用了哪些关键设计来应对海量数据？
四个关键决策：1. 统一信封 JtMessageEnvelope 消灭数据格式方言；2. Redis 键分两类，终端会话键管下行路由，最后位置快照键管看车不查库；3. PostgreSQL 月分区管理轨迹和报警表，XXL-Job 每月自动预建下月分区，超期分区整月 detach 归档；4. ORM 双轨制，低频 CRUD 走 MyBatis-Plus，高频写入走 JdbcTemplate 直写。
JT/T 808 平台的高可用设计原则是什么？
原则是：自研的部分全部无状态，有状态的事全交给专业中间件。这样每个组件挂掉都不会影响整体服务，通过中间件保障数据一致性和可靠性。
