文檔地址
- gRPC Motivation and Design Principles：英文原文
- GRPC的產生動機和設計原則: 此文的中文翻譯版本
讀後感
注：以下是個人的一點感觸
2015年3月的某一天，第一次接觸gRPC，當時的第一感覺： 這就是我要的東東！！
上面的這個文檔中，在闡述"原則和訴求"時，有幾點是特別打動我的：
服務而非對象、消息而非引用
促進微服務的系統間粗粒度消息交互設計理念，同時避免分佈式對象的陷阱和分佈式計算的謬誤。
2015年初，當時正在理解和接受微服務的理念，發現gRPC在理念上特別符合微服務的想法。後來看gRPC文檔時看到上面這句，才知道原來gRPC的設計理念本來就是衝著微服務去的......
在這之後的一年中，我心目中完美的服務化框架慢慢的形成了，基石就是：微服務 + gRPC。
普遍並且簡單
該基礎框架應該在任何流行的開發平臺上適用，並且易於被個人在自己的平臺上構建。它在CPU和內存有限的設備上也應該切實可行。
"在CPU和內存有限的設備",對我而言就是移動設備了，尤其特指手機和平板。2015年初在唯品會，遇到手機App端和服務器端通訊的方案選擇問題，當時我特別想把手機App端和服務器端這塊的通訊機制整合入唯品會的服務化框架，但是因種種原因未能如願，深以為憾。
當時有一個非常強烈的訴求，就是在如今的移動互聯網時代，PC沒落手機氾濫，如何可以實施一個服務化框架而無視移動端的需求？
之後就一直在gRPC和Rest之間搖擺，但是我對這兩個方案的共同要求，都是可以一套方案打通app到服務器和服務器之間的通訊機制。
2016年，在PPMoney，很有幸，基於gRPC的微服務框架得以開發並實施。
流
存儲系統依賴於流和流控來傳遞大數據集。像語音轉文本或股票代碼等其它服務，依靠流表達時間相關的消息序列。
雖說目前面對的直接需求中，對流的要求不多，乃至幾乎沒有。但是我依然看好這個思路，gRPC在框架層次上直接提供對流的支持，想法很好很對路。
元數據交換
常見的橫切關注點，如認證或跟蹤，依賴數據交換，但這不是服務公共接口中的一部分。部署依賴於他們將這些特性以不同速度演進到服務暴露的個別API的能力。
之前都是想辦法自己來生成/傳輸和利用元數據，如今終於gRPC直接提供。還有什麼好說，用，用，用！
閱讀更多 架構師的修煉之路 的文章
