這篇文章主要介紹“grpc是不是只支持go語言”，在日常操作中，相信很多人在grpc是不是只支持go語言問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”grpc是不是只支持go語言”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！
公司主營業(yè)務(wù)：成都做網(wǎng)站、網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)公司推出君山免費做網(wǎng)站回饋大家。
grpc不是只支持go語言。grpc是通信協(xié)議基于HTTP/2，支持多語言的RPC框架；目前提供C、Java和Go語言版本，分別是grpc、grpc-java、grpc-go；其中C版本支持C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#支持。
gRPC 是通信協(xié)議基于 HTTP/2，支持多語言的 RPC 框架，面向移動和 HTTP/2 設(shè)計。gRPC 基于 HTTP/2 標準設(shè)計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復(fù)用請求等特。這些特性使得其在移動設(shè)備上表現(xiàn)更好，更省電和節(jié)省空間占用。
RPC：Remote Procedure Call 的縮寫，譯為遠程過程調(diào)用（也可譯為遠程方法調(diào)用或遠程調(diào)用），它是計算機通信協(xié)議。該協(xié)議可以實現(xiàn)調(diào)用遠程服務(wù)就像調(diào)用本地服務(wù)一樣簡單，無需關(guān)心跨網(wǎng)絡(luò)，跨平臺，跨語言等問題。
gRPC 消息序列化方式通常使用 Protobuf，它是二進制格式，體積小，網(wǎng)絡(luò)傳輸快，占用帶寬流量少，調(diào)用性能更高。
gRPC 的特點
IDL
gRPC 使用 ProtoBuf 來定義服務(wù)，ProtoBuf 是由 Google 開發(fā)的一種數(shù)據(jù)序列化協(xié)議（類似于 XML、JSON）。ProtoBuf 能夠?qū)?shù)據(jù)進行序列化，并廣泛應(yīng)用在數(shù)據(jù)存儲、通信協(xié)議等方面。
多語言支持
gRPC 支持多種語言，并能夠基于語言自動生成客戶端和服務(wù)端功能庫。目前已提供了 C 版本 grpc、Java 版本 grpc-java 和 Go 版本 grpc-go，其中，grpc 支持 C、C++、Node.js、Python、Ruby、Objective-C、PHP 和 C# 等語言，grpc-java 已經(jīng)支持 Android 開發(fā)。
HTTP2
gRPC基于HTTP2標準設(shè)計，帶來了更多強大功能，如雙向流、頭部壓縮、多復(fù)用請求等。這些功能帶來重大益處，如節(jié)省帶寬、降低TCP鏈接次數(shù)、節(jié)省CPU使用和延長電池壽命等。同時，gRPC還能夠提高了云端服務(wù)和Web應(yīng)用的性能。gRPC既能夠在客戶端應(yīng)用，也能夠在服務(wù)器端應(yīng)用，從而以透明的方式實現(xiàn)客戶端和服務(wù)器端的通信和簡化通信系統(tǒng)的構(gòu)建。
為什么我們要用grpc
生態(tài)好：背靠Google。還有比如nginx也對grpc提供了支持，參考鏈接
跨語言：跨語言，且自動生成sdk
性能高：比如protobuf性能高過json, 比如http2.0性能高過http1.1
強類型：編譯器就給你解決了很大一部分問題
流式處理（基于http2.0）：支持客戶端流式，服務(wù)端流式，雙向流式
1）什么是protobuf？
Protobuf是由Google開發(fā)的二進制格式，用于在不同服務(wù)之間序列化數(shù)據(jù)。是一種IDL（interface description language）語言
2）他比json快多少？
快六倍，參考鏈接
3）為什么protobuf比json快？
protobuf的二進制數(shù)據(jù)流和json數(shù)據(jù)流如下圖
對比json數(shù)據(jù)和protobuf數(shù)據(jù)格式可以知道
體積小-無需分隔符：TLV存儲方式不需要分隔符（逗號，雙引號等）就能分隔字段，減少了分隔符的使用
體積小-空字段省略：若字段沒有被設(shè)置字段值，那么該字段序列化時的數(shù)據(jù)是完全不存在的，即不需要進行編碼，而json會傳key和空值的value
體積小-tag二進制表示：是用字段的數(shù)字值然后轉(zhuǎn)換成二進制進行表示的，比json的key用字符串表示更加省空間
編解碼快：tag的里面存儲了字段的類型，可以直接知道value的長度，或者當value是字符串的時候，則用length存儲了長度，可以直接從length后取n個字節(jié)就是value的值，而如果不知道value的長度，我們就必須要做字符串匹配
細化了解protobuf的編碼可以去看：varint 和 zigzag編碼方式
1）多路復(fù)用
http2.0和http 1.* 還有 http1.1pipling的對比
示意圖
http/1.* ：一次請求，一個響應(yīng)，建立一個連接用完關(guān)閉，每一個請求都要建立一個連接
http1.1 pipeling: Pipeling解決方式為，若干個請求排隊串行化單線程處理，后面的請求等待前面請求的返回才能獲得執(zhí)行機會，一旦有某請求超時等，后續(xù)請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞
http2: 多個請求可同時在一個連接上并行執(zhí)行。某個請求任務(wù)耗時嚴重，不會影響到其它連接的正常執(zhí)行
grpc 多路復(fù)用還有哪些優(yōu)點
減少了tcp的連接，降低了服務(wù)端和客戶端對于內(nèi)存，cpu等的壓力
減少了tcp的連接，保證了不頻繁觸發(fā)tcp重新建立，這樣就不會頻繁有慢啟動
減少了tcp的連接，使網(wǎng)絡(luò)擁塞情況得以改善
為什么http/1.1不能實現(xiàn)多路復(fù)用而http2.0可以？
因為http/1.1傳輸是用的文本，而http2.0用的是二進制分幀傳輸
2）頭部壓縮
固定字段壓縮：http可以通過http對body進行g(shù)zip壓縮，這樣可以節(jié)省帶寬，但是報文中header也有很多字段沒有進行壓縮，比如cookie， user agent accept，這些有必要進行壓縮
避免重復(fù)：大量請求和響應(yīng)的報文里面又很多字段值是重復(fù)的，所以有必要避免重復(fù)性
編碼改進：字段是ascii編碼，效率低，改成二進制編碼可以提高
以上通過HPACK算法來進行實現(xiàn)，算法主要包含三個部分
靜態(tài)字典：將常用的header字段整成字典,比如{":method":"GET"} 就可以用單個數(shù)字 2來表示
動態(tài)字典：沒有在靜態(tài)字典里面的一些頭部字段，則用動態(tài)字典
Huffman 編碼： 壓縮編碼
3）二進制分幀
在二進制分幀層上，HTTP 2.0 會將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶?并對它們采用二進制格式的編碼 ，其中HTTP1.x的首部信息會被封裝到Headers幀，而我們的request body則封裝到Data幀里面。
這樣分幀以后這些幀就可以亂序發(fā)送，然后根據(jù)每個幀首部的流標識符號進行組裝
對比http/1.1因為是基于文本以換行符分割每一條key：value則會有以下問題：
一次只能處理一個請求或者響應(yīng)，因為這種以分隔符分割消息的數(shù)據(jù)，在完成之前不能停止解析
解析這種數(shù)據(jù)無法預(yù)知需要多少內(nèi)存，會給服務(wù)端有很大壓力
4）服務(wù)器主動推送資源
由于支持服務(wù)器主動推送資源，則可以省去一部分請求。比如你需要兩個文件1.html,1.css，如果是http1.0則需要請求兩次，服務(wù)端返回兩次。但是http2.0則可以客戶端請求一次，然后服務(wù)端直接回吐兩次。
到此，關(guān)于“grpc是不是只支持go語言”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
文章標題：grpc是不是只支持go語言
網(wǎng)頁URL：http://weahome.cn/article/jgcdjg.html
重慶分公司
重慶分公司
