阿里云函数计算（Function Compute，简称 FC）是一个事件驱动的 Serverless 服务。你只管把业务代码传上去，设好触发条件，服务器采购、系统维护和弹性扩容都由平台来做。计费按调用次数和资源消耗算，没有请求时基本不花钱，流量忽高忽低的业务用起来会比较省心。
它擅长的是“某件事发生了，就执行一段逻辑”。文件传完做处理、接口被调用时返回数据、每天凌晨清一次日志，都是很典型的例子。它并不能替代所有后端服务，但在这些场景里，少操心一台机器，本身就是实实在在的收益。
先弄清楚几个概念
上手之前，下面四个概念要先搞明白，后面配置时会反复用到。
- 服务（Service）：一组相关函数的集合。权限、日志、VPC 网络可以在这一层统一配置，不用每个函数单独设一遍。
- 函数（Function）：真正跑业务代码的单元。要选运行时（Python、Node.js、Java、Go、PHP 等），还要定内存规格和超时时间。
- 触发器（Trigger）：决定函数什么时候执行。常见的有 OSS 事件、HTTP 触发和定时触发。
- 冷启动与预留实例：函数一段时间没人调用，下次执行会多等一会儿。如果你的服务对延迟很敏感，可以配置预留实例，把这部分等待压下去。
案例一：商品图上传后自动生成缩略图
某电商团队原来由后端服务同步生成多种尺寸的缩略图。大促高峰时，上传经常变慢，服务器负载也跟着往上冲。后来他们改了方案：用户把原图传到对象存储 OSS，OSS 事件触发一个函数，函数读取原图，生成几种标准尺寸，再写回 OSS 指定目录。
改完以后，上传接口只负责保存原图，响应明显快了。缩略图的并发由平台按请求数自动伸缩，大促前不用临时加机器，活动结束资源也会自己回落。这种“耗时的活交给异步函数”的做法，是函数计算最常见的落地方式之一。
案例二：定时任务不再占着一台服务器
一个内容平台每天要统计前一天的访问数据，再把报表发邮件。这个任务以前跑在一台常年开机的云服务器上，利用率很低，还得自己维护 crontab 和运行环境。迁到函数计算后，他们用定时触发器每天固定时间执行一次函数：统计结果写入数据库，再调用邮件服务发出报表。
这类任务执行时间短、频率固定，按量付费很合适。账单确实降了一些，更实在的变化是，那台只干一件事的服务器不用再管系统补丁和磁盘空间了。
部署时的几个注意点
- 一个函数只做一件事。职责越单一，出问题时越好定位，也能单独升级，不会牵一发而动全身。
- 内存规格会影响 CPU 性能。建议先用小配置压测，看耗时和失败率，再慢慢往上调，别一开始就拉满。
- 数据库地址、API 密钥这类配置放进环境变量或密钥管理服务。写死在代码里，一旦代码外泄，损失会很大。
- 日志一定要开。把关键的输入输出和错误堆栈记下来，异步任务失败时，你才知道是哪一步出了问题。
- 函数要访问内网数据库，就得正确配置 VPC 和安全组。同时评估一下冷启动对响应时间的影响，别等上线后用户投诉才发现。
什么场景适合，什么场景不适合
函数计算比较适合事件驱动、突发流量、短时任务和轻量接口。反过来，如果你要维持长连接，比如持续运行的 WebSocket 服务，或者是对执行时长和资源占用要求很高的计算任务，就该认真考虑容器服务或专用服务器。拿不准的时候，先用真实流量跑一段小规模验证，数据说话，比凭感觉迁移靠谱。
说到底，函数计算的好处是让团队把精力放回业务逻辑上。先挑一个边界清楚的小场景试一试，跑顺了再扩大范围，风险最小。
