Cloudevent是云原生基金会支持的一个开源项目，希望给云中传递的事件提供一个统一的标准，从而使云事件的传递更具有互操作性、可移植性、跨平台性。
参考链接https://github.com/cloudevents/spec/blob/v1.0/primer.md
服务器中常见的场景就是一个系统的状态改变导致另一个系统中的代码执行。状态改变体现为一个事件的产生，而经过某种通信协议传递给另一个系统触发相应的代码执行。
产生消息（message）的我们称之为源（source），源算是源这种类型的一个实例（与之前triggerflow中的思想一致）。源作为一种托管服务应该成为一个类似api网关的地方，接收消息并生成标准的事件发给指定的函数。
CloudEvent认为事件仅仅就只是事实（fact），函数的构建以及调用过程、特定的运行时api、选择访问控制系统同、协议级的路由信息、事件持久化流程不应该位于其中。这些内容都可以交给其它部分来做，不应该放到CloudEvent中，这会导致事件变得更臃肿，无法让事件生产者与消费者解耦。
CloudEvent仅仅只是一种事件格式，如果放在http中就是data字段的内容，因此如果需要处理事件还是需要开发者自行编程分条件进行判断。
CloudEvent中的属性之id id需要保证来自同一个事件源的事件之间不会有重复的id，仅作为唯一性检查
目前CloudEvent已经推出了多种语言的SDK，可以用于产生、发送、接收云事件
CloudEvent对部分术语的定义：
Occurrence：发生，指事件逻辑上的发生，基于某种情况，事件出现了。
Event：事件，表示事件以及上下文的数据记录。可以根据事件中的信息决定路由，但事件本身并不包含路由信息。
Producer：生产者，真正创造事件的实例，这个事件就是cloudevent
Source：源，事件发生的上下文，可以由多个producer组成。
Consumer：消费者，接收事件并采取行动
Intermediary：中介，接收包含事件的消息（message），并转发给下一个接收方，类似路由器
Context：上下文，上下文元数据被封装到context attributes中。用来判断事件与其它系统的关系
Data：数据，也可以叫做payload，相对自由。
EventFormat：事件格式，例如json
Message：消息，封装事件并将其从source传递到destination。
Protocol：协议，可以是行业标准如http，开源协议如kafka或者供应商协议如AWS Kinesis。
Protocol Binding：协议绑定，描述如何通过给定的协议收发事件，如何将事件放到消息里。
考虑到跨平台的问题，所以CE（缩写，全写太麻烦了）要求属性名全部是小写字母加数字，长度不超过20个字符（a-z，0-9），
所有上下文属性的值必须是符合国际标准的bool,int,string,binary,uri,uri-reference,timestamp，从而确保无论是强类型还是弱类型语言都能完成转换。
更具体地类型参考https://github.com/cloudevents/spec/blob/v1.0/spec.md。里面包括名称、数据类型和描述都很详细。
一个事件必须有id、事件源、cloudevent的版本、事件类型（可用于路由，具有可观察性，用来实施策略，由生产者定义）
eventdata属于扩展属性，用来供生产者自定义使用。
考虑到中介可以接受的数据包大小不同，所以中介需要转发不超过64KB的事件，而接收者由于解析协议的原因，所以必须接受大于64KB的事件
最后是一些安全上的考量，上下文中不应该有敏感信息，同时生产者，消费者和中介都应该具有自省上下文的能力
数据应该考虑加密机制，但是这部分内容属于生产者与消费者的秘密协议，不应该由cloudevent考虑
协议绑定要求协议本身是安全的。