目前需求:
目前考虑的方案:
目前问题的点是:
1
kk2syc 111 天前
图片分发是直接推给用户?建议 api 部分改成 cvm 或者多台轻量负载,处理云函数,推流直接 cos+防盗链+定时删除
|
2
shepherdlazy 111 天前
处理很耗时吗?为什么不用户首次获取图片的时候再处理呢?
不了解你的使用场景哈,只是设想下。 1. 用户上传到图片存储[原始存储]可以是服务器、目录或存储池。例如 http://example.com/origin/a.jpg 2. 服务器端用户消息分发,根据不同图片和用户生成不同 URL 推送给用户,例如图片 a ,用户 x ,http://example.com/u/x/a.jpg 3. 用户收到推送消息,开始下载图片 3.1 服务器收到图片请求,检查缓存是否存在图片,即是否实际存在 /u/x/a.jpg ,如果不存在,调用图片处理函数或添加到列队生成图片。wait 3.2 返回用户请求图片 |
3
shepherdlazy 111 天前
API 两个:上传图片,处理图片(将处理后图片生成到缓存位置,并返回处理的图片)
http://example.com/api_v1/image/upload http://example.com/api_v1/image/process [内网 API] 用户请求图片 http://example.com/u/x/a.jpg 时,nginx 确定文件是否存在,如果文件不实际存在时,反向代理到内网的图片处理 API ,并返回结果 |
4
Alan0000 111 天前
需求是不是可以再完善一些,比如原始图片大小、图片是否涉密、上传频率还有开发周期、人力
|
5
Vadden 111 天前
成本方面,云函数按照调用次数或者函数运行时间收费,图片处理数量多时,可能成本较高
|
7
caijunduo OP @shepherdlazy #2 还是挺耗时的,一张图处理耗时在 5-10s ,因为涉及多种图片处理策略,而且图片是属于收费项目的,让用户在首次获取图片时再处理体验较差,最终才采用队列提前生成好
|
8
caijunduo OP @Alan0000
1. 原始图片大小基本在 1-10M 左右,因为原始图片是属于收费项目,不好压缩,不然会有损 2. 图片存在涉密,通过图片加密等处理,生成专属用户的一张图片 3. 上传频率还好,主要是分发用户多,又要求用户专属,所以分发图片数量会很多,但原始图片不多 4. 开发周期 3 个月 5. 人力我自己😂 |
9
xiaoming1992 110 天前 via Android
图片是否支持前端处理呢?如果支持:
你们这个服务一看就是收费的,给用户提供选择,如果用户同意前端处理,就提示不要关闭网页。然后每个月给他便宜个十块八块的。 |
10
julyclyde 109 天前
1 图片处理服务,云那边不是已经提供了??
|