目前需求：
目前考虑的方案：
目前问题的点是：
 | 1 v1 Aug 12, 2024 图片分发是直接推给用户？建议 api 部分改成 cvm 或者多台轻量负载，处理云函数，推流直接 cos+防盗链+定时删除 |
 | 2 shepherdlazy Aug 12, 2024 处理很耗时吗？为什么不用户首次获取图片的时候再处理呢？ 不了解你的使用场景哈，只是设想下。 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 Aug 12, 2024 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 Aug 12, 2024 需求是不是可以再完善一些,比如原始图片大小、图片是否涉密、上传频率还有开发周期、人力 |
 | 5 Vadden Aug 12, 2024 成本方面，云函数按照调用次数或者函数运行时间收费，图片处理数量多时，可能成本较高 |
 | 7 caijunduo OP @shepherdlazy #2 还是挺耗时的，一张图处理耗时在 5-10s ，因为涉及多种图片处理策略，而且图片是属于收费项目的，让用户在首次获取图片时再处理体验较差，最终才采用队列提前生成好 |
| 8 caijunduo OP @Alan0000 1. 原始图片大小基本在 1-10M 左右，因为原始图片是属于收费项目，不好压缩，不然会有损 2. 图片存在涉密，通过图片加密等处理，生成专属用户的一张图片 3. 上传频率还好，主要是分发用户多，又要求用户专属，所以分发图片数量会很多，但原始图片不多 4. 开发周期 3 个月 5. 人力我自己 |
 | 9 xiaoming1992 Aug 12, 2024 via Android 图片是否支持前端处理呢？如果支持： 你们这个服务一看就是收费的，给用户提供选择，如果用户同意前端处理，就提示不要关闭网页。然后每个月给他便宜个十块八块的。 |
 | 10 julyclyde Aug 14, 2024 1 图片处理服务，云那边不是已经提供了？？ |
Select Language