微服務 gRPC 為什麼是HTTP 2

grpc是google開源的高效能跨語言的rpc方案。

grpc的設計目標是在任何環境下執行，支援可插拔的負載均衡，跟蹤，執行狀況檢查和身份驗證。它不僅支援資料中心內部和跨資料中心的服務呼叫，它也適用於分布式計算的最後一公里，將裝置，移動應用程式和瀏覽器連線到後端服務。

在正式討論grpc為什麼選擇http/2之前，我們先來簡單了解下http/2。

來自：可以看到：

在chrome瀏覽器裡，開啟chrome://net-internals/#http2，可以看到http2鏈結的資訊。

目前很多**都已經跑在http/2上了，包括alibaba。

準確來說grpc設計上是分層的，底層支援不同的協議，目前grpc支援：

但是大多數情況下，討論都是基於grpc over http2。

下面從乙個真實的grpcsayhello請求，檢視它在http/2上是怎樣實現的。用wireshark抓包：

可以看到下面這些header：

然後請求的引數在data frame裡：

簡而言之，ggrpc把元資料放到http/2 headers裡，請求引數序列化之後放到 data frame裡。

http/2 是乙個公開的標準

http/2 是乙個經過實踐檢驗的標準

http/2 天然支援物聯網、手機、瀏覽器

只討論協議本身的實現，不考慮序列化。

http/2支援stream和流控

在業界，有很多支援stream的方案，比如基於websocket的，或者rsocket。但是這些方案都不是通用的。

http/2裡的stream還可以設定優先順序，儘管在rpc裡可能用的比較少，但是一些複雜的場景可能會用到。

基於http/2 在gateway/proxy很容易支援

http/2 安全性***

http/2 鑑權成熟

比如傳統的rpc dubbo，需要寫乙個dubbo filter，還要考慮把鑑權相關的資訊通過thread local傳遞進去。rpc協議本身也需要支援。總之，非常複雜。實際上絕大部分公司裡的rpc都是沒有鑑權的，可以隨便調。

grpc選擇基於http/2，那麼它的效能肯定不會是最頂尖的。但是對於rpc來說中庸的qps可以接受，通用和相容性才是最重要的事情。

近10年來，google制定標準的能力越來越強。下面列舉一些標準：

當然google也並不都會成功，很多事情它想推也失敗了，比如chrome的native client。

grpc目前是k8s生態裡的事實標準。 grpc是否會成為更多地方，更大領域的rpc標準？

準確來說為什麼會出現基於http/2的rpc？

個人認為乙個重要的原因是，在cloud native的潮流下，開放互通的需求必然會產生基於http/2的rpc。

即使沒有grpc，也會有其它基於http/2的rpc。

grpc在google的內部也是先用在google cloud platform和公開的api上：

儘管grpc它可能替換不了內部的rpc實現，但是在開放互通的時代，不止在k8s上，grpc會有越來越多的舞台可以施展。