Serverless framework 101
Serverless Framework是一个开源命令行工具。他提供函数脚手架、流程自动化、最佳实践等帮助开发、部署跨云厂商的托管无服务器计算服务(官方已支持aws, Azure, GCP, IBM Cloud等各种厂商的无服务器计算)。同时支持使用插件来扩展各种功能,比如支持更多云厂商无服务器计算服务,例如阿里云的函数计算。
这里使用基于函数计算的钉钉回调函数接口示例来演示如何使用Serverless Framework将一个无服务器函数部署到AWS Lambda。
安装servereless后,可以通过serverless create
命令创建函数脚手架工程,或者在已有工程的下创建serverless配置文件serverless.yml
。
接下来可以参考serverless aws reference配置你的aws lambda函数及需要的各种资源。如果已经有过使用AWS CloudFormation或者AWS SAM经验的,可以很快适应编写Serverless配置。Serverless的配置本质上是将CloudFormation/SAM相关的概念进行抽象,为各个云厂商的无服务器计算服务提供统一的工具、命令以及概念抽象。在部署aws lambda时,serverless
配置会被转换为CloudFormation
配置,通过AWS API进行创建或变更。
对于Dingtalk Callback on AWS Lambda, serverless
配置声明如下。其中指定了service的基本信息,全局的配置(如stage、region等)、云厂商provider(这里是aws)。函数的基本信息、权限、layer、触发器,自定义layer以及其他云厂商资源,比如Dingtalk callback这里用到的DynamoDB。完整的serverless配置查看这里。
1service:
2 name: dingtalk-callback
3
4frameworkVersion: ">=1.0.0 <2.0.0"
5
6provider:
7 name: aws
8 runtime: java8
9 stage: ${opt:stage, 'dev'} # Set the default stage used. Default is dev
10 region: ${opt:region, 'ap-southeast-1'} # Overwrite the default region used. Default is ap-southeast-1
11 profile: ${opt:profile, 'default'} # The default profile to use with this service
12 versionFunctions: true # Optional function versioning
13 endpointType: regional # Optional endpoint configuration for API Gateway REST API. Default is Edge.
14
15functions:
16 dingtalk-callback:
17 handler: com.github.zxkane.dingtalk.Callback::handleRequest # required, handler set in AWS Lambda
18 name: ${self:provider.stage}-dingtalk-callback # optional, Deployed Lambda name
19 memorySize: 384 # optional, in MB, default is 1024
20 timeout: 15 # optional, in seconds, default is 6
21 environment: # Function level environment variables
22 PARA_DD_TOKEN: DD_TOKEN
23 TABLE_NAME: {Ref: BPMTable}
24 package:
25 artifact: build/libs/dingtalk-callback-1.0.0-SNAPSHOT.jar
26 role: dingtalkCallbackIAMRole
27 layers: # An optional list Lambda Layers to use
28 - {Ref: DependenciesLambdaLayer}
29 events: # The Events that trigger this Function
30 - http: # This creates an API Gateway HTTP endpoint which can be used to trigger this function. Learn more in "events/apigateway"
31 path: dingtalk # Path for this endpoint
32 method: post # HTTP method for this endpoint
33
34layers:
35 dependencies:
36 path: build/deps
37
38resources: # CloudFormation template syntax
39 Resources:
40 dingtalkCallbackIAMRole:
41 Type: AWS::IAM::Role
42 Properties:
43 Policies:
44 - PolicyName: SSMPolicy
45 - PolicyName: DynamoDBPolicy
46 BPMTable:
47 Type: AWS::DynamoDB::Table
48 Properties:
49 TableName: bpm_raw_${self:service.name}_${self:provider.stage}
50 ProvisionedThroughput:
51 ReadCapacityUnits: 1
52 WriteCapacityUnits: 1
对于使用单一云厂商无服务器计算并且已经使用了类似sam cli实现持续集成、持续部署的用户,Serverless Framework并不能带来更多生产力的提升,在稳定性(封装云厂商的功能,增加复杂度很可能引入新的问题)或功能的及时性上可能还不如云厂商提供的工具。
对于有多云厂商部署无服务器函数需求的用户,使用了Serverless Framework并不能轻松的将无服务器函数部署到不同云厂商的托管服务上,他只是帮助提供跨云厂商的统一工具链及相似的持续集成、部署等最佳实践流程。例如将一套函数从AWS迁移到Azure上,需要重新实现Azure provider下的配置,因为云厂商的托管无服务器服务和其他云资源都存在着大量差异。另外函数代码也需要面临改造,不同云厂商的触发器消息事件也都有不同的格式!这里可以考虑使用类似Spring Cloud Function这样的解决方案来实现跨云厂商的函数编写。
总之,Serverless Framework对于跨云厂商部署场景有一定生产效率的提升,但他离完美解决跨云厂商无服务器托管服务(各厂商服务天生不兼容)还有很远的距离,也许这个思路就是走不通的😕。