云厂商解耦的文件中台

该项目为业务系统提供统一的文件服务，使上传、下载和临时访问不再直接依赖具体云厂商。

单一应用的文件上传并不复杂，但当多个系统都直接使用 Ceph 的地址、密钥和接口后，迁移到 OBS 或 OSS 就需要逐个修改、测试和发布。存量文件迁移、旧链接兼容和失败回退也会成为独立风险。

项目将“每个应用分别连接存储”的方式，改造为由文件中台统一管理的共享能力。

职责与关键工作

我负责架构方案与关键落地路径，工作范围包括：

• 设计统一接口。 业务只需要使用上传、下载、临时访问、查询信息和删除等常用能力，不再直接依赖某个厂商的 SDK。
• 梳理厂商差异。 对比 Ceph、OBS 和 OSS 在分片上传、元数据、签名链接、生命周期和错误处理上的区别，明确哪些可以统一，哪些必须保留差异。
• 统一安全管理。 长期云密钥不再散落在各个应用中，由平台集中保管，并为用户签发有范围、有时限的访问链接。
• 设计可回退的迁移。 新旧存储先并行，新文件逐步切换，历史文件分批搬迁并校验；如果发现问题，可以暂停或退回旧路径。

同时推进统一 SDK、监控和故障处理规范，使方案具备接入、运行观察和迁移能力。

统一服务边界

对于接入方，文件服务像一个统一窗口。应用告诉平台“我要上传这个文件”或“请给我一个十分钟内有效的下载地址”，平台再根据配置选择实际存储位置。

业务系统不再负责拼接地址、计算签名或处理厂商特有错误。以后更换存储时，改动主要发生在平台适配层，而不是扩散到每个应用。

但统一接口并不意味着假装所有厂商完全相同。例如，某家支持的特殊元数据功能，另一家可能没有。我先做能力对照：

• 行为一致的能力，放进统一接口；
• 可以转换的能力，由平台适配，并说明限制；
• 只有单一厂商支持的能力，明确标为扩展；
• 无法可靠支持的请求，尽早返回清楚的错误。

这样做避免了“代码看起来兼容，真正运行时结果却不一样”。

存量文件迁移

迁移不是把一个地址换成另一个地址。它同时涉及正在产生的新文件和已经存在多年的旧文件。

我的方案是先让统一客户端接管入口，同时保留旧存储；然后逐步把新写入切到新平台。历史文件按小批次复制，每个文件用校验值确认内容没有变化，并记录进度和失败原因。引用关系、访问权限和 CDN 行为也需要一并验证。

在新平台稳定之前，旧路径不会立刻删除。这意味着迁移可以暂停、重试或回退，而不需要用一次高风险切换来赌结果。

结果与架构价值

这项工作降低了业务系统与云厂商的绑定。以后增加或更换存储服务时，不需要组织大量应用同时改造；密钥管理更集中，故障也可以按业务问题、平台问题或厂商问题快速区分。

更重要的是，它把存储迁移从一次不可控的大动作，变成可以分批执行、逐步验证、随时止损的平台操作。

接口设计、安全控制、厂商差异、存量数据和回退方案要同时成立，平台边界才能在真实迁移和生产流量里站得住。