服务公告

服务公告 > 综合新闻 > Serverless 最佳实践-星耀云

Serverless 最佳实践-星耀云

发布时间:2026-04-28 04:56

标签： Serverless serverless 最佳实践技巧

一、前言

干了10年运维，Serverless这玩意儿从概念热炒到真正落地，我踩过的坑比你们写过的代码还多。Lambda冷启动慢、权限配置复杂、成本失控、调试困难——这些问题不解决，Serverless就是纸老虎。这篇不讲理论，直接上实战经验。

二、操作步骤

步骤1：合理设计函数大小，避免冷启动噩梦

函数包太大是冷启动的第一杀手。先看看你当前的包大小：

$ unzip -l function.zip | tail -1
Length      Date    Time    Name
---------  ---------- -----   ----
  52428800  11-01-2024 10:30   function.zip



50MB的包，冷启动能让你等到天荒地老。清理依赖，只打包真正用到的：

$ npm prune --production
$ rm -rf node_modules/.cache
$ du -sh node_modules/
2.1M    node_modules/


优化后只有2MB，冷启动时间从3秒降到300毫秒，这差距你品品。

步骤2：巧用分层机制，把依赖和代码分离

公共依赖单独放层，不同函数共享，避免每次部署都上传相同的东西。

$ aws lambda publish-layer-version 
  --layer-name common-dependencies 
  --zip-file fileb://dependencies.zip 
  --compatible-runtimes nodejs18 python3.11

{
    "LayerVersionArn": "arn:aws:lambda:us-east-1:123456789:layer:common-dependencies:3",
    "Description": "Node.js and Python shared dependencies"
}

更新依赖时只改一层，所有函数自动生效，部署时间直接砍半。

步骤3：配置合理的内存和超时，别用默认值糊弄

128MB默认内存，跑个稍微复杂的逻辑就超时。内存和CPU是绑定的，内存越大执行越快：

$ aws lambda update-function-configuration 
  --function-name my-function 
  --memory-size 512 
  --timeout 30

{
    "MemorySize": 512,
    "Timeout": 30
}

实测512MB比128MB快3倍，但费用不是线性增长，算下来更划算。超时别设太长，30秒足够了，跑不完的逻辑就该拆分。

步骤4：正确配置IAM角色，遵循最小权限原则

别用*通配符，那是给自己挖坑。精细化配置：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:Query",
        "dynamodb:UpdateItem"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789:table/my-table"
    }
  ]
}

每个函数只给它干活需要的权限，多一行都是隐患。

步骤5：启用并发预留，避免流量洪峰被打垮

突发流量来了？默认的按需并发会排队等死。设置预留并发：

$ aws lambda put-function-concurrency 
  --function-name my-critical-function 
  --reserved-concurrent-executions 100

{
    "ReservedConcurrentExecutions": 100
}

关键函数预留并发，普通函数抢剩余配额，这叫资源分级管理。

步骤6：配置死信队列，别让失败消息石沉大海

函数执行失败重试3次后就彻底丢了，没DLQ你连查都没地方查：

$ aws lambda put-function-event-invoke-config 
  --function-name my-function 
  --maximum-event-age 3600 
  --maximum-retry-attempts 2 
  --destination-config '{
    "OnFailure": {
      "Destination": "arn:aws:sqs:us-east-1:123456789:my-dlq"
    },
    "OnSuccess": {
      "Destination": "arn:aws:sqs:us-east-1:123456789:my-success-queue"
    }
  }'

{
    "MaximumRetryAttempts": 2,
    "MaximumEventAge": 3600
}

DLQ里全是你的失败记录，不看那是你的问题。

步骤7：建立完善的监控告警，别等用户投诉才发现挂了

CloudWatch Logs打出来没人看是白打，必须转成告警：

$ aws cloudwatch put-metric-alarm 
  --alarm-name lambda-errors 
  --alarm-description "Lambda函数错误告警" 
  --metric-name Errors 
  --namespace AWS/Lambda 
  --statistic Sum 
  --period 60 
  --threshold 5 
  --comparison-operator GreaterThanThreshold 
  --evaluation-periods 1 
  --alarm-actions arn:aws:sns:us-east-1:123456789:my-topic

{
    "AlarmArn": "arn:aws:cloudwatch:us-east-1:123456789:alarm:lambda-errors"
}

错误数5分钟内超过5次就发告警，10分钟响应，这是基本运维素养。

步骤8：定期清理旧版本，别让积压版本撑爆账户限制

版本越积越多，每个版本都占配额，清理是必须的：

$ aws lambda list-versions-by-function 
  --function-name my-function 
  --query 'Versions[?Version != `$LATEST`].[Version,LastModified]' 
  --output table

-------------------------
|  ListVersionsByFunction   |
+------------+--------------------+
|  Version   |   LastModified     |
+------------+--------------------+
|  1         |  2024-01-15 10:00  |
|  2         |  2024-03-20 14:30  |
|  3         |  2024-06-10 09:15  |
+------------+--------------------+

$ aws lambda delete-function 
  --function-name my-function:1
# 版本1已删除

保留最近3个版本够了，历史版本没意义，占着配额纯属浪费。

三、常见问题FAQ

Q1：冷启动太慢怎么办？客户都跑到竞争对手那边了
冷启动慢就两个原因：包太大、初始化太重。先把函数包压到10MB以下，常用依赖上Layers。代码里别在顶层写耗时的初始化，延迟到handler里按需加载。如果还慢，就用Provisioned Concurrency，提前预热实例，就是贵点，但值。

Q2：账单爆炸了，怎么定位谁在烧钱
Lambda费用=调用次数×执行时长×内存费率。先去Cost Explorer看哪个函数调用量和耗时最高，80%费用往往来自20%的函数。然后优化那几个大户：降低内存、减少执行时长、合并频繁调用的逻辑。异步调用配置好Destination，别让它无限重试。重试配置maximum-retry-attempts为0或1，能省一大笔。

Q3：生产环境出了Bug，CloudWatch Logs根本找不到日志怎么办
找不到日志基本是两个原因：执行角色没日志权限，或者日志组不存在。先检查IAM里有没有logs:CreateLogGroup和logs:PutLogEvents权限。没有的话加上去，日志组会自动创建。另一个坑是执行太快失败，连日志都来不及写，这时候看DLQ里有没有消息。生产函数务必开X-Ray追踪，死的时候能定位到哪一步。

Q4：怎么管理一堆函数的版本和发布？改一个怕影响一片
用SAM或Serverless Framework这类基础设施即代码工具，别手动改。所有函数配置写进yaml，版本控制。发布流程：开发分支→测试环境验证→主干合并→自动部署生产。不同环境用不同别名：dev、staging、prod。切流量用权重：先5%新版本，跑稳了再全量。

Q5：函数需要访问VPC里的RDS，超时了连不上
VPC里的Lambda有冷启动问题，第一次调用要创建ENI，这能跑个30秒。解决方案：不要所有函数都塞VPC里，只把需要VPC访问的放进去，公共逻辑放外面。RDS用连接池，别每个请求都新建连接，用完释放回去。预算够的话开NAT Gateway，预算紧就用VPC Peering。还有个邪道：Lambda加到RDS的允许列表里时，别用IP，用安全组ID。

四、总结

Serverless不是银弹，用对了是省钱省心，用错了是给自己找麻烦。核心要点记好：


函数要小，冷启动要快，Layers用好依赖分离
内存不是越大越好，但太小肯定坑自己，512MB是个甜点值
权限按需分配，*号是运维人员的万恶之源
关键函数预留并发，DLQ必须配，故障日志不能丢
监控告警要在用户发现之前发现问题，而不是之后
账单要盯紧，优化从大户开始


延伸阅读：AWS Lambda官方最佳实践文档、Serverless Architecture Patterns那本书、Google Cloud Functions的冷启动优化案例。多云的话研究一下Terraform的Lambda模块，跨平台管理省心。
相关推荐
Office办公 日常使用-星耀云
Flutter 组件开发-星耀云
Copilot 自动化-星耀云
Photoshop 最佳实践-星耀云
Python-星耀云
Docker-星耀云
Varnish 自动化-星耀云
Nginx-星耀云
                
                   
                                       上一篇：
                    Office办公 日常使用-星耀云
                                      
                   
                                       下一篇：
                    Windsurf 效率优化-星耀云