Chronicle事件溯源的最佳實踐

Chronicle Software有兩個截然不同的事件溯源框架Chronicle Microservices Framework（CMF）和Chronicle Decentred。本演講有助於突出它們彼此之間的差異以及其他事件採購解決方案。
CMF建立在Chronicle Queue之上，專為低延遲交易系統而設計。複製通常是非同步的，以最小化延遲。
Chronicle Decentred是一個用於構建安全分散式分類賬（例如區塊鏈）的框架。它側重於高吞吐量而不是低延遲和拜占庭容錯。
David Schmitz 就他認為使用事件採購的最佳實踐進行了精彩的演講。大衛的演講適用於所有事件驅動系統，並且在演講中也有10分鐘時間適用於Chronicle的框架。

再交付
他指出，確保一次交付很難。
CMF方法是假設每個有效輸入都將輸出到已知佇列。這允許服務在上次成功釋出訊息後立即重新啟動。這種方法的好處是：

• 如果輸入訊息已傳送但服務在完成之前消失，則重新處理。
• 如果輸入訊息已處理但輸出訊息未成功寫入，則假定應對其進行重新處理，直到輸入訊息為止。
• 假設任何輸出訊息沒有輸出，沒有副作用並且可以重放，或者如果不能，則可以產生虛擬的“成功”訊息。

命令與查詢
CMF和Decentred旨在實時執行命令。要支援查詢，您需要維護事先知道的“實時”查詢或臨時查詢，維護您選擇的外部資料庫。

效能
這是CMF和Decentred差別很大的方式之一。
在他的演講中，David給出了一個服務示例，該服務在66毫秒內執行100次操作。這是0.66毫秒的平均延遲。
CMF旨在實現始終如一的低延遲，其中重點是系統看到的最差延遲。一個關鍵的衡量標準通常是99.9％達到低延遲，而不是平均或典型的延遲。
我們最近幫助一級銀行客戶構建了一個帶有3個微服務的訂單管理系統，其中線到線延遲低於20微秒，99.9％的時間用於每秒20,000條訊息的吞吐量。
Chronicle Decentred專為高吞吐量而設計。每個鏈可以在伺服器叢集中處理大量訊息，例如50K / s到400K / s，具體取決於硬體。但是，延遲是達到共識的時間，可能是5毫秒到500毫秒，具體取決於它們之間的網路

人類可讀的格式
為了支援模式更改，David提出了一種人類可讀的格式，可以在資料模型更改時更輕鬆地翻譯不同版本的資料傳輸物件。JSON是這樣做的常見選擇，但是，我發現它不像YAML那樣易讀。
人類可讀格式的一個缺點是它們沒有二進位制格式那麼快，因此，CMF和Decentred都支援YAML的二進位制格式，它可以自動轉換為YAML，但速度提高了2-3倍，並且作為較低階別的二進位制格式，它更快但不易維護。
YAML優於JSON的一些優點

• 更簡潔。
• 更好地支援複雜的資料型別。
• 直接支援型別和評論。

• 有關如何編寫資料的更多選項。
• 人類可讀性在旁觀者的眼中，使得編碼變得更加困難。
• 一個更簡單的規範，mroe跨語言的一致支援。
• YAML幾乎是一套超級JSON，但並不完整。例如，在屬性名稱之後，您需要YAML中的冒號空間，而JSON不需要空格。

批處理
在交易系統中，通常每天或每週執行一次。這可以透過以新事件開始時載入的事件形式拍攝快照來實現。大多數交易系統在一夜之間或週末都有很長的停機時間。

更新事件
事件驅動的系統不是為編寫事件而編寫的。事件失敗，在這種情況下，可以新增新的正確事件，或者事件成功但不正確，並且需要新增一個或多個事件來糾正或撤消操作。在設計之前，沒有簡單的方法來編輯事件。
擁有控制事件的優先順序佇列是相當普遍的，只要尚未處理修改的事件，這可用於注入刪除，取消或更正事件。
必須非常小心避免或管理任何可以執行的事件，但以後不能撤銷。

GDPR和加密資料
在不破壞整個佇列或流的情況下刪除資料的一種方法是使用與具有使用者特定金鑰的使用者相關的金鑰來加密所有資料。要“刪除”使用者，您只需刪除金鑰即可。Chronicle Queue支援外掛在編寫和讀取時加密和解密訊息，可以與金鑰管理整合。
另一種方法是匿名化資料，因此沒有任何流識別使用者，而是由其他系統處理。