转载

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 - 事件发⽣的事件