一、自我介绍
1.讲师简介
- Serverless Framework 社区专家;
- 腾讯云 Serverless 系列课程特约讲师;
- 参与 Serverless 社区及开源的相关工作;
- 拥有丰富前端、JavaScript 技术经验、网站和小程序等项目开发经验。
二、分享目录
三、入门:3分钟快速构建部署一个 Node 应用(Egg + Serverless)
1.准备 Egg 项目
1.1 初始化 Egg 项目
$ mkdir serverless-egg && cd serverless-egg
$ npm init egg src --type=simple
$ cd src && npm install
1.2 修改 Egg 配置
由于云函数在执行时,只有 /tmp
可读写的,所以我们需要将 egg.js
框架运行尝试的日志写到该目录下,为此需要修改 config/config.default.js
中的配置如下:
const config = (exports = {
rundir: '/tmp',
logger: {
dir: '/tmp'
}
})
1.3 测试运行项目
npm run dev
2.安装 Serverless Framework
// 安装Serverless 框架
npm i -g serverless
3.配置 YAML
3.1 在 egg 项目根目录,新建 Serverless 配置文件 serverless.yml
# serverless.yml
org: orgDemo
app: appDemo
stage: dev
component: egg@0.0.0-dev
name: eggDemo
inputs:
src: ./src
region: ap-guangzhou
functionName: eggDemo
runtime: Nodejs10.15
apigatewayConf:
protocols:
- http
- https
environment: release
4.部署到腾讯云
- 部署命令:
sls deploy
- egg详细配置参考:https://github.com/serverless-components/tencent-egg/tree/v2
四、Serverless 架构规范
1.传统 - 前端场景处理模型典型结构
- 传统前端处理场景,服务器中可能涉及路由规则,鉴权逻辑以及其它各类复杂的业务代码;
- 开发团队要付出很大的精力在这个服务器的运维上面,包括客户量突然增多时是否需要扩容服务器?
- 服务器上的脚本,业务代码等是否还在健康运行?
- 是否有黑客在不断地对服务器发起攻击?
- 等一系列问题……
2.Serverless - 前端场景处理模型典型结构
- 在 Serverless 场景客户端和数据库未发生变的前提下,之前需要开发团队维护的路由模块以及鉴权模块都将接入服务商提供的 API 网关系统以及鉴权系统;
- 开发团队无须再维护这两部分的业务代码,只需要持续维护相关规则即可;
- 同时业务代码也被拆分成了函数粒度,不同函数表示不同的功能。
2.1 Serverless 架构模型
FaaS 与 PaaS 的概念在某些方面有许多相似的地方。人们甚至认为 FaaS 就是另一种形式的 PaaS。但是 Intent Media 的工程副总裁 Mike Roberts 有自己的不同看法:“Most PaaS applications are not geared towards bringing entire applications up and down in response to an event, whereas FaaS platforms do exactly this.”
FaaS 和 PaaS 在运维方面最大的差异在于缩放能力。对于大部分 PaaS 平台,用户依然需要考虑缩放。但是对于FaaS 应用,这种问题完全是透明的。就算将 PaaS 应用设置为自动缩放,依然无法在具体请求的层面上进行缩放,而 FaaS 应用在成本方面效益就高多了。AWS 云架构战略副总裁 Adrian Cockcroft 曾经针对两者的界定给出了一个简单的方法:“If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless.”
正是因为 Serverless 与 PaaS 的不同,与 FaaS 以及 BaaS 的关系,所以有人说 Serverless 真正实现了当初云计算的目标,更有人这样定义 Serverless:Serverless = BaaS + FaaS + … 诚然,这种说法未必是百分之一百准确的,就像 Martin Fowler 的一句话:“Like many trends in software, there’s no one clear view of what Serverless is.” 但是不可否认的一点是 Serverless 在很多层面,很多领域,越来越突出“期望中云计算”的样子了。
2.2 Serverless 处理模型
● Event Sources(事件源):将 Event 触发或流式传输到一个或多个函数实例中;
● Function Instance(函数实例):可以根据需要,将单个函数/微服务进行扩展;
● FaaS Controller(FaaS 控制器):部署,控制和监视函数实例及其来源;
● 平台服务:FaaS 解决方案使用的一般集群或云服务(有时称为后端即服务,或者 BaaS 等)。
2.3 Serverless 场景典型的工作流程
- Event State(事件状态):此状态允许等待来自事件源的事件,然后触发函数运行或多个函数按顺序、并行或者在分支中运行。
- Operation/Task State(操作/任务状态):此状态允许按顺序或并行运行一个或多个函数,而不等待任何事件。
- Switch/Choice State(切换/选择状态):此状态允许转换到多个其他状态(例如,前一个函数结果触发分支/转换到不同的下一个状态)。
- End/Stop State(结束/停止状态):此状态以失败/成功终止工作流。
- Pass State(通过状态):此状态在两个状态之间插入事件数据。
- Delay/Wait State(延迟/等待状态):此状态导致工作流执行延迟指定的持续时间或直到指定的时间/日期。
3.Serverless 函数架构规范
3.1 函数定义
- ID
- 名称
- 描述
- 标签
- 版本ID
- 函数处理程序
- 运行时语言
- 代码+依赖项
- 环境变量
- 其他 ……
3.2 元数据详情(Metadata Details)
- 版本
- 环境变量
- 执行角色
- 资源
- 超时
- 其他 ……
3.3 数据绑定
一些无服务器框架允许用户指定函数使用的输入/输出数据资源,这使开发人员开发的函数资源可以简化、提高性能(在执行之间保留数据连接,可以预取数据等)和获得更好的安全性(数据资源凭据是上下文的一部分,而不是代码)。
3.4 函数约束
函数和无服务器运行时应该满足的通用需求:
● 函数必须与不同事件类的底层实现分离;
● 可以从多个事件源调用 Function;
● 每个调用方法不需要不同的函数;
● 事件源可以调用多个函数;
● 函数可能需要一种机制来与底层平台服务进行持久绑定;
3.5 函数调用类型
可以根据不同的用例从不同的事件源调用函数,例如:
● 同步请求(Req / Rep),例如 HTTP 请求,gRPC 调用;
● 客户发出请求并等待立即响应;
● 异步消息队列请求(发布/订阅),例如 RabbitMQ,AWS SNS,MQTT,电子邮件,对象(S3)更改,计划事件(如 CRON 作业)
● 消息发布到交换机并分发给订阅者;
● 没有严格的消息排序,以单次处理为粒度。
● 消息/记录流:例如 Kafka,AWS Kinesis,AWS DynamoDB Streams,数据库 CDC;
● 一组有序的消息/记录(必须按顺序处理)
● 通常,每个分片使用单个工作程序(分片消费者)将流分片为多个分区/分片;
● 可以从消息,数据库更新(日志)或文件(例如 CSV,JSON,Parquet)生成流;
● 事件可以推送到函数运行时或由函数运行时拉动。
● 批量作业,例如 ETL 作业,分布式机器学习,HPC 模拟
● 作业被调度或提交到队列,并在运行时使用并行的多个函数实例进行处理,每个函数实例处理工作集的一个或多个部分(任务)。
不同类型的事件源包括:
● 事件和消息服务,例如:RabbitMQ,MQTT,SNS;
● 存储服务,例如:COS,CDB,PGSQL,Cognito,Google 云存储;
● 端点服务,例如:物联网,HTTP 网关,移动设备,Alexa;
● 配置存储库,例如:Git,CodeCommit;
● 使用特定于语言 SDK 的用户应用程序;
● 计划事件,定期启用函数调用。
虽然每个事件提供的数据可能在不同的事件源之间有所不同,但事件结构应该是通用的,能够封装关于事件源的特定信息。
五、Serverless 的事件与规范
1.什么是 CloudEvents?
1.1 简介
- CloudEvents 是一种规范,用于以通用格式描述事件数据,以提供跨服务、平台和系统的交互能力。
- 事件格式指定了如何使用某些编码格式来序列化 CloudEvent。
- 支持这些编码的兼容 CloudEvents 实现必须遵循在相应的事件格式中指定编码的规则。
- 所有实现都必须支持 JSON 格式。
1.2 CloudEvents 参考:
2.什么是 Serverless 的事件?
2.1 Event 简介
- 事件 (Event) 无处不在,然而每个事件源产生的事件各不相同。
- 由于缺乏事件的统一描述,对于事件的开发者来说,需要不断地重复学习如何消费不同类型的事件。
- 例如同一个厂商的 CMQ 产生的事件和 API 网关触发器产生的事件是不同的,不同厂商的 API 网关触发器产生的事件也可能是不同的。
2.2 Serverless 必须的事件属性 (REQUIRED attributes)
- ID:识别事件;
- Source:识别发生事件的上下文;
- Specversion:事件使用该版本的 cloudEvents 规范;
- Type:发生相关事件的类型值;
- Data:Data 的数据内容格式;
- Subject:事件开发者有关的事件上下文主题;
- Tiem:事件发生的事件。
六、Serverless 工程化的难点与挑战
1.不适合长时间运行应用
2.完全依赖于第三方服务
3.冷启动时间
3.1 冷启动时间对比图
3.2 冷启动基本方案
4.缺乏调试和开发工具
5.语言版本落后
5.1 Serverless 框架支持的语言版本
- Python 2.7
- Python 3.6
- Node.js 6.10
- Node.js 8.9
- Golang 1.8
- PHP 5.6
- PHP 7.2
- Java 8
- 更多 ……
七、Serverless 行业应用
1.他们都在用Serverless架构
2.Serverless 架构应用 - Component
2.1 社区组件
3.关于费用:超值免费额度
3.1 费用说明
- Serverless Framework 服务当前免费;
- 但该产品所用到的相关腾讯云产品将按照资源使用量进行收费(遵循各产品的计费规则);
- 通过免费额度构建 Serverless 应用,每年能节省(13.3+44.432+6)× 12 = 764.784 元,相当于 PV 3w 的站点免费用,24 个月的免费视频会员,或 10 次免费的机场贵宾厅。
3.2 关联产品免费额度
八、Serverless 学习资源分享
1.学习网站
1.1 中文技术社区
-
1.2 官网
-
1.3 Github
https://github.com/serverless-components
1.4 腾讯云文档
2.学习交流
2.1 订阅微信公众号
2.2 问题反馈小助手
2.3 交流QQ群
别忘了点下方送稻谷