Serverless 基础知识

云计算技术的发展，使得用户只需要关注当前需要的底层资源，通过云基础设施可以自动完成资源的供给和伸缩；通过 Kubernetes、Mesos 等资源调度和编排平台对业务屏蔽了集群和机器资源管理的复杂度，不仅提高了资源的利用率，也通过为用户提供完善的环境管理和资源管理平台，提高了业务效率。但在这种使用场景下，用户仍然需要预估需要的资源，并在云平台上预先进行分配，而不管这些资源是否会被充分利用。因此对用户的容量预估和资源预估提出了很高的要求，如果预估和实际有很大偏差，就会导致很大的资源浪费，或者出现资源不足而影响业务使用，为了解决这个问题，Serverless 应运而生。

Serverless 中文可以翻译为“无服务器架构”，是最近几年兴起的一种新型架构理念，Serverless 不是指不需要服务器，主要是强调在 Serverless 下，业务不再需要固定的服务器资源，而是按需分配相应的服务资源。当业务请求比较多时，会多分配相应的服务实例；当业务请求比较少甚至为零时，可以不分配任何服务器资源。Serverless 架构和之前的架构相比，最大的差异是：业务服务不再是固定的常驻进程，而是真正按需启动和关闭的服务实例。因此 Serverless 架构可以提供如下两点优势。

（1）按需使用的资源管理 Serverless 架构下，容量规划成为历史，对一个业务进行准确的容量规划通常来说是特别有挑战性的事情，需要考虑的因素很多，通过 Serverless 的即需即用，不再需要容量规划，减少了业务架构和运维的复杂度。同时对于按需使用的资源管理，业务只需要为真正使用的部分付费，从而减少了不必要的资源浪费。

（2）简化业务运维复杂度在微服务架构下，微服务由各个功能模块，以及功能模块之间的通信组成，微服务开发者不仅需要关注业务功能，还要花费很多精力在完成不同微服务的交互和通信管理上。在 Serverless 架构下，你只需要实现具体的功能函数并提交给 Serverless，各功能函数之间的交互由 Serverless 接管，开发者不再需要关注功能函数交互的细节。

在简化微服务管理复杂度上，Serverless 和 Service Mesh 的目标是一致的，都是将微服务通信和服务治理相关的非功能需求从业务中剥离，对于 Serverless 是交给 Serverless 框架负责处理，对于 Service Mesh 是下沉到底层，成为通信基础设施的一部分。

在 Serverless 中，按需执行的代码片断称为“函数”，它是 Serverless 资源管理和调度的基本单位，因此 Serverless 有时也被称为 FaaS（Function As A Service，函数即服务）。Serverless 架构大体由如下几个部分组成。

（1）函数管理 Serverless 需要对用户编写的函数进行管理，通过一定的方式将用户函数变成可调度、可运行的实例。为了支持多个语言的 Serverless 函数，函数管理需要针对每种语言定义函数规范和标准，提供相应的实现机制。

（2）事件触发器事件驱动是 Serverless 非常重要的组成部分，Serverless 一般会定义一组关注的事件类型，并提供相应的事件触发和订阅框架，函数需要实现注册好关注的事件类型，事件触发时，Serverless 框架查找关注这个事件的函数，触发函数的具体执行。

（3）函数的路由和伸缩管理在很多 Serverless 实现中，函数的访问和路由一般由 API 网关来负责，API 网关根据相应的路由规则，找到相应的服务实例进行访问。在伸缩管理方面，监控函数当前的请求和资源。如果资源过多，则进行相应的资源回收；若资源不够，则增加相应的资源实例。

在 Serverless 中，函数实例按需创建运行，按需伸缩调整，函数实例必须特别轻量，能够快速启动，快速关停，Serverless 也需要提供完善的机制，支持函数实例的快速启动。当前 Serverless 在快速启动方面还没有很好的解决方案，快速启动的程度决定了 Serverless 的应用范围和应用场景，在很多场景下，如果没有快速启动的支撑，Serverless 很难应用起来。