做了三年车联网，我做过一个决定：放弃自研JT808网关。

这个决定不容易。团队花了半年写的代码，说扔就扔。但后来证明，这个决定是对的。

自研网关的三年

我们的JT808网关，最开始是2019年写的。当时的需求很简单：接收终端位置上报，存到MySQL，提供查询API。

第一版很快上线，跑了几百台车，没问题。

然后问题来了。

2020年，接了某厂商的终端，发现附加信息ID编码不一致。 标准里附加信息ID是1字节，那个厂商搞成了2字节。我们改了解析代码。

2021年，接了另一个厂商的终端，发现补报定位数据长度跟原始包不一致。 整包解析出错。我们又改了。

2022年，客户要求支持JT1078视频。 我们花了三个月对接ZLMediaKit，处理RTP/RTCP，调流媒体分发。

2023年，客户要求信创适配。 数据库从MySQL迁到达梦，SQL语法不兼容，分页查询性能下降。我们又花了两个月改存储层。

三年下来，网关代码从5000行涨到30000行。每次加一个新终端厂商，就要加一个适配器。每次加一个新协议，就要加一个解析器。每次换一个数据库，就要改一遍存储层。

代码越来越复杂，测试越来越难，上线越来越怕。

一个让我下决心的晚上

去年冬天，一个周五晚上，网关突然报警。某厂商的终端批量掉线，每小时掉几百台。

我远程登上去看日志，发现分包缓存满了。因为那个厂商的终端，分包序号从0开始，但我们的代码假设从1开始。收不到序号1的包，缓存永远不释放。

凌晨两点，我改了代码，加了兼容。凌晨四点，上线。凌晨六点，又出问题了——另一个厂商的终端，分包消息的流水号每个包都不一样，我们的缓存key对不上。

那天晚上，我坐在机房门口，想了一个问题：我到底在做什么？

我在给终端厂商擦屁股。我在重复解决已经被解决过无数次的问题。我在把时间花在协议解析上，而不是业务创新上。

找到JTE之后

后来一个朋友推荐了JTE。我花了一个周末看它的代码。

pkg/jt808里，帧解析、转义、分包缓存，都封装好了。module-adapter里，终端适配层做成了可插拔的接口。module-storage里，存储抽象把数据库差异隔离了。

我特别注意了它的分包缓存设计：

type PacketCache struct { total    uint16 received map[uint16][]byte lastSeen time.Time base     uint16 // 序号基准，0或1 } base字段就是兼容不同厂商序号基准的。JTE在初始化时根据终端厂商配置，自动设置base。

还有它的存储抽象： type Storage interface { SavePosition(ctx context.Context, pos Position) error QueryTrack(ctx context.Context, vehicleID string, start, end time.Time) ([]Position, error) SaveAlarm(ctx context.Context, alarm *Alarm) error } 业务层只依赖接口，不依赖具体数据库。达梦、金仓、TDengine、MySQL，都实现了这个接口。切换数据库只改配置。

迁移过程

我们花了两周时间，把自研网关迁移到JTE。

第一周，把终端接入层替换成JTE的module-adapter。原来每个厂商一个适配器，现在只需要配置。

第二周，把存储层替换成JTE的module-storage。原来写死的SQL，现在通过接口调用。

迁移完成后，代码从30000行降到8000行。不是功能变少了，是重复代码被抽走了。

更重要的是，我不用再担心“下一个终端厂商又有什么坑”。JTE的社区在持续适配新的终端型号，issue里有人反馈，PR里有人修复。

自研还是用开源？

如果你问我，自研还是用开源，我的答案是：看你的核心竞争力在哪。

如果你的核心竞争力是协议解析，那自研没问题。但大多数车联网公司的核心竞争力，是客户关系、业务理解、交付质量、售后运维。协议解析是基础设施，不是核心竞争力。

就像没人会因为自己会发电才开工厂。电是买来的，你专注于生产。

JTE用AGPL-3.0，企业商用需要购买授权。有人觉得开源还收费不合理。但你想过没有：一个七八十万的协议团队，换成几万块的授权费，省下来的钱干什么不行。

最后说一句

如果你的团队正在被JT808、JT1078、JT809的兼容问题折磨，如果你的网关代码越来越复杂、越来越不敢动，建议你花一个周末看看JTE。

不一定马上迁移，但至少可以看看别人是怎么把这件事拆解清楚的。

项目仓库：

Gitee：suoten/jt-engine GitHub：suoten/JTEngine