阿里云函数计算配置详解：从基础到高级

最近在项目中用了阿里云的函数计算（Function Compute），也就是Serverless/FaaS架构，用了一段时间，感觉真的很方便，不用管服务器，不用管运维，写好代码上传就行，自动扩缩容，按量付费，成本也很低。

但是，函数计算的配置还是挺复杂的，有很多概念和参数，刚开始用的时候，踩了不少坑，走了不少弯路。今天就来详细讲解一下阿里云函数计算的配置，从基础概念到高级配置，一步步讲清楚，包括函数、服务、触发器、运行时、内存、超时、环境变量、日志、权限、网络等，还有我踩过的坑和经验总结，希望能帮助大家更好地使用函数计算，少踩坑，少走弯路。

一、什么是函数计算，为什么要用它

在讲配置之前，先简单介绍一下什么是函数计算，以及为什么要用它，让没用过的朋友有个大概的了解。

函数计算（Function Compute，简称FC）是阿里云提供的一个事件驱动的无服务器计算服务，也就是我们常说的FaaS（Function as a Service，函数即服务），属于Serverless（无服务器）架构的一种。

简单来说，用函数计算，你不需要购买和管理服务器，只需要写好函数代码，上传到函数计算平台，然后配置触发器，当触发事件发生的时候（比如HTTP请求、定时任务、消息队列消息、文件上传等），函数计算平台会自动运行你的函数，处理请求，处理完之后就释放资源，你只需要为函数实际运行的时间付费，不用的时候不花钱。

函数计算的核心优势：

1. 无需管理服务器：不用买服务器，不用装环境，不用运维，不用打补丁，不用监控服务器状态，平台都帮你搞定了，你只需要专注于写代码，写业务逻辑就行。

2. 自动扩缩容：函数计算会根据请求量自动扩缩容，请求多的时候，自动启动更多的函数实例来处理，请求少的时候，自动减少实例，甚至降到0，不用你手动扩容缩容，也不用担心流量突增把服务器打挂。

3. 按量付费：你只需要为函数实际运行的时间付费，按毫秒计费，不用的时候不花钱，对于流量波动大、有明显峰谷的业务，成本很低，比买服务器包月划算很多。

4. 高可用：函数计算平台本身是高可用的，多可用区部署，自动故障转移，不用担心单点故障，你的函数会自动在健康的节点上运行。

5. 支持多种语言：支持Node.js、Python、Java、PHP、Go、C#等多种编程语言，你可以用自己熟悉的语言来写函数。

当然，函数计算也不是银弹，也有它的局限性，比如不适合长时间运行的任务（有超时时间限制，最长一般是几分钟到十几分钟）、不适合有状态的应用、冷启动有延迟、调试和排查问题相对麻烦等，所以要根据业务场景选择，不是所有业务都适合用函数计算。

但是对于很多场景，比如Web接口、定时任务、事件处理、数据处理、文件处理、IoT后端、小程序后端等，函数计算都非常合适，能大大降低运维成本和服务器成本，提高开发效率。

二、函数计算的核心概念

在讲配置之前，先了解一下函数计算的几个核心概念，这些概念是配置的基础，理解了这些概念，配置起来就容易了。

1. 服务（Service）

服务是函数计算的资源管理单位，一个服务下面可以有多个函数，这些函数共享一些配置，比如日志配置、权限配置、网络配置、环境变量等。

你可以把服务理解为一个项目或者一个应用，一个项目下面有多个函数，这些函数共享服务级别的配置，比如都用同一个日志库，都有相同的权限，都在同一个VPC网络里等。

服务级别的配置，会被下面的所有函数继承，但是函数也可以覆盖服务级别的配置，用自己的配置。

2. 函数（Function）

函数是函数计算的基本单位，就是你写的代码，一个函数完成一个特定的功能，比如处理一个HTTP请求，处理一个文件，处理一条消息等。

每个函数都有自己的配置，比如运行时、内存、超时时间、环境变量、触发器等，函数是实际运行代码的地方。

一个服务下面可以有多个函数，每个函数独立运行，独立扩缩容，互不影响。

3. 触发器（Trigger）

触发器是用来触发函数运行的，配置了触发器之后，当触发事件发生的时候，函数计算平台会自动调用你的函数。

常见的触发器类型：

• HTTP触发器：就是一个HTTP接口，当有HTTP请求的时候，触发函数运行，适合做Web接口、API、小程序后端等。
• 定时触发器：按照设定的时间规则，定时触发函数运行，适合做定时任务、定时数据同步、定时报表等。
• OSS触发器：当对象存储（OSS）里有文件上传、修改、删除的时候，触发函数运行，适合做文件处理，比如图片压缩、视频转码、文件解析等。
• 消息队列触发器：当消息队列（比如MNS、Kafka、RocketMQ）里有消息的时候，触发函数运行，适合做异步消息处理、解耦系统等。
• 日志触发器：当日志服务（SLS）里有新日志的时候，触发函数运行，适合做日志处理、日志分析、告警等。
• API网关触发器：通过API网关来触发函数，适合做更复杂的API管理，比如鉴权、限流、熔断等。

一个函数可以配置多个触发器，比如一个函数既可以通过HTTP请求触发，也可以通过定时任务触发，也可以通过消息触发，很灵活。

4. 运行时（Runtime）

运行时就是函数代码的运行环境，不同的语言有不同的运行时，比如Node.js 8、Node.js 10、Python 2.7、Python 3.6、Java 8、PHP 7.2、Go 1.x等。

你需要根据你写代码的语言，选择对应的运行时，运行时决定了你的代码在什么环境里运行，有哪些内置的库和模块。

函数计算的运行时是平台提供的，你不需要自己安装，但是如果你的代码依赖了一些第三方库，你需要把依赖一起打包上传，或者用平台提供的层（Layer）来管理依赖。

5. 实例（Instance）

实例就是函数运行的容器，当有请求进来的时候，函数计算平台会启动一个实例来运行你的函数，处理请求，处理完之后，实例不会马上销毁，会保留一段时间，如果有新的请求进来，就可以复用这个实例，不用重新启动，这就是"热启动"，如果没有可用的实例，就需要启动一个新的实例，这就是"冷启动"，冷启动会有一定的延迟。

实例的数量是根据请求量自动调整的，请求多的时候，启动更多的实例，请求少的时候，减少实例，甚至降到0，这就是自动扩缩容。

每个实例的内存是你配置的，内存越大，CPU越强，价格也越贵，你需要根据函数的资源需求，选择合适的内存。

三、基础配置详解

了解了核心概念之后，现在来详细讲解函数计算的基础配置，这些是每个函数都需要配置的，也是最常用的配置。

1. 服务配置

首先是服务配置，创建服务的时候，需要配置以下内容：

• 服务名称：服务的唯一标识，在同一个区域内唯一，一般用项目名或者应用名，比如my-project、blog-backend等。
• 服务描述：服务的描述，可选，用来备注这个服务是做什么的。
• 日志配置：配置函数的日志输出到哪里，一般是配置到阿里云的日志服务（SLS），指定日志项目（Project）和日志库（Logstore），这样函数的日志就会自动收集到SLS里，方便查看和分析。这个很重要，一定要配置，不然函数出了问题，看不到日志，很难排查。
• 权限配置：配置函数的执行角色（Role），也就是函数运行的时候，拥有什么权限，可以访问哪些阿里云资源，比如访问OSS、访问数据库、访问消息队列等。这个也很重要，如果函数需要访问其他阿里云资源，就需要配置对应的权限，不然会报权限不足的错误。
• 网络配置：配置函数是否在VPC（专有网络）里运行，如果函数需要访问VPC里的资源，比如RDS数据库、Redis、ECS等，就需要配置VPC，指定VPC、交换机、安全组，这样函数就能访问VPC里的资源了。如果不需要访问VPC里的资源，可以不配置，用默认的网络。
• 环境变量：服务级别的环境变量，配置之后，服务下面的所有函数都能继承这些环境变量，适合配置一些所有函数都共用的配置，比如数据库地址、缓存地址、公共密钥等。

服务配置是基础，配置好之后，下面的函数都能继承，不用每个函数都配置一遍，很方便。

2. 函数基础配置

创建函数的时候，需要配置以下基础内容：

• 函数名称：函数的唯一标识，在同一个服务下唯一，一般用函数的功能来命名，比如getUser、processImage、cronJob等。
• 函数描述：函数的描述，可选，用来备注这个函数是做什么的。
• 运行时：选择函数的运行时，也就是语言和版本，比如Node.js 10、Python 3.6、Java 8等，根据你写代码的语言来选。
• 函数入口：函数的入口方法，也就是平台调用你的代码的时候，调用哪个方法。不同的语言，入口格式不一样，比如Node.js是index.handler，就是index.js文件里的handler函数；Python是index.handler，就是index.py文件里的handler函数；Java是com.example.App::handleRequest，就是App类里的handleRequest方法。你需要按照平台的要求，写好入口方法，平台会调用这个方法来运行你的函数。
• 代码包：上传你的函数代码，可以是在线编辑，也可以是上传zip包，或者从OSS拉取代码包。代码包里包含你的函数代码和依赖的第三方库。
• 内存规格：函数实例的内存大小，可选的有128MB、256MB、512MB、1GB、2GB等，内存越大，CPU越强，价格也越贵。你需要根据函数的资源需求来选，如果函数是CPU密集型的，比如图片处理、视频转码、数据计算，就选大一点的内存；如果函数是IO密集型的，比如调用接口、查询数据库，选小一点的内存就行。注意，内存是和CPU绑定的，内存越大，CPU越强，所以有时候选大一点的内存，函数运行更快，反而更省钱，因为按运行时间付费，运行时间短了，虽然内存单价高，但是总价可能更低。
• 超时时间：函数的最大运行时间，超过这个时间，平台会强制终止函数，报错超时。可选的范围一般是1秒到600秒（10分钟），你需要根据函数的运行时间来设置，比函数的实际最大运行时间大一点，留一些余量，但是也不要太大，不然如果函数卡住了，会一直运行，浪费钱。注意，函数计算是按运行时间付费的，超时时间设置太大，如果函数出问题卡住了，会跑满超时时间，浪费钱，所以要合理设置。
• 环境变量：函数级别的环境变量，配置之后，只有这个函数能用到，适合配置这个函数特有的配置，比如函数的参数、密钥等。函数级别的环境变量会覆盖服务级别的同名环境变量。
• 初始化函数：有些运行时支持初始化函数，也就是函数实例启动的时候，会先调用初始化函数，做一些初始化的工作，比如加载模型、建立数据库连接、初始化缓存等，初始化函数只在实例启动的时候运行一次，之后的请求复用这个实例，就不用再初始化了，能提高性能，减少冷启动的影响。如果你的函数有一些耗时的初始化工作，建议用初始化函数，能大大提高性能。

这些基础配置，是每个函数都需要配置的，配置好了，函数就能基本运行了。

3. 触发器配置

函数创建好之后，需要配置触发器，这样函数才能被触发运行。不同的触发器，配置不一样，这里讲几个最常用的触发器的配置：

HTTP触发器配置：

• 触发器名称：触发器的名称，自己定义。
• 认证方式：可选anonymous（匿名，任何人都能访问）或者function（需要阿里云签名认证才能访问），如果是做公开的API，选anonymous；如果是内部接口，需要鉴权，选function。
• 请求方式：支持GET、POST、PUT、DELETE、HEAD、OPTIONS等HTTP方法，可以多选，一般常用的是GET和POST。
• URL路径：触发器的URL路径，平台会给你一个域名，加上路径，就是这个函数的访问地址，比如https://xxx.cn-hangzhou.fc.aliyuncs.com/2016-08-15/proxy/my-service/my-function/。

配置好HTTP触发器之后，访问这个URL，就会触发函数运行，函数的返回值会作为HTTP响应返回给客户端，很方便，就能做一个Web接口了。

定时触发器配置：

• 触发器名称：触发器的名称。
• 触发方式：选定时触发，也就是按照设定的时间规则触发。
• Cron表达式：用Cron表达式来设定触发的时间规则，比如每天凌晨2点触发，就是0 0 2 ；每小时触发一次，就是0 0 ；每周一早上9点触发，就是0 0 9 ? MON。Cron表达式有6位或者7位，分别是秒、分、时、日、月、周、年（可选），需要按照平台的格式来写。
• 触发消息：可选，触发的时候，传给函数的消息内容，可以在函数里获取到，用来做参数。

配置好定时触发器之后，到了设定的时间，平台就会自动触发函数运行，不用你管，很适合做定时任务。

OSS触发器配置：

• 触发器名称：触发器的名称。
• OSS Bucket：选择要监听的OSS Bucket，也就是哪个存储桶里的文件变化会触发函数。
• 触发事件：选择触发的事件类型，比如ObjectCreated（文件创建，包括上传、复制、追加等）、ObjectRemoved（文件删除），可以多选。
• 前缀过滤：可选，只有文件名以这个前缀开头的文件变化，才会触发，比如images/，只有images目录下的文件变化才触发。
• 后缀过滤：可选，只有文件名以这个后缀结尾的文件变化，才会触发，比如.jpg，只有jpg文件变化才触发。

配置好OSS触发器之后，当OSS里有符合条件的文件变化，就会自动触发函数运行，把文件信息传给函数，函数就可以处理这个文件了，比如图片上传之后，自动压缩、加水印、生成缩略图等，很方便。

其他触发器的配置也类似，根据提示配置就行，都不复杂。

四、高级配置详解

基础配置能满足大部分需求，但是有些场景，需要用到一些高级配置，这里也讲一下。

1. 层（Layer）配置

层是用来管理函数依赖的，如果你有多个函数，都依赖了一些相同的第三方库或者公共代码，你可以把这些依赖和公共代码打包成一个层，然后多个函数都引用这个层，不用每个函数都打包一遍依赖，能减小代码包的大小，也方便维护和更新依赖。

层的配置：

• 层名称：层的名称。
• 代码包：层的代码包，把依赖和公共代码按照一定的目录结构打包，比如Node.js的依赖放在nodejs/node_modules目录下，Python的依赖放在python目录下，Java的依赖放在java/lib目录下，这样函数运行的时候，会自动把层的代码加到对应的路径里，就能直接引用了。
• 兼容运行时：选择这个层兼容哪些运行时，比如Node.js 10、Python 3.6等。

配置好层之后，函数就可以引用这个层，不用自己打包依赖了，代码包会小很多，上传也快，而且更新依赖的时候，只需要更新层，不用更新每个函数，很方便。

2. 自定义运行时（Custom Runtime）

如果平台提供的运行时不能满足你的需求，比如你想用一个平台不支持的语言，或者想用特定版本的运行时，你可以用自定义运行时，自己打包运行环境，上传到函数计算平台运行。

自定义运行时，你需要在代码包里包含运行时的二进制文件，以及一个bootstrap启动脚本，平台会调用bootstrap脚本来启动你的运行时，你的运行时需要监听平台指定的端口，接收平台的调用请求，处理之后返回结果。

自定义运行时很灵活，几乎可以运行任何语言和任何环境，但是配置相对复杂，而且你需要自己维护运行时的安全和更新，适合有特殊需求的场景，一般场景用平台提供的运行时就够了。

3. 预留实例（Provisioned Instance）

函数计算的冷启动是一个常见的问题，当没有可用的热实例的时候，需要启动新的实例，冷启动会有一定的延迟，从几百毫秒到几秒不等，对于延迟敏感的业务，冷启动可能会影响用户体验。

预留实例就是用来解决冷启动问题的，你可以配置一定数量的预留实例，这些实例会一直运行，不会被释放，随时可以处理请求，不会有冷启动的延迟，但是预留实例是一直收费的，不管有没有请求，所以会增加成本。

预留实例的配置：

• 预留实例数量：要预留多少个实例，根据你的最低流量来配置，保证最低流量的时候，都能用预留实例处理，不会有冷启动。
• 弹性伸缩：可以配置预留实例的自动伸缩，根据流量自动调整预留实例的数量，比如流量大的时候增加，流量小的时候减少，这样既能保证性能，又能控制成本。

预留实例适合对延迟要求高、流量比较稳定的业务，对于流量波动大、对延迟不敏感的业务，用按需实例就够了，更省钱。

4. 异步调用配置

函数调用分为同步调用和异步调用，同步调用就是调用之后，等待函数返回结果，比如HTTP触发器就是同步调用；异步调用就是调用之后，马上返回，不等待函数结果，函数在后台运行，比如OSS触发器、消息队列触发器、定时触发器都是异步调用。

对于异步调用，有一些高级配置：

• 最大重试次数：异步调用如果函数执行失败，平台会自动重试，你可以配置最大重试次数，比如0次（不重试）、1次、2次、3次，默认是3次。重试次数不是越多越好，要根据业务场景来，如果函数是幂等的，重试几次没关系；如果函数不是幂等的，重试可能会导致重复处理，出问题，所以要合理配置。
• 最大异步事件时长：异步调用的最大排队时间，也就是事件在队列里等待的最长时间，超过这个时间还没被处理，就会被丢弃，默认是6小时。
• 目标服务：异步调用成功或者失败之后，可以把结果发送到目标服务，比如发送到消息队列、发送到另一个函数、写入OSS等，用来做结果处理、失败通知、死信队列等。比如函数执行失败了，把失败信息发送到消息队列，然后另一个函数处理失败的情况，做补偿或者告警。

异步调用的配置，对于保证异步任务的可靠性很重要，特别是重试和失败处理，一定要配置好，不然异步任务失败了，你都不知道，也没有重试，数据就丢了。

5. 网络配置（VPC）

如果你的函数需要访问VPC里的资源，比如RDS数据库、Redis、ECS、内网服务等，就需要配置VPC，让函数运行在VPC里，这样就能访问VPC里的资源了。

VPC配置：

• VPC：选择你的VPC。
• 交换机：选择VPC里的交换机，建议选多个可用区的交换机，提高可用性。
• 安全组：选择安全组，配置函数的出入站规则，保证函数能访问需要的资源，同时保证安全。

配置好VPC之后，函数就运行在VPC里了，能访问VPC里的资源，但是也有一个问题，就是VPC里的函数，默认不能访问公网，如果需要访问公网，需要配置NAT网关，或者在VPC里配置公网出口，不然函数访问不了公网的接口和服务。

所以，如果函数既需要访问VPC里的资源，又需要访问公网，就需要配置NAT网关，让函数能通过NAT网关访问公网，这个要注意，不然配置了VPC之后，函数访问不了公网，会报错。

6. 权限配置（RAM）

函数运行的时候，需要有相应的权限，才能访问其他阿里云资源，比如OSS、RDS、消息队列、日志服务等，这就需要配置RAM（资源访问管理）权限，给函数分配一个执行角色，这个角色有相应的权限，函数运行的时候，就用这个角色的权限来访问资源。

权限配置：

• 执行角色：给函数分配一个RAM角色，这个角色有相应的权限策略。
• 权限策略：给角色附加权限策略，比如AliyunOSSFullAccess（OSS全权限）、AliyunRDSFullAccess（RDS全权限），或者自定义更精细的权限策略，只给需要的权限，遵循最小权限原则。

权限配置很重要，一定要按照最小权限原则来配置，只给函数需要的权限，不要给全权限，不然如果函数出了安全问题，影响会很大。同时，权限不够的话，函数访问资源会报权限不足的错误，所以要配置合适的权限。

五、踩过的坑和经验总结

用函数计算这段时间，踩了不少坑，也积累了一些经验，分享给大家，希望大家少踩坑。

1. 冷启动问题

这是函数计算最常见的坑，冷启动有延迟，特别是Java、C#这些编译型语言，冷启动延迟比较大，可能有几秒甚至十几秒，对于延迟敏感的业务，影响很大。

解决办法：

• 用初始化函数，把耗时的初始化工作放在初始化函数里，只在实例启动的时候执行一次，减少每次请求的处理时间。
• 配置预留实例，预留一定数量的实例，一直运行，避免冷启动，但是会增加成本。
• 用轻量级的运行时，比如Node.js、Python，冷启动延迟比Java、C#小很多。
• 减小代码包的大小，代码包越小，冷启动越快，去掉不必要的依赖，只打包需要的代码。
• 定期预热，比如用定时触发器，每隔几分钟调用一次函数，保持有热实例可用，适合流量不大但是对延迟有要求的场景。

2. 超时问题

函数有超时时间限制，最长一般是10分钟，如果你的函数运行时间超过了超时时间，就会被强制终止，报错超时。

解决办法：

• 合理设置超时时间，比函数的实际最大运行时间大一点，留余量。
• 如果任务确实需要运行很长时间，超过了函数的最大超时时间，就不要用函数计算了，用ECS或者容器服务来跑，函数计算适合短时间的任务。
• 把大任务拆分成小任务，异步处理，比如处理一个大文件，拆分成多个小任务，每个函数处理一部分，最后汇总，这样每个函数的运行时间都在超时时间内。
• 做好异常处理和重试，函数超时失败了，要有重试机制，或者异步处理，保证任务最终能完成。

3. 内存和CPU的问题

函数的内存和CPU是绑定的，内存越大，CPU越强，价格也越贵，很多人以为选小内存省钱，结果因为CPU弱，函数运行慢，运行时间长，反而更贵，甚至因为内存不够，函数OOM（内存溢出）崩溃。

解决办法：

• 根据函数的实际资源需求，选择合适的内存，不要盲目选小的，也不要盲目选大的。
• 做压测，测试不同内存下函数的运行时间和稳定性，算一下总成本，选择性价比最高的内存配置。很多时候，选大一点的内存，CPU强，运行时间短，总成本反而更低。
• 对于CPU密集型的任务，比如图片处理、视频转码、数据计算，选大内存；对于IO密集型的任务，比如调用接口、查询数据库，选小内存就够了。
• 监控函数的内存使用情况，如果内存使用率经常超过80%，就说明内存不够，需要加大内存，避免OOM。

4. 依赖打包的问题

函数的代码包需要包含所有的依赖，很多人在本地开发没问题，但是上传到函数计算平台就报错，说找不到模块，就是因为依赖没有打包好，或者平台的运行环境和本地不一样，依赖不兼容。

解决办法：

• 打包依赖的时候，要在和平台运行环境一致的环境里打包，比如平台是Linux，你在Windows或者Mac上打包的二进制依赖，可能在平台上运行不了，最好用Docker或者平台提供的打包工具，在Linux环境里打包。
• 用层（Layer）来管理依赖，把依赖打包成层，函数引用层，这样不用每次都打包依赖，也方便维护。
• 注意依赖的版本，要和运行时的版本兼容，比如Node.js 10的依赖，不能用在Node.js 8上。
• 减小代码包的大小，去掉不必要的依赖和文件，只打包需要的，代码包越小，上传越快，冷启动也越快。

5. 日志和排查问题的问题

函数计算是无服务器的，你不能登录到服务器上看日志，排查问题相对麻烦，很多人出了问题，不知道怎么排查，就是因为日志没配置好，或者不会看日志。

解决办法：

• 一定要配置日志，把函数的日志输出到日志服务（SLS），这样出了问题，可以在SLS里查日志，很方便。
• 在代码里打好日志，关键的步骤、异常的地方，都要打日志，把上下文信息打出来，比如请求参数、用户ID、错误信息等，出了问题才能根据日志定位。
• 用函数计算的控制台，查看函数的调用记录、错误信息、监控指标，比如调用次数、错误率、运行时间、内存使用等，这些都能帮助排查问题。
• 本地调试，函数计算提供了本地调试工具，可以在本地运行函数，模拟触发器，调试代码，这样大部分问题在本地就能解决，不用上传到线上调试。

6. 幂等性问题

函数计算的异步调用，失败了会自动重试，而且网络抖动也可能导致重复调用，所以函数一定要保证幂等性，也就是多次调用和一次调用的结果是一样的，不会因为重复调用而出问题，比如重复扣款、重复下单、重复发消息等。

解决办法：

• 所有的写操作，都要做幂等，用唯一请求ID或者业务唯一键来保证幂等，重复的请求直接返回第一次的结果，不重复执行。
• 数据库操作，用唯一索引或者乐观锁来保证幂等，避免重复插入或者重复更新。
• 消息处理，要保证消息消费的幂等，重复消费消息不会出问题。
• 合理配置重试次数，不是所有场景都适合重试，对于非幂等的函数，要减少重试次数，甚至不重试，避免重复调用导致问题。

7. 成本问题

函数计算按量付费，用得好很省钱，但是用不好也可能很贵，比如函数卡住了跑满超时时间、内存选太大、预留实例太多、日志量太大等，都可能导致成本很高。

解决办法：

• 合理配置内存和超时时间，不要盲目选大的，根据实际需求配置，够用就行。
• 做好异常处理，避免函数卡住跑满超时时间，浪费钱。
• 预留实例根据实际需求配置，不要预留太多，用弹性伸缩自动调整，控制成本。
• 监控成本，定期看账单，分析函数的费用构成，找到成本高的函数，优化配置，降低成本。
• 日志不要打太多，特别是大量的debug日志，会产生日志费用，生产环境把日志级别调到info或者warn，减少日志量。

六、函数计算的适用场景和不适用场景

最后，总结一下函数计算的适用场景和不适用场景，帮助大家判断自己的业务适不适合用函数计算。

适用场景：

1. Web接口/API后端：特别是流量波动大、有明显峰谷的API，用函数计算自动扩缩容，按量付费，很省钱。
2. 小程序/公众号后端：小程序和公众号的流量一般不大，但是波动大，用函数计算很合适，不用买服务器，成本低。
3. 定时任务：比如定时数据同步、定时报表、定时清理、定时爬虫等，用定时触发器，很方便，不用自己搭定时任务服务器。
4. 事件驱动处理：比如文件上传之后自动处理（图片压缩、视频转码、文件解析）、消息队列消息处理、日志处理等，用对应的触发器，自动处理，很适合。
5. 数据处理/ETL：比如数据清洗、数据转换、数据分析、数据同步等，函数计算能自动扩缩容，处理大量数据，很适合。
6. IoT后端：物联网设备的消息处理、指令下发等，设备连接数多，流量波动大，用函数计算很合适。
7. Webhooks：比如GitHub Webhooks、支付回调、第三方系统回调等，用HTTP触发器接收，处理之后返回，很方便。

不适用场景：

1. 长时间运行的任务：函数有超时时间限制，最长一般10分钟，超过这个时间的任务不适合，比如大视频转码、大数据计算、长时间训练模型等，用ECS或者容器服务更合适。
2. 有状态的应用：函数计算是无状态的，实例会随时创建和销毁，不适合有状态的应用，比如需要长连接的WebSocket应用、需要本地存储状态的应用等，用ECS或者容器服务更合适。
3. 对延迟极度敏感的业务：函数计算有冷启动延迟，虽然可以用预留实例解决，但是成本会增加，如果对延迟极度敏感，要求毫秒级响应，用常驻的服务器更合适。
4. 流量非常稳定且很大的业务：如果流量非常稳定，而且很大，7x24小时都有很高的流量，用函数计算按量付费可能比买服务器包月还贵，这种情况用ECS或者容器服务更划算。
5. 需要底层系统权限的应用：函数计算是托管的运行环境，你没有root权限，不能自定义系统配置，不能安装系统级的软件，如果你的应用需要这些，用ECS更合适。

七、写在最后

阿里云函数计算配置详解：从基础到高级。

以上就是我对阿里云函数计算配置的详细讲解，从基础概念到基础配置，再到高级配置，还有我踩过的坑和经验总结，以及适用场景和不适用场景，希望能帮助大家更好地使用函数计算。

函数计算作为Serverless架构的代表，确实有很多优势，不用管服务器，不用管运维，自动扩缩容，按量付费，能大大降低运维成本和服务器成本，提高开发效率，是未来云计算的一个重要方向。但是，它也不是银弹，有它的局限性，也有很多坑，需要根据业务场景选择，合理配置，才能发挥它的优势，避免踩坑。

我用函数计算这段时间，整体感觉还是很好的，特别是对于一些小项目、小工具、定时任务、事件处理，用函数计算真的很方便，不用买服务器，不用运维，写好代码上传就行，成本也很低，几个项目加起来，一个月才几块钱几十块钱，比买服务器划算多了。

当然，也踩了不少坑，比如冷启动、超时、依赖打包、幂等性这些，但是只要了解了它的原理，合理配置，这些坑都是可以避免的。

希望这篇文章能帮助大家入门函数计算，少踩坑，少走弯路，用好函数计算，享受Serverless带来的便利。也欢迎大家在评论区交流，分享你们用函数计算的经验和踩过的坑，一起学习，一起进步。

最后，用一句话结尾："Serverless不是没有服务器，而是你不用再关心服务器；函数计算不是万能的，但用对了场景，它能让你事半功倍。"愿我们都能用好新技术，享受技术带来的便利，提高效率，降低成本，做出更好的产品。