接完四家 S3 兼容云,路线图上排在后面的是"专有签名"这一档:金山云 KS3、UCloud US3、京东云。 本来打算从 KS3 开始,像阿里云 OSS / 华为云 OBS / 腾讯云 COS 那样,从零手写一套独立的签名器。 查完文档后,这个计划中途改了方向。

KS3 的签名文档:形状对了,但凑不出一个能验证的数字

金山云官方文档把 V2 签名的 StringToSign 结构写得很清楚:

StringToSign = HTTP-Verb + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +
               Date + "\n" +
               [CanonicalizedKssHeaders + "\n" +]
               CanonicalizedResource

Authorization: KSS {AccessKey}:{Base64(HMAC-SHA1(SecretKey, StringToSign))}——和阿里云 OSS 的 V2 签名几乎是同一个模子刻出来的,只是头前缀从 x-oss- 换成 x-kss-,scheme 从 OSS 换成 KSS。子资源白名单也查到了(acl/lifecycle/location/uploadId/versionId……)。

但团队给签名代码定的规矩是硬的:《SDK 开发手册》里写着"签名步骤额外要求:必须用该厂商官方文档 给出的示例(AK/SK + 预期签名)写一个单测,验证签名逐字节相等——这是唯一能离线证明签名正确的 手段,不允许跳过"。翻遍能找到的 KS3 文档,示例请求里的签名值都是打了马赛克的占位符(比如 Signature=cef04283a6cd6babf04x7f1ab132xq0ac7cd7q81537beqedbd4d9495f8a8axe3 这种一看就是 脱敏过的字符串),没有一个"给定 AK/SK/Date/请求 → 期望签名值"的完整数字向量。

这不是小事。这个仓库里有过真实教训:阿里云 OSS 用未编码的原始 key 参与签名,华为云 OBS 用 percent-encoded 的 key——两家看起来同源的签名算法,一个字符编码细节不一样,签名就对不上。 没有官方向量,只凭文档里的文字描述去猜空格、换行、编码这些细节,写出来的代码"看起来是对的"和 "真的是对的"之间那道坎,只有拿真实签名比对过才能跨过去。金山云这边没有真实账号,也没找到能验证 的向量,继续往下写等于是在赌。

顺手查了一下同档的 UCloud US3,发现它根本不需要专有签名器

金山云卡住之后,查了一下同一档的下一家——UCloud US3。官方文档一句话说明了情况:“仅支持 签名 V4”(不支持 V2)。US3 有一个专门的"AWS S3 协议支持"文档,写着"用户采用 AWS S3 协议的 软件、服务基本上可以做到无缝迁移"。也就是说,US3 走的是标准 AWS SigV4,和 Wasabi、Backblaze B2、DigitalOcean Spaces、Scaleway 这些"S3 门面"厂商是同一条路——不需要写新签名器,直接复用 s3-core 就行。这家从"专有签名"档意外空降回了"S3 门面"档。

endpoint 是 s3-{region}.ufileos.com(比如 s3-cn-bj.ufileos.com)——注意是 s3- 连字符, 不是 s3. 点号,和 AWS 那种 s3.{region}.xxx.com 形状又不一样,parse_region 内置的 strip_prefix("s3.") 在这里解析不出来。这是"包一层构造函数推导 region"这个模式里的第四种 变体:R2/MinIO 是硬编码常量,DigitalOcean Spaces 是取 endpoint 第一段,这次是先剥掉 s3- 前缀再取第一个 . 之前的段。四次遇到四种不同的 endpoint 形状,再次印证"新接一家云先查 endpoint 长什么样,不能预设立场"这条早就总结过的教训。

US3 的能力矩阵:目前接入的厂商里限制最多的一个

逐项查证下来,US3 是这五家 S3 兼容云里限制最多的:

  • 确认支持:分片上传、对象 ACL(private/public-read/public-read-write 三种 canned 值,是 Nebula 现有二态实现的超集)、生命周期规则(官方文档写"部分地域支持"——和 Scaleway GLACIER 只在两个地域可用是同一个道理,Nebula 拿不到桶所在地域的信息,不做客户端拦截,交给 后端报错)、单次对象复制(CopyObject)。
  • 明确不支持:版本控制、对象标签——官方文档白纸黑字写"暂不支持"。
  • 没有证据支持:CORS 配置接口不在官方 API 支持列表里;静态网站托管官方文档完全没提; 存储类型转换虽然给了 US3⇄S3 的存储类型映射表,但没查到"上传后能不能转换"的确认信息,保守 标不支持。
  • 看起来像限制、实际不影响我们:官方文档提到"UploadPartCopy 处于内测阶段"——但这指的是 分片复制这条路径,Nebula 的 copy 走的是单次 CopyObject,不受影响,不用因为看到"内测"两个 字就连带怀疑整个复制功能。

小结

这次的教训不是"US3 怎么样",而是签名器这一步"不允许跳过官方向量"这条规矩顶住了没有让步。 临时换标的不是走捷径,是查证过程里发现的真实情况——KS3 缺一个能验证的数字向量,US3 恰好不需要 这道验证就能高置信度地复用现成代码。金山云 KS3 和京东云这两家真正的专有签名 SDK 还留在路线图里, 等找到能验证的官方向量,或者能拿到真实账号做端到端验证,再动手写。

返回博客列表