Cloud Computing - Serverless
Serverless vs Container
Serverless 是云计算中
资源抽象
的极致体现:用户专注于业务逻辑
,而无需关注基础设施
- Container
- 给予了用户很大的
定制
空间,按需对应用进行拆分和封装
- 给予了用户很大的
- Serverless
完全屏蔽
了计算资源,引导用户不再关注基础设施,只需遵循标准的方式编写业务代码即可更细
的拆分粒度- FaaS:将每一个具有
独立功能
的函数,作为一个单独的服务
进行部署和运行
- FaaS:将每一个具有
计费机制
- 底层没有
固化
的资源,一般会按照调用次数
和调用时长
来计费,可以精确到毫秒
- 从
成本
上,非常适合那些偶尔触发
、短时间运行
的工作负载
事件模型
事件模型是 Serverless 的
核心编程模型
和运行逻辑
,非常适合基于事件驱动
的开发场景
- 上游:
触发器
- Serverless 一般都会提供多种触发器:
API
触发器、OSS
触发器、MQ
触发器、定时
触发器等
- Serverless 一般都会提供多种触发器:
- 下游
- 在
函数内
访问其他云服务
(如 RDS、MQ 等外部存储
) Serverless Computing
本身是无状态
的,所有持久化
需求都需要借助外部存储
来实现
- 在
- 架构范式
FaaS
+MQ
:关注数据流
,是数据的传递
和流向
- 当 MQ 中有
新消息
进入,MQ 触发器
会触发云函数
,并将消息作为事件参数
传递给云函数 - 云函数进行及时处理,处理结果还能再进入另一个 MQ,进而触发另一个云函数
- 最终形成一个
流式数据
的处理管道
,实现数据的实时
处理和分发
- 当 MQ 中有
Workflow
:关注控制流
,定义事件发生的先后次序
和条件依赖
- 按照
业务逻辑
的控制处理流程,以工作流
的方式,进行云函数等事件处理单元
的组合
和编排
- 高层调度框架:用
配置文件
或者图形化
的方式,来设置一个复杂
的事件处理步骤和逻辑 - 工作流服务每次的运行都会自动维护一个
状态机
,用来记录和跟踪状态
- 按照
限制
- 客观限制:
冷启动
的延时、内存
的限制、云函数的运行时长
和并发上限
- 应用的
可迁移性
: 厂商绑定
All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.