一次旧系统的平滑迁移

一套监控系统运行多年以后，原有存储开始限制新的使用方式。

它能够支持固定时间范围的报表，却难以进行灵活查询，也不方便向其他系统开放指标。我们准备引入新的时序存储，同时保留旧系统继续运行。

真正困难的不是把数据写入新存储，而是怎样迁移已有的大量接入方。

客户端升级还是服务端改造

最直接的办法，是发布新版客户端，让业务项目逐步改为向新系统上报。

它的好处是新旧链路边界清楚，服务端不需要承担额外处理。问题也同样明显：接入项目很多，升级节奏无法统一，有些项目长期不再维护。迁移可能持续很久，期间还要同时维护两套接入方式。

另一种办法是在服务端改造。客户端继续按照原协议上报，服务端收到数据后同时写入新旧存储。业务方不需要配合，但双写会进入原有核心链路，可能影响正在运行的监控数据。

我们最终选择了服务端方案。它把迁移风险集中到平台团队，也让迁移进度变得可控。

最初实现是在原处理流程中直接把数据发送到消息队列，再由下游写入新存储。

数据量上来以后，双写性能明显下降。原系统本来能够处理的流量，因为新增链路开始受到影响。

后续优化分成几个方向：在发送前对指标进行预计算，减少原始数据量；把多条数据批量发送，降低网络与协议开销；使用更紧凑的序列化格式压缩消息；再将任务分片，避免处理集中在单一执行路径。

这些优化没有改变迁移目标，只是在控制双写给旧系统带来的额外成本。

双写以后，数据成功进入新系统并不代表迁移完成。

需要持续比较新旧结果，确认指标数量、时间范围和聚合结果是否一致。新链路出现问题时，还要判断是上报、消息传输、计算还是存储造成。

迁移期因此会暂时增加系统复杂度。旧逻辑不能立即删除，新逻辑又需要被完整监控。这个阶段如果没有明确结束条件，双写很容易从临时方案变成永久结构。

“平滑”容易让人以为迁移过程不会发生问题。实际上，它只是把一次集中切换的风险，拆成更长时间内可观察、可回退的步骤。

服务端双写降低了业务方升级的不确定性，却让平台承担更高性能风险；保留旧链路提供了回退能力，也增加了维护负担。方案并没有消除代价，只是选择了更适合当时组织条件的代价。

技术上更整洁的方案，不一定最容易在组织中完成。

当接入方数量很多、维护状态不一时，要求所有团队在同一时间配合升级，本身就是很高的协调成本。把兼容集中到平台端，有时比设计一套完美的新协议更现实。

这次迁移让我更清楚地认识到，旧系统改造不仅要考虑最终架构，还要设计从现在到最终状态之间的路径。迁移方案的质量，往往体现在这段中间状态是否可控。