L4 路线下发与车云调度

问题

真车协议里只有路线号与流水号，没有云端任务号。车端上报回来时，云端无法把这次上报关联到具体某一次下发 —— 也就无法驱动任务状态机、无法回放轨迹。而这份协议早于云端任务体系存在，改它意味着车端要跟着改并重新验证。

备选方案

• 改真车协议，加一个任务号字段：最干净，但要车端配合改动与回归
• 云端用「车辆 + 路线号 + 流水号」反查任务：不改协议，但流水号一旦重复或乱序就会错配
• 同一主题连发两条：裸报文保证真车能跑，信封报文携带任务号

选择

双报文下行。第一条是真车协议原样，第二条是带任务号与完整路径点的信封。车端只解析第一条也能正常行驶，解析第二条则能在上报中带回任务号，云端拿到精确关联。

代价

下行流量翻倍，且两条报文的顺序一致性必须由发送方保证。更实际的代价是：只要车端不解析第二条，云端就只能退回反查方案 —— 所以这个设计的成立与否，取决于车端是否愿意接。这一点需要对方拍板，不是云端单方面能定的。

问题

车端协议要求流水号形如「日期-序号」，且同一车辆当日不能重复。最初用数据库自增列生成，上线前发现两个必现问题。

备选方案

• 数据库自增：跨自然日不会归零，序号会一直涨；多实例并发下还要额外加锁才能保证「按车辆」唯一
• 服务端本地计数：多实例部署直接失效
• 缓存中按「车辆 + 自然日」为键原子递增：天然按车辆隔离，跨日自动从 1 开始

选择

按「车辆 + 自然日」组合键原子递增，键设三天过期。递增操作本身是原子的，多实例并发无需额外加锁；键里带日期，跨日自然归零。

代价

流水号依赖缓存可用性，缓存丢失会导致当日序号重新从 1 开始。因为键只用于当日内区分下发批次、且带三天冗余过期，重复的实际影响可接受；真正要保证唯一的是任务号，那个在数据库里。

问题

真车资源稀缺、调度成本高，且早期几乎每次联调都会因为云端自己的问题失败一次。如果等真车才开始验证，云端的问题会全部堆到有限的现场窗口里暴露。

备选方案

• 等真车联调：链路真实，但迭代一轮以天计
• 写单元测试覆盖各环节：快，但覆盖不到跨进程的报文顺序与时序问题
• 搭一个按协议行为等价的模拟车端：能跑完整闭环，迭代以秒计

选择

实现模拟车端：订阅下行主题、解析信封报文、按 20km/h、1Hz 沿路径点插值行驶，并按真车格式回传位置与完成回执。云端侧的下发、状态机、轨迹落库、前端回放因此可以在没有真车的情况下全部验证。

代价

模拟车端是按协议文档实现的，它验证不了真车对协议的实际理解 —— 恰恰是「车端是否解析第二条报文」这类问题，只有真车才能证伪。所以它降低的是云端自身缺陷的排查成本，不能替代真车联调。