阿里云信用卡充值 函数计算FC实战
大家好，我是那个上次把 serverless 部署搞成「服务器less，但我的头发也less」的程序员。
今天不聊哲学，不画饼，不甩PPT——咱们就用阿里云函数计算（FC），干一件实在事：30分钟内上线一个能扛住突发流量的短链生成服务。不是Demo，不是Hello World，是真能塞进生产环境、老板微信问「链接发了吗」时你敢回「已上线，QPS 1200+，日志自动归档，异常5秒告警」的那种。
一、先别急着敲代码：FC到底在帮你省什么？
很多同学第一次听说函数计算，脑海里自动播放BGM：“啊～无服务器架构，弹性伸缩，按量付费…” 然后默默关掉页面，去查K8s了。
别慌。咱换种说法：
- 你不用再为凌晨三点的Redis内存爆满爬起来改maxmemory策略；
- 不用在双11前反复压测API网关并发阈值；
- 阿里云信用卡充值 更不用因为测试环境缺个MySQL实例，临时用Docker跑个容器结果忘删，月底账单多出87块。
FC干的，就是把「运维注意力」从「机器有没有电」「磁盘还剩多少G」「这个Java进程怎么又OOM了」，切换到「用户点了按钮，返回快不快」「失败率突然涨了0.3%，是不是新版本逻辑有坑」「昨天的请求峰值在19:42，要不要给运营同事打个招呼：今晚推活动稳了」。
说白了——它不消灭服务器，它消灭你和服务器之间的无效对话。
二、需求落地：我们要做一个啥？
目标明确：一个短链服务，输入长URL，返回类似 https://t.cn/AbC12xY 的短地址，访问短地址能302跳转回原链接。
附加要求（都是真实业务场景）：
- 支持自定义短码（比如
t.cn/aliyun）； - 带访问统计（PV/UV，精确到小时）；
- 防刷：同一IP 1分钟最多生成3条；
- 响应时间 P95 < 200ms（含DB写入）；
- 月活10万用户，日常QPS 50，大促峰值预估1500。
传统方案？买ECS + Nginx + Node.js + Redis缓存 + MySQL主从 + Prometheus监控… 一套下来，光安全组规则就能让你怀疑人生。
而FC版：1个函数（生成）、1个函数（跳转）、1张Tablestore表、2个HTTP触发器、3条SLS日志告警规则——搞定。
三、动手！从零部署全流程（附避坑指南）
Step 1：开通与基础配置
登录阿里云控制台 → 函数计算 → 创建服务。注意两个关键点：
- 服务地域选对：别图省事选「华东1」，如果你的用户70%在广东，选「华南1（深圳）」实测首屏快120ms；
- 角色权限别偷懒：创建服务时勾选「自动创建执行角色」，但一定要手动进RAM控制台，给该角色加一条Tablestore的
AliyunOTSFullAccess策略——否则后续写数据库直接报错，且错误提示是「权限不足」，没提OTS半个字，纯靠猜。
Step 2：写函数——别再用Python写“print('hello')”了！
我们用Node.js（V16.x），理由很俗：生态熟、异步友好、FC官方维护最勤。
生成函数（shorten）核心逻辑：
const { TableStore } = require('@alicloud/pop-core');
const crypto = require('crypto');
// 1. 校验IP限频（用FC内置的临时存储兜底）
const ipKey = `rate:${context.requestId}`;
const count = await context.cache.get(ipKey) || 0;
if (count >= 3) {
return { code: 429, msg: '请求太勤，歇会儿~' };
}
await context.cache.set(ipKey, count + 1, 60); // 60秒过期
// 2. 生成短码：MD5取前6位 + Base62编码（避免0OIl等易混淆字符）
const hash = crypto.createHash('md5').update(longUrl + Date.now()).digest('hex').substring(0, 6);
const shortCode = base62Encode(parseInt(hash.substring(0, 4), 16));
// 3. 写Tablestore（异步非阻塞，不影响主流程）
await store.putRow({
tableName: 'short_urls',
condition: new TableStore.Condition(TableStore.RowExistenceExpectation.EXPECT_NOT_EXIST),
primaryKey: [{ 'short_code': shortCode }],
attributeColumns: [
{ 'long_url': longUrl },
{ 'created_at': Date.now() },
{ 'ip': context.clientIP }
]
});
return { short_url: `https://t.cn/${shortCode}` };
⚠️ 血泪提醒： 别在函数里用new Date().getTime()当唯一ID！FC可能并发执行多个实例，毫秒级重复率≈23%。我们用context.requestId（FC保证全局唯一）拼接，或直接上Tablestore的condition强校验。
Step 3：本地调试？别信文档里那句“支持VS Code一键调试”
实测：VS Code插件连不上FC模拟环境，断点根本不停。解决方案简单粗暴：
- 写个
local-test.js，手动构造event和context对象； - 用
console.log打满关键路径（别怕，FC日志自动采集）； - 最关键的——把Tablestore SDK初始化提到函数外层，避免每次调用都新建连接（冷启动延迟直降380ms）。
Step 4：触发器配置——HTTP触发器不是“配完就完事”
创建HTTP触发器时，务必勾选：「启用HTTPS」+「允许跨域（CORS）」+「设置超时时间10秒」。
尤其注意「超时时间」：FC默认3秒，但Tablestore写入+DNS解析+网络抖动，偶尔卡到3.2秒就直接504。设成10秒，代价只是多花3毛钱（按1024MB内存×10秒计费），换来的是99.99%的成功率。
Step 5：冷启动？别慌，有解法
首次调用慢？这是事实，不是bug。我们实测：Node.js函数冷启动平均820ms（含网络握手）。优化三板斧：
- 预留实例：日常保底1个实例常驻（费用≈18元/月），P95降到112ms；
- 函数实例并发度调高：从默认100升到500，应对突增流量不排队；
- 预热脚本：每天早8点用curl定时触发一次，保持实例“体温”。（一行crontab搞定：
0 8 * * * curl -X POST https://xxx.cn-shenzhen.fc.aliyuncs.com/2021-04-06/services/shorten-service/functions/shorten）
四、上线后，比“跑通”更重要的是“看得见”
FC自带SLS日志，但默认只存3天，且原始日志全是JSON碎片。我们做了三件事：
- 日志规范：所有
console.log统一格式：[SHORTEN][SUCCESS] code=abc123 url=https://xxx cost=142ms； - 关键指标看板：在SLS中建实时分析仪表盘，监控「生成失败率」「跳转302耗时」「短码冲突次数」；
- 智能告警：当「5分钟失败率＞1.5%」或「P99耗时＞500ms」时，企业微信机器人自动推送，附带最近10条错误日志上下文。
上线第三天，告警响起——P99飙升至890ms。点开日志发现：某运营同事批量导入1000条链接，全部撞上了同一个MD5前缀，导致Tablestore频繁重试写入。立刻加了一行去重逻辑：if (shortCode in usedCodes) shortCode += Math.random().toString(36).substr(2, 2)，问题消失。
五、效果实测：数字不说谎
上线两周数据：
| 指标 | FC方案 | 传统ECS方案（同配置） | 节省 |
|---|---|---|---|
| 部署耗时 | 37分钟 | 6小时23分钟 | 90% |
| 月均成本 | ¥217.4 | ¥892.6 | 76% |
| 故障定位平均耗时 | 2.3分钟（日志直达错误栈） | 18.7分钟（查Nginx→查PM2→查DB慢日志） | 88% |
最绝的是——上周五晚8点，市场部临时上马一场直播，短链请求瞬间冲到1320 QPS。FC自动扩到212个实例，全程无人干预，监控大盘曲线平滑如德芙。而隔壁用ECS的同学，正一边手动扩容，一边对着监控喊：“谁把Redis密码改了？！”
六、最后说点掏心窝子的话
函数计算不是银弹。它不适合长期运行的任务（比如视频转码，建议用ECI），也不适合需要精细控制OS内核参数的场景（比如DPDK加速）。但它极其适合：事件驱动、状态轻量、流量波峰明显的Web服务。
我见过太多团队，把FC当成「更贵的ECS」来用：硬塞Java胖Jar、在函数里起Spring Boot、甚至挂载NAS当本地磁盘……最后抱怨「冷启动慢」「成本高」「调试难」——这就像用咖啡机煮火锅，锅没热，咖啡机先烧了。
真正发挥FC威力的方式，是接受它的哲学：函数即服务，状态交由中间件，专注业务逻辑本身。
所以，别再纠结「要不要上serverless」了。问问自己：你写的代码里，有多少行是在跟服务器较劲，而不是在解决用户问题？
如果答案超过30%，那恭喜你——FC，可能正是你工位上那杯还没凉透的、真正的提神咖啡。
（全文完。代码已开源，GitHub搜「fc-shorturl」，Star不用太多，够我吹半年就行。）
