首次嘗試翻譯技術(shù)文章。原文：gRPC Motivation and Design Principles (http://www.grpc.io/posts/principles/)

動(dòng)機(jī)

十多年來(lái)，谷歌一直使用一個(gè)叫做Stubby的通用RPC基礎(chǔ)框架，用它來(lái)連接在我們數(shù)據(jù)中心內(nèi)和跨數(shù)據(jù)中心運(yùn)行的大量微服務(wù)。我們的內(nèi)部系統(tǒng)早就接受了如今越來(lái)越流行的微服務(wù)架構(gòu)。擁有一個(gè)統(tǒng)一的、跨平臺(tái)的RPC的基礎(chǔ)框架，使得服務(wù)的首次發(fā)行在效率、安全性、可靠性和行為分析上得到全面提升，這是支撐這一時(shí)期谷歌快速增長(zhǎng)的關(guān)鍵。

Stubby有許多非常棒的特性，然而，它沒(méi)有基于任何標(biāo)準(zhǔn)，而且與我們內(nèi)部的基礎(chǔ)框架耦合得太緊密以至于被認(rèn)為不適合公開發(fā)布。隨著SPDY、HTTP/2和QUIC的到來(lái)，許多類似特性在公共標(biāo)準(zhǔn)中出現(xiàn)，并提供了Stubby不支持的其它功能。很明顯，是時(shí)候利用這些標(biāo)準(zhǔn)來(lái)重寫Stubby，并將其適用性擴(kuò)展到移動(dòng)、物聯(lián)網(wǎng)和云場(chǎng)景。

原則和訴求

服務(wù)而非對(duì)象、消息而非引用 —— 促進(jìn)微服務(wù)的系統(tǒng)間粗粒度消息交互設(shè)計(jì)理念，同時(shí)避免分布式對(duì)象的陷阱和分布式計(jì)算的謬誤。

普遍并且簡(jiǎn)單 —— 該基礎(chǔ)框架應(yīng)該在任何流行的開發(fā)平臺(tái)上適用，并且易于被個(gè)人在自己的平臺(tái)上構(gòu)建。它在CPU和內(nèi)存有限的設(shè)備上也應(yīng)該切實(shí)可行。

免費(fèi)并且開源 —— 所有人可免費(fèi)使用基本特性。以友好的許可協(xié)議開源方式發(fā)布所有交付件。

互通性 —— 該數(shù)據(jù)傳輸協(xié)議(Wire Protocol)必須遵循普通互聯(lián)網(wǎng)基礎(chǔ)框架。

通用并且高性能 —— 該框架應(yīng)該適用于絕大多數(shù)用例場(chǎng)景，相比針對(duì)特定用例的框架，該框架只會(huì)犧牲一點(diǎn)性能。

分層的 —— 該框架的關(guān)鍵是必須能夠獨(dú)立演進(jìn)。對(duì)數(shù)據(jù)傳輸格式(Wire Format)的修改不應(yīng)該影響應(yīng)用層。

負(fù)載無(wú)關(guān)的 —— 不同的服務(wù)需要使用不同的消息類型和編碼，例如protocol buffers、JSON、XML和Thrift，協(xié)議上和實(shí)現(xiàn)上必須滿足這樣的訴求。類似地，對(duì)負(fù)載壓縮的訴求也因應(yīng)用場(chǎng)景和負(fù)載類型不同而不同，協(xié)議上應(yīng)該支持可插拔的壓縮機(jī)制。

流 —— 存儲(chǔ)系統(tǒng)依賴于流和流控來(lái)傳遞大數(shù)據(jù)集。像語(yǔ)音轉(zhuǎn)文本或股票代碼等其它服務(wù)，依靠流表達(dá)時(shí)間相關(guān)的消息序列。

阻塞式和非阻塞式 —— 支持異步和同步處理在客戶端和服務(wù)端間交互的消息序列。這是在某些平臺(tái)上縮放和處理流的關(guān)鍵。

取消和超時(shí) —— 有的操作可能會(huì)用時(shí)很長(zhǎng)，客戶端運(yùn)行正常時(shí)，可以通過(guò)取消操作讓服務(wù)端回收資源。當(dāng)任務(wù)因果鏈被追蹤時(shí)，取消可以級(jí)聯(lián)。客戶端可能會(huì)被告知調(diào)用超時(shí)，此時(shí)服務(wù)就可以根據(jù)客戶端的需求來(lái)調(diào)整自己的行為。

Lameducking —— 服務(wù)端必須支持優(yōu)雅關(guān)閉，優(yōu)雅關(guān)閉時(shí)拒絕新請(qǐng)求，但繼續(xù)處理正在運(yùn)行中的請(qǐng)求。

流控 —— 在客戶端和服務(wù)端之間，計(jì)算能力和網(wǎng)絡(luò)容量往往是不平衡的。流控可以更好的緩沖管理，以及保護(hù)系統(tǒng)免受來(lái)自異常活躍對(duì)端的拒絕服務(wù)(DOS)攻擊。

可插拔的 —— 數(shù)據(jù)傳輸協(xié)議(Wire Protocol)只是功能完備API基礎(chǔ)框架的一部分。大型分布式系統(tǒng)需要安全、健康檢查、負(fù)載均衡和故障恢復(fù)、監(jiān)控、跟蹤、日志等。實(shí)現(xiàn)上應(yīng)該提供擴(kuò)展點(diǎn)，以允許插入這些特性和默認(rèn)實(shí)現(xiàn)。

API擴(kuò)展 ——

可能的話，在服務(wù)間協(xié)作的擴(kuò)展應(yīng)該最好使用接口擴(kuò)展，而不是協(xié)議擴(kuò)展。這種類型的擴(kuò)展可以包括健康檢查、服務(wù)內(nèi)省、負(fù)載監(jiān)測(cè)和負(fù)載均衡分配。

元數(shù)據(jù)交換 —— 常見(jiàn)的橫切關(guān)注點(diǎn)，如認(rèn)證或跟蹤，依賴數(shù)據(jù)交換，但這不是服務(wù)公共接口中的一部分。部署依賴于他們將這些特性以不同速度演進(jìn)到服務(wù)暴露的個(gè)別API的能力。

標(biāo)準(zhǔn)化狀態(tài)碼 —— 客戶端通常以有限的方式響應(yīng)API調(diào)用返回的錯(cuò)誤。應(yīng)該限制狀態(tài)代碼名字空間，使得這些錯(cuò)誤處理決定更清晰。如果需要更豐富的特定域的狀態(tài)，可以使用元數(shù)據(jù)交換機(jī)制來(lái)提供。

最初由Louis Ryan在谷歌其他同事幫助下寫成。