一次旧系统的平滑迁移

一套监控系统运行多年后，旧存储只能较好地支持固定时间范围的报表，灵活查询和向外开放指标都不方便，我们准备引入时序存储，同时保留旧系统运行。

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

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

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

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

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

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

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

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

后来先在发送前预计算指标，减少原始数据量，再批量发送，降低网络和协议开销。同时采用更紧凑的序列化格式，并把任务分片，避免处理都集中在一条执行路径上。

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

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

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

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

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

服务端双写不用等待业务方升级，但性能风险由平台承担，旧链路可以回退，却也得继续维护。这些成本在选择方案时就需要考虑。

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

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

这次迁移里，最终写到哪里反而比较容易确定，花了更多精力的是兼容、双写和结果校验，要让旧系统在这段时间里继续正常运行。