Serverless基础、架构和原理

整理自《Serverless从入门到进阶:架构、原理与实践》

一,Serverless概述

1.1 基本概念

Serverless中文常被译为:无服务器,拆解一下,Server+less即尽量减少服务器的份额

维基百科Serverless Computing
无服务器计算(Serverless Computing)又称为函数即服务(Function as a Service,FaaS),是云计算的一种模型。云服务商通过运行服务器,动态管理和分配对应的计算资源,最终以资源实际使用量来收取费用。

综上
Serverless并不是没有服务器。(只是将服务器的运维、管理和分配都托管给了云提供商)
Serverless的产生基于云计算。
Serverless具有动态扩缩、按需计费的特点。

Serverless的意义不仅在于计算,也在于提供后端服务的Serverless化,后端可以称为Bass(Backend as a Service)

Serverless最终定义
Serverless是基于云计算的一种模型,是“函数即服务”和“后端即服务”的总和。云服务商托管计算、存储、数据库等服务资源,进行动态管理和分配,之后提供给用户,而费用则基于资源的实际使用量来计算。

1.2 Serverless优缺点

优点

1,节省资源成本
基于细粒度的计费模型
2,节省人力成本
将人力从机器资源配置、运维中释放出来,专注于业务的开发和实现
3,弹性扩缩容
根据业务的实际请求弹性扩缩底层资源
4,免除运维烦琐
让运维聪资源运维转为业务运维

不足

1,厂商绑定
业务部署在单一厂商后,过于依赖该厂商的架构和规范,耦合度高,难以迁移或进行多厂商部署
2,底层不透明
Serverless的底层调度对于用户来说是黑盒,大大增加了测试/调试的难度,同时基于云端的Serverless开发方式和传统的开发方式有一定的差异。排障也更加困难。
3,花销难预测
攻击等突发流量异常时
4,性能
Serverless架构可能出现首次请求“冷启动”的情况
5,安全
数据安全,传输安全等

1.3 应用场景

1,Restful & GraphQL API
2,Web框架支持
不同开发语言的Web框架都可以支持Serverless部署,如Python Flash、Node Express.js、Next.js、PHP Laravel等
3,数据管道--流数据处理
在流式消息处理的框架中,对流数据做一些分析和处理
4,CI/CD流程自动化
持续集成(CI)和持续部署(CD)是DevOps的核心概念,利用CI/CD流水线可以很好的实现测试/发布自动化,降低错误率,提升软件开发效率。
Serverless通过事件触发能力,可以完整串联构建、测试、部署的流程,实现自动化的CI/CD流水线
5,物联网

1.4 Serverless框架和生态

CNCF对Serverless的定义分为以下几个层级:
1,工具(Tools)
主要包括补齐Serverless周边能力的工具,例如提供监控、排障能力的Dashbird和Thundra等
2,框架(Framework)
主要包括部署Serverless资源的成熟框架。框架通常遵循某一套规范(如YAML规范)对资源进行抽象描述,通过框架可以进一步降低Serverless的使用门槛。
主流的框架包括AWS SAM、Serverless Framework等。
3,托管平台(Hosted Platform)
主要指云服务商提供的产品化Serverless计算平台。这类平台提供计算资源的完全托管,同时会进行商业化的计费。例如AWS的Lambda、腾讯云的SCF(Serverless Cloud Function)
4,开发平台(Installable Platform)
主要包括开源的Serverless平台,可以提供私有化的安装和部署,支持灵活定制,例如Apache OpenWhisk(IBM Cloud Function基于该开源版提供服务)、Knative和Kubeless等
5,安全(Security)
主要为Serverless提供安全相关的解决方案,例如Protego Labs等,提供从Serverless应用到运行时层面的安全防护,如持续的漏洞扫描、攻击检测、权限控制等

总之,Serverless是FaaS和BaaS的结合,基于云计算而生,它的特征是弹性扩缩、按需付费

二,Serverless框架

Serverless = FaaS + BaaS

FaaS服务主要提供计算相关的平台,用于实现应用的业务逻辑
BaaS服务侧重冰山底层的能力,例如数据库服务、存储服务、鉴权服务等
一个完整的Serverless应用必然是FaaS和BaaS服务的结合,此外,该应用中所有FaaS和BaaS服务是Serverless化的,即拥有弹性扩缩容、按需使用和付费的特点

典型Serverless应用框架

1,用户通过多种客户端(Web端、App端、小程序端等)对服务进行访问,发起请求
2,接入层,通过网关服务对访问请求进行处理,并将请求转发到后端的Serverless计算(FaaS)节点中执行业务逻辑。
3,在后端,可以连接多种多样的BaaS服务,例如设计数据增删改查的业务,会在后端连接数据库、Redis换存等;如果需要调用其他服务,可以直接连接第三方API快速实现,如图片识别、文字翻译等;如果需要对消息进行批量处理或再次计算,可以在后端连接消息队列实现解耦,并再次调用Serverless计算(FaaS)节点

对比传统的服务框架,Serverless无需考虑底层的运维和调度,也不需要关心后端数据层的连接管理、复用等,为开发者提供了极大地便利,让其可以专注于业务逻辑的实现

FaaS架构

FaaS架构帮助开发者的主要事件
1,通过负载均衡进行请求调度和转发
2,通过集群调度实现计算资源的弹性扩缩容
3,对请求做错误处理
4,安全隔离不同租户的资源

FaaS架构组成

FaaS需要以下模块的支持
1,负载均衡器:用于接收请求并转发到最近的后端服务中(往往适用于多地域、多可用区的部署方式)
2,请求处理模块:用于接收和处理请求,区分同步和异步请求等
3,计数器:用于计算并发请求,并调整实例的并发限制等
4,实例(worker):FaaS架构中最核心的部分,为用户代码提供安全隔离,多语言支持的运行环境
5,实例管理模块(worker manager):用于调度请求到对应的实例中。通过追踪实例的状态(繁忙或者空闲),针对状态信息分配请求,将请求调度到处于空闲状态的容器中
6,资源调度模块:管理实例的资源。在确保不影响用户业务的前提下,用最合理的方式创建或者销毁实例,确保资源池内的实例资源充足,可复用

FaaS架构执行流程

在FaaS环境中已有可用实例的情况下,请求的执行流程:


FaaS架构中的请求处理流程图(有可用实例)

在进入FaaS平台后,请求处理模块会在实例管理模块中查询是否有可用(空闲状态)的实例,如果有,则将对应的请求调度到该实例中。此时,如果实例第一次调用,则会执行初始化操作,加载业务代码。之后实例会执行分配的请求,运行用户代码并返回结果

当遇到业务请求突增,需要弹性扩容时,FaaS环境中实例资源池不足,则新的请求回如下执行:


FaaS架构中的请求处理流程图(无可用实例)

请求处理模块收到请求后,先去实例管理模块查询是否有可用实例,如无,则去资源调度模块中深情扩容,资源调度模块会创建新的实例加入资源池。此时,实例管理模块会对新的实例进行初始化操作(创建运行环境、加载业务代码等)。初始化完毕后,新实例会执行分配到的请求,运行用户代码并返回结果

因为FaaS平台屏蔽了许多底层的调度、扩缩容策略,所以内部的请求处理链路较长。尤其是在业务请求突增的情况下,需要通过资源调度模块分配实例,并且对实例进行初始化。这一系列处理流程太久,就会造成“冷启动”的问题,即首次请求到达FaaS平台延时过长

BaaS服务

随着FaaS技术的发展,开发者可以通过更便捷、更低成本的方式使用计算资源。随之而来的是对其他关联服务的需求,例如数据库服务、数据存储服务、消息推送服务等。当这些服务被抽象为按需付费、弹性扩缩容平台的时候,用户无须关心底层运维和实现,开发者可以更快速、更低成本地开发移动或Web应用

BaaS服务的分类

1,接入层服务:和FaaS服务结合最紧密的BaaS服务之一,最典型的是API网关服务,通过提供Serverless的接入层,请求弹性伸缩,转发到FaaS服务进行处理
2,登录/鉴权服务:提供便捷接入的登录鉴权服务,典型的如AWS Cognito
3,数据库服务:包括非关系型NoSQL和关系型SQL两种,并且符合Serverless的特征,即按需付费、弹性伸缩。Serverless数据库不需要客户管理连接池、优化数据库性能,典型的关系型数据库如AWS Aurora Serverless、腾讯云PostgreSQL Serverless;非关系型数据库有AWS Dynamo DB等
4,存储服务:用于提供数据的存储,通常用来存储静态资源、视频、图片等文件,能起到加速访问的作用。典型的存储服务如AWS S3、腾讯云COS对象存储等
5,提醒推送服务:基于消息队列等技术,提供短信、邮件等提醒推送服务,无须用户应用搭建推送服务器,直接调用对应的服务API/SDK即可实现消息推送。提醒推送服务经常用于短信验证、业务告警提醒等场景
6,API服务:通过调用多种API服务,提供成熟的应用解决方案,如基于图像处理、机器学习的图片识别、文字识别、基于自然语言处理的NLP对话平台服务等。这些能力极大地拓展了Serverless技术的覆盖边界,让全面Serverless化成为可能。

Serverless服务构建的思维方式

在构建Serverless服务时,开发者的思维方式也要有相应的转变。最重要的一点在于,要将思路从自底向上转为自顶向下

以全栈应用为例,传统的构建方式:
应用设计→容量预估→资源选型→架构设计验证→业务开发实现→测试及部署→应用交付
Serverless架构下的构建方式:
应用设计→选取对应模板→业务开发/改造→测试及部署→应用交付

在传统的开发模式中,要实现一个业务场景,开发人员会先思考架构所需的基础资源,逐步将这些资源组合、编排在一起,最终提供对应的功能模块,例如支付功能、登录功能等
在Serverless架构下,开发者可以专注于业务实现,从应用实现的角度设计方案,并将基础资源的使用、编排和组合交给服务商实现。这种思维方式的转变,可以极大赋能开发者,让构建一个开箱即用的Serverless应用成为可能

Serverless原理详解:Faas层

事件模型

FaaS事件模型

事件驱动是FaaS平台常见的编程模型。FaaS事件模型主要由以下几个部分组成


Serverless事件模型组成

1,事件源:触发后端服务的事件
2,FaaS平台:函数平台
3,后端服务:包括广泛的服务,如数据库、消息队列、其他API服务等

在FaaS平台中,通常将事件分为三类


Serverless事件分类
  1. 同步/推送事件
    在同步/推送事件模型中,通过一个请求触发函数,等待其返回函数的执行结果。一个典型的例子是,当我们访问一个API网关结合函数组成的网站时,输入对应域名(发送请求)后,这个请求会收到一个resp的返回事件,也就是我们在浏览器中查看到的网页(返回执行结果)
  2. 异步事件
    我们在对象存储中上传某个文件,或者在通知服务中传入一条消息,请求会先传入对应的服务,之后该服务会生成一条请求触发函数。在这种情况下,函数将执行请求,但不会向客户端返回执行结果,因此称为异步事件
  3. 拉取事件
    在拉取事件模型中,触发源往往会收到持续不断的请求,也称为流数据。和上述两种事件模型不同,触发源不会主动上报或推送请求,而是由FaaS平台持续运行一个探测服务,检测变化并主动拉取数据,传入一个触发请求执行的函数。该模型最典型的案例是触发消息队列,在交易系统中,通过消息队列实时处理用户的交易日志,将该队列配置为FaaS平台的触发源,则可以对消息队列中的流数据进行安全性检查,筛选出异常数据(如刷单)并告警

常见触发器介绍

FaaS平台的强大能力来自对多种触发方式的支持,FaaS平台常见的触发器有以下几种:
API网关:FaaS平台最常用的触发器之一,作为Serverless服务的API接入层,起到请求转发、认证鉴权、安全防护等作用。网关的触发方式主要是同步请求
对象存储服务:作为云端的分布式存储服务,在数据转存、文件处理等场景下和FaaS服务有紧密的结合,例如文件解压缩、CDN缓存刷新等
消息队列服务:用于数据处理,对生产者和消费者之间的数据进行解耦。FaaS服务可以很好地完成数据中转处理,在数据清洗、异常检测场景的应用十分广泛
数据库服务:FaaS服务和云上数据库服务也有紧密的结合。数据库增删改查等操作作为触发器事件会传入FaaS平台,从而执行关联操作,例如计数、发送告警等
监控、告警:FaaS服务可以作为监控服务的事件处理平台,用户通过配置监控触发FaaS服务执行自定义逻辑,例如发送告警短信和邮件等
物联网应用:物联网应用具有弱状态性、波峰波谷明显等特点,十分适合通过FaaS平台触发。典型的物联网服务有AWS Alexa、腾讯云智能对话平台等
定时触发:用于在约定的时间执行计划好的工作,一般通过用户定义CRON表达式实现时间周期的配置。定时触发的应用场景非常广泛,例如定时提醒服务(邮件、企业办公软件等)、日志定时清理及收集、请求定时刷新保活等
API / SDK触发:针对一些自定义场景,也可以直接调用FaaS服务的标准HTTP接口触发,从而实现服务间的灵活组合及扩展

错误处理和重试机制

FaaS平台有可能会出现不同类型的错误,主要分为运行错误和调用错误(同步调用、异步调用)

错误类型

调用错误:调用请求被拒绝时报错,该类型的错误发生在函数实际执行之前。常见的调用错误如并发超出平台限制、调用方无权限、调用请求传参不符合要求等
运行错误:函数的业务代码或运行环境返回错误。运行错误主要发生在函数的实际执行中。常见的运行错误有用户代码运行的异常、函数运行环境发现并抛出的异常等

重试机制

调用错误:平台方不会重试,而是直接将错误信息返回给用户,重试策略主要由调用方决定
异步调用错误:如超限,平台会持续重试24小时,重试的间隔按照指数退避增加到1小时。超过24小时仍调用失败,则将本次调用的返回结果存入死信队列或丢弃
运行错误中用户代码或运行环境错误:平台会自动重试,一般会做间隔分钟级别的两次重试。在三次重试失败后,错误事件将被存入死信队列或丢弃

各云平台也提供了死信队列等产品化策略,用于收集错误事件,分析失败原因。此外,为了更好地收集和分析错误请求,用户也可以针对调用方配置监控告警,感知函数配置日志服务,及时处理和分析错误

生命周期

FaaS的生命周期,如图所示


FaaS平台生命周期

开发者在创建FaaS服务时,从本地上传、选取模板创建对应的函数,函数上传到FaaS平台后,会提供运行环境托管用户业务代码。开发者可以在代码中调用BaaS服务,这样就完成了FaaS服务的创建
终端用户通过事件触发的方式访问FaaS服务(包含COS、消息队列、定时任务、网关等多种触发器)。触发事件发生后,FaaS平台将分配对应的实例运行用户上传的代码、执行业务逻辑,并访问对应的BaaS服务,从而实现业务访问
FaaS是分布式、事件驱动的架构,其核心节点为一个个函数实例。通过上述流程可知,函数实例的生命周期有以下两个特点
1,函数实例按需运行,在长时间未被事件触发时,处于关闭状态
2,事件触发时,函数才会被启动和运行

为了高效地复用函数实例,公有云服务商会在函数实例启动后,将实例保留一定时间,从而避免频繁创建和销毁资源。因此可知,函数实例的生命周期主要有以下几个阶段
1,事件触发
2,创建及启动函数实例
3,执行函数触发逻辑并返回结果
4,在实例保留时间内,如有新的请求,再次执行启动或触发阶段
5,等待一段时间,若无新的事件请求,则销毁函数实例

冷启动优化

所谓“冷启动”,就是第一次部署函数,运行实例时,由于 Faas 平台需要创建实例、部署网络,会有秒级别的较高延时。

冷启动的产生

函数冷启动指的是Faas 函数在启动过程中的代码下载、启动实例、初始化运行时及用户代码等环节
具体而言,FaaS 函数在接收请求且没有空闲实例时,平台需要启动新的并发实例处理事件,该过程中并发实例创建和业务代码初始化引起的耗时都可以称为函数的冷启动耗时。


冷启动的产生原因

根据上述执行流程可以看出,函数实例的启动过程主要分为两部分。
第一部分是启动的函数实例,包合资源调度、下载客户提交的函数代码、启动初始化运行环境、加载运行代码。这一部分产生的耗时也叫作冷启动时间,主要由 Faas 平台调度、执行和优化
第二部分是函数的执行阶段,包含初始化代码、执行函数然后结束、退出执行环境。函数执行阶段主要由用户控制,根据业务及实现方式的不同,初始化和执行时间也不同,用户可以自行对这部分时间进行优化

FaaS平台冷启动过程

公有云Faas 平台上的冷启动主要分为以下几个过程:
1,创建虚拟机或容器:根据用户选择的配置,Faas 平台需要创建对应的运行环境。在不进行优化的情况下,该过程的平均耗时在秒级别,遇到极端情况时 (需要创建新虚拟机或容器)甚至可能达到分钟级别
2,函数代码包下载:该过程主要为运行环境加载用户的业务代码,代码包一般从对象存储等服务中获取,因此代码下载速度取次于业务代码包的大小,代码包较大时也会达到秒级别的耗时
3,打通 VPC (Virtual Private Cloud)等网络配置:Faas 平台不仅承担计算任务,当函数和其他资源,如外网服务、数据库等服务进行交互时,需要考虑打通私有网络和公网,这一步通常需要秒级别实现

平台侧冷启动的优化

各大云厂商针对冷启动提供了各种优化策略,主要涉及以下三个方面。
1.创建虚拟机和容器阶段
在该阶段,由于公有云平台的虚拟机调度系统需要满足更广泛的需求,难以针对Faas 场景做定制优化,因此各厂商相继推出了适用于 Faas 平台的轻量级虛拟化系统(Mioro VM),例如 AWS Firecracker、Kata Container 等。这些轻量级虚拟化系统主要针对镜像和驱动做了裁剪,使其更加轻量。此外,该系统将虚拟机的内存、设备状态等信息存储到共享内存,通过提前创建虚拟机模板文件,实现了极速启动和部署

  1. 代码包下载阶段
    为了加速代码下载的速度,各云厂商通过代码缓存方案,将同账户下的代码缓存在本地节点作为一级缓存,多个可用区的代码也会作为二级缓存。
    3.打通网络配置阶段
    在网络配置阶段,云厂商通过抽取网络转发层,将弹性网卡 (Elastic Network Interface, ENI) 鄉定在转发层上,既可以复用网卡,又能降低绑定时间,提供高可用的架构

此外,各商业化平台也提供了一些可配置的预留实例策略,通过提供常驻实例,降低服务延时等。相信随着技术的持续进步,冷启动的问题将被更好地解决。

用户侧冷启动的规避

当前主流的冷启动规避方式为预置并发实例。从原理上讲,主要是通过预留实例的分式,有效规避冷启动的产生。但这也需要用户根据业务的具体场景,对不同函数的并发量进行预测、规划及合理分配。根据主流云厂 商的产品限制,在对并发实例进行 配置时,需要注意以下几点:
1,预置并发不支持 LATEST 最新版本,仅支特已发布的稳定版本
2,可供配置的预置并发总数有限,一般会为账户 / 函数维度提供一个预置额度,需要用户根据账号下不同函数的使用情况进行合理分配
3,由于预置并发需要额外的资源分配,因此计费方式可能有所不同
4,并发实例处理完时间请求后,不会被立刻回收,而是会继续执行一段时间,以便于实例的复用

第一个Serverless实例

1,创建云函数
2,创建触发器
3,触发函数

云函数中几个独特的参数定义
1,入口函数(handler function):用于指定云端运行环境被触发时,执行的函数/方法
2,事件 (event):用于传递触发事件数据,在各个公有云平台中,不同的触发器对应不同的事件结构
3,上下文(context):用于传递函数的运行时信息,例如请求唯一ID、日志组配置等

运行时和自定义运行时

概念

Faas 平台的每个函数的底层是基于轻量化虛拟机 (MicroVM)实现的,而每个函数都需要通过运行时环境的承载来提供服务,因此可以将运行时看作每个函数的执行环境


函数、运行环境和轻量化虚拟机的层级关系

运行时的生命周期

标准运行时的生命周期由两部分组成:初始化阶段和调用阶段
初始化阶段,会准备运行函数需要的资源,然后拉取用户代码,对函数进行初始化,并对外暴露入口函数(handler)接口
在调用阶段,通过事件触发,对函数进行调用,并执行函数内部定义的逻辑进行响应


运行时的生命周期

自定义运行时的生命周期

自定义运行时的生命周期如下图所示,可以看到,不同的触发器,如网关触发器、定时触发器,在触发事件后,会先将事件分发给Runtime API,之后由用户的实现自定义运行时部分,和Runtime API通过 HTTP/RPC年方式进行交互
用户实现自定义运行时主要需要考虑以下几个部分:首先需要自定义引导文件bootstrap,通过 bootstrap进行初始化,和负责调度的引擎,即 Runtime API进行交互,实现运行时的自定义,之后再执行函数的业务逻辑。


自定义运行时的生命周期

与标准的内置运行时相比,自定义运行时的开放性主要体现在以下三个方面。
1,支持自定义开发语言。
2,开放了运行时的初始化阶段。
3,支持通用的 HTTP/RPC 协议通信。

自定义运行时每个阶段所做的工作:
首先,启动运行时寻找代码包中的bootstrap 文件,此阶段引导程序 bootstrap 做启动之前的准备和数据加载等工作,同时也需要确保该文件的权限为 chmod 755
之后,进入函数的初始化阶段。该阶段之前是通过 Faas 平台实现的,在自定义运行时中则开放给用户。本阶段可以做许多初始化的工作,例如上文提到的加载扩展、启动自定义插件、创建连接池等。初始化完成后,可以通过 /runtime/init/ready的 API 通知平台初始化己经完成。
最后,进入函数调用阶段,通过 /runtime/invocation/next API 中长轮询的方式获取时间,并调用函数处理对应事件。处理完毕后,通过/runtime/invocation/response|error 等API推送函数的处理结果或者异常报告。由此可见,在函数调用和初始化阶段,都可以通过用户自定义和平台的运行时 API 进行交互,定义函数的生命周期

通过自定义运行时的能力,FaaS 函数平台可以完美支持 Deno、NET、WASM、
Swift 等编程语言,同时也能满足用户对运行时自定义扩展和插件的需求,进一步扩展FaaS 函数的边界。

Serverless原理详解:BaaS层

在 Serverless 架构中,FaaS层主要用于处理业务逻辑中计算相关的部分,而BaaS层则包含其他重要部分,如接入层、数据存储、数据库等。认识这些 BaaS服务有利于我们构建完整的 Serverless 应用架构

Serverless接入层:API网关

基本概念

API网关主要实现了 API托管的能力,能够对 API提供完地的生命周期管理,如API的创建、维护、发布、测试、下线等。此外,网关通过集成认证鉴权、流量控制、黑白名单、监控告警等能力,可以作为通用接入层,对外部的多个终端( Web/H5/iOS/Android/IoT等)提供服务。业界比较知名的商业化产品有谷歌 Apigee、AWS API Gateway、腾讯云 API Gateway 等,开源的 API 网关产品有Kong、Apache基金会顶级项目 APISIX 等

API 网关产品的主要能力:
1,API管理和配置:如API分组、增删改查等管理能力;基础配置如协议支持、CORS 跨域、自定义域名等配置,降低了用户的配置成本
2,API 认证能力:如密钥支持鉴权、SAML、JWT、OAuth2 等认证方式
3,多后端支持:除了支持 Faas 的对接之外,后端支持主机、容器、微服务架构的接入和转发,且相对于传统的网关服务而言更加灵活可控
4,版本和环境管理:支持针对 API 在开发、测试、发布等不同环境的发布,支特API 的版本管理和切换,并提供灰度发布、回滚等功能
5,高级配置:针对IP进行访问控制,针对API进行流量控制、熔断、缓存配置等
6,导入和导出:支持导入和导出 OpenAPI/Swagger 等标准规范,支持生成 API 文档和SDK 等
7,灵活的排障能力:支持多种监控指标和时问维度,帮助用户知悉业务运行情況;日志支持类似 ELK 平台的运算符检索能力,便于快速定位问题。
8,安全可靠:自带高防 IP,抵抗 DDoS 攻击;具备被攻击后自动更换IP 的能力,最大限度避免业务损失

由上述特性可以看出,API 网关可以让用户专注于核心业务的开发,无须为接人层投人过多精力,与 Serverless 的核心理念非常契合。

网关合FaaS的联动

FaaS平台主要基于事件模型,因此网关和FaaS平台的联动也是通过事件触发的,并通过特定的event格式进行传输。配置网关的后端为FaaS函数,就能实现API接受客户端请求后触发FaaS函数,并将结果作为API响应返回给客户端

API网关和FaaS请求流程

需要注意的是,上述流程是 API 网关开启了集成响应配置后的结果,此时网关会解析FaaS函数的返回内容,并根据解析内容构造HTTP响应。可以通过代码自主控制响应的状态码、响应头header、响应体 body 等内容,进而实现自定义格式的响应,例如响应XML、HTML、JSON,甚至 JavaSoript 等格式。因此设置集成响应时,也需要返回特定的数据结构给网关。HTTP 是目前最主流的传输方式,集成响应主要是为了支持 HTTP场景而提供的配置。
在 Web框架支持的场景下,由于涉及路由,对于 HTTP 的适配和改造会更为复杂,例如 Node.js 的 Express.js 框架、Python 的 Django 框架等。在这种场景下,需要一个中
间层或适配层对 API 网关和 Faas 函数的事件触发进行改造,即将JSON 结构体改造成标
准的 HTTP 请求,并将 HTTP 响应转换为 API 网关标准数据结构并返回。

Faas 平台的一些限制和常用配置进行说明
1.上传文件的处理
在传统架构中,上传文件可以查接通过POST表单加上文件类型的标签mulipart/form-data的形式实现,但在serverless框架中,由于使用了API网关和函数,涉及客户端上传文件到FaaS服务时,一般要用下面两种方式进行处理:
第一种是容户端将上传的文件镇换为Base64编码,API网关再将Base64编码作为文本传递给云函数,由云函数进行解码。
第二种是容户端将文件上传到对象存储COS的存储桶中,再由API网关将上传文件对象地址传递给云函数,云函数通过对象地址从COS中拉取文件。

当前的两种处理方式都涉及对服务端和客户端的改造,并不友好,因此云服务商也提供了直接通过网关进行请求的Base64编解码配置,带给用户接近原生的上传文件体验

  1. 请求/ 响应大小限制
    通常情况下,FaaS平台对同步请求和响应事件大小的限制为6MB,因此涉及大6MB 的请求时,需要进行切分和优化。结合上述上传文件的限制,网关向云函数中
    传入文件时,若文件在Base64编码后小于6MB,则将编码后的内容传入FaaS;若文件在Base64编码后大于或等于6MB,建议将文件上传至对象存储,并将对象地址传递给FaaS函数,从而完成大文件的上传

3.集成响应
鉴于网关和函数的交互方式,对于有HTTP需求的场景,Faas平合提供了集成响应的配置,即网关会解析云函数返回的内容,并根据解析内容构造HTTP响应。开启集成响应后,函数需要按照特定的数据结构返回才能被成功解析。如未开启集成响应,则网关会将函数的返回内容直接传递给API请求方,一般为JSON格式

4.CORS 跨域访问
CORS 即跨域资源共享 ( Cross-origin resource sharing),开启CORS后,允许浏览器向跨源服务器发出XMLHttpRequest请求,因此涉及跨域请求的页面需要在 API网关开启该配置。

Serverless 和存储

存储服务是BaaS服务中重要的组成部分,FaaS和存储服务相结合,可以在Serverless架构下实现文件存储、缓存共享、文件上传等多个常用场景,进一步完善了 Serverless 架构所需的数据存储和数据共享能力

基本概念

存储主要分为块存储、文件存储和对象存储三个类型
块存储需要把云盘挂载在主机上,在格式化安装文件系统后才能使用,支持高性能随机读写,但是共享因难,需要分区管理,主要用于数据库、OLTP ( On-Line Transaction Processing,联机事务处理过程)等场景。文件存储可以挂载多个客户端环境,无须格式化,可共享存储,方便访问,主要用于文件共享,流媒体处理等场景。对象存储则将非结构化的数据(视频、镜像、软件等)当作完整的对象进行存取,无须挂载,通过 HTTP 协议可直接发起对象读写,支持大规模并发,但不支持随机写,主要用于视频、文件和应用的存储、备份归档等场景

不同存储类型的功能对比,其中块存储是高度结构化的,因为每个数据块都排列在结构化的固定块中,便于搜索和索引。而文件存储是通过分层的方式被索引和结构化。对象存储则是非结构化的,因为没有用于数据存储的格式或者结构,只是简单的对象列表。

对象存储

对象存储:无目录层次结构、无数据格式的限制、支特HTTP/HTTPS 访问的分布式存储服务

对象存储服务具有如下特性:
1,存储可靠:多副本冗余存储,可达12个9(即 9999999999.99%)的数据持久性,保障数据耐久性
2,高可用:提供特定 SLA(如 99.95%)的高可用性,支持异地容灾、跨域复制等特性
3,开放兼容:支持 SDK、API、命令行、GUI 等工具,提供批量操作、迁移等能力,让使用和接入更为简单方便
4,数据安全:提供防盗链能力,支持多租户隔离、HTTPS 加密传输及数据加密等功能
5,高并发:可支持上万 QPS 的请求,保障高并发下的业务稳定
6,多种规格:根据业务场景访问频度的高低,提供标准、低频和归档存储等多种类型。提供更具性价比的解决方案。例如低频存储适用于较低访问频率的场景,可用于网盘、大数据分析等场景;归档存储适用于档案、医疗影像、科学资料等适合长期保存,但需要较长解冻时间的数据

典型的应用场景

  1. 数据处理
    对于用户传入对象存储的数据,可结合多种数据处理类服务进行编辑、处理和审核,针对图片数据,用户可结合数据万象进行裁剪、缩放、转码、锐化、添加水印等操作,还可以进行鉴黄、签政、鉴暴恐等内容审核。针对视频数据,用户可进转码、水印、截帧等处理。针对文档数据,用户可利用第三方服务生成文档的图片或HTML预览,并对预览图添加水印


    数据处理
  2. 内容分发
    网站服务通常会在动态网页中根据一定的规则,区分开经常变动和长期不变的资源
    静态资源是指长期不巫的非结构化数据终源,如图所示。对象存储提供了静态资源的存储和分发能力,减轻资源服务器的压力,并利用无限容量、高频读写的特性,为静态资源提供可扩展能力和可靠的存储。用户可以将网站中的静态内容(包括音视频、图片等文件)全部托管在标准存储中,并利用内容分发网络(CDN)分发。利用CDN 全球加速节点的能力,可以将热点文件提前下发至边缘节点,降低访问延迟


    内容分发
  3. 大数据分析
    无论用户存储的是医疗或财务方面的数据还是照片和音视频之类的多媒体文件,对象存储都可以作为数据源进行大数据分析,如图所示。对象存储支持存储EB级别的非结构化数据,具备高可用、高可靠、高安全和可扩展性,结合大数据服务,可以快速构建和部署分析应用程序。在实现高性能计算需求后,可以将数据转换为归档存储,降低服务使用成本,以便长期存储数据


    大数据分析

文件存储

随着业务的蓬勃发展,对于数据存储和管理的需求越来越明显。企业主要面临着存储容量不足、资源配置复杂、采购运营成本高、利用率低及不能满足大数据分析需求等几大挑战。而NAS(Network Attached Storage)存储以其灵活扩展、高性能、易用等优势广泛应用在多个行业中。文件存储作为云上NAS存储的代表服务,和各个计算服务如云服务器、容器和FaaS函数等搭配使用,可以为多个计算节点提供容量和性能可弹性扩展的高性能共享存储

当前 NAS 文件存储服务普遍支持下列功能和特性。
1,支持多种协议:支持 NFSV3.0/NFSV4.0、SMB协议,支持POSIX访问语义,兼容POSIX接口,可跨平台访问,保证文件数据的一致性
2,共享访问:多台主机或容器服务可以共享同一个文件系统,运行在不同可用区的计算节点也可以通过VPC网络使用同一个文件系统,实现多计算节点的协同工作及数据共享
3,弹性挂载/卸载:支持上万节点并发挂载,文件系统性能会随存储容量线性增长,用户可以灵活挂载或卸载文件系统
4,弹性扩容:单文件系统支持PB级存储,文件系统容量可随用户使用而弹性扩容无须提前分配资源
5,安全控制:具有极高的可用性和持久性,支持细粒度权限控制,支持VPC网络及基础网络的网络隔离及来访用户白名单访问控制
6,传输加密:支持在挂载文件系统时启用传输层安全性(TLS),实现数据传输加密
7,数据备份及冗余:数据3份冗余,具备高可靠、高可用的特性;提供数据备份的能力,用户可以根据业务需求定期进行数据备份

NAS 文件系统结合其他服务,可以支持以下常用的应用场景:

  1. 企业文件共享
    企业员工办公时通常需要共享和访问相同的数据集,管理员可以通过对文件系统进行管理和设置,授获组织中的个人访问有关资源,还可以在文件系统中对特定的用户组统一设置权限


    企业文件共享
  2. 流媒体处理
    文件存储支持CIFS/SMB协议,兼容Windows 7、Windows Server 2003/2012等多种操作系统,支持数万客户端并发访问,提供高吞吐量、亳秒级响应等特性,为吞吐量及延迟要求高的视频、图像渲染场景提供保障


    流媒体处理
  3. 大数据分析
    文件存储支持数万客户端并发访问,具备超大容量、高吞吐、NFS 协议的文件锁特性,为数据读写一致性需求强的大数据分析场景提供了保障


    大数据分析
  4. Web服务及内容管理
    文件存储作为一种持久性强、吞吐量高的文件系统,可用于各种内容管理场景,例如为网站、在线发行、存档等各种应用服务提供数据源文件


    Web服务及内容管理

存储和 FaaS 的联动

  1. 对象存储
    对象存储和云上多服务联动能够提供丰富的场景支持,云函数也是其中之一。对象存储支持以触发器的方式,通过JSON事件和函数进行交互,触发函数并支持用户自定义触发事件和处理逻辑。例如可以通过定义对象存储中的文件上传或删除等操作触发函数,并增加条件进行过滤。函数被触发后,也可以在代码中自定义处理逻辑

通过FaaS和对象存储产品进行联动,可以快速部署轻量级的业务处理逻辑,实现自动化处理,整个联动流程如图所示。通过一键配置对象存储作为事件的监听器,并在Faas函数中基于不同的编程语言和第三方库自定义处理逻辑,可以实现业务的自动化处理。通过FaaS平台的弹性伸缩能力,完美应对流量负载的波峰、波谷


FaaS函数和对象存储结合场景

下图是对象存储触发FaaS的一些典型场景,如音视频转码回传


FaaS和对象存储结合场景

某家用摄像头提供商基于Serverless架构,实现了摄像头视频回传----处理(拼接、转码)----存储方案。结合对象存储+云函数+Serverless DB,首先将回传的视频存储到COS,然后自动触发函数做拼接处理,最后通知DB做数据写人。整个流程支持毫秒级弹性伸缩,即使週到流量洪峰,世能完美承载。后来业务不断发展(C端售卖量上升),整套方案无需二次开发。几乎无容量上限,而Serverless按需付费的能力也极大的节约了机器资源和运维成本

和用户自建方案进行对比,在开发流程方面,云函数FaaS更加简单高效,云函数自带能力较完善;在运维方面,云函数更加易用和省心,降低了运维成本;在费用方面,云函数相比自建服务可节省30%以上的费用。
总体而言,使用Serverless云函数实现音视频转码服务的优势有下列几点:
1,FaaS函数提供了标准的运行环境,并保障资源的高可用和弹性伸缩,无须专人维护
2,FaaS函数根据实际业务消耗收费,不存在资源浪费
3,FaaS函数的开发调试流程更加高效,依赖和业务解耦,可以单独更新,支持实时热更新
4,运行环境隔离,单次请求失败不影响正常执行其他请求

2.文件存储
基于FaaS平台“无状态性”的运行原理,各云厂商FaaS的运行环境都有较为严格的限制。一般临时缓存空间为 512MB,并且只能存到1tmp 目录中。在这种情况下,随着函数实例的销毀(一般FaaS平合的实例回收时间为30分钟),这部分缓存也会被销毁为了确保这些数据能够持久存储,一般会引入对象存储或数据库将数据落盘。但在这种解決方案中,对象存储主要用来存储静态资源。此外,文件存储的读写速度不够快,延迟较高。因此,在多函数之间的文件共享、大文件处理和缓存等场景中,需要引入CFS文件系统的挂载。当前各云厂商的解决方案是,支持在FaaS函数中配置对应的文件系统进行挂载,实现多函数对文件的共享存储和访问

文件系统联动 FaaS 的常用场景有机器学习、音视频文件处理、数据共享、内容管理等

(1)机器学习
机器学习场景需要大量的数据存储和较大的依赖库,因为Faas平合的限制,所以这种场景难以在单个云函数中实现(由上文可知,平台对单个函数的限制一般为 500 MB,而机器学习的依赖库常达到GB级别)。但引入了文件存储做BaaS服务后,可以通过文件存储承载较大的依赖库,例如TensorFlow等,从而让函数可以执行机器学习模型。当然,这种情况也需要考虑因过大的依赖包引人冷启动的问题,预置并发实例是当前比较好的一种解决方案
FaaS 两数结合文件存储的架构如图所示


FaaS函数和文件存储结合场景:大体积依赖或代码包

(2)音视频文件处理
在音视频文件的处理场景中,主要基于FFmpeg等通用开源库对视频文件进行转码等处理,通过Serverless实现该场景可以达到降低成本、弹性扩缩容的效果。通过将视频源文件存放在文件存储中,配合视频切片,可以对大文件进行处理。函数平台可以直接挂载文件存储,对其中的文件进行处理,如图所示


FaaS和文件存储结合场景:音视频文件处理

(3)数据共享场景
由于文件存储支持至计算资源共享访间,对应FaaS平台,不同的函数可以以不同的权限访问不同的文件存储路径。Faas结合文件存储能够支持一些涉及共享数据的场景,例如需要持久化的用户登录sesion信息的存储和共享,或者多个函数获取不同的测试数据,进行黑盒测试后,将结果写回文件,文件存储则可以根据对应的结果进行模型调整和结果分析

  1. Serverless 结合存储实现文件上传
    在不同的语言环境中,处理 HTTP 上传、下载的方法有很多,结合Serverless架构进行实现时,根据不同的场景和成本预估,能够选择不同的解决方案。由于各个云厂商对 HTTP 请求和响应的内容限制为 6MB,因此对于大小不同的文件大小,也有不同的实现方式
    a,文件小于 6MB:结合 API 网关做 Base64 解码。
    b,文件大于 6MB:由于FaaS函数本身无法对文件做持久化,函数实例生命周期结束后会被回收和销毁,因此需要结合存储服务实现文件上传能力。这种情况下又有以下三种实现方式:
    分片上传,将大文件切分成小块,完成上传后再拼接起来。
    借助 COS 对象存储功能,先将文件上传至COS,调用两数从COS 下载文件,处理完之后进行回传。
    借助 CFS 文件存储功能,将大文件存放在CFS 盘中,通过函数挂在 CFS,可以像读写普通文件系统一样访问CFS 盘中的文件

(1)文件小于 6MB
在本地开发时,如果要实现文件上传功能,我们通常会用content-type:multipart/form-data类型作为请求头实现HTTP文件上传,或者将文件进行base64编码之后再上传。在文件不超过FaaS平台限制的情況下,这种思路依然可以通过网关结合函数实现,即将小文件通过网关传到FaaS函数平台,并由函数将结果在对象存储COS中做持久化但这种实现方式也有诸多弊端。一方面,将文件直接从网关传给函数时,需要用户将文件转换为base64编码后再传输。函数通过网关收到数据后,再将base64编码的文件进行解码,之后进行持久化存储。这一过程依赖用户对代码进行额外改造。此外,由于Faas平台的接人层,也就是API网关的数据包有6MB的限制,超过限制的文件会被裁剪或拦截。最后,通过API网关进行文件传输,需要较高的API网关和对象存储COS的流量费,因此,传输大文件时,不建议直接通过网关,可以结合两数及存储服务,对文件进行持久化处理

(2)文件大于6MB
在文件大于6MB 的情况下,需要结合FaaS函数和存储服务进行文件持久化。其中最直观的一种方式是直接传输文件到对象存储中。在这个方案里,客户端需要分别发起请求,获得临时上传的地址,将文件上传到COS,获取处理结果。这种方式在二进制上传、文件大小及成本控制方面都能提供更好的支持。以OCR文字识别为例,用户上传图片,调用OCR接口将图片转换为文宇并展示。这种场景更适合直接将文件上传到COS对象存储中

使用对象存储做文件上传,需要额外注意下面两点。
Web服务可能存在跨域问题,因此需要对COS桶进行跨域设置,即开启CORS的支持
因为客户端直接将文件上传到对象存储中可能有较大的安全风险,所以可以考虑在服务端做签名,通过客户端获取签名结果,上传文件到对象存储的指定位置

Serverless和数据库

基本概念

关系型数据库便于理解和维护,并且具有事务一致性,遵循 ACID 的原则,即原子性(Atomiciy)、一致性(Consistency)、独立性(Isolation)和持久性(Durability)。这种特点使得关系型数据库能满足所有要求强一致性的场景,例如银行交易。但这些特性,也导致了关系型数据库在高并发读写、高扩展性的场景下不能很好的适配。此外,随着用户生成数据(UGD)和操作日志成倍增加,在很多场景下并不需要保持关系型数据库的事务一致性或读写实时性。此时非关系型数据库应运而生,可用于海量数据查询场景,支持高性能、高可用和弹性伸缩,并且基于 BASE 原则,即基本可用 (Basically Available)、软状态/ 柔性事务 (Soft-state)和最终-一致性 (Eventually Consistent)

特性对比

对比项 关系型 非关系型
数据存储 关系表 数据集(键值/JSON文档/哈希表/其他)
模式结构 结构化,提前定义表结构 动态调整模式,非结构化
扩展方向 纵向扩展,提高处理能力 横向扩展,增加分布式节点
数据查询 标准通用的查询语言(SQL) 非标准非结构化的查询语言(UnQL)
关键特性 ACID CAP,BASE
主要优势 结构化、事务处理、易于维护使用 扩展性、灵活调整、大数据分析
主要劣势 扩展性、高并发场景、大数据分析 事务支持较弱、标准不统一

CAP即一致性(Consistency)、数据可用性(Availability)、分区耐受性(Partition Tolerance)。 CAP 原理认为一个提供数据服务的存储系统无法同时完美满足一致性、数据可用性和分区耐受性这三个条件

数据库和FaaS的联动

为了确保数据库连接的安全性,在FaaS平台访问数据库时,需要配置私有网络VPC,将数据库和函数放置在相同的VPC内,可以通过私有网络安全连接云数据库

  1. 关系型数据库
    FaaS访问关系型数据库时,在开通对应访问权限、配置网络后,可以通过对应的数据库客户端直接连接

一般在FaaS连接关系型数据库时,需要管理连接池,实现连接复用。
1,通过 Redis 进行数据缓存,从而有效控制实际的数据库连接
2,调整数据库的超时时间,同时在代码中针对断开的连接做重连策略
3,适当限制 FaaS 西数的并发,使其小于数据库承载的最大连接数,防止数据库高负载
4,通过限制连接用户数、扩容并增加数据库 max connections 等方式进行优化

对于用户来说,最好的方案当然是不需要考虑数据库的连接管理,在数据库层也能够实现 Serverless 化。针对这个需求,AWS 发布了 Aurora Serverless for MySQL,实现了关系型数据库的弹性伸缩和按需付费(无请求时销毁数据库实例),并且支持 HTTP 方式的连接和访问,降低了数据库使用的门槛

  1. 非关系型数据库
    在 Serverless和非关系型数据库的联动中,AWS Lambda 和 DynamoDB 的打通最为典型,其他云提供商也在逐步提供类似的服务

DynamoDB 是一个非关系型Key-Value 键值存储数据库。它不会通过结构化、关系型的方式存储数据,而是用简单的Key-Value 格式存储JSON对象。此外,DynamoDB是分布式数据库,因此提供了天然的冗余和备份能力
在DynamoDB 中,表(table)、数据 (item)和属性 (attributes)是三个核心概念。其中,每个表由一个或多个数据组成,每个数据又由一个或多个属性组成。每个表需要设置主键(primary key)作为索引,主键可以由单一的分区键(partition key)组成,也可以由分区键和排序键(sort key)组成,即复合主键。不管使用哪种方式,最后的组成的主键在一张表中必须是唯一的。DynamoDB 中各个概念之间的关系如图所示。


DynamoDB概念介绍

AWS Lambda 可以通过配置数据库触发器的方式,一键打通 DynamoDB,也可以在函数代码中实现数据库的增删改查。例如每次更新 DynamoDB 表时,该操作都可以作为事件触发 Lambda 函数,执行自定义逻辑。流事件可以同步触发函数进行数据库操作,也可以批量读取,进行数据库操作。AWS DynamoDB 大大降低了开发人员对数据库运维和管理的依赖,进一步拓展了开发者的边界

ServerLess和消息队列

本节介绍Kafka的基本概念和特性

基本概念

Apache Kafka 是一个分布式的流数据平台,既可以作为消息引擎,用来对流数据进行发布和订阅,也可以作为消息的流式存储,确保存储的容错性,还可以作为一个流处理的平台提供服务,对流数据进行处理。Apache Kafka 的架构及特性如图所示


消息队列Apache Kafka架构

由于 Apache Kafka 是一个开源项目,搭建方式简单便捷,并且具备高性能特点,因此许多企业会选择自建 Kafka 集群。但是随着业务消息量增加,自建集群会出现各种各样的问题,需要开发人员持续运维,针对参数配置进行调优,保证维持高性能运行,并且快速处理突发故障,对集群的健康状况进行监控和扩缩容,在进阶使用 Kaftka 服务及周边组件的过程中也有一定的门槛。因此,市面上也出现了商业化公司如 Contluent,提供消息队列 Kafka 的托管服务。公有云厂商也提供了 Cloud Kafka 的云端解决方案,通过增加下列特性,保证 Kafka 服务的托管、伸缩和免运维

高可用:提供磁盘高可靠,即使服务器坏盘达到50%,也不会影响业务,保证数据不丟失
高可靠:提供多副本备份,支持跨可用区容灾
水平扩展:解决开源版本 Kafka 长期以来数据水平扩展和迁移的痛点,配置升级
无感知
鉴权和安全性:支持云上私有网络隔离、账户权限管理以及 SASI 等鉴权方式,保证公网访问的安全性
数据监控告警:针对集群提供默认的指标监控和告警配置(例如消息条数、磁盘容量、峰值带宽等),及早发现异常问题
云上服务打通:支持和公有云上的对象存储、MapReduce 等服务一键打通
开源兼容:完全兼容 Kafka 0.9、0.10和1.1.1 等社区版本

消息队列Kafka 在日志转储、大数据分析等场景下均有典型的应用。如图所示,某知名电商在做视频直播的过程中,利用CDN 做数据分发,产生许多日志数据。业务方需要利用日志数据进行实时数据分析,因此客户选择将流式数据上传到Katka中并由业务团队实时拉取进行消费,从而实现了分钟级别的数据分析能力


消息队列Kafka在日志转储场景的应用

消息队列在大数据分析方面也有非常广泛的应用。如图所示,某知名 UGC视频企业通过自建 Kafka 和 ELK 的方案进行数据处理、过滤,但随着数据量增大,自建运维成本越来越高。因此该企业选择结合公有云的大数据套件+消息队列CKafka 的方案,划分数据清洗和计算、数据检索、数据罗盘等阶段,对数据流转过程进行优化,并且针对业务波峰波谷,支持平滑扩缩容


消息队列Kafka在大时速据分析场景的应用

4.4.2 消息队列和FaaS 的联动

消息队列和 Serverless 结合的场景及优势。如图所示,在一个较为通用的流数据处理模型中,上游有多种多样的数据源,如数据库、应用运行过程中采集的日志、第三方数据源等。通过采集工具将这些数据导人消息队列Kafka 中.之后再通过各种流处理工具对这些数据进行加工,最终对加工后的数据进行存储落盘或中转处理


流式计算典型数据流示意图

在这个过程中,Faas 可以在数据采集和数据处理环节提供快速、简单、水平扩展的处理能力,从而确保数据处理流的完整性。FaaS 本身具备以下几个特点,能够很好地支持消息队列上下游的处理能力:
1,使用成本低(提供多语言的支持,包括自定义运行时)
2,近乎无限的横向扩容能力
3,支持多种触发方式,如事件触发、定时触发、API接口调用触发等
4,按需付费,空闲时不付费

在没有FaaS参与上述架构的情況下,一般流处理工具和采集工具需要客户自建和运维。例如最典型的 、ELK集群,消息队列转到Elasticsearch(ES)组件的过程中,需要用户创建ES和Logstash资源,并了解对应的导入配置。而结合FaaS和消息队列触发器的方案时,只需要用户选择对应的模板,即可默认打通消息队列到后端的对象存储/ES等集群,降低了学习门槛,且无须对函数集群进行运维,可以满足业务波峰波谷的需求
使用 Faas 后流式计算的典型数据流示意如图所示


FaaS结合流式计算典型数据流示意图

最终架构如下图所示,消息队列Kafka 结合FaaS函数的多种配置模板,可以实现一键转储流数据到多个数据消费者,例如云上Elasticscarch、对象存储 COS、数据库TencentDB、数据仓库Data warehouse等。可以说,Serverless 结合消息队列,实现了更为通用的流数据处理方案,搭建了 “云上数据管道”


消息队列联动Serverless搭建“云上数据管道”

Serverless 和日志服务

本节将介绍日志服务的基本概念和常用组件,之后详细说明日志服务结合 Serverless 在数据分析、转换和加载流程中的应用

基本概念

针对日志处理,往往有ETL( Extract、Transform、Load)三个阶段,即消息提取、转换和加载。这三个阶段可以通过开源服务如Logstash、Elasticsearch和 Kibana等实现。在公有云上也提供了许多一站式解决方案。譬如一站式日志平台,可覆盖数据源的采集数据转换加载和展示等环节,提供封装好的数据检索、展示和转储的能力。下图所示是一个通用的日志处理平台架构图


一站式日志处理平台

在日志处理平台中,从数据源部分获取云端服务的日志、agent自行采集系统和应用日志进行数据上报。之后通过 LogListener 进行数据格式解析、过滤等操作,并在日志平台中进行检素、分析、告警和投递等二次操作。通过云端服务进行日志处理,可以依靠云厂商的支持,保证服务的弹性扩缩容和稳定性、高可用,从而降低企业运维成本

日志服务在上下文检索、聚合分析等方面均有比较成熟的应用。在聚合分析方面,针对日志执行对应的分析语句,通过 SQL 命令即可获取可视化的分析视图。针对数据的可视化分析服务,如PowerBI 等,在企业数宇化转型的过程中起到了重要的作用。日志聚合的应用实例如图所示


日志聚合分析展示

日志服务和 Faas 的联动

在Serverless应用开发中,核心诉求是希望用最少的工作量,实现最高的效率,开发最可靠的应用。而在这个过程中,计算存储等资源被托管到云端,大大降低了平台和资源的运维成本,开发者和企业只需要针对业务提供运维工作,例如对业务日志进行收集和分析,而这些工作完全可以借助 Faas 结合日志服务实现,如图所示


应用开发及运维全景图

具体到日志处理流程中,LogListener采集到日志后,需要通过用户自建虚拟机/容器等方案进行消息向下游的分发和转储。在这种方案下,往往会有以下几个问题。
1,需要用户自行购买虚拟机 / 容器等,成本高、周期长
2,需要运维服务器,关注日志服务整体的高可用和安全性
3,除了业务处理逻辑外,还需要针对不同的语言环境编写服务框架
针对上述问题,可以通过日志服务触发FaaS函数,对日志进行自定义处理,从而进一步降低整个架构的开发和运维成本,实现一键式日志导人和转储,便捷地对接到后端服务,如对象存储、Kafka 消息队列、Elasticsearch 等。结合日志服务和FaaS 架构及运行原理如图所示


云函数处理日志运行原理

在上述架构中,开发者可以在本地或者FaaS函数的 WebIDE 中选取合适的编程语言,自定义编写日志的处理逻辑,并上传到FaaS平台。之后,开发者可以针对该函数创建日志服务的触发器,监听采集到的日志。另一方面,通过日志服务的LogListener 可以采集不同数据源中的日志,并上传到日志服务CLS中,此时日志服务会触发对应的函数触发器,对日志进行批量消费,将日志异步转发到云函数平台,执行函数自定义的处理逻辑。处理完毕后,再将对应的日志上传到下游的存储组件(如ES、COS 等)中。在整个处理流程中,我们使用的组件都是基于云端服务,可以弹性扩缩容的,因此可以有效降低运维压力,让开发者专注于业务逻辑的实现

其他扩展能力

除了上面提到的常用BaaS服务之外,Serverless 的另一大特点是可以与第三方服务结合。在联动方式上,一些服务可以通过触发器直接打通,例如消息队列、物联网服务等;另外一些服务可以通过FaaS函数主动调用 API 和 SDK,作为后端提供服务。本节主要对第三方扩展能力进行简单分类,并举例介绍一些典型的应用场景

鉴权认证类:如 AWS Cognito 等
音视频、人工智能和机器学习等特定领城的应用:如文字识别、语音转文字、机
器学习模型服务等
通知/订阅服务:包括主动推送的消息和 RSS (Really Simple Syndication, 简易
信息聚合)订阅和拉取内容。如短信服务 SMS、Twilio、企业微信提醒、Slack机
器人等
消息队列:通过消息队列生成的事件触发函数进行二次处理、业务解耦
物联网:如智能设备的连接、对话平台等
数据获取:如 GraphQL API、 Salesforce 系统等
打通 CI/CD 或监控服务:如 GitElub、Datadog 等提供的接人 API,可实现自动化工作流

以下是几个典型的 Serverless 结合第三方服务场景
图像识别服务:通过调用图像识别 API,实现图片转文宇,常用于身份证、车牌
识别等场景。
短信通知服务:通过调用第三方短信等服务,在完成特定操作后给用户发短信。
ETL:对系统中的日志进行分析和检索并生成报表。
数据清洗、转存:结合消息队列进行数据的转储或自定义清洗和转存等逻辑,架
构如图所示


函数时和消息队列实现数据清洗场景

以上为Serverless基础、Serverless架构和原理

你可能感兴趣的:(Serverless基础、架构和原理)