Serverless架构基础详解(3)

举报
小云悠悠zZ 发表于 2023/01/24 13:58:13 2023/01/24
【摘要】 作为云时代新的计算范式,Serverless架构本身属于一种天然的分布式架构,其工作原理与传统架构虽没有翻天覆地的变化,但也是有细微的不同。

1.1.3 工作原理
作为云时代新的计算范式,Serverless架构本身属于一种天然的分布式架构,其工作原理与传统架构虽没有翻天覆地的变化,但也是有细微的不同。

如下图所示,传统架构下,开发者开发完成应用之后,还需要购买虚拟机服务,初始运行环境,安装需要的软件(例如MySQL等数据库软件,Nginx等服务器软件等),完成环境的准备之后,还需要上传开发好的业务代码,启动该应用,此时用户才可以通过网络请求,成功的访问到目标应用。此时,如果应用的请求量过大或者过小时,开发者或运维人员,还需要针对实际的请求数量进行相关资源的扩充或缩容,并在负载均衡&反向代理模块增加相对应的策略,以确保扩缩容操作的及时生效,当然,在做这些操作的时候还要保证线上用户不会受到影响。

image.png

而在Serverless架构下,整个应用发布的过程和工作的原理,将会发生一定的变化:

image.png

如上图所示,当开发者开发完整业务代码之后,只需要部署或更新到对应的FaaS平台即可,完成之后根据真实的业务需求,进行相关的触发器配置,例如为了对外提供Web应用服务,可以配置HTTP触发器等,此时用户就可以通过网络,访问到开发者所发布的应用。在这个过程中,开发者不需要再额外关注服务器的购买,运维等相关的操作,也无需对一些软件的安装,应用资源的扩缩容进行额外的精力支出,开发者所需要关注的仅仅是自身的业务逻辑,至于在传统架构下需要安装配的各种服务器软件等,均变成配置项交给云厂商来管理,同样,传统架构下需要根据服务器的利用进行资源的扩缩行为,也全都自动化的交给云厂商来实现。

在整个Serverless工作的流程中,不难发现FaaS平台实际上会作为计算资源,承载着诸多核心能力,包括不限于执行开发者的业务代码,自动进行资源的扩缩等操作,那么Serverless架构中的FaaS平台是什么样子的呢?通常情况下一个简化的Faas系统分为APIServer,Scheduler,ResourceManager,NodeService,ContainerService一共有5个组件。

image.png

如上图所示:

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平台的工作流程。

image.png

如上图所示,当开发者把代码和配置交付到FaaS平台之后,FaaS平台并不会按照用户的预定配置进行资源的分配,而是会将这一部分的内容进行持久化。只有请求到来时,FaaS平台才会根据真实流量进行资源的分配。从FaaS平台接受到函数调用或者被触发的请求时,到函数正式执行并反馈最终结果,粗略的可以认为是两个过程。

容器&Runtime准备阶段:这个阶段主要是进行相关的资源准备,例如某些计算资源的准备,某些网络资源的准备等,准备好这些资源之后,系统会根据用户的函数进行相对应的代码的下载,然后在进行实例的启动;这个过程通常也可以认为是冷启动的过程;

函数执行阶段:函数执行阶段指的是实例启动之后,函数代码进行初始化以及指定方法执行的过程。当然,在某些开发者眼中,或者某些平台的定义中,代码初始化的过程往往也会被算作是资源准备阶段;

当函数执行完成之后,返回了结果之后,就意味着本次触发已经完成。此时函启动的实例通常会有三种处理方案:

实例会被搁置一段时间,如果搁置的这段时间内,没有被分配处理新的触发请求,实例会被释放掉;

实例会被搁置一段时间,但是在搁置的这段时间内,被分配处理新的触发请求,此时实例会处理新的触发请求;

实例由于一些特殊的配置,被标记为长期活跃实例,即使被搁置很久(超过释放的时间阈值)也不会被释放;

通过上面所表述的三种处理方法,不难发现实例是可能存在被复用的情况,所以函数在被触发的时候,通常也可能会有两种可能:

当前时间段,并没有已经准备好且可以被利用的实例(例如函数的首次调用/触发),此时FaaS平台会全新启动实例,包括容器&Runtime准备以及函数执行等;

当前阶段,有已经准备好且可以被利用的实例(例如上述函数执行完成的三种情况中的2,3情况),此时FaaS平台会优先复用已存在的实例,以避免再次进行容器&Runtime准备而浪费时间,提升请求效率,降低请求时延;

由此也可见,Serverless架构之所以被认为是天然分布式架构,其原因是Serverless架构的模型实现,是请求级别的隔离,可以认为每次请求都可能会出现一个实例(部分厂商提供的单实例多病发的情况除外),即同一时间段的请求数量会和实例数量成正相关。

除此之外,还值得注意的是,Serverless应用是由事件驱动的,即FaaS平台中的函数是由事件触发的,事件的产生者按照某些规范描述不同的事件,并以参数的形式在调用函数指定方法时,传递给函数。所以事件生态也是影响Serverless架构应用领域、应用场景的重要影响因素。

image.png

如上图所示,按照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架构工作原理用一张图完整表示,可参考下图:

image.png

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。