Serverless 架构与事件规范

基础服务架构

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

首先，咱们先来了解下在 HTTP/Web 场景下咱们的典型的WEB场景是怎样的：

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

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

Serverless服务架构

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

Serverless 场景下，客户端须要经过 API 网关 Baas 来访问函数 FaaS 服务，而后在经过函数计算作数据库连接实现数据库的写入和拉取。

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

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

Serverless 架构核心

了解完总体 Serverless 的状况，咱们来看下传统 Faas 的基础架构，其实传统 Faas 最关键的核心概念是咱们的调用，咱们能够经过 Event Sources 事件源调用另外一个函数的 Function 来实现单个函数的扩展，总体的原理图以下所示：

​

• 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 调用

• 客户发出请求并等待当即响应。

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

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

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

• 一组有序的消息/记录（必须按顺序处理）；
  • 一般，每一个分片使用单个工做程序（分片消费者）将流分片为多个分区/分片；
  • 能够从消息，数据库更新（日志）或文件（例如 CSV，Json，Parquet）生成流；
  • 事件能够推送到函数运行时或由函数运行时拉动。

1. 批量做业，例如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 架构：从原理、设计到项目实战》