使用Protocol Buffers代替JSON的五個(gè)原因
在Ruby和Rails開發(fā)者中，面向服務(wù)(Service-Oriented)架構(gòu)有一個(gè)當(dāng)之無愧的名聲，它是一個(gè)緩解程序規(guī)模惡性增長的一個(gè)強(qiáng)有力的途徑，可在大量應(yīng)用程序中提取關(guān)注點(diǎn)。這些新生小巧的服務(wù)通常繼續(xù)使用Rails或Sinatra,并使用JSON在HTTP上通信。盡管JSON作為一個(gè)數(shù)據(jù)相互交換格式，有很多優(yōu)點(diǎn)：人類可讀、可理解，并通常表現(xiàn)出色。
瀏覽器和JS并不直接處理數(shù)據(jù)--尤其是遇到內(nèi)部服務(wù)時(shí)。我的觀點(diǎn)是，結(jié)構(gòu)化格式，例如谷歌的Protocol Buffers，是一個(gè)比JSON在編碼方面更好的選擇。如果你從來沒有使用過Protocol Buffers，你可以參看 這里。不要擔(dān)心，在說明為什么要選擇Protocol Buffers而不是JSON之前，本文會(huì)簡介如何使用在Ruby上使用它 。
Protocal Buffers的簡短介紹
首先，什么是Protocol Buffers？文檔中說：
“Protocol Buffers是一種以有效并可擴(kuò)展的格式編碼結(jié)構(gòu)化數(shù)據(jù)的方式。”
Google開發(fā)了Protocol Buffers使用于內(nèi)部的服務(wù)。 它是一種二進(jìn)制格式允許你使用規(guī)范的語言定義一個(gè)模式，例如：
- message Person {
- required int32 id = 1;
- required string name = 2;
- optional string email = 3;
- }
你能在命名空間中封裝他們或者用上面的方式在頂層聲明他們。這個(gè)片段定義了Person數(shù)據(jù)類型的模式，有三個(gè)字段：id, name和email。除了命名字段，你能提供一個(gè)類型決定數(shù)據(jù)怎樣編碼和在線上發(fā)送，在上面我們看到有int32類型和string類型。還提供了關(guān)鍵字進(jìn)行驗(yàn)證和結(jié)構(gòu)化（required 和optional ）。字段被編號(hào)，這有助于向后兼容，我將在以后詳細(xì)的介紹。
Protocol Buffers規(guī)范已被多種語言實(shí)現(xiàn)：Java,C,Go等。如果你四處找找最現(xiàn)代的語言都有實(shí)現(xiàn)的方式。Ruby也不例外，有幾個(gè)不同的Gems使用Protocol Buffers編碼和解碼數(shù)據(jù)。這就意味著，這個(gè)規(guī)范可以在不同語言實(shí)現(xiàn)的系統(tǒng)間傳遞數(shù)據(jù)。
例如，Ruby Gem安裝被稱為ruby-protoc的二進(jìn)制可以和主Protocol Buffers庫組合使用（在OSX中brew install protobuf），自動(dòng)的產(chǎn)生樁類文件用于編碼和解碼數(shù)據(jù)。正在運(yùn)行的二進(jìn)制proto文件產(chǎn)生以下的Ruby類：
- #!/usr/bin/env ruby
- # Generated by the protocol buffer compiler. DO NOT EDIT!
- require 'protocol_buffers'
- # forward declarations
- class Person < ::ProtocolBuffers::Message; end
- class Person < ::ProtocolBuffers::Message
- set_fully_qualified_name "Person"
- required :int32, :id, 1
- required :string, :name, 2
- optional :string, :email, 3
- end
正如你所見，通過支持這種模式（Protocol Buffer格式），用來編碼和解碼信息，我們就能自動(dòng)得到一個(gè)類（查看代碼ProtocolBuffers::Message的基類在Gem中有更多細(xì)節(jié)的介紹）。我們已經(jīng)看到了一些信息，那么就讓我們再來仔細(xì)看看這些特征點(diǎn)，讓我嘗試說服你考慮Protocol Buffers——這里有5個(gè)理由。
原因 #1: 模式本身很不錯(cuò)
有一種痛苦的諷刺指向一個(gè)事實(shí)，我們小心謹(jǐn)慎地在我們的數(shù)據(jù)庫里面編寫數(shù)據(jù)模型，維護(hù)各個(gè)層次的代碼，保持這些數(shù)據(jù)模型處于控制之中，當(dāng)我們想要發(fā)送數(shù)據(jù)連接到另一個(gè)服務(wù)的時(shí)候，要求所有的疑慮都要被考慮到。然而，我們往往依靠的是在邊界上與我們的系統(tǒng)之間不一致的代碼，我們的系統(tǒng)不能強(qiáng)制結(jié)構(gòu)化我們的數(shù)據(jù)組件，這是如此的重要，編碼的語義是你曾經(jīng)的業(yè)務(wù)對象，在proto格式中，它足以幫助并保證應(yīng)用程序之間的信號(hào)不會(huì)丟失，而界限就在你所創(chuàng)建并執(zhí)行的業(yè)務(wù)規(guī)則。
原因 #2: 無償?shù)叵蚝蠹嫒?
被編號(hào)的字段在proto的定義中排除了所需的版本檢查，這是其中一個(gè)被明確表述的動(dòng)機(jī)（為什么這樣設(shè)計(jì)和實(shí)現(xiàn)Protocol Buffers）。如同開發(fā)者文檔中聲明的那樣，協(xié)議被設(shè)計(jì)成能在一定程度上避免出現(xiàn)像下面這樣的“丑陋的代碼”，下面的代碼用來檢測協(xié)議的版本:
- if (version == 3) {
- ...
- } else if (version > 4) {
- if (version == 5) {
- ...
- }
- ...
- }
同編號(hào)字段一樣, 你必須改變編碼習(xí)慣，朝著能向老版本維護(hù)和向后兼容的方向改變。正如在文檔中的聲明那樣，曾經(jīng) Protocol Buffers 是這樣被介紹的：
“新的字段可以很容易被引入，并且不需要中間服務(wù)去檢查數(shù)據(jù)就能被解析，通過數(shù)據(jù)不必知道所有的字段。”
已經(jīng)部署各種JSON的服務(wù)器已經(jīng)遭受各種與發(fā)展模式以及向后兼容的相關(guān)問題。我現(xiàn)在深信編號(hào)字段能防止錯(cuò)誤，并且能在新功能和服務(wù)的推出上做到簡化。
原因 #3: 更少的樣本代碼
除了顯式的版本檢查和缺乏后續(xù)的兼容性，JSON終端在HTTP上的基礎(chǔ)服務(wù)通常依賴專門的手寫樣板代碼去處理Ruby對象的編碼和解碼。解析和反解析類常常包含隱藏的業(yè)務(wù)邏輯，它暴露了手動(dòng)解析每個(gè)新的數(shù)據(jù)類型的缺陷，當(dāng)一個(gè)類通過Protocol Buffers產(chǎn)生（你一般就不會(huì)再去觸碰它），它能提供大量相似的方法，還避免了大量頭痛的事情。隨著模式的發(fā)展，你將會(huì)用proto產(chǎn)生類（應(yīng)當(dāng)承認(rèn)，一旦你更新他們），你可以把更多的空間留給你所關(guān)注的挑戰(zhàn)（保持你的應(yīng)用運(yùn)行和持續(xù)構(gòu)建產(chǎn)品）。
原因 #4: 驗(yàn)證和可擴(kuò)展性
required，optional 和 repeated關(guān)鍵字在Protocol Buffers中的定義是非常強(qiáng)大的。它們允許你去編碼，在模式級(jí)別，形象化你的數(shù)據(jù)結(jié)構(gòu)和去實(shí)現(xiàn)類怎樣工作（每種編程語言處理）的細(xì)節(jié)。Ruby的protocol_buffers庫將會(huì)提升異常，例如：如果一個(gè)對象實(shí)例沒有填寫必填的字段，你試著去對這樣一個(gè)對象實(shí)例編碼，就會(huì)提升異常。通過簡單地編輯一個(gè)新的編號(hào)字段的值，你可以把一個(gè)字段從required變成optional或者反之亦然。有了這種靈活編碼的語義序列化格式，大大增強(qiáng)了其功能。
因?yàn)槟氵€可以嵌入proto，定義內(nèi)部的其他成員，你也可以擁有通用的Request和Response結(jié)構(gòu)，它還允許其他數(shù)據(jù)結(jié)構(gòu)的傳輸并確保傳輸連接上，它為服務(wù)器間通訊實(shí)現(xiàn)真正的靈活性和安全的數(shù)據(jù)傳輸提供了機(jī)會(huì)。類似Riak的數(shù)據(jù)庫系統(tǒng)使用Protocol Buffers有巨大的效果——因?yàn)橛辛艘恍﹩⑹荆医ㄗh重新審視那些接口。
原因#5：建議的語言互操作性
因?yàn)镻rotocol Buffers已經(jīng)被多種語言實(shí)現(xiàn)，在你的架構(gòu)中多語言混合的應(yīng)用程序之間的互操作性變得更簡單。如果你引入了一個(gè)新的服務(wù)在JAVA或者GO中，甚至和用Node或者Clojure或者Scala實(shí)現(xiàn)的后端通訊，你只需簡單的把proto文件交給目標(biāo)語言編寫的代碼生成器，你將在這些架構(gòu)之間獲得較好的安全和互操作性。平臺(tái)特定數(shù)據(jù)類型的細(xì)節(jié)被目標(biāo)語言處理，你將更多的關(guān)注你的問題的困難部分，而不是匹配字段和數(shù)據(jù)類型在JSON的編碼和解碼方案中。
什么時(shí)候更適合使用JSON?
有些時(shí)候JSON比Protocol Buffers更適合，包括如下的場景：
-
你需要或者想讓數(shù)據(jù)對人是可讀的
-
來自于服務(wù)的數(shù)據(jù)是直接發(fā)送到web瀏覽器
-
你的服務(wù)端應(yīng)用程序是用javaScript編寫的
-
你不準(zhǔn)備把數(shù)據(jù)模型綁定到模式上
-
你沒有帶寬添加另外一個(gè)工具到你的軍火庫
-
運(yùn)行不同類型的網(wǎng)絡(luò)服務(wù)的運(yùn)營負(fù)擔(dān)過大
可能還有更多的情況。***，總之，這是很重要的在心里權(quán)衡和不要盲目的選擇一項(xiàng)技術(shù)
結(jié)論
Protocol Buffers提供了幾種相對JSON在內(nèi)部服務(wù)之間在線傳輸數(shù)據(jù)的引人注目的優(yōu)勢。并沒有完全的替換JSON，特別是服務(wù)和web瀏覽器直接通訊的情況，Protocol Buffers提供了真正的優(yōu)勢不僅在上面概述的方法，也編解碼的速度和數(shù)據(jù)大小上有更多的優(yōu)勢。
你可以從你的應(yīng)用程序中提取出哪些服務(wù)？如果你今天不得不做出選擇，你會(huì)選擇JSON還是Protocol Buffers？讓我們討論討論-我們愿意在下面的評(píng)論中聽到更多關(guān)于你在使用JSON和Protocol Buffers上的經(jīng)驗(yàn)。
英文原文：5 Reasons to Use Protocol Buffers Instead of JSON For Your Next Service
譯文鏈接：http://www.oschina.net/translate/choose-protocol-buffers
