“向后/向前兼容”的語義

Question

作為一個非英語母語的人，我總是對是否有一種任意的方式來命名以下客戶端/服務器互操作性場景感到困惑：

場景一：

clientN+1 - serverN+1
          \
clientN  -- serverN           where N is a concrete arch version

場景 B：

clientN+1 - serverN+1
          /
clientN  -- serverN           where N is a concrete arch version 

一種情況是否以任意方式稱為“向后兼容性”，另一種情況稱為“向前兼容性”？ 否則，如果兩者都可以根據引用以兩種方式調用，那么，場景 A 中的客戶端是向后兼容和服務器向前兼容還是相反？

Answer 1

當某些東西仍然可以連接到以前的版本時（我假設 A 中的客戶端 - 服務器）它與以前的版本“向后兼容”。 “Forwards compatibility”在英文中不常用，但意思相反。

示例 (A)：客戶端 N+1 向后兼容服務器 N，服務器 N 向前兼容客戶端 N+1

Answer 2

你問的是 API，但我將根據消息傳遞模式，特別是 kafka 來回答。 此消息傳遞場景中的前向/后向兼容性概念的子集可直接轉化為與常規 API 相同的兼容性概念。當涉及事件驅動微服務時，通過消息傳遞技術（例如 kafka）交換消息這種“消息傳遞 API”兼容性問題是您問題中“微服務 API”兼容性問題的唯一且更復雜的形式。

Kafka 有一個模式注冊服務。 您可以注冊一個架構，該架構定義了該主題允許的 json/avro/protobuf 消息。 您可以通過編輯模式來改進模式，它會保留模式版本的歷史記錄。 模式注冊表有一個完整的 API。它的使用是可選的。 您可以為針對此處描述的主題注冊的模式設置兼容級別。 因為它正在談論在嘗試根據分配給主題的以下模式兼容性注冊新模式時驗證/拒絕更新主題的模式。 為了清楚起見，我稍微編輯了文本：

• BACKWARD ：使用建議模式的消費者將能夠讀取生產者使用當前注冊模式寫入的數據
• BACKWARD_TRANSITIVE ：使用建議模式的消費者可以讀取生產者使用所有先前注冊的模式寫入的數據
• FORWARD ：使用最新注冊模式的消費者可以讀取生產者使用建議模式寫入的數據
• FORWARD_TRANSITIVE ：使用所有先前注冊模式的消費者可以讀取生產者使用建議模式寫入的數據
• FULL ：建議的模式與最新注冊的模式向前和向后兼容
• FULL_TRANSITIVE ：提議的模式向前和向后兼容所有以前注冊的模式
• NONE ：模式兼容性檢查被禁用

NONE是零保護。 您可以注冊一個沒有兼容性的新模式，並希望所有生產者和所有消費者同時更新為兼容。 年長的制作人會毒害這個話題。 老消費者在嘗試閱讀消息時會崩潰。

FULL是顯而易見的。 不允許進行重大更改，您可以添加可能存在的可選字段。 不提供可選字段的老生產者不會破壞不期望它的老消費者或新消費者。 新的生產者不會破壞舊的消費者，因為他們在從消息有效負載中讀取數據時會忽略可選字段。

在上面我們看到“方向”取決於我們正在考慮的是生產者還是消費者，這就是我們談論“向前”和“向后”兼容性的原因。

通常情況下，更新的是“數據提供者”，它“提供”最新版本的數據。 通常情況下，我們不想破壞舊的“數據閱讀器”。 在 kafka 的情況下，通常是更新主題模式的數據生產者團隊。 兼容性是他們是否會打破多個消費者。 在這種情況下，我們需要舊模式與新模式“向前”兼容。 真正復雜的地方在於，當我們讓老生產者向同一主題發送消息，同時新生產者向同一主題發送新消息時。

我不認為以英語為母語的人在這里真的是一個問題，這是一個有明確定義的問題。 對於具有單個“供應商”的簡單 API，我們可以向老讀者討論 API 消費者的“向前兼容性”或新 API 的“向后兼容性”。 我們很自然地談論以“向后兼容”的方式更新我們的 API。 然而，您要維護的實際上是所有現有 API 消費者的“向前兼容性”。 這是一個角度問題。