Serverless

Serverless 是一种云计算模型，它的核心理念是开发者无需关心底层的服务器和基础设施管理，只需专注于编写和部署代码。

开发流程

在 Serverless 中，开发者编写函数（通常是按照一定规则的代码），将这些函数上传到 Serverless 平台，然后平台负责执行这些函数，并在有请求时动态地分配资源运行代码

函数编写： 开发者编写自己的业务逻辑代码，通常是一个独立的函数，用于执行特定的任务或处理特定的请求。

函数打包： 将函数和其依赖项打包成一个可执行的单元。对于不同的 Serverless平台，打包方式可能有所不同，但通常包括将代码和依赖项打包成一个压缩文件。

函数上传： 将打包好的函数上传到 Serverless 平台，这个平台可能是 AWS Lambda、Azure Functions、Google Cloud Functions 或其他 Serverless 提供商的平台。

触发器配置： 配置触发器，定义函数应该在何时执行。触发器可以是 HTTP 请求、定时任务、消息队列中的消息等。当触发条件满足时，平台会自动调用相应的函数。

动态分配资源： 在有请求触发函数执行时，Serverless 平台会动态地分配资源（例如计算资源、内存等）来运行函数。这种按需分配资源的特性是 Serverless 的一大优势，因为它使得开发者无需关心底层的服务器和资源管理。

执行函数： 平台运行函数代码，执行业务逻辑，处理请求或事件。

返回结果： 函数执行完成后，平台将结果返回给调用者。这可以是 HTTP 响应、消息队列中的消息，或者其他形式的结果。

资源释放： 在函数执行完成后，平台可能会释放分配给函数的资源，确保资源的高效使用。

优劣点

在 Serverless 架构中，开发者无需预先购买或租赁服务器，也不需要处理服务器的配置、维护、扩展等操作，所有这些工作都由云服务提供商负责。

其优点包括：

• 无服务器运维，不需要关心服务器问题和基础设施,让开发者只关注业务代码
• 弹性扩展，系统会自动scale,无需人工干预, Both vertically 和 horizontally.
• 按用量付费，只需要为实际消耗的资源和执行时间付钱,无需为可能用不到的资源买单。

当然，Serverless架构也有一些缺陷需要注意:

• 调试困难: 传统方式的debug在无服务器环境下不可用,本地模拟调试可能会与实际环境有差异。
• 供应商锁定: 代码和业务逻辑可能会对特定的FaaS供应商有较强依赖性和锁定性，这导致业务代码可能不太容易迁移到其他的供应商
• 冷启动问题:当一个函数长时间未被调用时,可能会因为环境未初始化而导致第一次执行延迟较高。
• 性能不确定性: 执行环境、启动时间和并发度都可能影响函数的整体性能。
• 状态管理困难: 由于函数拥有写状态的能力可能引起一些问题。
• 超时限制: 大多 FaaS 平台对函数执行时间有严格限制(比如5分钟),对长时间运行任务不友好。
• 高并发限制: FaaS 平台通常会对账号下函数并发执行数量设置默认配额,限制相对较多的并发。
• 资源访问限制: 函数无法直接访问本地文件系统、网络等资源。
• 计费复杂: 按执行时间和资源使用量计费可能会很难预估成本或做成本优化。

所以 Serverless 更适合优势明显的事件驱动应用,而对长时间执行的任务以及需要连接外部资源的任务则不太适合。