基于事件驱动的零碎架构在日常的平台开发中早已司空见惯，通过音讯队列进行事件的发送，而后别离构建对应的生产者和消费者。不过在传统的业务开发模式不同的事件会有不同的格局，不同的生产者生成出的事件格局也各不相同，消费者能生产的格局也是千差万别，实质上事件、生产者、消费者还是耦合的。那如何解决该问题呢？那就是咱们明天要聊的 CloudEvent。

CloudEvent 简介

从官网的 CloudEvents 形容中咱们能够看出，CloudEvent 实质上就是一个形容事件数据的标准。所以对于 CloudEvents 的学习有的时候，咱们更多的应该是取了解其设计规范，而不是其所呈现出的数据结构状态。就像大家去学 tcp 协定一样，你不是去学的这个字段叫什么，而是要了解为什么会有这个字段，其解决的问题是什么。

如何解耦

对于 CloudEvents 的学习笔者采纳自顶向下的形式来进行学习，即先去理解 CloudEvents 是如何在平台上进行事件、消费者、生产者的解耦，而后在去思考底层的相干字段的细节

一个事件的生命周期通常会蕴含生产、传输、生产三个环节，上面咱们别离对这三个环节来进行介绍 cloudevent 与传统事件开发模式的区别。

事件生产

在传统的开发模式下不同的业务生产的的事件也各不相同，并且事件自身数据会绝对较少，更多的是相似信号传递的角色，即告诉后端服务某个类型事件产生了，而后由对应的零碎构建事件的上下文数据，进行业务逻辑解决。而在 Cloudevents 中则更重视事件的一致性与完整性。

为了保障事件能够被对立的散发、解析与解决，Cloudevents 采纳了相似分层的事件封装机制，即 ” 事件协定 ” 与 ” 事件数据 ” 两层。事件协定是指 Cloudevent 定义了底层事件的格局，即大家都依照一套规范的标准来进行事件的封装，这样事件就能够被对立的解决和散发。而事件专有的数据则存储在对应的数据字段外面

完整性是我集体的了解，即咱们在 Cloud 的环境中构建的事件须要蕴含其以后的残缺上下文数据，以便后续零碎有足够的信息能够进行业务逻辑解决与决策。这样能够防止后端系统在接管到事件后，须要进行以后事件对应上下文的组装，次要是解决因为传输存在的提早导致相干数据可能曾经不再是事件产生时的状态，存在状态不统一的状况

事件传输

事件产生后通常要发送到对应的音讯代理服务进行暂存，在传统的业务中通常会抉择特定的音讯协定来进行传输，这两头通常会波及两局部：序列化与传输协定。

在传输协定中 Cloudevents 中反对常见的行业标准协议比方 HTTP、AMQP、MQTT、SMT 等，并反对常见的供应商与平台比方 kafka、AWS Kinesis、Azure 事件网格、Alibaba Cloud EventBridge，用户能够依据本人的场景抉择对应的供应商散发对应的事件

在序列化方面 cloudevents 反对 HTTP、AMQP、Kafka 等常见的标准协议，而不须要用户手动进行相干协定的序列化

事件生产

事件的生产端通常会对其关注的事件类型感兴趣，并且因为音讯的格局是对立的咱们很容易就能够通过对应的平台来依据音讯体外面的内容进行音讯路由，分发给对应的事件消费者，事件的消费者只有负责对应事件的接管即可，而并不关注其余的信息

对于 Cloudevents 事件更多的内容，前面再持续分享，而后接下来就介绍下咱们基于 cloudevent 是怎么设计零碎的

入门场景

在后面的文章中，介绍过咱们的服务目录零碎，服务目录中要接入不同的根底服务，根底服务的格局各不相同，而且还要对接计费、效率统计等零碎，前期可能还会对接公司的事件流平台，那如何对这些这些异构模块中异构的数据进行对立的散发和解决，咱们的架构如下：

音讯解决流程

首先在音讯发送端，咱们基于 cloudevent 构建对应的音讯，并且将以后事件的上下文数据对立封装到 data 中，而后发送给公司的音讯队列零碎。由公司的音讯队列来实现对应的事件散发与路由，对应的事件接收端只须要定义本人关注的事件，而不须要去监听具体的 MQ，只须要定义一个承受音讯的 HTTP 接口接口，对应音讯的路由与散发性能由公司的 MQ 来实现
服务生产端解析音讯队列传递过去的事件信息，解析出对应的数据结构，而后进行业务解决即可。后续如果减少模块，或者减少新的事件生产需要，只须要实现对应的逻辑即可

数据结构

联合 Cloudevents 的标准，咱们定义本人外部的零碎的数据结构。次要应用的构造如下：

这里次要介绍下咱们附加的一些字段以及依据本人场景的定义：

type

从外表上看 Source 和 type 都形容了以后事件产生的零碎，不同的是 type 中是一个结构化的数据，依照这个构造咱们对应的计费、效率统计模块，就能够拿到这个数据去做相干一些干线逻辑的解决了。

resources：变更资源列表

即标识以后事件触发了哪些相干资源的扭转，比方虚机增加硬盘，实际上是蕴含了两种资源即虚机与对应的磁盘资源

整合服务目录

后面提到咱们应用服务和提供的 API 标准实现了一个服务代理模块，在服务代理模块中 Cloudevent 的次要应用场景如下：

1. 服务目录接管到服务变更申请后，保留数据库后，产生对应的 cloudevent 事件到音讯队列
2. 在音讯队列中设定对应的路由转发规定，将对应的事件产生给服务代理模块
3. 服务代理模块依据 type 字段进行解析，获取对应的后端服务地址，并从音讯中解析出对应的数据，将数据发送给后端实在的服务
4. 后端实在服务接管到结构化数据后，进行本人的业务逻辑解决，解决实现后发送对应的事件
5. 服务代理模块依据事件解析出相干的资源，调用对应的平台获取以后资源的数据，生成事件
6. 服务目录模块接管到对应的服务实例数据，存储到本人的数据库中

如果后续有变更则只须要产生对应的事件产生到音讯队列中，会反复进行 5 - 6 阶段

链路尽管有点长，但其实整个链路的零碎设计非常简单，零碎之间的通信、可靠性、容错、耦合性都不须要关注(音讯队列服务来保障)，后续如果要扩大，就再怼个模块就能够了。要生产新的事件，就再写个新的接口，而后编辑下路由规定，就能够实现新的模块的接入了。

后续

最近身材不好，明天刚去完医院，不能老熬夜。心愿接下来能把我的项目进度赶上，前面就会有更多的场景了，年前要是进度赶上了，我就把想做的利用治理那个模块这块的代码实际抽空给写了，而后给大家分享下利用治理那块基于上述的实际，不过要是我的项目被砍了，就到这了吧。等最近下层的概念介绍完了，就给大家分享一些源码上的设计，如果跟我做相似方向的敌人，也欢送加微信交换交换。

云原生学习笔记地址: https://www.yuque.com/baxiaoshi/tyado3)
微信号：baxiaoshi2020 公共号: 图解源码

微信号：baxiaoshi2020
关注布告号浏览更多源码剖析文章
本文由博客一文多发平台 OpenWrite 公布！