Serverless 架构与事件规范

基础服务架构

本篇内容主要探讨的是 Serverless 架构与其事件规范的基础准则。

首先，我们先来理解下在 HTTP/Web 场景下我们的典型的WEB场景是怎么的：

基础架构

这里，我们不难看出典型的Web场景其实是由三大块内容，用户端，服务器，数据库组成。用户端在服务器侧通过类型 apache，nginx 等代理商服务器来请求数据，代理商服务器又通过数据库来写入或者拉取数据资料。这个很简单，也是我们最常用的 Web 场景。

这里面服务器中可能涉及路由规则，鉴权逻辑以及其余各类复杂的业务代码，同时，开发团队要付出很大的精力在这个服务器的运维上面，包括用户量忽然增多时能否需要扩容服务器？服务器上的脚本，业务代码等能否还在健康运行？能否有黑客在不断地对服务器发起攻击？

Serverless服务架构

那么接下来，我们来看下 Serverless 服务是如何请求数据的吧：

Serverless架构

Serverless 场景下，用户端需要通过 API 网关 Baas 来访问函数 FaaS 服务，而后在通过函数计算做数据库链接实现数据库的写入和拉取。

当用户端和数据库未发生变的前提下，服务器变化巨大，之前需要开发团队维护的路由模块以及鉴权模块都将接入服务商提供的 API 网关系统以及鉴权系统，开发团队毋庸再维护这两部分的业务代码，只要要持续维护相关规则就可。同时业务代码也被拆分成了函数粒度，不同函数表示不同的功能。

从上面的例子中，我们不难发现，其实一个完整的 Serverless 请求其实是有两大块的，即我们的 Faas 服务和我们的 BaaS 服务。那么，简单叙述下 Serverless，其实由两部分组成的，即我们的 Faas+Baas。

Serverless概念

Serverless 架构核心

理解完整体 Serverless 的情况，我们来看下传统 Faas 的基础架构，其实传统 Faas 最关键的核心概念是我们的调用，我们可以通过 Event Sources 事件源调用另一个函数的 Function 来实现单个函数的扩展，整体的原理图如下所示：

Faas处理方案

?

• Event Sources（事件源）：将 Event 触发或者流式传输到一个或者多个函数实例中；
• Function Instance（函数实例）：可以根据需要，将单个函数/微服务进行扩展；
• FaaS Controller（Faas 控制器）：部署，控制和监视函数实例及其来源
• 平台服务：FaaS 处理方案使用的一般集群或者云服务（有时称为后台即服务，或者者 BaaS 等）

Serverless 架构中的事件

这样，我们引出出来另一个概念，就是事件，什么是事件？事件是怎样定义的？

我们可以引出来 CloudEvents ，它是?种规范，?于以通?格式形容事件数据，以提供跨服务、平台和系统的交互能?。 事件格式指定了如何使?某些编码格式来序列化 CloudEvent。?持这些编码的兼容 CloudEvents 实现必需遵循在相应的事件格式中指定的编码规则。所有实现都必需?持 JSON 格式。

事件 (Event) ?处不在,然?每个事件源产?的事件各不相同。因为缺乏事件的统?形容,对于事件的开发者来说,需要不断地重复学习如何消费不同类型的事件。 例好像?个?商的 CMQ 产?的事件和 API ?关触发器产?的事件是不同的,不同?商的 API ?关触发器产?的事件也可能是不同的。

必需的事件属性（REQUIRED attributes）

? ID – 识别事件

? Source – 识别发?事件的上下?

? Specversion – 事件使?该版本的 cloudEvents 规范

? Type – 发?相关事件的类型值

? Data – Data的数据内容格式

? Subject -事件开发者有关的事件上下?主题

? Tiem – 事件发?的事件

Serverless 架构中的调用

聊完我们的事件，我们来谈谈另外一个核心调用，其实在 Serverless 架构中，调用简单分为四种：

可以根据不同的用例从不同的事件源调用函数，例如：

1. 同步请求（Req / Rep），例如 HTTP 请求，gRPC 调用

• 用户发出请求并等待立即响应。

2. 异步消息队列请求（发布/订阅），例如 RabbitMQ，AWS SNS，MQTT，电子邮件，对象（S3）更改，计划事件（如 CRON 作业）

• 消息发布到交换机并分发给订阅者；
• 没有严格的消息排序，以单次解决为粒度。

3. 消息/记录流：例如 Kafka，AWS Kinesis，AWS DynamoDB Streams，数据库 CDC

• 一组有序的消息/记录（必需按顺序解决）；
  • 通常，每个分片使用单个工作程序（分片消费者）将流分片为多个分区/分片；
  • 可以从消息，数据库升级（日志）或者文件（例如 CSV，Json，Parquet）生成流；
  • 事件可以推送到函数运行时或者由函数运行时拉动。

4. 批量作业，例如ETL作业，分布式机器学习，HPC 模拟

• 作业被调度或者提交到队列，并在运行时使用并行的多个函数实例进行解决，每个函数实例解决工作集的一个或者多个部分（任务）

不同类型的事件源包括：

• 事件和消息服务，例如：RabbitMQ，MQTT，SNS
• 存储服务，例如：COS，CDB，PGSQL，Cognito，Google 云存储，
• 端点服务，例如：物联网，HTTP 网关，移动设施，Alexa，
• 配置存储库，例如：Git，CodeCommit
• 使用特定于语言 SDK 的客户应用程序
• 计划事件，定期启用函数调用。

尽管每个事件提供的数据可能在不同的事件源之间有所不同，但事件结构应该是通用的，能够封装关于事件源的特定信息。

总结

如上就是关于 Serverless 架构与事件规范的一点思考，希望可以给到大家少量帮助。

传送门：

• GitHub: github.com/serverless
• 官网：serverless.com

欢迎访问：Serverless 中文网，您可以在 最佳实践 里体验更多关于 Serverless 应用的开发！

推荐阅读：《Serverless 架构：从原理、设计到项目实战》