微服務優化之使用gRPC做微服務的內部通信

2021-01-15 字母哥博客

gRPC是一個由Google開源的遠程服務調用框架，具有多路復用和雙向流式通信的特性。

大家好，在本文中將為大家介紹為什麼我們應該使用gRPC代替RESTful或JSON，來開發微服務內部的通信接口。

什麼是gRPC?

gRPC是一個高性能的、開源的、普遍通用的RPC框架。簡單地說，它能夠幫助我們建立透明的服務端和客戶端通信系統。Google開發了GRPC並且將其開源。 通過它，一個客戶端消費者服務可以像調用本地方法一樣，調用另一臺主機上面的服務端方法。 gRPC本質上仍然遵循常規的Remote Procedure Call (RPC) 技術，但是在實現上使用了HTTP2.0、協議緩衝區等更現代化的技術方案，從而最大程度上確保服務端和客戶端的互操作性及性能上的提升。

服務之間如何使用gRPC通信？

當客戶端向服務端發起請求的時候，客戶端gRPC類庫使用協議緩衝區並且封裝遠程過程調用(RPC),並且將其通過HTTP2發送到服務端。服務端將其拆封，並且使用協議緩衝區調用對應的程序。響應數據的過程和發送請求的過程是類似的，只不過一個是從客戶端到服務端，一個是從服務端到客戶端。從開發的角度，在服務端和客戶端使用gRPC最大的好處在於：你的服務端的代碼和客戶端的代碼不需要擔心它會影響你解析JSON或者其他類似的文本格式消息。gRPC雖然接收到的是二進位格式，但會並將其反序列化為對象。同樣的我們可以通過IDL來定義服務接口，IDL是非常強大的一個特性，幫助我們處理多個微服務之間的互操作。

為什麼gRPC是高效的？

它基於HTTP2構建，既支持傳統的請求-響應模型，也支持雙向流模型。

可以將JSON數據轉換到協議緩衝區

多路復用

雙向流模型

網絡傳輸的是二進位數據，相對於JSON等文本數據更加輕量級。

多語言支持

什麼時候使用gRPC？

最初，幾乎所有的微服務之間都是通過JSON數據接口通信的，一個服務可能調用空一個服務或者多個服務，被調用的服務可能還調用其他服務。如果其中任何一個服務運行緩慢，將影響整個系統的運行速度，因為RESTful(JSON) API不支持HTTP2的多路復用和雙向流模型。傳統的RESTful接口使用JSON、XML或者其他的一些格式作為數據載體，使得服務運行緩慢，內存佔用較高、並且傳輸過程沒有壓縮。

gRPC解決所有的這些問題，但是它僅僅用於系統應用微服務之間的通信的情況，系統的對外服務接口仍然使用HTTP-JSON接口。這樣保證對外部用戶的開發技術棧沒有任何影響。

總結 Conclusion

與傳統REST API相比，使用gRPC創建的API可以為你的應用帶來令人難以置信的性能改進。如果您覺得本文可以幫助到您的話，希望得到您的關注。期待您的關注 ，z i m u g 點 扛 m，更多精品合集知識等待你！

相關焦點

  • 2021升級版微服務教程—為什麼會有微服務?什麼是SpringCloud?
    對並夕夕商城進行升級優化。分析升級的方向：資料庫 和 應用代碼要放在不同的伺服器上 增加應用負載能力【集群】 於是增加負載均衡。招人在多位同事努力之下，對項目進行進一步的優化—讀寫分離。3.讀寫分離image-20200317145753793 上述的架構看上去非常的完美，但是，隨著並夕夕商城業務量的不斷增加，新的問題暴露了出來。
  • 「首席架構師看微服務架構」介紹NGINX的微服務參考架構
    我們還認識到，實現微服務有許多不同的方法，其中許多方法都是新穎的，並且特定於各個開發團隊的需求。我們認為需要使用模型來使公司更容易開發和交付自己的基於微服務的應用程式。考慮到這一切，NGINX專業服務部門正在開發NGINX微服務參考架構（MRA） - 一組可用於創建自己的微服務應用程式的模型。
  • gRPC 通信框架實現存在數據洩露等安全問題
    目前提供 C、Java 和 Go 語言版本，分別是：grpc, grpc-java, grpc-go. 其中 C 版本支持C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持。當前企業正在慢慢改用微服務架構來構建面向未來的應用程式，微服務使企業能夠有效管理基礎架構，輕鬆部署更新或改進，並幫助IT團隊的創新和學習。
  • 微服務,Java目前很火熱的系統架構
    無法針對不同模塊進行針對性優化以及擴展。 單點容錯率低，並發能力差。當然為了解決這些問題，後續也做了優化，根據業務功能對系統進行拆分。雖然解決了代碼耦合問題，但是系統間相互獨立，會有很多重複開發工作，影響開發效率。
  • 微服務架構技術棧
    下圖是我近期工作總結和參考的一個微服務技術體系，我想同時分享給一線架構師或者工程師參考，其中粉紅色標註的模塊是和微服務關係最密切的模塊，大家在做技術選型時，可以同時對照這個體系。.四、服務框架選型服務框架是一個比較成熟的領域，有太多可選項。
  • 基於Prometheus來做微服務監控,有多吃香?
    愛奇藝號整體採用微服務架構，內部依據功能、領域等角度劃分為不同的微服務，外部流量先經DNS、QLB、前置機、網關等層完成統一鑑權、負載均衡、限流等操作後路由到系統內部不同的微服務實例。系統內部微服務除專有的MySQL、Redis、MQ等資源外，共享服務註冊/發現、配置中心等服務治理能力。
  • 基於容器雲的微服務架構實踐
    【編者按】微服務架構的誕生和容器技術的流行，幾乎是同時發生的，這並非偶然，而是網際網路時代倒逼傳統技術和架構而產生的變革，而以Docker為代表的容器技術則為微服務理念提供了匹配的實現機制，本文作者從什麼是微服務切入，詳細的介紹了微服務架構的優勢，最後從自身實踐出發，給出了微服務架構的雲端實踐。
  • 微服務這麼流行,你理解嘛?
    2、微服務和微服務架構的區別是什麼？3、微服務技術有什麼？4、微服務的優缺點是什麼？5、為什麼選擇Springcloud作為微服務架構？就是我們今天所說的微服務架構。二、什麼是微服務由於業界還沒有對微服務的概念有一個統一的解釋，但是你可以這樣去理解，微服務其實就是一種思想，這個思想是：考慮如何把一個複雜的項目拆分成一個個獨立的小項目。就好比是電腦中的進程，拆分成一個個小的線程一樣。
  • 放棄微服務,改用宏服務,Uber 這波什麼操作?
    ，轉而使用了宏服務，這一消息在網友中引起了熱議。以「簡單」著稱的微服務為什麼又變得難以維護了呢？ 1 Uber 支付團隊放棄微服務，轉用宏服務 4 月 6 日，Uber 支付體驗平臺的工程經理 Gergely Orosz 發布推文表示其團隊的架構方向已經發生了變化，放棄微服務，轉而使用宏服務。
  • 服務網格和API網關在微服務架構中的作用
    服務網格和API網關在微服務架構中的作用 如果您從事微服務，那麼您可能已經多次聽說過這兩個術語。 人們常常在兩者之間感到困惑。 在本文中，我將詳細討論服務網格和API網關，並討論何時使用。
  • SpringCloud微服務架構篇3:Spring Cloud簡介
    Spring Cloud技術SpringCloud使用Spring Boot風格將比較成熟的微服務框架組合起來，屏蔽掉了複雜的配置和實現原理，為快速構建微服務架構的應用提供了一套設施工具和開發支持。通過Zuul的反向代理功能，可以實現路由尋址，將請求轉發到後端的粗粒度服務上，並做一些通用的邏輯處理。Zuul默認會與Eureka伺服器進行整合，自動從Eureka伺服器中獲取所有註冊的服務並進行路由映射，實現API服務網關自動配置。
  • 覆蓋全網的阿里微服務架構有多牛:K8S+實戰+筆記+項目教程
    第2章Spring Boot基礎本書以實戰為導向，講解了如何使用Spring Cloud開發微服務項目，而Spring Cloud基於SpringBoot,所以本章先來初步了解如何使用Spring Boot搭建框架。
  • 微服務RPC框架選美
    服務通信協議Motan：我支持 Motan 協議，使用tcp 長連接模式，基於 netty通信。gRPC：我，我支持 HTTP/2.0 協議，基於 Netty4.1.3 通信。 序列化Motan：我默認使用對 java 更友好的 hessian2 進行序列化，還支持 Json 格式。
  • 微服務拆分到什麼粒度合適——康威定律
    微服務這個概念一直很火，現在ServiceMesh概念更火，最近我經手的多個項目也都採用微服務的方式開發。但實踐發現，當一個RD同時開發超過2個微服務的時候，出現bug或故障的概率會提升。我現在看項目的時候會不自覺的關注工程服務拆分個數和研發人數的比值。雖然這麼做，我卻說不出來個所以然，也沒有找到一個理論依據。
  • DDD到底適不適合微服務架構?
    從初期的單體架構，到豎井式架構、RPC架構，再到大放異彩的微服務架構，可以說架構演進，本質上就是基於業務，對現有架構的抽象過程。一名架構師，最怕缺少全局意識和長線思維。如果架構師設計架構的出發點，只是緩解燃眉之急，那麼在未來，這套系統的迭代會越來越困難，很可能陷入推翻、重建，再推翻、再重建的「鬼打牆」。
  • 無服務和微服務架構,誰是業務計算的未來?
    此外，在選擇無伺服器服務，以簡化應用開發流程的同時，您也可以用它來大幅改善諸如DevOps和敏捷實踐等其他業務優化計劃。無伺服器和微服務模型的區別？總的說來，這兩種架構的相似之處在於：它們都能夠最大程度地降低運營的成本，縮短應用部署的周期，滿足不斷變化的開發需求，以及優化那些對於時間和資源敏感的日常任務。那麼，微服務和無伺服器模型之間的不同之處在哪裡呢？首先，微服務屬於一種小型的SOA(面向服務的體系架構)技術解決方案。
  • 20道你必須要背會的微服務面試題,面試一定會被問到
    從技術維度來說：微服務化的核心就是將傳統的一站式應用，根據業務拆分成一個一個的服務，徹底地去耦合,每一個微服務提供單個業務功能的服務，一個服務做一件事，從技術角度看就是一種小而獨立的處理過程，類似進程概念，能夠自行單獨啟動或銷毀，擁有自己獨立的資料庫。2、微服務之間是如何通訊的？
  • Java微服務可以和Go一樣快嗎?
    我們想要一個公平的測試，所以我們創建了一個非常簡單的微服務，沒有外部依賴項(例如資料庫)，並且代碼路徑非常短(僅處理字符串)。 我們確實包含了指標和日誌記錄，因為它們似乎總是包含在任何實際的微服務中。 我們使用了小型輕量級的框架(Helidon for Java和Go-Kit for Go)，並且還嘗試了Java的純JAX-RS。
  • restful微服務風格_restful 風格的微服務架構 - CSDN
    本文整理了 spring boot + jpa+mysql+redis +swagger+yml等技術，實現了微服務restFul 風格的demo,下載即運行[http://localhost:8080/
  • Spring Cloud系列各子項目在微服務架構中的作用分析
    Springcloud一般用於搭建微服務項目，那麼微服務項目是怎麼工作的呢?Springcloud的幾個子項目分別扮演什麼角色？如果需要給所有請求做統一的處理，比如認證、授權方面，也不應該在每個微服務寫一套驗證邏輯。所以需要網關來提供一個統一的調用地址給前端調用,通過請求信息區分調用不同微服務，提供統一的路由定位轉發、請求過濾、負載均衡、請求響應修改等功能，在網關服務上做認證授權等公共處理。