添加額外的Schema Registry註冊表權重？

Question

在生成/消費者消息時添加Schema Registry的附加層（又稱失敗點）是否有任何好處？如果服務發生故障，則不會消耗或生成消息。使用卡夫卡的系統不會因爲不使用架構註冊表而導致錯誤少一點，從而不易發生錯誤？

Answer 1

在您的體系結構中擁有模式註冊表的一個關鍵點是確保您的數據管道即使在正常操作期間也是端到端工作的「。也就是說，即使所有系統啓動並運行（「全部綠色，100％正常運行！」），由團隊A管理的生產者應用程序可能會得到更新，並且現在開始生成不兼容的數據，這些數據導致對下游消費者造成的附帶損害，這​​些下游消費者由團隊B和C管理，他們並不期待這種變化。

因此，當您決定是否使用模式註冊表時，您不僅應該問自己「何時失敗」的情況（這很可能會在某個時候發生，這就是爲什麼例如Confluent模式註冊表支持諸如高可用性設置之類的功能），但是關於數據管道所需的一般保證。

如果服務發生故障，則不會消耗或生成消息。

一般來說，是的。實際上，架構註冊表服務的高可用性模式，模式的客戶端緩存等功能都有助於最大限度地減少任何此類損害。

使用卡夫卡的系統不會因爲不使用架構註冊表而導致錯誤少一點，從而不會出現錯誤？

你是對的，一般來說，你想避免引入一個組件，這將是鏈中的另一個失敗點。也就是說，如果您正在生產中運行數據管道 - 特別是在一個更大的組織中 - 模式註冊中心還有助於通過確保寫入的數據始終可以讀取來消除「故障點」。有人可能會爭辯說，由「數據變化」引發的故障至少可以和由於一個或多個系統不可用而引發的故障一樣常見。

Answer 2

模式註冊表可以配置爲highly available，因此它不是單點故障。

也就是說，如果您需要模式註冊表附帶的便利性和模式兼容性規則，那麼您希望使用它。並非所有連接到Kafka集羣的客戶端都需要使用它，因此您可以嘗試它，而不會影響同一集羣上的其他客戶端。

對於avro消息使用模式註冊表的主要替代方法是將模式添加到消息本身。一些用戶對於較大的消息大小並沒有系統地演進架構是可以的。模式註冊表適用於那些關心這些事情的人。