开篇词 | 说来说去，到底Serverless要解决什么问题？
1、省钱省力 可减少运维资源成本以及学习成本
2、提高研发效能 前端可自己对数据接口编排，外包可快速迭代，降低容错，沉淀领域解决方案
3、解放生产力，激发创造力 前端可自由通过FaaS组合完成业务需求，大大激发前端创造力
4、后端应用BaaS化 通过FaaS的后端解决方案将后端服务BaaS化，让后端工程师更加专注领域设计
GMTC 分享资料
01｜定义：到底什么是Serverless？
- 第一种：狭义 Serverless（最常见）= Serverless computing 架构 = FaaS 架构 = Trigger（事件驱动）+ FaaS（函数即服务）+ BaaS（后端即服务，持久化或第三方服务）= FaaS + BaaS
- 函数即服务，它还有个名字叫作 Serverless Computing，它可以让我们随时随地创建、使用、销毁一个函数。
- BaaS 其实是一个集合，是指具备高可用性和弹性，而且免运维的后端服务
- 第二种：广义 Serverless = 服务端免运维 = 具备 Serverless 特性的云服务
- 无需用户关心服务端的事情（容错、容灾、安全验证、自动扩缩容、日志调试等等)。
- 按使用量（调用次数、时长等）付费，低费用和高性能并行，大多数场景下节省开支。
- 快速迭代 & 试错能力（多版本控制，灰度，CI&CD 等等）。
02 | 原理：通过一个案例，理解FaaS的运行逻辑
纯 FaaS 应用调用链路由函数触发器、函数服务和函数代码三部分组成，它们分别替代了传统服务端运维的负载均衡 & 反向代理，服务器 & 应用运行环境，应用代码部署。
对比传统应用托管 PaaS 平台，FaaS 应用最大的不同就是，FaaS 应用可以缩容到 0，在事件到来时极速启动，Node.js 的函数甚至可以做到 100ms 启动并执行。
FaaS 在设计上牺牲了用户的可控性和应用场景，来简化代码模型，并且通过分层结构进一步提升资源的利用率，这也是为什么 FaaS 冷启动时间能这么短的主要原因。关于 FaaS 的 3 层结构，你可以这么想象：容器层就像是 Windows 操作系统；Runtime 就像是 Windows 里面的播放器暴风影音；你的代码就像是放在 U 盘里的电影。
03 | 原理：FaaS的两种进程模型及应用场景
FaaS 进程模型
- 用完即毁型：函数实例准备好后，执行完函数就直接结束。这是 FaaS 最纯正的用法。
- 常驻进程型：函数实例准备好后，执行完函数不结束，而是返回继续等待下一次函数被调用。这里需要注意，即使 FaaS 是常驻进程型，如果一段时间没有事件触发，函数实例还是会被云服务商销毁。
应用场景
- 数据编排
BFF 层充当了中间胶水层的角色，粘合前后端。未经加工的数据，我们称为元数据 Raw Data，对于普通用户来说元数据几乎不可读。所以我们需要将有用的数据组合起来，并且加工数据，让数据具备价值。对于数据的组合和加工，我们称之为数据编排。
- SFF（Serverless For Frontend）
- BFF (Backend For Frontend)
- 服务编排
服务编排和数据编排很像，主要区别是对云服务商提供的各种服务进行组合和加工。
比如小程的“待办任务”Web 服务需要发送验证码邮件，我们可以用一个用完即毁型 FaaS 函数，调用云服务商的 SDK 发送邮件；再用一个常驻进程型 FaaS 函数生成随机字符串验证码，生成后记录这个验证码，并且调用发送邮件的 FaaS 将验证码发给用户邮箱；用户验证时，我们再调用常驻进程型 FaaS 的方法校验验证码是否正确。
04 | 原理：FaaS应用如何才能快速扩缩容？
纵向扩缩容与横向扩缩容
纵向扩缩容：增加或减少单机性能就是纵向扩缩容，纵向扩缩容随着性能提升成本曲线会陡增，通常我们采用时要慎重考虑。
横向扩缩容：增加或减少机器数量就是横向扩缩容，横向扩缩容成本更加可控，也是我们最常用的默认扩缩容方式
Stateful VS Stateless
Stateful 就是有状态的节点，Stateful 节点用来保存状态，也就是存储数据，因此 Stateful 节点我们需要额外关注，需要保障稳定性，不能轻易改动。例如通常数据库都会采用主 - 从结构，当主节点出问题时，我们立即切换到从节点，让 Stateful 节点整体继续提供服务。
Stateless 就是无状态的节点，Stateless 不存储任何状态，或者只能短暂存储不可靠的部分数据
若有收获，就点个赞吧
0 人点赞
