grpc是不是只支持go語言

這篇文章主要介紹“grpc是不是只支持go語言”，在日常操作中，相信很多人在grpc是不是只支持go語言問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”grpc是不是只支持go語言”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

grpc不是只支持go語言。grpc是通信協議基于HTTP/2，支持多語言的RPC框架；目前提供C、Java和Go語言版本，分別是grpc、grpc-java、grpc-go；其中C版本支持C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#支持。

什么是grpc

gRPC 是通信協議基于 HTTP/2，支持多語言的 RPC 框架，面向移動和 HTTP/2 設計。gRPC 基于 HTTP/2 標準設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復用請求等特。這些特性使得其在移動設備上表現更好，更省電和節省空間占用。

RPC：Remote Procedure Call 的縮寫，譯為遠程過程調用（也可譯為遠程方法調用或遠程調用），它是計算機通信協議。該協議可以實現調用遠程服務就像調用本地服務一樣簡單，無需關心跨網絡，跨平臺，跨語言等問題。

gRPC 消息序列化方式通常使用 Protobuf，它是二進制格式，體積小，網絡傳輸快，占用帶寬流量少，調用性能更高。

gRPC 的特點

• IDL

  gRPC 使用 ProtoBuf 來定義服務，ProtoBuf 是由 Google 開發的一種數據序列化協議（類似于 XML、JSON）。ProtoBuf 能夠將數據進行序列化，并廣泛應用在數據存儲、通信協議等方面。

• 多語言支持

  gRPC 支持多種語言，并能夠基于語言自動生成客戶端和服務端功能庫。目前已提供了 C 版本 grpc、Java 版本 grpc-java 和 Go 版本 grpc-go，其中，grpc 支持 C、C++、Node.js、Python、Ruby、Objective-C、PHP 和 C# 等語言，grpc-java 已經支持 Android 開發。

• HTTP2

  gRPC基于HTTP2標準設計，帶來了更多強大功能，如雙向流、頭部壓縮、多復用請求等。這些功能帶來重大益處，如節省帶寬、降低TCP鏈接次數、節省CPU使用和延長電池壽命等。同時，gRPC還能夠提高了云端服務和Web應用的性能。gRPC既能夠在客戶端應用，也能夠在服務器端應用，從而以透明的方式實現客戶端和服務器端的通信和簡化通信系統的構建。

為什么我們要用grpc

• 生態好：背靠Google。還有比如nginx也對grpc提供了支持，參考鏈接

• 跨語言：跨語言，且自動生成sdk

• 性能高：比如protobuf性能高過json, 比如http2.0性能高過http1.1

• 強類型：編譯器就給你解決了很大一部分問題

• 流式處理（基于http2.0）：支持客戶端流式，服務端流式，雙向流式

grpc 的優點是怎么實現的

1、grpc性能高：protobuf為什么比json性能高？

1）什么是protobuf？

• Protobuf是由Google開發的二進制格式，用于在不同服務之間序列化數據。是一種IDL（interface description language）語言

2）他比json快多少？

• 快六倍，參考鏈接

3）為什么protobuf比json快？

• protobuf的二進制數據流和json數據流如下圖

• 對比json數據和protobuf數據格式可以知道

• 體積小-無需分隔符：TLV存儲方式不需要分隔符（逗號，雙引號等）就能分隔字段，減少了分隔符的使用

• 體積小-空字段省略：若字段沒有被設置字段值，那么該字段序列化時的數據是完全不存在的，即不需要進行編碼，而json會傳key和空值的value

• 體積小-tag二進制表示：是用字段的數字值然后轉換成二進制進行表示的，比json的key用字符串表示更加省空間

• 編解碼快：tag的里面存儲了字段的類型，可以直接知道value的長度，或者當value是字符串的時候，則用length存儲了長度，可以直接從length后取n個字節就是value的值，而如果不知道value的長度，我們就必須要做字符串匹配

• 細化了解protobuf的編碼可以去看：varint 和 zigzag編碼方式

2、grpc性能高：http2.0為什么比http1.1性能高？

1）多路復用

• http2.0和http 1.* 還有 http1.1pipling的對比

  示意圖

• http/1.* ：一次請求，一個響應，建立一個連接用完關閉，每一個請求都要建立一個連接

• http1.1 pipeling: Pipeling解決方式為，若干個請求排隊串行化單線程處理，后面的請求等待前面請求的返回才能獲得執行機會，一旦有某請求超時等，后續請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞

• http2: 多個請求可同時在一個連接上并行執行。某個請求任務耗時嚴重，不會影響到其它連接的正常執行

• grpc 多路復用還有哪些優點

• 減少了tcp的連接，降低了服務端和客戶端對于內存，cpu等的壓力

• 減少了tcp的連接，保證了不頻繁觸發tcp重新建立，這樣就不會頻繁有慢啟動

• 減少了tcp的連接，使網絡擁塞情況得以改善

• 為什么http/1.1不能實現多路復用而http2.0可以？

• 因為http/1.1傳輸是用的文本，而http2.0用的是二進制分幀傳輸

2）頭部壓縮

• 固定字段壓縮：http可以通過http對body進行gzip壓縮，這樣可以節省帶寬，但是報文中header也有很多字段沒有進行壓縮，比如cookie， user agent accept，這些有必要進行壓縮

• 避免重復：大量請求和響應的報文里面又很多字段值是重復的，所以有必要避免重復性

• 編碼改進：字段是ascii編碼，效率低，改成二進制編碼可以提高

• 以上通過HPACK算法來進行實現，算法主要包含三個部分

• 靜態字典：將常用的header字段整成字典,比如{":method":"GET"} 就可以用單個數字 2來表示

• 動態字典：沒有在靜態字典里面的一些頭部字段，則用動態字典

• Huffman 編碼： 壓縮編碼

3）二進制分幀

• 在二進制分幀層上，HTTP 2.0 會將所有傳輸的信息分割為更小的消息和幀,并對它們采用二進制格式的編碼 ，其中HTTP1.x的首部信息會被封裝到Headers幀，而我們的request body則封裝到Data幀里面。

• 這樣分幀以后這些幀就可以亂序發送，然后根據每個幀首部的流標識符號進行組裝

• 對比http/1.1因為是基于文本以換行符分割每一條key：value則會有以下問題：

• 一次只能處理一個請求或者響應，因為這種以分隔符分割消息的數據，在完成之前不能停止解析

• 解析這種數據無法預知需要多少內存，會給服務端有很大壓力

4）服務器主動推送資源

• 由于支持服務器主動推送資源，則可以省去一部分請求。比如你需要兩個文件1.html,1.css，如果是http1.0則需要請求兩次，服務端返回兩次。但是http2.0則可以客戶端請求一次，然后服務端直接回吐兩次。

到此，關于“grpc是不是只支持go語言”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！