在分散式系統與事件驅動架構中，確保資料格式的一致性至關重要。這就是為什麼我們需要 Schema Registry，它像是一個中央圖書館，定義了資料的結構（Schema），並為每個版本分配一個唯一的 Schema ID。當 Producer 發送訊息時，Consumer 必須知道該使用哪個 Schema ID 才能正確地將二進位資料還原（Deserialize）成可讀的物件。
在傳統的 Confluent Wire Format 實作中，Schema ID 是直接被嵌入在訊息的 Payload（實際資料內容）最前面的幾個位元組中。這意味著想確保 Consumer 拿到資料後能立刻知道去哪裡找對應的 Schema，但這種做法在長期維運中帶來了嚴重的耦合問題。
Payload 與元數據的強耦合問題
當 Schema ID 存在於 Payload 中時，資料內容與其元數據（Metadata）被緊緊綁在一起。這會導致一個問題：如果你想在不改變資料內容的情況下對資料進行治理或驗證，你必須解析整個 Payload 才能獲取 ID。對於許多下游系統或分析工具來說，這種特殊的封裝格式讓資料不再是純粹的 Avro 或 Protobuf 格式，而是一種 Confluent 特有的封裝格式，增加了系統間的互操作性成本。
此外，當多個團隊共同消費同一組事件流時，任何關於 Schema 的演進或變更，往往需要 Producer 與 Consumer 之間高度同步的協調，否則很容易在解析 Payload 時發生錯誤，增加維運壓力。
將 Schema ID 移至 Kafka Header 的解決方案
為了降低耦合，Confluent 引入了將 Schema ID 儲存在 Kafka Record Headers 中的新機制。Kafka Header 允許在不影響 Payload 的情況下，為每條訊息附加鍵值對（Key-Value Pairs）。
現在，Schema ID 被移到了 Header 中，而 Payload 則恢復為純粹的資料格式。Consumer 在接收到訊息時，先從 Header 中讀取 Schema ID，再向 Schema Registry 請求對應的結構定義，最後才對 Payload 進行反序列化。
這種設計帶來了三個核心優勢。首先是解耦，資料內容與管理資訊分離，使得事件流更加靈活。其次是提升互操作性，因為 Payload 變回了標準的格式，像是 Apache Flink 或機器學習 pipeline 等下游工具可以更輕鬆地處理這些資料，而不需要處理 Confluent 的特定封裝邏輯。最後是降低協調成本，Producer 與 Consumer 可以更獨立地演進，驗證邏輯被集中在 Schema Registry 中。
實務上的導入與影響
對於現有的系統，這種改變支持漸進式採納。企業不需要一次性重寫所有程式碼，而是可以逐步將 Schema ID 附加到現有的事件流中，在維持向後相容性的前提下，逐步強化資料治理。
然而，在實作時需要注意，如果你的環境中使用了舊版的 Kafka Connector 或某些假設 Schema ID 必然存在於 Payload 中的下游工具，這些工具將需要更新才能支援從 Header 讀取 ID。在過渡期間，系統可能會同時存在兩種儲存方式，因此開發者需要確保客戶端能兼容處理這兩種情況。
總結來說，這次的調整將 Schema 治理從資料內容中抽離，讓 Kafka 訊息回歸到資料本身，大幅提升了大規模分散式系統在資料演進時的靈活性與維護品質。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。