1.1.3 工作原理
作为云时代新的计算范式，Serverless架构本身属于一种天然的分布式架构，其工作原理与传统架构虽没有翻天覆地的变化，但也是有细微的不同。
如下图所示，传统架构下，开发者开发完成应用之后，还需要购买虚拟机服务，初始运行环境，安装需要的软件（例如MySQL等数据库软件，Nginx等服务器软件等），完成环境的准备之后，还需要上传开发好的业务代码，启动该应用，此时用户才可以通过网络请求，成功的访问到目标应用。此时，如果应用的请求量过大或者过小时，开发者或运维人员，还需要针对实际的请求数量进行相关资源的扩充或缩容，并在负载均衡&反向代理模块增加相对应的策略，以确保扩缩容操作的及时生效，当然，在做这些操作的时候还要保证线上用户不会受到影响。
而在Serverless架构下，整个应用发布的过程和工作的原理，将会发生一定的变化：
如上图所示，当开发者开发完整业务代码之后，只需要部署或更新到对应的FaaS平台即可，完成之后根据真实的业务需求，进行相关的触发器配置，例如为了对外提供Web应用服务，可以配置HTTP触发器等，此时用户就可以通过网络，访问到开发者所发布的应用。在这个过程中，开发者不需要再额外关注服务器的购买，运维等相关的操作，也无需对一些软件的安装，应用资源的扩缩容进行额外的精力支出，开发者所需要关注的仅仅是自身的业务逻辑，至于在传统架构下需要安装配的各种服务器软件等，均变成配置项交给云厂商来管理，同样，传统架构下需要根据服务器的利用进行资源的扩缩行为，也全都自动化的交给云厂商来实现。
在整个Serverless工作的流程中，不难发现FaaS平台实际上会作为计算资源，承载着诸多核心能力，包括不限于执行开发者的业务代码，自动进行资源的扩缩等操作，那么Serverless架构中的FaaS平台是什么样子的呢？通常情况下一个简化的Faas系统分为APIServer，Scheduler，ResourceManager，NodeService，ContainerService一共有5个组件。
如上图所示：
APIServer往往对外暴露整体能力的API服务，例如invokeFunction的功能等；
Scheduler模块用于管理系统的Container，例如APIServer通过Scheduler获得可以执行Function的Container；
ResourceManager模块用来管理系统里的Node，负责申请和释放，可以认为Node对应于虚拟机，占用虚拟机需要一定的成本，因此Scheduler的一个目标是如何最大化的利用Node，比如尽量创建足够多的Container，不用的Node应该尽快释放。当然申请和释放Node又需要一定的时间，造成延迟增加，Scheduler需要平衡延迟和资源使用时间；
NodeService管理单个Node上创建和销毁Container，Node可以认为是一个虚拟机，Scheduler可以在Node上创建用于执行Function的Container；
ContainerService用于执行函数；
正是这些组件或者模块的联动，才得以让FaaS平台可以为应用提供更为稳定、安全，性能更高的技术支持；对FaaS平台的组成结构有了初步了解之后，可以进一步探索一下FaaS平台的工作流程。
如上图所示，当开发者把代码和配置交付到FaaS平台之后，FaaS平台并不会按照用户的预定配置进行资源的分配，而是会将这一部分的内容进行持久化。只有请求到来时，FaaS平台才会根据真实流量进行资源的分配。从FaaS平台接受到函数调用或者被触发的请求时，到函数正式执行并反馈最终结果，粗略的可以认为是两个过程。
容器&Runtime准备阶段：这个阶段主要是进行相关的资源准备，例如某些计算资源的准备，某些网络资源的准备等，准备好这些资源之后，系统会根据用户的函数进行相对应的代码的下载，然后在进行实例的启动；这个过程通常也可以认为是冷启动的过程；
函数执行阶段：函数执行阶段指的是实例启动之后，函数代码进行初始化以及指定方法执行的过程。当然，在某些开发者眼中，或者某些平台的定义中，代码初始化的过程往往也会被算作是资源准备阶段；
当函数执行完成之后，返回了结果之后，就意味着本次触发已经完成。此时函启动的实例通常会有三种处理方案：
实例会被搁置一段时间，如果搁置的这段时间内，没有被分配处理新的触发请求，实例会被释放掉；
实例会被搁置一段时间，但是在搁置的这段时间内，被分配处理新的触发请求，此时实例会处理新的触发请求；
实例由于一些特殊的配置，被标记为长期活跃实例，即使被搁置很久（超过释放的时间阈值）也不会被释放；
通过上面所表述的三种处理方法，不难发现实例是可能存在被复用的情况，所以函数在被触发的时候，通常也可能会有两种可能：
当前时间段，并没有已经准备好且可以被利用的实例（例如函数的首次调用/触发），此时FaaS平台会全新启动实例，包括容器&Runtime准备以及函数执行等；
当前阶段，有已经准备好且可以被利用的实例（例如上述函数执行完成的三种情况中的2，3情况），此时FaaS平台会优先复用已存在的实例，以避免再次进行容器&Runtime准备而浪费时间，提升请求效率，降低请求时延；
由此也可见，Serverless架构之所以被认为是天然分布式架构，其原因是Serverless架构的模型实现，是请求级别的隔离，可以认为每次请求都可能会出现一个实例（部分厂商提供的单实例多病发的情况除外），即同一时间段的请求数量会和实例数量成正相关。
除此之外，还值得注意的是，Serverless应用是由事件驱动的，即FaaS平台中的函数是由事件触发的，事件的产生者按照某些规范描述不同的事件，并以参数的形式在调用函数指定方法时，传递给函数。所以事件生态也是影响Serverless架构应用领域、应用场景的重要影响因素。
如上图所示，按照CNCF白皮书中的规范，FaaS平台可以根据不同的用例从不同的事件源调用函数，例如：
同步请求（Req / Rep），例如HTTP请求，gRPC调用
客户发出请求并等待立即响应。
异步消息队列请求（发布/订阅），例如RabbitMQ，AWS SNS，MQTT，电子邮件，对象（S3）更改，计划事件（如CRON作业）
消息发布到交换机并分发给订阅者；
没有严格的消息排序，以单次处理为粒度。
消息/记录流：例如Kafka，AWS Kinesis，AWS DynamoDB Streams，数据库CDC一组有序的消息/记录（必须按顺序处理）；
通常，每个分片使用单个工作程序（分片消费者）将流分片为多个分区/分片；
可以从消息，数据库更新（日志）或文件（例如CSV，Json，Parquet）生成流；
事件可以推送到函数运行时或由函数运行时拉动。
批量作业，例如ETL作业，分布式机器学习，HPC模拟
作业被调度或提交到队列，并在运行时使用并行的多个函数实例进行处理，每个函数实例处理工作集的一个或多个部分（任务）
当所有并行工作程序成功完成所有计算任务时，作业完成
综上所述，将Serverless架构工作原理用一张图完整表示，可参考下图：
