1. 地球号头像/图标服务

1.1. 设计理念

头像服务与数据库脱离，即，图片传入bucket时触发函数计算，在函数计算里，不会访问数据库。也不依赖数据库，从而使得头像服务完全和数据库脱离。独立思考。

[!note|label:头像服务独立的缺点] 无法做出依赖数据库的检查，如，某个上传的用户id是否存在？但仔细想，这样的检查时无意义的，因为OSS上传是必然发生，后知后觉的。

[!note|label:客户端在申请sts的时候，是否要汇报自己要上传的文件的key? ] 需要。先说一下为什么有人想这么做，因为汇报了，我们可以在数据库临时创建一个临时的object_access_id,然后对穿上来的文件的函数计算触发，检查这个key是否存在。 这样做的好处是，我们能够知道哪些文件时走正常程序上来的，哪些是截取sts上传的。

1.2. 地球号头像服务列表

• 用户头像服务。地址:u/12345678.webp
• 社区图标服务。地址:z/12345678.webp
• 产品图标服务。地址:p/12345678.webp
• 象目图标服务。地址:c/12345678.webp

[!note|label:如果26个字母不够用怎么办?] 就可以用两个字母。如果将来不够了，可以换三个字母。

1.3. 技术结构

地球号头像服务包含如何资源。两个oss的bucket, 两个函数计算

• OSS BUCKET upatar-xuda-com, 上传头像文件,png/gif/jpg/jpeg,然后加工成webp存入avatar-xdua-com 这个过程是函数计算 oss_upatar_trigger来实现。
• OSS BUCKET avatar-xdua-com, 从uptar-xdua-com的文件过来后，存入它名下。全是8位短码的webp格式
• FC oss_upatar_trigger,做图片加工，目前制作格式转换，未来可以做加水印。图片存入avatar-xdua-com。

[!note|label:?] 就可以用两个字母。如果将来不够了，可以换三个字母。

1.4. 头像的格式

我们的做法，规定bucket的子文件夹为最小控制粒度。但avatar.xdua.com是个特例。我们很希望有avatar.xdua.com/12345678.webp 这样的短码路径。这样对user表压力也小。另外avatar仅仅是头像，它有自己独立的应用特征

1：文件都很小 2：只接受putObject接口，不支持断点续传，和multipart上传。 3：正因为只有putObject接口，我们就可以轻松的从obj的etag上获取它的MD5,然后转成8位短码。 4：头像上传还需要返回头像地址,因为网页上要立刻刷新显示。 5: 头像存储的OSS对象名不能有路径,这个必须SDK来控制。

avatar与普通的obj还不一样，

2. 如何搞定头像上传

【本方案已废弃】

第一步：创建一个专门上传头像的子账户，因为头像服务是全局服务，整个地球号就只需要一个。同时也创建全控账户，全空账户主要用来在控制台调用delObj来删除不用的obj的

第二步：

这个账号是可读/可写，那为什么不选择完全控制呢，因为完全控制，意味着可以删除，但我们不需要删除。

第三步：php集成OTS

https://github.com/ShaoZeMing/Aliyun-Sts

第四步：浏览器端上传obj的时候必须有对应的meta,否则传入就失败。

第五步：在后台读取上传的文件里相关的meta从oss.obj读出来存入数据库。

3. 地球号对象的skema

地球号的skema包含如下

4. 如何解决OSS死循环？

• 在阿里云控制台删除某个文件对象，引发BUcket里的真实文件被删除，删除的结果是，引发dua_trg_fobj函数计算。这并不是一个死循环，而是一个多余迭代。 解决方法：dua_trg_foby不要对文件删除敏感触发，删除操作只能在地球号控制台进行。

• 在地球号控制台硬删bucket里的某个文件，导致dua_trg_fobj被触发。 解决方法：dua_trg_foby不要对文件删除敏感触发，删除操作只能在地球号控制台进行。

怎么免疫文件删除，在dua_trg_fobj的对象触发器那里，不要加DeleteObj的相关触发。

5. 为什么要在文件上传的时候设计meta-objr-id标签？

obj的每个objcato都是用户自己创建的，但我们也有公用的cato。功能要支持如下功能

• 公共的objc，大家都可以访问。尤其是神店创建的那么多官方objc，要有一个方法可以管理这个可以这个访问，哪个可以访问。

• 有些开发者创建的Objc,这个是zone的属性。开发者可以配置，自己的Objc可以让哪个zone的user_id通过哪个app来访问。这种控制其实是控制了osssts的发放。

现在就是objr这个标签命名太难听了。

5.1. 问题，如果程序员通过别的channel申请获取一个ststoken,然后上传的时候通过token检查。上传到channl2里，完美绕过上传验证，如何应对？

一个方法是，可以把得到的授权做成token,但开发者仍旧可以用这个机制来绕过去。从公共的频道获取token,用到本次上传。

6. 如何设计文件上传机制？

第一步：确定objc_id(这个可以在公告文档中，也可以在开发者提供的目录)

地球号提供几个公共的cato，这个是地球号提供的免费公共服务。比方说
`TempCato`这个cato,你可以上传文件到这个cato,但文件保留24小时候就会被自动删除。

第二步：通过sts接口，获取一个临时文件上传sts.key/secret，并且有一个token用于放到meta里

这个地方要向接口提供 objc_id,而发起者自己的authorization会告诉sts接口自己的shop,app_id,user_id. sts接口还会返回一个objacs_id,这个objacs_id是个临时创建的表项。是个8位短码。 obja表存了对象名，channel,要传的文件名。

第三步：客户端上传文件时把obja_id放到meta里，

第四步: OSS触发函数dua_trg_fobj会检查obja_id，

通过obja_id搜查obja表，获取objc_id,okey,app 比较obja_表预定的okey和oss_event里的objk是否一致?

如果object_key一致，就可以把这个对象写入表了。

如果检查失败，就会标记例外到obje表里
如果检查成功，就会记录到obj表

i

7. 文件fobj_jkey命名规范，必须是一个8位的cato号和后续的oejbect_key。

现在的问题是，如果强硬把objc_id植入到objk的命名里。会出现这样的问题

+ 开发者A创建了一个`ExampleC`的objc。
+ 开发者A把它广告给其它所有人。
+ 用户开始把文件传到这个目录
+ 文件越来越多
+ 开发者A注销了`ExampleC`这个objc。
+ 这个目录下的文件都失效了。
+ 开发者A删除了`ExampleC`这个objc，也相当于删除了这个目录。
+ 这个目录下的所有文件都消失了。
+ 这些文件不可以重用了

这个问题很严重，我们需要再三考虑。

考虑的结果是:objc_id一旦创建，就不能改变。obj_key中一定要有个8位的objc_id。这样创建的文件obj一旦创建，就不能改变了。