Serverless 无服务器架构

1.Serverless定义

Functions-as-a-Service（FaaS）：函数即服务，开发者以一个函数（function）为入口，将业务逻辑编程打包上传，同时指定触发该函数的事件，如一个HTTP请求。当无事件发生时，函数不会执行且不产生费用。当指定的事件发生时，这些函数即被触发并执行，且可以自动扩展，当事件结束时自动销毁，按函数实际执行时间计费。

2.Serverless优势

成本更低

第一个方面是按实际使用量收费。

选择Serverless则不存在这个问题。对于一个FaaS服务来说，当有请求到来的时候，应用才会被初始化并执行，当请求返回时，应用便被销毁。而我们只需要为该请求实际被处理的时长付费。尤其是当没有请求的时候，应用本质上并没有运行，当然无须付费。这种收费模式，对于那些服务器利用率不高但又要求能实时应对突增流量的应用来说，最适合不过了。

第二个方面是零服务器运维成本。

Serverless将开发者与服务器完全屏蔽，开发者只需在UI上进行少量配置，并通过Serverless提供的API接口上传自己的代码便可实现部署，中间无须任何有关服务器的操作，实现了零成本服务器运维。

自动缩扩容

在Serverless下，每一个API即为一个FaaS服务，其运行环境和配置可以分别指定，扩容的粒度精确到API级别。FaaS所提供的并行处理能力也会根据流量的大小进行调整，这些特性是FaaS的原生功能，自动实现且完全无须开发者介入。

迭代和交付更快

Serverless为开发者屏蔽了部署和运行中大量的复杂细节，以往需要数位工程师花费几周时间才能完成的工作，使用Serverless可以在几分钟之内完成。而为了吸引开发者的加入，Serverless服务商往往会提供丰富的配套服务以应对不同的应用场景。这些服务可能包括数据库服务、索引服务、日志服务、验证服务、文件服务等。FaaS服务的优势在这里就充分体现出来了，它可以轻松、高效且安全地与这些服务进行集成。用户甚至不需要专业的背景知识，只需要在UI上简单拖曳就能在几分钟时间内上线一个包含数据库访问、身份验证等功能的安全可靠的Web服务。

3.Serverless不足

端到端测试困难

不适合长时间运行

云服务商锁定

受限的运行环境

4.Serverless常用场景

构建Web API后端服务

● 网页端或移动端通过标准的HTTP或SDK向服务地址发送请求。
● 请求会被解析到某一个网关地址，作为应用程序的统一入口，网关负责实现流量管理、CORS支持、授权和访问控制、监控等任务，同时根据不同的访问路径触发不同的FaaS服务。
● FaaS根据传入的请求运行业务代码，执行计算。根据不同的用户场景调用不同的服务实现文件读写、数据持久化、消息分发等。

构建数据编排器

随着用户交互变得越来越复杂，V逐渐前置，发展为单页面应用。M和C则逐渐下沉，发展成面向服务编程的SOA后端应用。当前后端分离之后，为了实现多端应用、多端业务解耦，通常还会引入BFF（Backend For Frontend）层来做数据编排。

 更重要的一点是，从零构建一个高可用的FaaS服务所需要的人力和时间成本较低，服务的使用者和数据的消费者也完全有能力快速构建出满足要求的数据编排器。这样一来，前后端服务的对接和接口定制工作从服务开发者移交给了服务使用者，服务开发者可以专注于业务领域模型的实现，服务使用者则可以根据需求灵活实现数据编排，在极大解放了服务开发者的同时，也实现了前后端更快地交付和迭代。

构建定时任务

事件触发

事件触发的方式最为常见。如在上两节中，当FaaS作为Web API服务时，用户的请求可以看作一种事件。当使用FaaS监听数据库消息源时，对某条记录的修改也是一种事件。根据云提供商的不同，FaaS支持的事件类型也会有所差别。

定时触发

定时触发的任务包括但不限于以下几类。
● 网络爬虫定期抓取网络数据。
● 数据的定期备份或导入导出。
● 自动化运维中开发或集成环境的定期部署。
● 定期数据采集分析和报告推送。

● 首先需要建立一个定时触发器，该触发器在每天的固定时刻（比如凌晨），激活基于FaaS构建的下载器，见步骤①。
● 下载器读取URL管理器中的种子URL，下载URL对应的网页数据并上传到文件存储服务，见步骤②③④。
● 当网页数据被上传到文件存储服务地址时，会触发下游FaaS构建的网页解析器的执行，见步骤⑤。
● 解析器会下载该网页数据，提取出感兴趣的数据和新的URL，数据被推送到消息队列，而URL则被加入现有URL列表，见步骤⑥⑦。
● 当数据被推送到消息队列之后，下游的基于FaaS服务的索引器将被触发，索引器将数据编排成可供查询的结构并将其存储到数据库或搜索引擎中，见步骤⑧⑨。
● 使用FaaS构建Web API后端，并集成网关服务向外暴露CRUD等接口，见步骤⑩⑪。

构建实时流处理服务

第一阶段：数据采集。
● 流数据通常采集自成千上万不同的数据源，这些数据源可以通过SDK直接向流存储服务发送数据，也可以通过构建FaaS服务先对数据进行简单的格式转换再发送，见步骤①。
● 流存储服务负责接收存储这些数据，并作为下游消费者的缓冲防止采集和处理速度不匹配。
第二阶段：数据处理。
● 当流存储服务采集到数据之后，它会将这些数据推送给下游的流处理服务。为了向流处理服务提供统一的格式，这些数据通常还会被FaaS预处理器预处理，如检查数据一致性，处理无效数据和缺失值等，见步骤②。
● 流处理服务接收到这些数据之后并不会立即消费，而是会先将这些数据进行持久化以供日后查询，并提取其中感兴趣的数据将其推送到数据仓库，用于之后的离线计算，见步骤③④。
● 流处理服务会根据需求进行数据分析和聚合，如进行基于时间范围的指标计算、为实时监控看板生成聚合结果、通过机器学习算法和历史数据监测异常值等，见步骤⑤。
● 处理之后的数据将被分类推送给下游的流存储服务。
第三阶段：数据交付。
● FaaS订阅流存储服务中的不同主题，并根据不同主题将数据交付给不同的消费者，如将异常数据推送给报警系统，见步骤⑥。