函数计算上线前，最容易出问题的往往是触发器没接对，或者部署配置和线上环境对不上。阿里云函数计算（Function Compute，简称FC）是事件驱动的全托管计算服务，图片转码、日志处理、定时任务和轻量后端接口都很常见。服务器运维交给平台之后，要检查的内容换了一批。触发器和部署两部分，上线前各需要核对哪些地方，下面分开说。
先理清函数、服务和触发器的关系
函数是代码和运行配置的最小部署单元。服务是一组函数的逻辑分组，权限、日志和VPC网络通常在服务层统一配置。触发器决定函数什么时候被调用，它挂在函数上，一个函数可以挂多个触发器。这也是很多线上问题的来源：测试时只挂了一个，上线后另一个触发器悄悄把同一段代码又执行了一遍。
实例是函数运行时的容器环境，平台会根据并发请求自动创建和回收。理解这一点，才能看懂冷启动和并发数为什么会影响触发器的响应表现。
触发器上线前要核对的几处
HTTP触发器要先确认鉴权方式。如果接口对公网开放，又没有签名或访问控制，等于把函数直接暴露出去。只给内网调用的接口，则要检查VPC和安全组是否放行了对应来源。
OSS事件触发器最容易重复执行。对象覆盖上传、批量导入都可能产生多次事件。确认事件类型是否选准确，比如只关心新建对象时，就不要勾选所有事件。
定时触发器要核对时区和cron表达式。不少人写完表达式就直接上线，结果任务按UTC时间执行，和业务预期差了八个小时。在测试环境完整跑一个周期，比反复看表达式更可靠。
消息队列触发器要提前定好消费失败的处理方式。失败后是重试，还是进入死信队列，都需要明确。否则异常消息会在重试中反复占用并发。
每个触发器对应的RAM角色都应该只覆盖这个业务需要的资源。触发器能调用函数，不代表函数有权读写所有OSS Bucket。
部署上线前要核对的几处
先确认运行时版本。本地开发用的Python或Node.js版本，与函数运行时不一致，是常见的上线失败原因。依赖库如果含有编译产物，也要在与运行环境相同的架构下构建，否则部署能成功，调用时却报导入错误。
依赖包体积要控制。图片处理这类库动辄几十MB，直接打进代码包会拖慢部署和冷启动。把通用依赖抽成依赖层，业务代码只保留核心逻辑，会稳得多。
内存和超时时间要依据实测设定。函数的CPU与内存是绑定分配的，内存越大，可用计算资源越多，单价也越高。用真实样本压测，找到耗时和成本都能接受的配置，再给超时时间留出一定余量。直接拉到最大值并不稳妥，失控的任务会持续计费。
数据库地址、第三方接口密钥这类配置，放在环境变量里，不要写进代码。测试和生产最好使用两套参数。上线前再检查一遍，看看调试用的地址是否还留在配置中。
日志和告警要提前接好。把函数日志接入日志服务，并配置错误率、执行时长和并发数的告警。出问题时，能分清是代码异常、依赖超时，还是上游流量突增，排查会快很多。
一个图片处理的实际改造
某电商内容团队每天要处理数万张商品图。原来的方案是一组常驻ECS服务器轮询任务队列。高峰期资源不够，夜间又大量闲置，月度成本一直降不下来。
改造后，商品图上传到OSS指定Bucket，OSS事件触发器自动调用函数。函数使用Python运行时调用图片处理库，完成压缩、加水印和多尺寸缩略图，结果回写到OSS另一个目录，处理状态由日志服务记录。单张图片的处理内存设为512MB，超时时间则依据实测耗时调整。
上线后，夜间的闲置成本明显下降，大促期间不用人工扩容也能承接峰值。落地过程中有两个问题值得提前注意。一是图片库体积较大，团队通过依赖层减小了部署包。二是首次请求有明显延迟，于是开启了预留实例来缓解冷启动。预留实例会产生固定费用，是否开启要看接口对延迟的要求。
什么情况下不适合用函数计算
长时间运行的常驻进程、对冷启动延迟很敏感的交易接口，或者需要大量本地状态的计算任务，通常更适合放在ECS或容器服务上。选型时先看业务特征，再决定是否放进函数，比上线后再迁移省事得多。
