unify the translations of backward/forward compatibility

Author: yingang

ch4.md

@@ -65,7 +65,7 @@
 
 * 这类编码通常与特定的编程语言深度绑定，其他语言很难读取这种数据。如果以这类编码存储或传输数据，那你就和这门语言绑死在一起了。并且很难将系统与其他组织的系统（可能用的是不同的语言）进行集成。
 * 为了恢复相同对象类型的数据，解码过程需要 **实例化任意类** 的能力，这通常是安全问题的一个来源【5】：如果攻击者可以让应用程序解码任意的字节序列，他们就能实例化任意的类，这会允许他们做可怕的事情，如远程执行任意代码【6,7】。
-* 在这些库中，数据版本控制通常是事后才考虑的。因为它们旨在快速简便地对数据进行编码，所以往往忽略了前向后向兼容性带来的麻烦问题。
+* 在这些库中，数据版本控制通常是事后才考虑的。因为它们旨在快速简便地对数据进行编码，所以往往忽略了向前和向后兼容性带来的麻烦问题。
 * 效率（编码或解码所花费的 CPU 时间，以及编码结构的大小）往往也是事后才考虑的。 例如，Java 的内置序列化由于其糟糕的性能和臃肿的编码而臭名昭著【8】。
 
 因此，除非临时使用，采用语言内置编码通常是一个坏主意。
@@ -410,7 +410,7 @@ REST 风格的 API 倾向于更简单的方法，通常涉及较少的代码生
 
 #### 远程过程调用（RPC）的问题
 
-Web 服务仅仅是通过网络进行 API 请求的一系列技术的最新版本，其中许多技术受到了大量的炒作，但是存在严重的问题。 Enterprise JavaBeans（EJB）和 Java 的 **远程方法调用（RMI）** 仅限于 Java。**分布式组件对象模型（DCOM）** 仅限于 Microsoft 平台。**公共对象请求代理体系结构（CORBA）** 过于复杂，不提供前向或后向兼容性【41】。
+Web 服务仅仅是通过网络进行 API 请求的一系列技术的最新版本，其中许多技术受到了大量的炒作，但是存在严重的问题。 Enterprise JavaBeans（EJB）和 Java 的 **远程方法调用（RMI）** 仅限于 Java。**分布式组件对象模型（DCOM）** 仅限于 Microsoft 平台。**公共对象请求代理体系结构（CORBA）** 过于复杂，不提供向后或向前兼容性【41】。
 
 所有这些都是基于 **远程过程调用（RPC）** 的思想，该过程调用自 20 世纪 70 年代以来一直存在【42】。 RPC 模型试图向远程网络服务发出请求，看起来与在同一进程中调用编程语言中的函数或方法相同（这种抽象称为位置透明）。尽管 RPC 起初看起来很方便，但这种方法根本上是有缺陷的【43,44】。网络请求与本地函数调用非常不同：
 
@@ -437,9 +437,9 @@ Web 服务仅仅是通过网络进行 API 请求的一系列技术的最新版
 
 #### 数据编码与RPC的演化
 
-对于可演化性，重要的是可以独立更改和部署 RPC 客户端和服务器。与通过数据库流动的数据相比（如上一节所述），我们可以在通过服务进行数据流的情况下做一个简化的假设：假定所有的服务器都会先更新，其次是所有的客户端。因此，你只需要在请求上具有向后兼容性，并且对响应具有前向兼容性。
+对于可演化性，重要的是可以独立更改和部署 RPC 客户端和服务器。与通过数据库流动的数据相比（如上一节所述），我们可以在通过服务进行数据流的情况下做一个简化的假设：假定所有的服务器都会先更新，其次是所有的客户端。因此，你只需要在请求上具有向后兼容性，并且对响应具有向前兼容性。
 
-RPC 方案的前后向兼容性属性从它使用的编码方式中继承：
+RPC 方案的向后和向前兼容性属性是从它使用的编码方式中继承而来：
 
 * Thrift、gRPC（Protobuf）和 Avro RPC 可以根据相应编码格式的兼容性规则进行演变。
 * 在 SOAP 中，请求和响应是使用 XML 模式指定的。这些可以演变，但有一些微妙的陷阱【47】。
@@ -489,7 +489,7 @@ Actor 模型是单个进程中并发的编程模型。逻辑被封装在 actor 
 
 三个流行的分布式 actor 框架处理消息编码如下：
 
-* 默认情况下，Akka 使用 Java 的内置序列化，不提供前向或后向兼容性。 但是，你可以用类似 Prototol Buffers 的东西替代它，从而获得滚动升级的能力【50】。
+* 默认情况下，Akka 使用 Java 的内置序列化，不提供向前或向后兼容性。 但是，你可以用类似 Prototol Buffers 的东西替代它，从而获得滚动升级的能力【50】。
 * Orleans 默认使用不支持滚动升级部署的自定义数据编码格式；要部署新版本的应用程序，你需要设置一个新的集群，将流量从旧集群迁移到新集群，然后关闭旧集群【51,52】。 像 Akka 一样，可以使用自定义序列化插件。
 * 在 Erlang OTP 中，对记录模式进行更改是非常困难的（尽管系统具有许多为高可用性设计的功能）。 滚动升级是可能的，但需要仔细计划【53】。 一个新的实验性的 `maps` 数据类型（2014 年在 Erlang R17 中引入的类似于 JSON 的结构）可能使得这个数据类型在未来更容易【54】。
 
@@ -504,17 +504,17 @@ Actor 模型是单个进程中并发的编程模型。逻辑被封装在 actor 
 
 我们讨论了几种数据编码格式及其兼容性属性：
 
-* 编程语言特定的编码仅限于单一编程语言，并且往往无法提供前向和后向兼容性。
+* 编程语言特定的编码仅限于单一编程语言，并且往往无法提供向前和向后兼容性。
 * JSON、XML 和 CSV 等文本格式非常普遍，其兼容性取决于你如何使用它们。他们有可选的模式语言，这有时是有用的，有时是一个障碍。这些格式对于数据类型有些模糊，所以你必须小心数字和二进制字符串。
-* 像 Thrift、Protocol Buffers 和 Avro 这样的二进制模式驱动格式允许使用清晰定义的前向和后向兼容性语义进行紧凑，高效的编码。这些模式可以用于静态类型语言的文档和代码生成。但是，他们有一个缺点，就是在数据可读之前需要对数据进行解码。
+* 像 Thrift、Protocol Buffers 和 Avro 这样的二进制模式驱动格式允许使用清晰定义的向前和向后兼容性语义进行紧凑、高效的编码。这些模式可以用于静态类型语言的文档和代码生成。但是，他们有一个缺点，就是在数据可读之前需要对数据进行解码。
 
 我们还讨论了数据流的几种模式，说明了数据编码重要性的不同场景：
 
 * 数据库，写入数据库的进程对数据进行编码，并从数据库读取进程对其进行解码
 * RPC 和 REST API，客户端对请求进行编码，服务器对请求进行解码并对响应进行编码，客户端最终对响应进行解码
 * 异步消息传递（使用消息代理或参与者），其中节点之间通过发送消息进行通信，消息由发送者编码并由接收者解码
 
-我们可以小心地得出这样的结论：后向/前向兼容性和滚动升级在某种程度上是可以实现的。愿你的应用程序的演变迅速、敏捷部署。
+我们可以小心地得出这样的结论：向后/向前兼容性和滚动升级在某种程度上是可以实现的。愿你的应用程序的演变迅速、敏捷部署。
 
 
 ## 参考文献

zh-tw/ch4.md

@@ -65,7 +65,7 @@
 
 * 這類編碼通常與特定的程式語言深度繫結，其他語言很難讀取這種資料。如果以這類編碼儲存或傳輸資料，那你就和這門語言綁死在一起了。並且很難將系統與其他組織的系統（可能用的是不同的語言）進行整合。
 * 為了恢復相同物件型別的資料，解碼過程需要 **例項化任意類** 的能力，這通常是安全問題的一個來源【5】：如果攻擊者可以讓應用程式解碼任意的位元組序列，他們就能例項化任意的類，這會允許他們做可怕的事情，如遠端執行任意程式碼【6,7】。
-* 在這些庫中，資料版本控制通常是事後才考慮的。因為它們旨在快速簡便地對資料進行編碼，所以往往忽略了前向後向相容性帶來的麻煩問題。
+* 在這些庫中，資料版本控制通常是事後才考慮的。因為它們旨在快速簡便地對資料進行編碼，所以往往忽略了向前和向後相容性帶來的麻煩問題。
 * 效率（編碼或解碼所花費的 CPU 時間，以及編碼結構的大小）往往也是事後才考慮的。 例如，Java 的內建序列化由於其糟糕的效能和臃腫的編碼而臭名昭著【8】。
 
 因此，除非臨時使用，採用語言內建編碼通常是一個壞主意。
@@ -410,7 +410,7 @@ REST 風格的 API 傾向於更簡單的方法，通常涉及較少的程式碼
 
 #### 遠端過程呼叫（RPC）的問題
 
-Web 服務僅僅是透過網路進行 API 請求的一系列技術的最新版本，其中許多技術受到了大量的炒作，但是存在嚴重的問題。 Enterprise JavaBeans（EJB）和 Java 的 **遠端方法呼叫（RMI）** 僅限於 Java。**分散式元件物件模型（DCOM）** 僅限於 Microsoft 平臺。**公共物件請求代理體系結構（CORBA）** 過於複雜，不提供前向或後向相容性【41】。
+Web 服務僅僅是透過網路進行 API 請求的一系列技術的最新版本，其中許多技術受到了大量的炒作，但是存在嚴重的問題。 Enterprise JavaBeans（EJB）和 Java 的 **遠端方法呼叫（RMI）** 僅限於 Java。**分散式元件物件模型（DCOM）** 僅限於 Microsoft 平臺。**公共物件請求代理體系結構（CORBA）** 過於複雜，不提供向後或向前相容性【41】。
 
 所有這些都是基於 **遠端過程呼叫（RPC）** 的思想，該過程呼叫自 20 世紀 70 年代以來一直存在【42】。 RPC 模型試圖向遠端網路服務發出請求，看起來與在同一程序中呼叫程式語言中的函式或方法相同（這種抽象稱為位置透明）。儘管 RPC 起初看起來很方便，但這種方法根本上是有缺陷的【43,44】。網路請求與本地函式呼叫非常不同：
 
@@ -437,9 +437,9 @@ Web 服務僅僅是透過網路進行 API 請求的一系列技術的最新版
 
 #### 資料編碼與RPC的演化
 
-對於可演化性，重要的是可以獨立更改和部署 RPC 客戶端和伺服器。與透過資料庫流動的資料相比（如上一節所述），我們可以在透過服務進行資料流的情況下做一個簡化的假設：假定所有的伺服器都會先更新，其次是所有的客戶端。因此，你只需要在請求上具有向後相容性，並且對響應具有前向相容性。
+對於可演化性，重要的是可以獨立更改和部署 RPC 客戶端和伺服器。與透過資料庫流動的資料相比（如上一節所述），我們可以在透過服務進行資料流的情況下做一個簡化的假設：假定所有的伺服器都會先更新，其次是所有的客戶端。因此，你只需要在請求上具有向後相容性，並且對響應具有向前相容性。
 
-RPC 方案的前後向相容性屬性從它使用的編碼方式中繼承：
+RPC 方案的向後和向前相容性屬性是從它使用的編碼方式中繼承而來：
 
 * Thrift、gRPC（Protobuf）和 Avro RPC 可以根據相應編碼格式的相容性規則進行演變。
 * 在 SOAP 中，請求和響應是使用 XML 模式指定的。這些可以演變，但有一些微妙的陷阱【47】。
@@ -489,7 +489,7 @@ Actor 模型是單個程序中併發的程式設計模型。邏輯被封裝在 a
 
 三個流行的分散式 actor 框架處理訊息編碼如下：
 
-* 預設情況下，Akka 使用 Java 的內建序列化，不提供前向或後向相容性。 但是，你可以用類似 Prototol Buffers 的東西替代它，從而獲得滾動升級的能力【50】。
+* 預設情況下，Akka 使用 Java 的內建序列化，不提供向前或向後相容性。 但是，你可以用類似 Prototol Buffers 的東西替代它，從而獲得滾動升級的能力【50】。
 * Orleans 預設使用不支援滾動升級部署的自定義資料編碼格式；要部署新版本的應用程式，你需要設定一個新的叢集，將流量從舊叢集遷移到新叢集，然後關閉舊叢集【51,52】。 像 Akka 一樣，可以使用自定義序列化外掛。
 * 在 Erlang OTP 中，對記錄模式進行更改是非常困難的（儘管系統具有許多為高可用性設計的功能）。 滾動升級是可能的，但需要仔細計劃【53】。 一個新的實驗性的 `maps` 資料型別（2014 年在 Erlang R17 中引入的類似於 JSON 的結構）可能使得這個資料型別在未來更容易【54】。
 
@@ -504,17 +504,17 @@ Actor 模型是單個程序中併發的程式設計模型。邏輯被封裝在 a
 
 我們討論了幾種資料編碼格式及其相容性屬性：
 
-* 程式語言特定的編碼僅限於單一程式語言，並且往往無法提供前向和後向相容性。
+* 程式語言特定的編碼僅限於單一程式語言，並且往往無法提供向前和向後相容性。
 * JSON、XML 和 CSV 等文字格式非常普遍，其相容性取決於你如何使用它們。他們有可選的模式語言，這有時是有用的，有時是一個障礙。這些格式對於資料型別有些模糊，所以你必須小心數字和二進位制字串。
-* 像 Thrift、Protocol Buffers 和 Avro 這樣的二進位制模式驅動格式允許使用清晰定義的前向和後向相容性語義進行緊湊，高效的編碼。這些模式可以用於靜態型別語言的文件和程式碼生成。但是，他們有一個缺點，就是在資料可讀之前需要對資料進行解碼。
+* 像 Thrift、Protocol Buffers 和 Avro 這樣的二進位制模式驅動格式允許使用清晰定義的向前和向後相容性語義進行緊湊、高效的編碼。這些模式可以用於靜態型別語言的文件和程式碼生成。但是，他們有一個缺點，就是在資料可讀之前需要對資料進行解碼。
 
 我們還討論了資料流的幾種模式，說明了資料編碼重要性的不同場景：
 
 * 資料庫，寫入資料庫的程序對資料進行編碼，並從資料庫讀取程序對其進行解碼
 * RPC 和 REST API，客戶端對請求進行編碼，伺服器對請求進行解碼並對響應進行編碼，客戶端最終對響應進行解碼
 * 非同步訊息傳遞（使用訊息代理或參與者），其中節點之間透過傳送訊息進行通訊，訊息由傳送者編碼並由接收者解碼
 
-我們可以小心地得出這樣的結論：前向相容性和滾動升級在某種程度上是可以實現的。願你的應用程式的演變迅速、敏捷部署。
+我們可以小心地得出這樣的結論：向後/向前相容性和滾動升級在某種程度上是可以實現的。願你的應用程式的演變迅速、敏捷部署。
 
 
 ## 參考文獻