本篇文章给大家分享的是有关基于云原生CloudEvent如何实现服务目录，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
基于事件驱动的系统架构在日常的平台开发中早已司空见惯，通过消息队列进行事件的发送，然后分别构建对应的生产者和消费者。不过在传统的业务开发模式不同的事件会有不同的格式，不同的生产者生成出的事件格式也各不相同，消费者能消费的格式也是千差万别，本质上事件、生产者、消费者还是耦合的。那如何解决该问题呢？那就是我们今天要聊的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来实现 服务消费端解析消息队列传递过来的事件信息，解析出对应的数据结构，然后进行业务处理即可。后续如果增加模块，或者增加新的事件消费需求，只需要实现对应的逻辑即可
