原文鏈接：https://mp.weixin.qq.com/s/ah9gdutZueCxbqjrWVhiQg
本文概括性的介紹gRPC，包括gRPC的起源，核心特性，生態體系，以及一些知名開源軟件對gRPC的使用，最后總結gRPC與netty、dubbo等框架的區別，目的是讓讀者從整體上對gRPC有一個相對全面的認知。
1 gRPC起源
十多年來，Google一直在使用一個名為Stubby的通用RPC基礎架構來連接在數據中心內部和跨越數據中心運行的大量微服務，其內部系統長期以來一直接受微服務架構的普及。
擁有統一的跨平臺RPC基礎架構，可以在整個系統范圍內推廣效率，安全性，可靠性和行為分析，這對于支持Google的驚人增長至關重要。我們今天使用的每個Google服務背后的RPC骨干都是Stubby。
Stubby有許多很棒的功能 - 但是，它不是基于任何標準，而是與Google的內部基礎設施緊密耦合，并不適合公開發布。
隨著SPDY，HTTP / 2和QUIC的出現，許多這些相同的功能已經出現在公共標準中，以及Stubby未提供的其他功能。很明顯，是時候重做Stubby以利用這種標準化，并將其適用范圍擴展到分布式計算的最后一英里，支持移動設備(如安卓)、物聯網(IOT)、和瀏覽器連接到后端服務。
2015年3月，Google決定在公開場合構建下一版Stubby，以便與業界分享經驗，并進行相關合作，為Google內部以及外界的微服務構建下一版本的Stubby，也就是本文要介紹的主角gRPC。
2 gRPC介紹
gRPC是一個現代的開源高性能RPC框架，可以在任何環境中運行。它可以有效地連接數據中心內和跨數據中心的服務，并提供可插拔的支持，以實現負載平衡(load balancing)，調用鏈追蹤(tracing)，健康檢查(health checking)和身份驗證(authentication)。它還適用于分布式計算的最后一英里，用于將設備，移動應用程序和瀏覽器連接到后端服務。
gRPC的四個核心特性，使得其對開發者有著極大的吸引力：
簡單的服務定義
跨平臺跨語言
基于http/2雙向流傳輸
可插拔的插件機制
2.1 服務定義
與許多 RPC 系統類似，gRPC 也是基于以下理念：定義一個服務，指定其能夠被遠程調用的方法（包含參數和返回類型）。在服務端實現這個接口，并運行一個 gRPC 服務器來處理客戶端調用。在客戶端擁有一個存根(Stub)，它提供與服務器相同的方法。客戶端應用可以像調用本地對象一樣直接調用另一臺不同的機器上服務端應用的方法，其背后會通過RPC通信給服務端發送請求，并獲得響應。如下圖：
要完成這樣的功能，我們首先要進行服務定義(Service Definition)，一些框架中，將定義服務的語法稱之為IDL(Interface Definition Language，接口定義語言)。
gRPC 默認使用 Protocol Buffer進行服務定義，這是 Google 開源的一套成熟的結構數據序列化機制（當然也可以使用其他數據格式如 JSON)。
目前Protocol Buffer已經發展到proto3，相對于proto2，它擁有輕量簡化的語法、一些有用的新功能，并且支持更多新語言。通常建議在 gRPC 里使用 proto3，因為這樣你可以使用 gRPC 支持全部范圍的的語言，并且能避免 proto2 客戶端與 proto3 服務端交互時出現的兼容性問題，反之亦然。
使用Protocol Buffer進行服務定義非常簡單明了，我們可以創建一個.proto文件，按照Protocol Buffer語法編寫此文件，如：
說明如下：
定義一個表示請求的HelloRequest，其包含一個message字段表示請求內容
定義一個表示響應的HelloResponse，其包含一個message字段表示響應內容
定義服務HelloService，其提供一個hello方法，以HelloRequest作為方法參數，并返回HelloResponse
考慮為什么要在一個文件中進行服務定義？
這主要是為了跨語言。gRPC提供了工具，可以根據服務定義文件，來為不同的平臺和語言生成server端和client端的代碼，意味著你的服務端和客戶端，可以使用不同的語言。例如，筆者最近開發的一個服務，服務端使用go編寫，客戶端需要支持go、python、java。此時筆者就可以根據這個配置文件，分別生成不同語言的代碼。
2.2 跨語言跨平臺工作
gRPC提供了工具，可以為不同的平臺、語言，生成對應的client和server代碼，使得彼此之間可以通過gRPC進行通信。
通常一個規模較大的公司，技術棧往往不統一，可能會使用多種語言。通過gRPC，服務端我們可以使用一種語言編寫，而客戶端可以支持多種語言。
下圖演示了服務端使用C++，客戶端使用Java和Ruby的交互案例：
截止筆者撰寫此文(2019年6月28日)，官方支持10種語言，以及linux、mac、windows三種平臺，具體如下：
2.3 插件機制
grpc提供了可插拔的插件機制，或者說是攔截器機制，以對每一次RPC請求進行攔截。基于此，我們可以實現一些RPC通信過程中的高級功能。如：
身份驗證：
gRPC內置了兩種驗證機制，基于連接層面的SSL/TLS，以及基于Google Token的身份認證機制。如果不滿足需求，你也很容易的進行擴展自己驗證機制。
負載均衡：
在微服務架構中，為了實現容災、高可用或者水平擴展等目的，通常一個服務都會部署多個節點。客戶端在調用時，盡量的將請求分散在不同的節點上，以實現負載均衡。通常負載均衡有兩種模式：1)通過代理，即請求先發送給一個中間代理服務器，例如nginx，由代理按照負載均衡策略選擇一個后端節點進行處理；2) 客戶端路由：客戶端按照負載均衡選擇某個后端服務節點，進行調用。gRPC提供了一套完善的機制，支持客戶端發現服務端有哪些節點，以及自定義負載均衡策略。
健康檢查：
健康檢查用于探測服務端是否可以處理RPC請求。檢查檢查可以由客戶端直接發起，或者通過其他系統(如consul)。服務端可以選擇回復”unhealthy"來表明自己還沒準備好處理請求，或者服務端已經宕機。客戶端根據服務端回復的響應信息，或者指定時間內是否收到響應，來判斷服務端是否健康。
2.4 基于HTTP/2雙向流傳輸
gRPC 基于 HTTP/2 標準設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復用請求等特。這些特性使得其在移動設備上表現更好，更省電和節省空間占用。
gRPC利用HTTP/2進行消息傳輸，但是其只是本身定義了HTTP2中的傳輸單元中幀(Frame)的格式。至于HTTP/2協議本身的解析，gRPC盡量復用已有的組件。例如，在Java中，Netty本身支持HTTP/2協議協議，因此gRPC默認是支持與netty進行整合的。又或者，如果你希望移動設備(如安卓)，可以直接與服務端進行交互，那么在安卓客戶端，你可以選擇將gRPC與okHttp進行整合。
3 gRPC生態體系
gRPC有著豐富的生態系統，這些組件是由不是官方提供。以下介紹部分組件：
grpc-opentracing
grpc-gateway
grpc-prometheus
其他組件
3.1 grpc-opentracing
在RPC調用過程中，可能會出現A調動B，B又調用C等情況，此時我們希望對完整的調用鏈路進行追蹤。
grpc生態系統中有一個grpc-opentracing組件，我們可以使用其對接zipkin，進行調用鏈路展示，查看整個調用鏈路中每個環節的耗時，以發現系統的瓶頸。下
圖來源自zipkin官網，我們可以看到鏈路追蹤的最終展示效果：
3.2 grpc-promethus
grpc-prometheus來對gRPC服務進行監控，并將監控數據存儲到prometheus中。
目前有2種語言的實現：
java-grpc-prometheus
go-grpc-prometheus
監控指標服務端與客戶端分別統計，統計的指標包括：發起了多少個請求，接收到了多少個響應，響應延遲等。
3.3 grpc-gateway
gRPC已經支持了絕大部分主流語言，對于一些小眾語言可能不支持，此時你可以使用grpc-gateway來進行反向代理。
grpc-gateway本質是一個protoc插件，我們在編寫gRPC服務定義proto文件，通過指定一些自定義選項，在編譯時，在生成gRPC代碼時，額外指定生成grpc-gateway反向代理相關代碼，其作用是將RESTful JSON API請求轉換為gRPC請求。
之后，我們對反向代理代碼進行改造，對于不支持gRPC的語言，讓其發送HTTP RESTful JSON 請求，通過反向代理將其轉換成grpc請求，下圖演示了其工作原理：
3.4 其他支持
上述提到的幾個組件gRPC生態體系中的組件，圍繞著gRPC來開發的。一些其他的著名開源軟件，如nginx、haproxy等，也提供了對gRPC的支持。
3.4.1 nginx對gRPC的支持
nginx從1.13.10開始提供對grpc的支持，client端和server端都可以使用gRPC實現，通過nginx進行代理，如下圖：
nginx使用grpc_pass指令代理流量。下面的nginx代理配置，演示了在端口80上偵聽未加密的gRPC流量并將請求轉發到端口50051上的服務器。
更完整的介紹和配置，點擊這里：
https://www.nginx.com/blog/nginx-1-13-10-grpc/
3.4.2 HAProxy對gRPC的支持
HAProxy 從1.9.2 添加了對gRPC的支持。完整介紹，點擊以下鏈接：
https://www.haproxy.com/blog/haproxy-1-9-2-adds-grpc-support/
4 gRPC使用案例
很多知名公司或者機構目前都使用了gRPC，這些公司對gRPC的使用，本身就證明了其強大穩定與可靠。官方列出有以下這些：
這些公司分別在各自的產品中使用了gRPC，下面介紹etcd和tidb。
4.1 etcd案例
etcd是一個可靠的分布式k/v存儲，利用Raft一致性算法，用于存儲分布式系統的最關鍵數據，使用Go語言編寫，k8s使用了etcd來存儲數據。
etcd v3 使用 gRPC 作為它的消息協議。etcd 項目包括基于 gRPC 的 Go client 和 命令行工具 etcdctl，通過 gRPC 和 etcd 集群通訊。另外，對于gRPC不支持的語言，etcd v3通過grpc-gateway(回顧前文)予以支持。
4.2 tidb案例
TiDB 是 PingCAP 公司設計的開源分布式 HTAP (Hybrid Transactional and Analytical Processing) 數據庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持無限的水平擴展，具備強一致性和高可用性。
TiDB 集群主要包括三個核心組件：TiDB Server，**PD Server **和 TiKV Server。此外，還有用于解決用戶復雜 OLAP 需求的 TiSpark 組件。這些組件之間也使用gRPC來交互，如下圖：
圖片來源自網絡
關于tidb與gRPC的淵源，參考這里(故事比較曲折)：
https://blog.csdn.net/weixin_33919941/article/details/89145274
5 gRPC性能
之所以有這么多廠商使用gRPC，除了其本身的設計，豐富的生態體系，與其高性能也有著極大的關系。
gRPC專為分布式應用的高性能和高生產率設計而設計。持續性能基準測試是gRPC開發工作流程的關鍵部分。目前gRPC會針對master分支每小時運行一次多語言性能測試，并將這些數字報告給儀表板以進行可視化。
測試場景
無爭用延遲 - 只有1個客戶端使用StreamingCall一次發送一條消息時看到的中位數和尾部響應延遲
QPS - 當有2個客戶端和總共64個通道時的消息/秒速率，每個通道使用StreamingCall一次發送100個未完成的消息
可伸縮性（適用于所選語言） - 每個服務器核心的消息數/秒
下圖演示了第二個測試場景下的測試qps：
可以看到，使用go和java時，qps接近240w/s這個驚人的數字。當然，千萬不能完全相信這個數字，qps受到網絡、消息大小、機器配置等多種因素的綜合影響。實際使用還是需要自行測試。
6 總結
本文概括性的介紹gRPC，包括gRPC的起源，核心特性，生態體系，以及一些知名開源軟件對gRPC的使用，目的是讓讀者從整體上對gRPC有一個相對全面的認知。
補充：gRPC與netty、dubbo等框架的區別
netty本質上是一個高性能的網路通信框架，且局限于Java語言。gRPC則不同，則是面向微服務設計的，netty可以作為gRPC的底層通信框架，gRPC本身還支持很多微服務中的概念，如前面提到的服務發現注冊，鏈路追蹤等。
與其他微服務框架如dubbo、spring cloud等，gRPC不局限于某一種語言，而是幾乎所有主流語言。
另外一個很大的不同是，gRPC不是采用私有協議，而是基于標準的HTTP/2實現，這意味著可能會有更多的廠商使用或者支持gRPC，如果前面提到的nginx、etcd等。這體現了遵循標準的重要性，試想，如果想要nginx支持dubbo，或者etcd來使用dubbo，幾乎是不可能的事情。
設計者的思路，直接決定了一門技術到底能夠有多廣泛的使用場景。
微信公眾號【程序員黃小斜】作者是前螞蟻金服Java工程師，專注分享Java技術干貨和求職成長心得，不限于BAT面試，算法、計算機基礎、數據庫、分布式、spring全家桶、微服務、高并發、JVM、Docker容器，ELK、大數據等。關注后回復【book】領取精選20本Java面試必備精品電子書。
