首次嘗試翻譯技術(shù)文章酵颁。原文：gRPC Motivation and Design Principles (http://www.grpc.io/posts/principles/)
動(dòng)機(jī)
十多年來怠硼，谷歌一直使用一個(gè)叫做Stubby的通用RPC基礎(chǔ)框架噩死，用它來連接在我們數(shù)據(jù)中心內(nèi)和跨數(shù)據(jù)中心運(yùn)行的大量微服務(wù)趁怔。我們的內(nèi)部系統(tǒng)早就接受了如今越來越流行的微服務(wù)架構(gòu)哥童。擁有一個(gè)統(tǒng)一的递宅、跨平臺(tái)的RPC的基礎(chǔ)框架歪泳，使得服務(wù)的首次發(fā)行在效率任斋、安全性继阻、可靠性和行為分析上得到全面提升，這是支撐這一時(shí)期谷歌快速增長(zhǎng)的關(guān)鍵废酷。
Stubby有許多非常棒的特性瘟檩，然而，它沒有基于任何標(biāo)準(zhǔn)澈蟆，而且與我們內(nèi)部的基礎(chǔ)框架耦合得太緊密以至于被認(rèn)為不適合公開發(fā)布墨辛。隨著SPDY、HTTP/2和QUIC的到來趴俘，許多類似特性在公共標(biāo)準(zhǔn)中出現(xiàn)睹簇，并提供了Stubby不支持的其它功能。很明顯寥闪，是時(shí)候利用這些標(biāo)準(zhǔn)來重寫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ù)載無關(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)依賴于流和流控來傳遞大數(shù)據(jù)集羔沙。像語音轉(zhuǎn)文本或股票代碼等其它服務(wù)，依靠流表達(dá)時(shí)間相關(guān)的消息序列厨钻。
阻塞式和非阻塞式 —— 支持異步和同步處理在客戶端和服務(wù)端間交互的消息序列扼雏。這是在某些平臺(tái)上縮放和處理流的關(guān)鍵。
取消和超時(shí) —— 有的操作可能會(huì)用時(shí)很長(zhǎng)夯膀，客戶端運(yùn)行正常時(shí)呢蛤，可以通過取消操作讓服務(wù)端回收資源。當(dāng)任務(wù)因果鏈被追蹤時(shí)棍郎，取消可以級(jí)聯(lián)其障。客戶端可能會(huì)被告知調(diào)用超時(shí)涂佃，此時(shí)服務(wù)就可以根據(jù)客戶端的需求來調(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)免受來自異常活躍對(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ù)交換 —— 常見的橫切關(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ī)制來提供舰始。
最初由Louis Ryan在谷歌其他同事幫助下寫成。
