Serverle 实践总结和未来展望
学习 Serverless 开发结果测试题
1.下面关于 Serverless 定义的说法错误的是?
A Serverless 不需要服务器
B Serverless 是指构建和运行软件时不需要关心服务器的一种架构思想
C 目前 Serverless 的主流实现是 FaaS+ BaaS
D Serverless 是云原生的一种实现
2.一个应用如果是 Serverless 架构的,必须要实现自动弹性伸缩和按量付费。
A 正确
B 错误
3.(多选)下面哪些选项是 Serverless 应用的特点?
A 自动弹性伸缩
B 按量付费
C 事件驱动
D 运维成本高
4.Serverless 只能用来开发无状态的应用,不能用来开发有状态的应用。
A 正确
B 错误
5.下面关于 Serverless 函数启动过程说法错误的是?
A 函数启动过程分为冷启动和热启动
B 冷启动耗时较长,热启动耗时很短
C 热启动时函数会重复利用上一次的执行上下文 D 函数每次执行都需要经过冷启动
6.函数的启动过程包含下载代码、启动容器、启动运行环境、执行代码四个步骤前三个步骤为冷启动,最后一个步骤为热启动。
A 正确
B 错误
7.运行 Serverless 函数代码的 FaaS 平台通常是容器技术实现运行环境隔离的。
A 正确
B 错误
8.不同 FaaS 平台的触发器和入口函数定义是完全一致的
A 正确
B 错误
9.Serverless 应用的代码依赖和系统依赖都需要安装在项目中,并和应用代码一起部署到 FaaS 平台。
A 正确
B 错误
10FaaS 平台的自定义运行时本质上是实现一个自定义的 HTTP 服务
- A 正确
- B 错误
11 下面哪个关于 Serverless 应用单元测试的描述是错误的?
A Serverless 应用由于其分布式、依赖云服务、事件驱动等特性,导致编写单元测试很困难
B 为了方便编写单元测试,需要将业务逻辑和依赖的云服务分离开来
C 编写单元测试时,需要考虑速度、隔离性、单一职责等因素,避免单元测试成为开发的负担
D 为了代码快速上线,我们可以不编写单元测试
12.(多选)下面哪些方案可以提升 Serverless 应用的性能?
A 提前给函数预热
B 减小代码体积、减少不必要的依赖
C 选择 Node.is、Python 等冷启动耗时短的编程语言
D 为函数设置合适的内存和并发
13.(多选)下面关于在 Serverless 应用中使用访问控制说法正确的是?
A 云厂商主要通过主账号、角色、权限策略等方式来实现云上资源的访问控制
B 通过访问控制,我们能实现分权、云服务授权、跨账号授权等云上资源管控需求
C 为了安全,我们需要为函数设置最小的权限
D 为了方便,我们可以给直接给函数设置尽可能大的权限
14.(多选)下面关于 Serverless 应用安全的说法正确的是?
A 在云上运行的应用,云厂商负责计算、网络、存储等底层资源的安全性,应用所有者负责应用本身的安全性 B Serverless 安全性面临的主要挑战是:越来越多的攻击面、越来越复杂的攻击方式、可观测性不足,以及传统安全测试方法和防护方案不适用于 Serverless 架构
C Serverless 安全性的面临的风险有:函数事件数据注入、身份认证无效、用户或角色权限过高、敏感数据泄漏、DDoS 攻击等
D Serverless 应用无须运维,所以 Serverless 应用很安全,不需要我们关心
15.(多选)下面哪些方案可以提升 Serverless 应用的安全性?
A 对于提供 API 服务的 Serverless 应用,使用 API 网关代替 HTTP 触发器
B 在代码中尽可能使用临时访问凭证
C 对存储在云上和需要传输的数据进行加密
D 使用日志服务等产品统一记录函数执行的日志
16.(多选)下面哪些方案可以节省 Serverless 应用的成本?
A 为函数设置超时时间,避免函数因为异常而无限制地运行下去
B 为函数分配合适的内存,在不影响性能的情况下减少资源消耗
C 为函数实例设置合适的并发,使多个请求共用一个实例
D 提升函数的性能
17.Serverless 应用的成本包括 FaaS 中函数执行的成本,以及函数所依赖的触发器、数据源和 BaaS 服务的成本。
A 正确
B 错误
18.(多选)下面关于传统应用迁移到 Serverless 架构的说法正确的是?
A 传统应用迁移到 Serverless,想要考虑内存缓存、身份认证、持久化存储、Web 服务 Serverless 化等改造点
B 如果一个应用本身就是分布式部署的,且在架构上是计算和存储分离的,比较容易迁移到 Serverless
C Web 服务 Serverless 化主要原理是实现一个自定义 HTTP 服务,通过该 HTTP 服务处理事件对象和 Web 请求的差异 D 传统应用不需要改造就可以直接迁移到 Serverless
19.Serverless 应用中的函数是无状态的,所以传统的 Cookie-Session、JWT 等身份认证方案都不适用于 Serverless?
A 正确
B 错误
20.将可以执行文件(如 ffmpeg)部署到函数计算时,如果可执行文件在本地权限是
-rwxr-xr--
,我们可以直接将其上传到函数计算平台,并在代码中使用。A 正确
B 错误
答案:
未来展望:Serverle 掀起新的前后端技术变革
Serverless 将对前后端开发带来什么影响?
答:
未来 Serverless 将会带来哪些机会?
答:略
Serverless 开发框架将百花齐放
- 传统的开发框架主要是面向技术问题提升开发效率---单机资源
- 云服务:Serverless 开发框架,除了解决技术问题还需要解决应用开发、部署、监控、运维等问题
Serverless 开发框架主要包含几个部分
- 开发工具,比如命令行工具、编辑器插件、WebIDE 等
- 部署工具,比如与 Git 集成、CI/CD 等
- 监控运维工具,实现日志、报警等功能
Serverless 第三方的开发框架
- serverless:
- MIDWAY:
- malagu:
传统 LAMP:LAMP 架构可以很方便构建动态网站但随着用户增多流量增大服务端所需要的资源也就越来越多
Serverless Jamstack:Jamstack 则是为了构建更快、更安全且更易于扩展的 Web 系统而诞生的
- Jamstack:
- Jam 的 J 代表:JavaScript Jam 的 a 代表:APIs Jam 的 m 代表:Markup
- 有了 Serverless 之后,我们可以将 API 也托管到 Serverless 上这样整个 Web 系统就完全不依赖服务器,也更易于扩展
Serverless Kubernetes:业界容器编排的事实标准
以下云厂商都发布了相关产品
- AWS
- 阿里云
- Knative
- OpenFaaS
- Fission
- Kubeless
随着技术上对去中心化、轻量虚拟化、细粒度计算等需求愈发强烈 Serverless 也必将借势迅速发展,带来一场新的技术变革
Serverless 实践经验
提升开发质量,让应用代码更 Serverless 化
1.使用代码描述基础设施
在使用 Serverless 时,经常会用到很多云服务
建议用代码的方式描述这些资源,这样当代码更新时也能同步更新云资源基础设施即代码 (Infrastructure as Code, laC)
AWSSAM 和阿里云资源编排
- 如果业务中使用多云,建议用 terraform
- 如果主要用国内的云,使用资源编排更方便
2.将业务逻辑抽离到入口函数之外
在入口函数中只应该处理函数参数,不应该处理业务逻辑
3.函数单一职责
每个函数只负责一件事情,这样才更方便扩展
建议:函数职责单一后,方便对其编写单源测试
4.函数不能调用其他函数
很多经验不足的同学经常在一个函数中调用另一个函数,这样做会让函数执行成本翻倍,还会导致函数间逻辑耦合
建议:如果两个函数需要通信建议使用消息队列或事件总线等方案
5.为异步函数设置调用目标
异步函数执行过程是异步的,无法立即知道执行结果所以要为异步函数设置异步调用目标
建议:函数的异步调用以及调用目标
6.编写详细的测试用例
测试是保障应用质量和稳定性的重要手段
建议:为应用编写详细的单元测试和集成测试
7.避免使用基于连接的服务
基于连接的服务主要是 RDS 数据库等;建立连接会带来额外的冷启动耗时,并且要在内存中维护连接池
建议:Serverless 应用由于无状态的特点,并不适合使用连接
提升应用性能
1.为函数设置合适的内存大小
到达某个闯值后,内存增长就不会再带来性能的增长了随着内存增加,代码执行所消耗的成本也是线性增加的
建议:通过链路追踪或一些开源产品分析函数性能并找到最佳内存
2.选择合适的编程语言
Node.js、Python 等解释型语言会比 Java、.NET 等编译型语言性能更好函数执行时间越长,成本也越高
建议:
- 如果应用对延迟非常敏感,容易引发频繁的冷启动建议选择解释型语言
- 如果应用对性能要求不高,也没有流量波峰波谷建议选择最熟悉的编程语言
3.优化代码
影响函数性能的因素主要有冷启动和代码逻辑及其依赖
建议:主要就是利用容器重用,最大程度减少冷启动与代码初始化耗时:
- 1.初始化后,将代码中引用到的任何外部配置或依赖性存储下来;
- 2.减少每次调用时变量、对象的重新初始化
4.使用链路追踪分析应用性能
为了了解应用中各个组件的性能使用链路追踪去分析应用的性能
建议:如果没有定制化需求比较推荐直接使用云厂商提供的链路追踪云服务
5.减小代码的体积
代码体积越小,冷启动耗时越短,函数性能越高
建议:精简代码体积,尤其是精简依赖的大小要避免部署不必要的依赖
增强系统稳定性
对线上应用来说,稳定性甚至比性能更重要
1.通过多地域部署实现多地域容灾
如果应用对可用性要求很高,可以多地域部署应用应用也可能因法律合规要求,必须多地域部署
建议:多地域部署的复杂性,主要在于函数以及依赖的各种云服务都要多地域部署,建议用 laC 的方式来管理云上资源
2.通过多可用区实现单地域高可用
一个地域通常会有多个可用区
建议:在 VPC 内的函数,如果要实现高可用建议为函数指定多个不同可用区的交换机
3.使用日志服务记录应用日志
日志是我们监控应用运行状态和排查问题的重要依据 Serverless 应用屏蔽了服务器所以就要使用云厂商提供的日志服务来集中记录应用日志
建议:对于 RestfulAPl,建议针对每个请求和响应都打印日志,这样更方便排查问题
4.设定应用指标和监控
建议:Serverless 应用的指标还包括函数调用次数、执行时间、代码出错次数等需要为这些指标设置监控报警
保障应用安全
如何提升 Serverless 应用的安全性
1.不要相信任何用户输入
2.正确地处理程序异常
3.对云上敏感数据进行加密
4.为用户和角色配置最小的权限
5.为函数设置最小执行权限
6.在代码中使用临时访问凭证
7.记录云上操作及资源变化
优化应用成本
在进行技术选型时,除了要考虑开发效率、应用性能、稳定性和安全性几个方面还要考虑技术成本
1.提升函数性能
Serverless 应用是按执行次数和执行时消耗的内存等资源计费因此函数性能越高,执行时间越短,成本也就越低
2.为函数设置超时时间
为了避免函数因异常而无限运行,所以要为函数设置超时时间
为函数设置合适的超时时间,可以避免产生不必要的费用
3.选择合适的云服务
Serverless 应用往往依赖很多云服务
根据你的应用需求,使用不同云服务的架构总成本,要综合考虑应用需求与成本
4.选择合适的计费方式
通常 FaaS 平台的付费方式有按量付费和预付费。按量付费就是按实际函数执行次数和消耗的资源计费。预付费则与传统付费方式类似,预先支付费用购买资源生成函数实例
5.关注 FaaS 和 BaaS 等云服务的总成本
对 Serverless 应用进行成本分析很容易陷入的误区:就是只考虑了 FaaS 的成本而忽略了 BaaS 的成本