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考慮
協議綁定要求協議本身是安全的。