#serverless
杨凯 中国工信出版集团
大纲#
- 综述颠覆性影响、理解 sls 和目前技术的定位关系
- FaaS 是 Serverless 核心思想的实际应用技术
- BaaS 是 sls 的另一大分值体系
概述#
#cloudnative 云原生被提到最多的概念就是 serverless 了
sls 的概念、sls 的开发理念、极低的运维成本、大幅下降的服务器费用
举例 github pages，开发者把文件部署为静态站点，分配域名、访问服务。屏蔽了很多细节。
举例 CDN，无需关注细节、节点，全球用户高速访问。
可以认为把计算资源作为服务的方式提供产品，复合 serverless 理念，屏蔽技术细节，对外提供服务。
CNCF 在 2018 年发布了 serverless 白皮书
sls 是指无论在应用的构建还是运行，都不用对服务器进行维护和管理
sls 计算平台应该包含一种或者两种能力 faas baas
接下来介绍，使用场景，优势劣势
faas 的优势：研发效率搞、部署成本低、运维成本低、学习成本低、服务器费用低、部署方案灵活、系统安全性高
劣势：平台学习成本高、调试成本高（运行时在云端，本地调试、日志查询困难）、冷启动、供应商锁定
使用场景：
- 函数本身无状态，和持久化服务器融合
- 函数独立工作，彼此大量函数联动计算费用会上升
- 自动伸缩
- 事件驱动，http、数据库修改、定时事件等
- 冷启动要求低的场景
faas 本身不支持 http 协议，所以需要通过 api gateway 对外提供 web api
sls 和服务端技术#
单体应用 - 分层架构，UI 层、业务逻辑层 Business Logic Layer、数据访问层 Data Access Layer
三层架构的基础上，比如 企业应用架构模式、领域驱动设计两本书，进一步区分
- 应用层
- 领域层
- 持久层
- 基础设施层
还是分层的思路，对代码切分，达到关注点分离 Separation of concerns SOC 的目标。
我能不能抽离 登录、权限判断等逻辑，从而在不同业务之间进行复用
微服务 microservices 架构风格，从分布式架构演变而来。多个独立小型服务进行轻量 、可控的软件研发管理。服务之间通过 RPC 实现相互通信，这样各个服务就可以是哟给你不同的技术栈完成功能。
设计系统的架构受制于组织的沟通结构。康威定律。什么样的组织架构，就设计出什么样的架构。比如小公司，单体应用，规模扩大，新增人员需要重新熟悉整体内容，这是网状结构，彼此都需要同步信息，沟通成本指数级增加。
单体拆分为微服务，只关注自己的业务，屏蔽不必要的信息，降低沟通成本
容器化、云计算、noops- devops 的下一阶段，减少研发人在运维的投入，是一种理念。
sls 和前端技术#
bff，后端服务于前端。在前端和后端之间做胶水层，做信息的聚合和裁剪。一个接口完成多个接口的操作。移出不需要的字段等。
这让接口更加灵活。沟通成本低。减少请求做性能优化、减少数据暴露做安全性
graphQL 在多语言的微服务架构下不容易应用，改造成本太高，目前没有太多跨语言。跨数据库统一实现聚合查询的能力。如果与 serverless 结合才有可能
FaaS 技术#
事件驱动。是一种设计模型。
faas 函数同样是事件驱动，不同的 trigger 触发器作为事件源。比如 http 触发器
函数无状态足够简单。
创建函数。里面有很多技术细节，现在改版多次了已经。
- 运行时选择
- 默认的
- 自定义运行时，这种兼容性最高
- 自定义容器，比如 GPU 容器
- 基本信息，名称、区域、触发器事件和 http
- 代码上传
- 示例 demo
- zip 包压缩
- oss 上传
- 文件夹上传
- 规格设计
- cpu 0.05~16g
- 内存 128M ~ 32 G
- 临时硬盘 512M、10G
- 如果选择容器部署，还可以选择 GPU T4/A10 规格
- 实例并发度。同时处理多少个请求
- 超时时间 60s
- 时区
- 鉴权认证
- 签名
- jwt
2015 年，开源社区出现了 serverless framework，目标是成为 sls 的框架和生态系统，解决供应商锁定的问题。
编写细节忽略
7 函数生命周期#
module.exports.handler = function (request, response, context) {
// code
(async () => {
response.setStatusCode(200);
response.setHeader('content-type', contentType);
response.send(fs.readFileSync(path))
})().catch(err => {
response.setStatusCode(500);
response.setHeader('content-type', 'text/plain');
response.send(err.message);
});
}
8 理解函数运行时#
设计模式 23 种设计模式
消息队列，能解决高并发的问题，也能实现系统解耦。削峰填谷。保证信息按顺序接受。
突然想到 信息触发的方案，站内信、短信、微信推送等。
9 自建简易 FaaS#
要保证各函数的安全性，避免互相打扰，隔离的关键技术是沙箱 Sandbox
- 使用 docker 隔离
- 使用进程隔离，不如 docker
使用 master 监听函数调用，启用子进程 child 执行函数。返回的结果通信给主进程。
这里使用 child_process.fork() 启动子进程实现隔离。
如果执行代码可以用 eval/Function 来比较，最佳的方案还是 node 的 new vm.Script(code) 方案
但 vm 也会有风险，举例 this.constructor.construcotr
原型链的设计，所以没有原型链就好了
const sandbox = Object.create(null)
vm.createContext(sandbox)
vm.runInContext(code,sanbox)
但是也不完美，社区中使用 vm2 ，通过 proxy 特性进行封装，更加安全。
因此，运行时使用 vm2 和 child_process.fork 组合使用，可以实现隔离和用户代码执行。
实现 http 协议支持，可以使用 koa 来实现。动态下载函数并执行。。
简易版完成，但还需要考虑吞吐性能、安全稳定、开发效率。
每次执行都会创建 子进程来执行，这个进城的创建和销毁管理是性能开销，高并发时候过多的进城也可能导致崩溃，这就考虑 进程池了。
可以使用 cluster，对 child_process 的进一步抽象封装，用起来更好用。
使用 cluster 和 vm2 配合 koa 就能实现一个方案了。
问了 gpt，
可以考虑 generic-pool：这个模块提供了一个通用的资源池，可以用于管理各种资源，包括进程。你可以使用它来创建一个进程池，从而避免频繁地启动和停止子进程。它提供了灵活的配置选项，允许你自定义池的大小、资源分配策略等。
用户代码如果用了死循环，就无法结束任务了。设定超时时间。 vm/vm2 都有 timeout 比如设置 5000ms
异步调用问题，默认的超时不起作用，可以考虑自行实现计时器
确保稳定性，资源限制。cpu、内存、磁盘的高强度使用。要限制资源，在 Linux 里有 CGroup 限制资源，docker 里也用到了这个能力。
介绍了一堆 CGroup 的概念，略过细节，通过命令就可以限制某个进程最多使用 20% 的 cpu 资源了。有点复杂，gpt 答的挺好
提高效率，内置前端常用服务。
- 简单的 kv 存储，使用 vm2 实现 get/set
当然，最好还是 redis
BaaS 技术#
backend as a service。
![[Pasted image 20230923233047.png]]
后续提到了 firebase 一展示提供了很多开箱机用的基础服务，比如云数据库、云函数、auth、托管、存储等。
还有崩溃报告、性能监控、test lab、应用分发等功能。
还有拓展类的运营功能
- 应用内消息 in-app messaging
- 分析
- a/b testing
- cloud messaging 云消息，推送 IM 等
- remote config 配置中心
国内的 leancloud/bmob 等，整体完整性还有差距。
数据库设计原则部分。
比如 posts 和 comments 两张表查询，会有 select 1+n 的问题，也就是需要先查询 n 条记录找到信息，再查询 n 次对应的数据。sql 中使用 join 就行
举个例子，最近五条评论的内容，所属文章标题。
使用 sql 比较简单。如果提前设计成嵌入的方案就容易。如果已经变成引用的方案了，可能需要保留更多冗余内容。设定一个新集合，最新评论的集合，冗余字段。如果有读写问题，就可以改成缓存，一小时更新一次。这带来的问题是，删除时候需要同步删除多份。
如果使用内嵌，一次查询就可以了，而且查询性能好。对于嵌套的复杂数据就不好了。先把数据聚合再排序，实现也是放入内存中，大量数据可能就不好。
快速介绍了 CDN、对象存储等功能
用户鉴权介绍了 OneID 不流行的趋势，介绍了 OAuth 2.0
最终纳入了 IETF 组织，实现了标准化。
oauth2 里提供了四中授权模式
- 授权码 auth code，默认
- 简化模式
- 密码
- 客户端凭证
后面三种比较特殊，不用管
OAuth 解决的是授权，不是用户认证，引入了 OIDC - openID Connect
进一步拆分了 id token 和 access token
jwt 是 rfc 7519
对接第三方会比较费劲，就产生了 IDaaS 比如 auth0 网站和 authing 网站
- 身份认证 账户授权
- sso single sign in 一个应用登录，多个应用共享
- 对外提供 oauth2
- 统一发送邮件、短信重置密码
- 企业身份登录
- 两步验证
可以看看，有一些 user/rule/rules/hooks 等
没了。
总结展望#
第二部分比较精彩，其他一般。