Serverless Framework 核心概念指南在 AWS 上用 Functions、Events、Resources 与 Services 构建事件驱动架构【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverlessServerless Framework 是一套开源的 CLI 工具帮助开发者在 AWS 上开发并部署 AWS Lambda 函数及其所需的 AWS 基础设施资源。它以开箱即用的结构化、自动化与最佳实践让你把精力集中在构建由Functions函数与Events事件组合而成的复杂事件驱动无服务器架构上。阅读本篇后你将掌握 Serverless Framework 的四大核心概念Functions、Events、Resources、Services及其在serverless.yml中的声明方式并了解从服务配置、多语言支持、资源命名到插件扩展的完整知识链路。本文内容以仓库中的官方概念文档 docs/sf/providers/aws/guide/intro.md 为骨架并结合 functions.md、events.md、resources.md、services.md 及各页面背后的核心源码进行纵深展开。Serverless Framework 为何与众不同在进入具体概念之前先理解 Framework 与普通应用框架的本质区别这决定了你理解后续所有概念的方式它同时管理代码与基础设施一份serverless.yml既可以声明 Lambda 业务代码也可以声明背后的 DynamoDB 表、S3 桶、SNS Topic 等云资源它支持多种语言Node.js、Python、Java 等运行时均可部署框架本身与语言无关它以事件驱动为核心抽象函数只负责单件事务由事件触发、由框架自动创建配套基础设施并完成监听配置。以下四个概念是理解 Serverless Framework 的地基Functions代码单元、Events触发来源、Resources被函数使用的基础设施以及把它们编排到一起的 Services组织单元。Functions部署在云上的独立执行单元Functions是无服务器应用的代码载体它们被部署到 AWS Lambda 中执行。每个函数都是一个独立的执行与部署单元形态上类似于一个微服务。一个函数本质上只是一段部署到云端的代码通常被写成只完成单一任务例如将用户保存到数据库处理数据库中的某个文件执行一个定时任务。在 functions.md 中有完整的函数配置说明这里先给一个典型的函数声明形态# serverless.yml service: myService provider: name: aws runtime: nodejs14.x runtimeManagement: auto # 可选默认 auto可设 auto 或 onFunctionUpdate memorySize: 512 # 可选单位 MB默认 1024 timeout: 10 # 可选单位秒默认 6 functions: hello: handler: handler.hello # 必填指向函数代码模块 name: ${sls:stage}-lambdaName # 可选部署后的 Lambda 名称 description: Description of what the lambda function does # 可选 runtime: python3.11 # 可选覆盖 provider 级运行时 memorySize: 512 # 可选单位 MB默认 1024 timeout: 10 # 可选单位秒默认 6 provisionedConcurrency: alias: active # 可选默认 provisioned executions: 3 # 指定为对象时必填 reservedConcurrency: 5 # 可选默认遵循账户并发上限这里的handler属性指向包含待执行代码的文件与模块// handler.js module.exports.functionOne function (event, context, callback) {}一个服务内可以声明任意多个函数且函数属性遵循provider 级继承 函数级覆盖的分层规则。例如在 provider 层设置memorySize: 512所有函数都会继承若某函数需要更大的内存再在函数级单独覆盖。这一继承-覆盖规则同样适用于环境变量、标签、VPC、追踪等几乎所有配置维度详见 functions.md。此外functions也可以声明为一个数组并借助变量加载把不同函数拆分到多个文件便于按业务模块组织例如${file(./foo-functions.yml)}。Events触发函数运行的引信Events是触发函数运行的信号源。在使用 AWS 作为 provider 时服务中定义的events可以是任何能触发 AWS Lambda 的 AWS 资源例如API Gateway URL 上的 HTTP 请求例如 REST APIS3 桶中新上传的文件例如图片上传场景CloudWatch 定时调度例如每 5 分钟执行一次SNS Topic 中的一条消息CloudWatch 告警以及更多其他事件源。关键机制当你在 Lambda 函数上配置一个事件时Serverless Framework 会自动创建该事件所需的基础设施例如一个 API Gateway 端点并把你的函数配置为监听它。也就是说声明一个事件 声明了基础设施 权限 触发绑定整套链路。事件定义在functions下的events数组里事件是对象可携带事件专属信息数组形态意味着一个函数可被多个事件触发只要 AWS 支持# functions in serverless.yml functions: createUser: # 函数名 handler: handler.users # 指向 handler.js 文件中的 users 导出函数 events: - httpApi: POST /users/create - httpApi: PUT /users/update - httpApi: DELETE /users/deleteHTTP 事件还支持路径参数只需在路由中声明{id}之类的占位符即可把路径参数传给 Lambda 函数更多细节见 docs/sf/providers/aws/events/apigateway.mdevents: - httpApi: GET /users/{id}Framework 支持 AWS Lambda 的全部事件类型完整的事件词典位于 docs/sf/providers/aws/events/README.mdschedule、S3、SNS、SQS、Kinesis/Streams、EventBridge、IoT、MQ、Kafka/MSK、ALB、WebSocket、Cognito 等。每种事件都有大量配置与独立功能本概念指南只负责事件是什么、如何挂接具体到某类事件的参数请进入对应页面。从源码实现看事件类型的支撑正是 Framework 核心插件集的一部分——packages/serverless/lib/plugins/index.js 中的loadModules()依次加载了schedule.js、s3/index.js、api-gateway/index.js、sns.js、stream.js、kafka.js、activemq.js、rabbitmq.js、msk/index.js、alb/index.js、alexa-skill.js、alexa-smart-home.js、iot.js、cloud-watch-event.js、cloud-watch-log.js、cognito-user-pool.js、event-bridge/index.js、sqs.js、cloud-front.js、http-api.js等事件编译模块。每个模块都对应一个事件类型的编译/编排插件这印证了文档Serverless Framework 支持所有 AWS Lambda 事件且不止于此的描述。Resources函数依赖的 AWS 基础设施Resources是函数所使用的 AWS 基础设施组件例如DynamoDB 表用于保存用户/文章/评论等数据S3 桶用于保存图片或文件SNS Topic用于异步发送消息任何可以在 CloudFormation 中定义的东西Serverless Framework 都支持。Framework 不仅能部署函数与事件也能部署 AWS 资源。所有使用awsprovider 的服务在每个阶段stage的部署本质上对应一个独立的 AWS CloudFormation 栈——Lambda 函数、事件配置、自定义资源最终都会被打包进这个栈由 CloudFormation 统一执行创建与更新。在serverless.yml中通过resources属性直接书写原生的 CloudFormation 模板语法YAML# serverless.yml service: usersCrud provider: aws functions: resources: # CloudFormation 模板语法 Resources: usersTable: Type: AWS::DynamoDB::Table Properties: TableName: usersTable AttributeDefinitions: - AttributeName: email AttributeType: S KeySchema: - AttributeName: email KeyType: HASH ProvisionedThroughput: ReadCapacityUnits: 1 WriteCapacityUnits: 1资源命名规则可被引用的稳定约定为了让生成的 CloudFormation 模板命名一致、可被自定义资源引用Framework 采用统一命名模式{函数名}{CloudFormation 资源类型}{资源名}{SequentialID / instanceId / 随机串}函数名可选用于区分随函数名变更而重建的资源即 function bound 资源CloudFormation 资源类型例如S3Bucket资源名具体资源的标识例如 S3 桶的配置名SequentialID / instanceId / 随机串部分资源需要追加的序号、${sls:instanceId}或随机串。路径变量也会被规范化例如POST /users/{user_id}会被规范为UsersUseridVarTestPost。下表摘录几个最常见资源类型的命名模板完整表格见 docs/sf/providers/aws/guide/resources.mdAWS 资源名称模板示例S3::BucketS3Bucket{normalizedBucketName}S3BucketMybucketIAM::RoleIamRoleLambdaExecutionIamRoleLambdaExecutionLambda::Function{normalizedFunctionName}LambdaFunctionHelloLambdaFunctionLogs::LogGroup{normalizedFunctionName}LogGroupHelloLogGroupApiGateway::RestApiApiGatewayRestApiApiGatewayRestApi排查技巧不确定某个资源最终叫什么名字时先执行serverless package它会生成服务的 CloudFormation 模板到.serverless目录文件名cloudformation-template-update-stack.json打开即可查到真实生成的资源名。扩展与覆盖内置资源在resources.Resources中直接书写资源时需注意可能误覆盖框架生成的同名资源。若想有意地扩展框架生成的资源应使用resources.extensions。以把日志组的保留期设为 30 天为例函数名write-post规范化为WriteDashPostLogGroup注意-→Dash、_→Underscore且必须以大写字母开头functions: write-post: handler: handler.writePost events: - httpApi: POST /api/posts/new resources: extensions: WriteDashPostLogGroup: Properties: RetentionInDays: 30extensions的合并语义非常明确详见 resources.mdProperties与Metadata是键级替换式合并DependsOn是追加式合并Condition/CreationPolicy/DeletionPolicy/UpdatePolicy/UpdateReplacePolicy直接设为扩展值其他属性类型不支持会抛错。同时框架允许用null赋值删掉某个资源属性——因为 CloudFormation 本身不允许这样做Serverless 会在上传前把这些属性从最终模板中剥离。ServicesFramework 的组织单元Service即 project是 Framework 的组织单元。可以把它想成一个项目文件而一个应用可以拥有多个 service。Service 通过一份serverless.yml配置函数、事件与要部署的 AWS 资源service: users provider: name: aws # 云服务商配置 functions: # 要部署的函数 usersCreate: events: - httpApi: POST /users/create usersDelete: events: - httpApi: DELETE /users/delete plugins: # 要启用的插件 resources: # 额外要部署的 AWS 资源执行serverless deploy时配置文件里的所有内容会被一次性整体部署。服务的目录组织项目早期通常建议把该应用的所有函数、事件与资源放在一个 service中my-service/ # 包含所有函数与基础设施资源 serverless.yml随着应用增长可以拆分成多个 service。常见实践是按工作流或数据模型来划分——把与同一工作流/数据模型相关的函数聚合在一个 service 里例如独立的users/、posts/、comments/各含自己的 CRUD 函数与数据库表。这样划分的合理性在于相关函数通常共享公共基础设施资源把它们作为一个整体部署单元能获得更好的组织性与关注点分离。当需要编排、协同部署多个 service 时可参考 docs/sf/guides/compose.mdCompose 机制。新 service 的创建方式是执行serverless命令并跟随 docs/sf/getting-started.md 的引导。serverless.yml 的职责与完整形态每个 service 的配置都存放在serverless.yml中其主要职责是声明一个 serverless service定义服务将要部署到的云服务商定义一个或多个函数定义触发每个函数的事件如 HTTP 请求定义要启用的插件定义要创建的 AWS 资源集合让events段中的事件在部署时自动创建所需资源通过 变量系统 实现灵活配置。综合前三节概念一个相对完整的serverless.yml如下# serverless.yml service: users provider: name: aws runtime: nodejs14.x stage: dev # 默认阶段默认为 dev region: us-east-1 # 覆盖默认区域默认 us-east-1 profile: production # 本服务使用的默认 AWS profile memorySize: 512 # 覆盖默认内存默认为 1024 functions: usersCreate: # 函数 handler: users.create events: # 触发该函数的事件 - httpApi: POST /users/create usersDelete: # 函数 handler: users.delete events: - httpApi: DELETE /users/delete resources: # 函数使用的资源这里放置原生的 AWS CloudFormation Resources: usersTable: Type: AWS::DynamoDB::Table Properties: TableName: usersTable AttributeDefinitions: - AttributeName: email AttributeType: S KeySchema: - AttributeName: email KeyType: HASH BillingMode: PAY_PER_REQUEST按阶段stage差异化配置stages段允许针对不同部署阶段做差异化配置包括参数params、可观测性开关以及变量解析器resolvers声明并可用default作为未显式声明阶段的兜底。例如为不同阶段配置不同密钥# serverless.yml service: billing stages: prod: params: stripe_api_key: ${env:PROD_STRIPE_API_KEY} default: params: stripe_api_key: ${env:DEV_STRIPE_API_KEY} functions: chargeCustomer: handler: billing.charge environment: STRIPE_API_KEY: ${param:stripe_api_key}框架会依据当前部署阶段自动解析stripe_api_key。stages同样可控制 Dashboard 可观测性开关observability: true/false、声明terraform/vault等变量解析器详细说明见 docs/sf/guides/parameters.md 与 docs/sf/guides/variables/hashicorp/terraform.md 等文档。部署与移除部署服务时serverless.yml中所有函数、事件与资源会被翻译为一份 AWS CloudFormation 模板并作为单一 CloudFormation 栈整体部署。在serverless.yml所在目录执行serverless deploy部署默认针对dev阶段与us-east-1区域可通过 CLI 选项覆盖serverless deploy --stage prod --region us-east-1从 deploying.md 的工作原理可以看出其整体流程将配置翻译为 CloudFormation 模板 → 首次创建栈时先建一个存放函数代码 zip 的 S3 桶 → 打包函数代码 → 对比上次部署的文件哈希一致则终止实现增量跳过→ 上传 zip → 把 IAM 角色、函数、事件与资源一并写入 CloudFormation 模板执行。需要移除服务时执行serverless remove它只清理 AWS 侧的栈与相关资源本地目录保留方便以后重新部署到其他阶段、区域或 provider。版本固定Version PinningServerless Framework 通常通过npm install -g serverless全局安装。全局安装的缺点是版本无法锁定在项目package.json中——当你升级 Framework 而同事或 CI 未升级时可能用上新版本专属的配置语法、部署时却仍由旧版本执行。解决办法是在serverless.yml顶部声明frameworkVersion语义化版本支持精确值与范围每次 CLI 执行前都会校验当前版本是否落在该范围内# serverless.yml frameworkVersion: ^3.0.0 # 例3.0.0 且 4.0.0 service: users provider: name: aws runtime: nodejs14.x建议在团队中固定到一个精确版本确保人人含 CI环境完全一致。注意文档示例中的具体版本号仅为演示请以你实际安装/期望使用的版本为准。替代的配置格式JSON / JavaScript / TypeScript当需要更大灵活性时服务配置也可以写成 JSONserverless.json、JavaScriptserverless.js或 TypeScriptserverless.ts。Framework 本身语言无关但对 Node.js 项目而言前后端同一语言能降低心智负担。使用 JS/TS 时文件必须以 JS 对象形式导出配置use strict // serverless.js module.exports { service: users, functions: { usersCreate: { events: [ { httpApi: POST /users/create, }, ], }, // ... }, resources: {}, }// 需要先在项目 package.json 中安装 types/serverless import type { Serverless } from serverless/aws // serverless.ts const serverlessConfiguration: Serverless { service: users, functions: { usersCreate: { events: [ { httpApi: POST /users/create, }, ], }, // ... }, resources: {}, } module.exports serverlessConfiguration两点注意使用serverless.ts部署时需将ts-node单独安装为 devDependency文档中绝大多数示例以serverless.yml展示但所有功能对四种格式一视同仁。Plugins用插件覆盖与扩展框架能力你可以通过插件覆盖或扩展 Framework 的功能。每个serverless.yml都可以包含plugins:属性并挂载多个插件# serverless.yml plugins: - serverless-offline - serverless-secrets关于插件的更完整介绍安装、本地插件、加载顺序、自定义插件编写在 docs/sf/guides/plugins/README.md这里简述与概念相关的内容插件本质一段自定义 JavaScript 代码为 Framework 扩展新功能Framework 本身也由一组核心插件组成因此自定义插件的写法与核心插件完全一致按服务安装插件按 service 维度安装而非全局。可运行serverless plugin install -n 插件名自动安装并在serverless.yml注册也可手动npm install --save-dev后手工加入plugins段插件专属配置放在custom段由各插件文档决定需要配置哪些键本地加载路径以./开头时从服务根目录相对加载本地插件适合单项目专用插件或开发中插件加载顺序Framework 先加载全部核心插件再按plugins声明顺序依次加载自定义插件plugin1先于plugin2。从实现上印证Framework 即一组核心插件在 packages/serverless/lib/plugins/index.js 中可以看到 Framework 把deploy、invoke、info、logs、metrics、remove、rollback、AWS provider 及各类事件编译模块全部统一作为模块列表加载而 packages/serverless/lib/classes/plugin-manager.js 中的loadAllPlugins(servicePlugins)则负责协调内置插件bundled与用户外部插件的加载与覆盖逻辑——例如某服务若在plugins中显式声明了某社区同名插件框架会跳过内置版本、优先使用社区实现。理解这一点对排查为什么我的插件没生效/被覆盖很有帮助。从概念到深度配置Functions 的进阶能力Functions 作为无服务器应用的执行核心其配置面远不止handler与runtime。为了让你在理解概念后能直接落地这里按 functions.md 提炼若干高频且重要的配置维度权限IAM每个 Lambda 函数都通过一个 IAM Role 获得访问账户内其他 AWS 资源的权限。可通过provider.iam.role.statements批量声明策略语句支持 DynamoDB/S3 等操作的细粒度授权也可通过provider.iam.role直接传入一个已存在的角色 ARN用法与函数级 IAM 见 docs/sf/providers/aws/guide/iam.md。Function URLurl: true即可为函数直接生成免 API Gateway 的公开 HTTP 端点对象形式可配置authorizer: aws_iamIAM 鉴权、cors支持 true 全放开或细粒度配置allowedOrigins/allowedMethods/allowCredentials/exposedResponseHeaders/maxAge等并可用null移除默认项、以及invokeMode: RESPONSE_STREAM流式响应默认BUFFERED。容器镜像通过image属性引用 ECR 镜像含uri直接引用已有镜像或provider.ecr.images定义本地 Dockerfile 构建、再以path/file/buildArgs/platform等控制构建使用image时handler与runtime不再适用。框架会在首次部署时为镜像服务自动创建serverless-service-stage的 ECR 仓库并在sls remove时随之移除。指令集架构默认 x86_64在 provider 或函数级设置architecture: arm64即可切换到 AWS Graviton2可能带来更优的价格与性能。VPC函数级vpc.securityGroupIdsvpc.subnetIds可把函数放入 VPC支持双栈子网 IPv6 出站ipv6AllowedForDualStackprovider 级可配置后由函数继承函数级配置以~null覆盖为无 VPC。注意 VPC 内函数默认失去公网访问能力访问 S3/DynamoDB 需 VPC Endpoint、访问 Kinesis 等需 NAT Gateway。环境变量与标签environment、tags均支持 provider 级与函数级合并 同名覆盖。版本管理versionFunctions默认每次部署都会生成函数版本可通过:3之类限定符按版本调用。版本不会被框架自动清理需借助插件或工具定期剪除旧版本versionFunctions: false可关闭该行为。异步调用治理destinationsonSuccess/onFailure 目标其他函数、EventBridge、SQS 或 SNS、maximumEventAge60 秒~6 小时、maximumRetryAttempts0~2。可观测性与安全tracingX-Ray 追踪true/Active/PassThrough、kmsKeyArn自定义 KMS 加密环境变量、snapStartJava 11/17/21 的启动加速且不兼容 provisioned concurrency、arm64、EFS 等、recursiveLoop递归调用检测allow/terminate。日志治理框架默认会为 Lambda 创建 LogGroup 以便服务删除时一并清理可用disableLogs、logRetentionInDays、logDataProtectionPolicy以及logs.logGroupClass: infrequent_access低频访问日志类约省 50% 摄入成本但注意该模式下sls logs -f不可用、需用 CloudWatch Logs Insights 读取且切换与重建存在文档明确警示的边界情形管理。概念落地一个最小可部署的服务综合上述概念你最终交付给框架的是一份声明式契约函数回答代码放哪、怎么执行事件回答谁来触发资源回答背后依赖什么service 则把它们打包成一个可整体部署的 CloudFormation 栈。要实际体验可在仓库相应测试目录的 fixture 中查看更多真实示例例如 packages/sf-core/tests/integration/simple-nodejs/fixture 下的serverless.yml与 handler或在空目录中执行serverless交互式引导创建第一个服务。完整函数配置文档docs/sf/providers/aws/guide/functions.md事件配置总入口docs/sf/providers/aws/guide/events.md 与事件清单 docs/sf/providers/aws/events/README.md资源与 CloudFormation 扩展docs/sf/providers/aws/guide/resources.md服务组织与部署docs/sf/providers/aws/guide/services.md、docs/sf/providers/aws/guide/deploying.md插件机制docs/sf/guides/plugins/README.md、docs/sf/guides/plugins/creating-plugins.md【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Serverless Framework 核心概念指南在 AWS 上用 Functions、Events、Resources 与 Services 构建事件驱动架构【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverlessServerless Framework 是一套开源的 CLI 工具帮助开发者在 AWS 上开发并部署 AWS Lambda 函数及其所需的 AWS 基础设施资源。它以开箱即用的结构化、自动化与最佳实践让你把精力集中在构建由Functions函数与Events事件组合而成的复杂事件驱动无服务器架构上。阅读本篇后你将掌握 Serverless Framework 的四大核心概念Functions、Events、Resources、Services及其在serverless.yml中的声明方式并了解从服务配置、多语言支持、资源命名到插件扩展的完整知识链路。本文内容以仓库中的官方概念文档 docs/sf/providers/aws/guide/intro.md 为骨架并结合 functions.md、events.md、resources.md、services.md 及各页面背后的核心源码进行纵深展开。Serverless Framework 为何与众不同在进入具体概念之前先理解 Framework 与普通应用框架的本质区别这决定了你理解后续所有概念的方式它同时管理代码与基础设施一份serverless.yml既可以声明 Lambda 业务代码也可以声明背后的 DynamoDB 表、S3 桶、SNS Topic 等云资源它支持多种语言Node.js、Python、Java 等运行时均可部署框架本身与语言无关它以事件驱动为核心抽象函数只负责单件事务由事件触发、由框架自动创建配套基础设施并完成监听配置。以下四个概念是理解 Serverless Framework 的地基Functions代码单元、Events触发来源、Resources被函数使用的基础设施以及把它们编排到一起的 Services组织单元。Functions部署在云上的独立执行单元Functions是无服务器应用的代码载体它们被部署到 AWS Lambda 中执行。每个函数都是一个独立的执行与部署单元形态上类似于一个微服务。一个函数本质上只是一段部署到云端的代码通常被写成只完成单一任务例如将用户保存到数据库处理数据库中的某个文件执行一个定时任务。在 functions.md 中有完整的函数配置说明这里先给一个典型的函数声明形态# serverless.yml service: myService provider: name: aws runtime: nodejs14.x runtimeManagement: auto # 可选默认 auto可设 auto 或 onFunctionUpdate memorySize: 512 # 可选单位 MB默认 1024 timeout: 10 # 可选单位秒默认 6 functions: hello: handler: handler.hello # 必填指向函数代码模块 name: ${sls:stage}-lambdaName # 可选部署后的 Lambda 名称 description: Description of what the lambda function does # 可选 runtime: python3.11 # 可选覆盖 provider 级运行时 memorySize: 512 # 可选单位 MB默认 1024 timeout: 10 # 可选单位秒默认 6 provisionedConcurrency: alias: active # 可选默认 provisioned executions: 3 # 指定为对象时必填 reservedConcurrency: 5 # 可选默认遵循账户并发上限这里的handler属性指向包含待执行代码的文件与模块// handler.js module.exports.functionOne function (event, context, callback) {}一个服务内可以声明任意多个函数且函数属性遵循provider 级继承 函数级覆盖的分层规则。例如在 provider 层设置memorySize: 512所有函数都会继承若某函数需要更大的内存再在函数级单独覆盖。这一继承-覆盖规则同样适用于环境变量、标签、VPC、追踪等几乎所有配置维度详见 functions.md。此外functions也可以声明为一个数组并借助变量加载把不同函数拆分到多个文件便于按业务模块组织例如${file(./foo-functions.yml)}。Events触发函数运行的引信Events是触发函数运行的信号源。在使用 AWS 作为 provider 时服务中定义的events可以是任何能触发 AWS Lambda 的 AWS 资源例如API Gateway URL 上的 HTTP 请求例如 REST APIS3 桶中新上传的文件例如图片上传场景CloudWatch 定时调度例如每 5 分钟执行一次SNS Topic 中的一条消息CloudWatch 告警以及更多其他事件源。关键机制当你在 Lambda 函数上配置一个事件时Serverless Framework 会自动创建该事件所需的基础设施例如一个 API Gateway 端点并把你的函数配置为监听它。也就是说声明一个事件 声明了基础设施 权限 触发绑定整套链路。事件定义在functions下的events数组里事件是对象可携带事件专属信息数组形态意味着一个函数可被多个事件触发只要 AWS 支持# functions in serverless.yml functions: createUser: # 函数名 handler: handler.users # 指向 handler.js 文件中的 users 导出函数 events: - httpApi: POST /users/create - httpApi: PUT /users/update - httpApi: DELETE /users/deleteHTTP 事件还支持路径参数只需在路由中声明{id}之类的占位符即可把路径参数传给 Lambda 函数更多细节见 docs/sf/providers/aws/events/apigateway.mdevents: - httpApi: GET /users/{id}Framework 支持 AWS Lambda 的全部事件类型完整的事件词典位于 docs/sf/providers/aws/events/README.mdschedule、S3、SNS、SQS、Kinesis/Streams、EventBridge、IoT、MQ、Kafka/MSK、ALB、WebSocket、Cognito 等。每种事件都有大量配置与独立功能本概念指南只负责事件是什么、如何挂接具体到某类事件的参数请进入对应页面。从源码实现看事件类型的支撑正是 Framework 核心插件集的一部分——packages/serverless/lib/plugins/index.js 中的loadModules()依次加载了schedule.js、s3/index.js、api-gateway/index.js、sns.js、stream.js、kafka.js、activemq.js、rabbitmq.js、msk/index.js、alb/index.js、alexa-skill.js、alexa-smart-home.js、iot.js、cloud-watch-event.js、cloud-watch-log.js、cognito-user-pool.js、event-bridge/index.js、sqs.js、cloud-front.js、http-api.js等事件编译模块。每个模块都对应一个事件类型的编译/编排插件这印证了文档Serverless Framework 支持所有 AWS Lambda 事件且不止于此的描述。Resources函数依赖的 AWS 基础设施Resources是函数所使用的 AWS 基础设施组件例如DynamoDB 表用于保存用户/文章/评论等数据S3 桶用于保存图片或文件SNS Topic用于异步发送消息任何可以在 CloudFormation 中定义的东西Serverless Framework 都支持。Framework 不仅能部署函数与事件也能部署 AWS 资源。所有使用awsprovider 的服务在每个阶段stage的部署本质上对应一个独立的 AWS CloudFormation 栈——Lambda 函数、事件配置、自定义资源最终都会被打包进这个栈由 CloudFormation 统一执行创建与更新。在serverless.yml中通过resources属性直接书写原生的 CloudFormation 模板语法YAML# serverless.yml service: usersCrud provider: aws functions: resources: # CloudFormation 模板语法 Resources: usersTable: Type: AWS::DynamoDB::Table Properties: TableName: usersTable AttributeDefinitions: - AttributeName: email AttributeType: S KeySchema: - AttributeName: email KeyType: HASH ProvisionedThroughput: ReadCapacityUnits: 1 WriteCapacityUnits: 1资源命名规则可被引用的稳定约定为了让生成的 CloudFormation 模板命名一致、可被自定义资源引用Framework 采用统一命名模式{函数名}{CloudFormation 资源类型}{资源名}{SequentialID / instanceId / 随机串}函数名可选用于区分随函数名变更而重建的资源即 function bound 资源CloudFormation 资源类型例如S3Bucket资源名具体资源的标识例如 S3 桶的配置名SequentialID / instanceId / 随机串部分资源需要追加的序号、${sls:instanceId}或随机串。路径变量也会被规范化例如POST /users/{user_id}会被规范为UsersUseridVarTestPost。下表摘录几个最常见资源类型的命名模板完整表格见 docs/sf/providers/aws/guide/resources.mdAWS 资源名称模板示例S3::BucketS3Bucket{normalizedBucketName}S3BucketMybucketIAM::RoleIamRoleLambdaExecutionIamRoleLambdaExecutionLambda::Function{normalizedFunctionName}LambdaFunctionHelloLambdaFunctionLogs::LogGroup{normalizedFunctionName}LogGroupHelloLogGroupApiGateway::RestApiApiGatewayRestApiApiGatewayRestApi排查技巧不确定某个资源最终叫什么名字时先执行serverless package它会生成服务的 CloudFormation 模板到.serverless目录文件名cloudformation-template-update-stack.json打开即可查到真实生成的资源名。扩展与覆盖内置资源在resources.Resources中直接书写资源时需注意可能误覆盖框架生成的同名资源。若想有意地扩展框架生成的资源应使用resources.extensions。以把日志组的保留期设为 30 天为例函数名write-post规范化为WriteDashPostLogGroup注意-→Dash、_→Underscore且必须以大写字母开头functions: write-post: handler: handler.writePost events: - httpApi: POST /api/posts/new resources: extensions: WriteDashPostLogGroup: Properties: RetentionInDays: 30extensions的合并语义非常明确详见 resources.mdProperties与Metadata是键级替换式合并DependsOn是追加式合并Condition/CreationPolicy/DeletionPolicy/UpdatePolicy/UpdateReplacePolicy直接设为扩展值其他属性类型不支持会抛错。同时框架允许用null赋值删掉某个资源属性——因为 CloudFormation 本身不允许这样做Serverless 会在上传前把这些属性从最终模板中剥离。ServicesFramework 的组织单元Service即 project是 Framework 的组织单元。可以把它想成一个项目文件而一个应用可以拥有多个 service。Service 通过一份serverless.yml配置函数、事件与要部署的 AWS 资源service: users provider: name: aws # 云服务商配置 functions: # 要部署的函数 usersCreate: events: - httpApi: POST /users/create usersDelete: events: - httpApi: DELETE /users/delete plugins: # 要启用的插件 resources: # 额外要部署的 AWS 资源执行serverless deploy时配置文件里的所有内容会被一次性整体部署。服务的目录组织项目早期通常建议把该应用的所有函数、事件与资源放在一个 service中my-service/ # 包含所有函数与基础设施资源 serverless.yml随着应用增长可以拆分成多个 service。常见实践是按工作流或数据模型来划分——把与同一工作流/数据模型相关的函数聚合在一个 service 里例如独立的users/、posts/、comments/各含自己的 CRUD 函数与数据库表。这样划分的合理性在于相关函数通常共享公共基础设施资源把它们作为一个整体部署单元能获得更好的组织性与关注点分离。当需要编排、协同部署多个 service 时可参考 docs/sf/guides/compose.mdCompose 机制。新 service 的创建方式是执行serverless命令并跟随 docs/sf/getting-started.md 的引导。serverless.yml 的职责与完整形态每个 service 的配置都存放在serverless.yml中其主要职责是声明一个 serverless service定义服务将要部署到的云服务商定义一个或多个函数定义触发每个函数的事件如 HTTP 请求定义要启用的插件定义要创建的 AWS 资源集合让events段中的事件在部署时自动创建所需资源通过 变量系统 实现灵活配置。综合前三节概念一个相对完整的serverless.yml如下# serverless.yml service: users provider: name: aws runtime: nodejs14.x stage: dev # 默认阶段默认为 dev region: us-east-1 # 覆盖默认区域默认 us-east-1 profile: production # 本服务使用的默认 AWS profile memorySize: 512 # 覆盖默认内存默认为 1024 functions: usersCreate: # 函数 handler: users.create events: # 触发该函数的事件 - httpApi: POST /users/create usersDelete: # 函数 handler: users.delete events: - httpApi: DELETE /users/delete resources: # 函数使用的资源这里放置原生的 AWS CloudFormation Resources: usersTable: Type: AWS::DynamoDB::Table Properties: TableName: usersTable AttributeDefinitions: - AttributeName: email AttributeType: S KeySchema: - AttributeName: email KeyType: HASH BillingMode: PAY_PER_REQUEST按阶段stage差异化配置stages段允许针对不同部署阶段做差异化配置包括参数params、可观测性开关以及变量解析器resolvers声明并可用default作为未显式声明阶段的兜底。例如为不同阶段配置不同密钥# serverless.yml service: billing stages: prod: params: stripe_api_key: ${env:PROD_STRIPE_API_KEY} default: params: stripe_api_key: ${env:DEV_STRIPE_API_KEY} functions: chargeCustomer: handler: billing.charge environment: STRIPE_API_KEY: ${param:stripe_api_key}框架会依据当前部署阶段自动解析stripe_api_key。stages同样可控制 Dashboard 可观测性开关observability: true/false、声明terraform/vault等变量解析器详细说明见 docs/sf/guides/parameters.md 与 docs/sf/guides/variables/hashicorp/terraform.md 等文档。部署与移除部署服务时serverless.yml中所有函数、事件与资源会被翻译为一份 AWS CloudFormation 模板并作为单一 CloudFormation 栈整体部署。在serverless.yml所在目录执行serverless deploy部署默认针对dev阶段与us-east-1区域可通过 CLI 选项覆盖serverless deploy --stage prod --region us-east-1从 deploying.md 的工作原理可以看出其整体流程将配置翻译为 CloudFormation 模板 → 首次创建栈时先建一个存放函数代码 zip 的 S3 桶 → 打包函数代码 → 对比上次部署的文件哈希一致则终止实现增量跳过→ 上传 zip → 把 IAM 角色、函数、事件与资源一并写入 CloudFormation 模板执行。需要移除服务时执行serverless remove它只清理 AWS 侧的栈与相关资源本地目录保留方便以后重新部署到其他阶段、区域或 provider。版本固定Version PinningServerless Framework 通常通过npm install -g serverless全局安装。全局安装的缺点是版本无法锁定在项目package.json中——当你升级 Framework 而同事或 CI 未升级时可能用上新版本专属的配置语法、部署时却仍由旧版本执行。解决办法是在serverless.yml顶部声明frameworkVersion语义化版本支持精确值与范围每次 CLI 执行前都会校验当前版本是否落在该范围内# serverless.yml frameworkVersion: ^3.0.0 # 例3.0.0 且 4.0.0 service: users provider: name: aws runtime: nodejs14.x建议在团队中固定到一个精确版本确保人人含 CI环境完全一致。注意文档示例中的具体版本号仅为演示请以你实际安装/期望使用的版本为准。替代的配置格式JSON / JavaScript / TypeScript当需要更大灵活性时服务配置也可以写成 JSONserverless.json、JavaScriptserverless.js或 TypeScriptserverless.ts。Framework 本身语言无关但对 Node.js 项目而言前后端同一语言能降低心智负担。使用 JS/TS 时文件必须以 JS 对象形式导出配置use strict // serverless.js module.exports { service: users, functions: { usersCreate: { events: [ { httpApi: POST /users/create, }, ], }, // ... }, resources: {}, }// 需要先在项目 package.json 中安装 types/serverless import type { Serverless } from serverless/aws // serverless.ts const serverlessConfiguration: Serverless { service: users, functions: { usersCreate: { events: [ { httpApi: POST /users/create, }, ], }, // ... }, resources: {}, } module.exports serverlessConfiguration两点注意使用serverless.ts部署时需将ts-node单独安装为 devDependency文档中绝大多数示例以serverless.yml展示但所有功能对四种格式一视同仁。Plugins用插件覆盖与扩展框架能力你可以通过插件覆盖或扩展 Framework 的功能。每个serverless.yml都可以包含plugins:属性并挂载多个插件# serverless.yml plugins: - serverless-offline - serverless-secrets关于插件的更完整介绍安装、本地插件、加载顺序、自定义插件编写在 docs/sf/guides/plugins/README.md这里简述与概念相关的内容插件本质一段自定义 JavaScript 代码为 Framework 扩展新功能Framework 本身也由一组核心插件组成因此自定义插件的写法与核心插件完全一致按服务安装插件按 service 维度安装而非全局。可运行serverless plugin install -n 插件名自动安装并在serverless.yml注册也可手动npm install --save-dev后手工加入plugins段插件专属配置放在custom段由各插件文档决定需要配置哪些键本地加载路径以./开头时从服务根目录相对加载本地插件适合单项目专用插件或开发中插件加载顺序Framework 先加载全部核心插件再按plugins声明顺序依次加载自定义插件plugin1先于plugin2。从实现上印证Framework 即一组核心插件在 packages/serverless/lib/plugins/index.js 中可以看到 Framework 把deploy、invoke、info、logs、metrics、remove、rollback、AWS provider 及各类事件编译模块全部统一作为模块列表加载而 packages/serverless/lib/classes/plugin-manager.js 中的loadAllPlugins(servicePlugins)则负责协调内置插件bundled与用户外部插件的加载与覆盖逻辑——例如某服务若在plugins中显式声明了某社区同名插件框架会跳过内置版本、优先使用社区实现。理解这一点对排查为什么我的插件没生效/被覆盖很有帮助。从概念到深度配置Functions 的进阶能力Functions 作为无服务器应用的执行核心其配置面远不止handler与runtime。为了让你在理解概念后能直接落地这里按 functions.md 提炼若干高频且重要的配置维度权限IAM每个 Lambda 函数都通过一个 IAM Role 获得访问账户内其他 AWS 资源的权限。可通过provider.iam.role.statements批量声明策略语句支持 DynamoDB/S3 等操作的细粒度授权也可通过provider.iam.role直接传入一个已存在的角色 ARN用法与函数级 IAM 见 docs/sf/providers/aws/guide/iam.md。Function URLurl: true即可为函数直接生成免 API Gateway 的公开 HTTP 端点对象形式可配置authorizer: aws_iamIAM 鉴权、cors支持 true 全放开或细粒度配置allowedOrigins/allowedMethods/allowCredentials/exposedResponseHeaders/maxAge等并可用null移除默认项、以及invokeMode: RESPONSE_STREAM流式响应默认BUFFERED。容器镜像通过image属性引用 ECR 镜像含uri直接引用已有镜像或provider.ecr.images定义本地 Dockerfile 构建、再以path/file/buildArgs/platform等控制构建使用image时handler与runtime不再适用。框架会在首次部署时为镜像服务自动创建serverless-service-stage的 ECR 仓库并在sls remove时随之移除。指令集架构默认 x86_64在 provider 或函数级设置architecture: arm64即可切换到 AWS Graviton2可能带来更优的价格与性能。VPC函数级vpc.securityGroupIdsvpc.subnetIds可把函数放入 VPC支持双栈子网 IPv6 出站ipv6AllowedForDualStackprovider 级可配置后由函数继承函数级配置以~null覆盖为无 VPC。注意 VPC 内函数默认失去公网访问能力访问 S3/DynamoDB 需 VPC Endpoint、访问 Kinesis 等需 NAT Gateway。环境变量与标签environment、tags均支持 provider 级与函数级合并 同名覆盖。版本管理versionFunctions默认每次部署都会生成函数版本可通过:3之类限定符按版本调用。版本不会被框架自动清理需借助插件或工具定期剪除旧版本versionFunctions: false可关闭该行为。异步调用治理destinationsonSuccess/onFailure 目标其他函数、EventBridge、SQS 或 SNS、maximumEventAge60 秒~6 小时、maximumRetryAttempts0~2。可观测性与安全tracingX-Ray 追踪true/Active/PassThrough、kmsKeyArn自定义 KMS 加密环境变量、snapStartJava 11/17/21 的启动加速且不兼容 provisioned concurrency、arm64、EFS 等、recursiveLoop递归调用检测allow/terminate。日志治理框架默认会为 Lambda 创建 LogGroup 以便服务删除时一并清理可用disableLogs、logRetentionInDays、logDataProtectionPolicy以及logs.logGroupClass: infrequent_access低频访问日志类约省 50% 摄入成本但注意该模式下sls logs -f不可用、需用 CloudWatch Logs Insights 读取且切换与重建存在文档明确警示的边界情形管理。概念落地一个最小可部署的服务综合上述概念你最终交付给框架的是一份声明式契约函数回答代码放哪、怎么执行事件回答谁来触发资源回答背后依赖什么service 则把它们打包成一个可整体部署的 CloudFormation 栈。要实际体验可在仓库相应测试目录的 fixture 中查看更多真实示例例如 packages/sf-core/tests/integration/simple-nodejs/fixture 下的serverless.yml与 handler或在空目录中执行serverless交互式引导创建第一个服务。完整函数配置文档docs/sf/providers/aws/guide/functions.md事件配置总入口docs/sf/providers/aws/guide/events.md 与事件清单 docs/sf/providers/aws/events/README.md资源与 CloudFormation 扩展docs/sf/providers/aws/guide/resources.md服务组织与部署docs/sf/providers/aws/guide/services.md、docs/sf/providers/aws/guide/deploying.md插件机制docs/sf/guides/plugins/README.md、docs/sf/guides/plugins/creating-plugins.md【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
