探索架构#

我们先不讲一个抽象的概念，我们首先来做一个小项目

一个随机图API，每次请求都返回不同的图片

你会怎么做？

有非常多的解决方案，就拿最简单的一说，我们可以先搞来一个服务器，然后往里面塞图片，最后写一个脚本创建一个Web服务器，接收客户端请求，每一个请求都从图片库里抽一张图返回

能实现吗？

当然可以！这是你的流程图！

1
flowchart TD
2
    A[客户端请求<br/>GET /random]
3
    B[Web 服务器接收请求]
4
    C[从图片目录读取图片列表]
5
    D[随机选择一张图片]
6
    E[读取图片文件内容]
7
    F[构造 HTTP 响应<br/>Content-Type: image/*]
8
    G[返回图片给客户端]
9

10
    A --> B
11
    B --> C
12
    C --> D
13
    D --> E
14
    E --> F
15
    F --> G

但也会带来一些问题，比如，图片存在本地，给客户端响应图片的时候走的是你机子的流量，那么你就需要一个 高带宽 的服务器，这无疑是一个 高昂 的成本

那可能你会有新的方案： 前后端分离 （逻辑与资产分离），只将返回这个图片的逻辑存放在服务器上，而图片存到其他地方，如对象存储（Cloudflare R2）、IPFS等等

1
flowchart TD
2
    A[客户端请求<br/>GET /random]
3
    B[随机图逻辑服务器]
4
    C[读取图片索引 / 元数据]
5
    D[随机选择一张图片]
6
    E[生成图片访问地址<br/>R2 / IPFS / 对象存储]
7
    F[返回 302 重定向<br/>Location: 图片URL]
8
    G[客户端请求图片资源]
9
    H[对象存储 / IPFS / CDN]
10
    I[返回图片数据给客户端]
11

12
    A --> B
13
    B --> C
14
    C --> D
15
    D --> E
16
    E --> F
17
    F --> G
18
    G --> H
19
    H --> I

那么问题又来了，假如说你的项目太多人用了，那你的服务器性能可能不够，在后期，你仍然需要一个 高昂 的 维护成本

那么那么那么，现在是 2025 年，传统的架构已经无法满足我们了，我们不妨可以试试 云函数 仍然是前后端分离，我们现在将逻辑放到一个函数上面，如Cloudflare Worker、EdgeOne Function、Vercel Function等等

1
flowchart LR
2

3
    Client[客户端]
4

5
    subgraph Logic[逻辑层（云函数 / API）]
6
        A[接收 /random 请求]
7
        B[读取图片索引]
8
        C[随机选择图片]
9
        D[生成访问地址]
10
        E[返回 302 重定向]
11
    end
12

13
    subgraph Assets[资产层（静态资源）]
14
        F[CDN / IPFS Gateway]
15
        G[对象存储<br/>R2 / S3 / COS]
16
    end
17

18
    Client --> A
19
    A --> B
20
    B --> C
21
    C --> D
22
    D --> E
23
    E --> Client
24

25
    Client --> F
26
    F --> G

那么现在是不是无敌了？

并非，虽然前端因为使用了 云函数 也就是直接接入了CDN，高并发已经不是问题了，但是由于资产并不直接托管在 云函数 中，云函数 仍然需要创建一个长连接从你的后端，如对象存储获取图片，这样一折腾，你的服务可能并不算快

有人就会说了，那既然现在我都把我服务器丢了，前端在云，后端也在云，为什么不直接让前端的云直接存储后端的资产呢？

当然可以！你已经非常接近最佳实践了！

绝大部分 云函数 都支持动静结合，也就是支持你在他们的云存放一些动态脚本，再顺便 存放静态资产

那么接下来，你就得到了一个完全不需要你买服务器托管，也不需要你担心存储爆仓导致天价账单的随机图…了吗？

1
flowchart TB
2

3
    C1[客户端1]
4
    C2[客户端2]
5
    C3[客户端3]
6

7
    A1[请求API]
8
    A2[请求API]
9
    A3[请求API]
10

11
    F1[云函数节点1]
12
    F2[云函数节点2]
13
    F3[云函数节点3]
14

15
    R1{抽选一张图片}
16
    R2{抽选一张图片}
17
    R3{抽选一张图片}
18

19
    S[云函数静态资产]
20

21
    C1 --> A1 --> F1 --> R1
22
    C2 --> A2 --> F2 --> R2
23
    C3 --> A3 --> F3 --> R3
24

25
    R1 --> S
26
    R2 --> S
27
    R3 --> S

探索随机图（随机URL）的本质#

我们刚刚只是在抽象的说明某种架构 好像 可行，好像 又有什么问题，然后又有一种什么新思路 好像 可以解决这个问题

但我们要走的路才刚刚开始，我们不妨思考一下，随机图，又或者说随机URL这类项目，服务器（如果有）究竟发送了什么给客户端，客户端又对服务器发回的报文执行了什么动作

你肯定知道，如果想要客户端每次请求同一个URL，都返回不同的东西，那肯定是服务器针对每一个请求都返回了不同的响应，它可以是内部的，比如直接在响应体塞图片，又或者也可以是 重定向

直接在响应体塞图片很简单，在客户端是不可见的，当客户端请求API时，服务器直接将选中的图片作为响应体发出，在客户端看来，就好像是请求了一张图片，只不过每次刷新都不一样

而响应 重定向 就更简单了，只需要让服务器发送一个 临时重定向 的状态码，比如 302

有人就会说了，为什么必须要 临时重定向 ？

因为你肯定是想要客户端每次刷新都返回不同的图，一旦你使用了 永久重定向 如 301 ，客户端在收到 301 的那一刻就会在浏览器里写一个记录：下次访问这个URL直接重定向，不再请求服务器 ，这就会导致你的随机图API真的就变成一张图片了

那么，这两种方法哪种更好呢？

各有利弊，一句话说明：直接返回MIME类型是连请求复用，仅需一次请求即可得到图片。而返回302重定向至少需要客户端请求两次

这得看你的实际架构，如果说你是前后端分离，即逻辑和资产不在一个地方，肯定是 302 好，因为如果你直接在响应体塞图片，就相当于你的服务器作为 代理 让客户端访问你的资产，流量全部走你服务器

而如果说你前后端都在一起，正常情况下来说，一次请求复用肯定是比两次连接更快的，不过为了方便管理和统计，我的大部分API仍然使用 302 重定向

上线的API： https://eopfapi.acofork.com/pic?img=ua

奇技淫巧1：利用Cloudflare Origin Rules实现无计费的随机URL#

Video: https://www.bilibili.com/video/BV19ZBzB8EDQ/ 起因于有一天一位粉丝在我视频下留言

他提到的仓库为

大致为，Cloudflare在规则提供一个方法，该方法可以在规则层生成一个UUID，而UUID每次都是随机的，我们可以依据此来在规则层做随机URL

理论可行，实践开始

首先，我们要知道UUID是一串带有连字符的随机数，而每一位有16种可能，我们可以仅截取前4位，也就是 16^4 ，共能存储65536张图，每一张图可以分配到一个唯一的UUID，接下来让CF边缘在收到请求的时候，生成UUID，然后直接拼接URL请求静态资产，如 /img/0000.webp ，再返回给客户端即可

那如果说我图比这多呢？加一位，16^5 = 1048576，够用了吧 那如果说我图比这少呢？那我们可以让图片填充，说个极端的例子，假如你只有2张图，每张图创建32768个副本即可，依此类推

1
flowchart TD
2

3
A[客户端请求<br/>GET /h]
4
B[Cloudflare 边缘节点]
5
C{Transform Rules<br/>是否匹配?}
6

7
D[Rewrite URL<br/>动态重写 Path]
8
E[按原路径处理]
9

10
F[生成随机字符串<br/>uuidv4 + random_seed]
11
G[取前三位十六进制字符<br/>substring 0~3]
12
H[拼接新路径<br/>/h/abc.jpg]
13

14
I[Cloudflare Pages 静态站点]
15
J[命中 dist/h/abc.jpg]
16
K[直接返回图片资源]
17
L[客户端接收随机图片]
18

19
A --> B
20
B --> C
21

22
C -- 是 --> D
23
C -- 否 --> E
24

25
D --> F
26
F --> G
27
G --> H
28
H --> I
29
I --> J
30
J --> K
31
K --> L

上线的API： https://img.072103.xyz/h | https://img.072103.xyz/v

奇技淫巧2：丢掉后端，让前端JS自己拼URL#

Video: https://www.bilibili.com/video/BV1tNB4BEEaE/ Video2: https://www.bilibili.com/video/BV1mMBKBREkB/

把思路打开，我们真的需要一个 请求一个端点，返回一个随机内容 的东西吗

如果只是想在我们的网站上用上随机图，那是不是可以让客户端JavaScript代劳呢

大致原理为编写一个客户端JS，生成一个随机数，然后拼接URL得到最终的随机图，然后寻找需要替换为随机图的img容器或者背景图容器，替换其中内容

1
flowchart LR
2
  subgraph build["构建期"]
3
    direction LR
4
    src["原始图片"] --> buildjs["build.js"]
5
    buildjs --> static["静态图片库"]
6
    buildjs --> randomjs["random.js"]
7
  end
8

9
  subgraph runtime["运行期（浏览器）"]
10
    direction LR
11
    exec["random.js 执行"] --> pick["随机选图"] --> dom["DOM 注入"]
12
  end
13

14
  randomjs --> exec

上线的 API： https://pic1.acofork.com

总结#

我们共探索了三种流派

• 传统派：中规中矩，在边缘函数找图，取图
• 极客派：通过CF的规则实现在边缘找图，取图，但是不计费
• 环保派：通过客户端JS直接在浏览器上实现找图，取图，改图