无服务器短链接服务：API网关和FunctionGraph的使用

一、背景：短链接服务，其实是 Serverless 的好教材

短链接（把长 URL 压缩成 t.cn/abc）看着简单，但要长期跑稳定，传统做法得有一台常驻服务器、一个数据库、一套路由。量小的时候，这台服务器的算力基本在空转，却一直计费。如果换成 Serverless 思路——请求来了才跑函数、平时零成本——刚好契合"短链接查询是突发、低频、无状态"的特点。

华为云的 API 网关（APIG）负责把 HTTP 请求接进来并做路由、鉴权、限流，FunctionGraph 负责真正的增/查逻辑，两者拼起来就是一个完整的无服务器短链接服务。本文把这条链路讲通，重点在 API 网关怎么把请求转给函数、函数里怎么存映射关系。

二、链路拆解：请求从哪来到哪去

一次"访问短链跳转到原链"的完整路径：

1. 用户浏览器访问 https://你的域名/abc；
2. API 网关收到请求，按路由规则转发给背后的 FunctionGraph 函数；
3. 函数从存储里查出 abc 对应的原 URL；
4. 函数返回 302 重定向，浏览器跳走。

而"创建短链"是另一条：客户端调 POST /create 带上原 URL，函数生成短码写进存储并返回。存储可以用 DCS Redis（快、带过期）或者云数据库，按是否需要持久化选。本文以"查询走函数 + 存储用 Redis 思路"为例，具体选型以官方文档为准。

三、函数在做什么

核心就两个动作。查询函数收到 code 后查原链并返回 302：

def redirect_handler(event, context):
    code = event.get("pathParameters", {}).get("code")
    origin = storage_get(code)          # 从存储取原URL
    if not origin:
        return {"statusCode": 404, "body": "not found"}
    return {
        "statusCode": 302,
        "headers": {"Location": origin},   # 浏览器据此跳转
        "body": ""
    }

创建函数生成短码并写入：

def create_handler(event, context):
    body = json.loads(event.get("body", "{}"))
    origin = body.get("url")
    code = gen_code(origin)              # 短码生成，哈希或随机都行
    storage_set(code, origin, ex=86400*365)  # 设个过期，按需
    return {"statusCode": 200, "body": json.dumps({"short": code})}

这里返回 302 + Location 头是跳转的关键，API 网关透传这个响应，浏览器就完成了重定向。短码生成用原 URL 的哈希（同一长链始终得同一短码）或随机串都行，前者省存储、后者防枚举，按需求选。

四、API 网关怎么把请求交给函数

函数写好只是后端逻辑，真正对外要让用户能 HTTP 访问，靠 API 网关：

1. 在 API 网关创建 API 分组，绑定你的自定义域名（或先用网关分配的临时域名）。
2. 新建一个 API，方法 GET，路径 /{code}，后端类型选「函数工作流 FunctionGraph」，指向你的查询函数。
3. 再建一个 POST /create，后端同样指向创建函数。
4. 配置好发布到对应环境（如 RELEASE），拿到可调用的 URL。

网关在这里不只是转发，还能顺手做鉴权（创建接口加个 Key 防止被乱发短链）、限流（防刷）、CORS（前端跨域调用）。这些在控制台勾选即可，不用在函数里手写，比自己造轮子干净。具体网关的 API 定义字段、环境变量和发布流程以官方文档为准，照着填不会错。

五、几个工程上的注意点

第一，创建接口必须鉴权。如果 /create 完全公开，任何人都能拿你的服务发短链，容易被用来做跳转钓鱼。至少加个简单的 API Key 或网关鉴权，查询接口可以放开。

第二，短码冲突。随机生成短码有极小概率撞车，写入前先查一下是否已存在，存在就重新生成，避免覆盖别人的映射。用哈希方案则天然不冲突，但要处理哈希碰撞（极罕见）。

第三，存储选型的取舍。Redis 快但实例要钱、且重启可能丢（看持久化配置）；云数据库稳但慢一点、也计费。短链一般读多写少、可丢失可重建，Redis 更合适；若要求永久可追溯，上数据库。

第四，302 还是 301。302 是临时重定向，每次都会回源查（便于统计点击）；301 是永久，浏览器会缓存不再问你。要做点击统计就用 302，纯跳转省事用 301。

六、小结

短链接是理解 Serverless 组合的好例子：API 网关接流量、做安全和限流，FunctionGraph 跑无状态逻辑，存储按需选 Redis 或数据库。平时没请求就不计费，比常驻服务器适合这种突发低频场景。真正要上心的是创建接口的鉴权和短码冲突处理，其余都是配置活。API 网关与 FunctionGraph 的对接字段、域名绑定和发布流程以官方文档为准，照文档走一遍就能跑通。