CloudEvent 初探

CloudEvent

CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems.

CloudEvent 重点在于跨平台, 跨服务, 跨系统的一个跨字. 重在适应性, 通用性.     

该类用户认为, 世界上无处不在事件, 行为均可看作是事件驱动. 也认为这样消耗比是最低的(我的看法)因为事件->行为 这一个模式是典型的按需供应资源.

CloudEvent 我认为意在跨不同的云, 不同的数据源, 比如你在 阿里云的数据应用和在 亚马逊的数据应用, 是不能互通的, 至少同一个软件不行. 任意数据的变动, CloudEvent 或者 CNCF 认为是一个 Occurrence. 不同的 Occurrence 触发的事件是各个云服务商, 各个软件, 各个协议所独有的. 这给云原生或者大混合云(我取的名字, 意为以混合云服务为主的云服务商经营的云集群)带来了不方便. 不方便之处在于, 开发者的任意一款产品, 是在单独的一片云上原生的. 我认为 CNCF 一直致力于制定一个标准解决这一个问题.

下图是 go-sdk 中 event 的定义.

我尤其注意到的是事件携带有错误域, 我认为这给了 Occurrence 方的适配层或者用户一个处理的机会. 但最重要的是, 事件发生的错误也是 CloudEvent 的一部分.

更新: 我看了之后发现, 和我现在做的 MQ 是一样的思路. 通过 CloudEvent.New 生成不同的 Client 针对不同的通信方式并进行通信. go-sdk 相当于为不同的传输方式(协议) 实现了 CloudEvent 定义的 Transport 接口.
该类实现由 amqp, http , nats, pubsub 定义在 pkg/cloudevent/transport 下

此时看 Client 的接口, 可以看到仅发送和接收两个方法, 看注释 可以接受很多种函数签名. 如何从 fn interface{} 中断定 fn 是哪一种呢.

找到 Receive 的 func 签名可以看到, 实际上所有的签名都是用的一个, 即三个参数和 error 返回值都有的签名. 只是传入的时候, 会转换为 receiveFn 结构体判断用户的自定义 fn 回调有哪些参数, 从而不使用哪一些.

最后根据 receiveFn 的结构来传入参数们

我们看一看 CloudEvent 支持的协议如下. 但是数据源并不只是由这些协议的承载体(你写的程序). 还有包括 github, aws , gitlab 等, 均可产生消息. 这时候用到了 CloudEvent Adapters 这一个工具了.
类似于 Prometheus Exporter 的作用. 作为适配层, 将 CloudEvent 需要的 Event 元数据解出来使用.
https://github.com/cloudevents/spec/blob/master/adapters/github.md 用于参考 GitHub webhook events 是如何转换成 CloudEvents 的.

综上 CloudEvent 是一个规约, 他贯彻了 CNCF 规范云的思想. CloudEvent 定义了一个事件系统, 让云原生程序(函数)不仅只需要关注自己本身业务, 同时让云原生程序在不同的云之间依然具有鲁棒性. 如果云上有操作系统, CloudEvent 就是他的协议层.

如果了解更多, 可以查看 CloudEvent 的 Primer