[微服務] 什麼是 gRPC，架構上為什麼要使用 gRPC

[@zeralux100]

個人不怎喜歡gencode 這種方式 , 如果其中一個自部門clietn有特例要微調 或者 自部門的clietn代碼小版本跌帶版控 都要考量, 太貼的做法會怕. api這種情況喜歡用 運行服務後線上呈現的swagger spec , 各部門要串接則查看線上doc , 如果要依各部門的版本需要釋出對應的gencode版本也是困擾, 幫別人做好意謂就是要幫他們維護? 不如rest一點realease api出來讓其他部門自己串接, 每部門維護自己的項目=>高內聚? 跟其他部門不要gencode這種方式 => 低耦合?

[@傳說紀錄]

感謝講解 一直很不懂gRPC與API到底有啥差別 今天終於懂了

[@jct808]

謝謝您的解釋～非常的清楚明暸～感謝你

[@appleboy46]

感謝支持

[@masonlu100]

讲的很厉害，感谢分享

[@appleboy46]

感謝支持

[@BillLin1]

gRCP好像5 6年前就有聽過了XD，比較好奇從RESTful和GraphQL換過去會有什麼痛點或是有那些不適合的場景，我是只有用過RESTful API啦，像是RESTful常用到的HTTP header，URL path的功能，CDN cache，還有Circuit Break之類的功能也要考量

[@appleboy46]

gRPC 2015 年出來的，2016 年 8 月正式 release stable 版本。XD 我正打算錄製一篇 RESTful API vs GraphQL vs gRPC 適用場景

[@JkeyKong]

我也是觉得 RESTFul 用到好好，还出现什么这种东西？是为了和 Golang 或者和底层语言沟通吗？一般JSON还是不能满足吗？

[@rogerroan7583]

@@JkeyKonggrpc也能做restful,你們是不是把restful跟http api混為一談了

[@123fffffxl]

在我理解 grpc 并不能够替代 restful 以及 mq 这类中间件； 它们之间是并存的关系，选用哪种技术是需要根据实际情况而定的； 在异构语言之间通信我觉得 mq就很好

[@appleboy46]

grpc-gateway 可以將 RESTful JSON API 轉換成 gRPC。至於 mq 又是另一種使用情境了。

[@b123321321]

RESTful gRPC 是同步通訊, 可以互相替代; 但MQ是非同步通訊, 跟前者情境不同.

[@123fffffxl]

@@b123321321 我想表述的观点就是 服务之间通信(包括异构系统) 要看具体实际场景进行选型; 究竟是同步或是异步要看实际需求以及成本等综合因素

[@billwu7367]

讲得太好了，迫不及待想尝试下

[@appleboy46]

感謝支持，昨天本來發佈到 bibi 那邊，結果 AI 判斷我裡面有廣告 XD

[@windsoar]

你說的第三方 library，通常不會由服務提供者來撰寫吧？如果是說 SDK (Software Development Kit) 還比較能理解。

[@appleboy46]

網路上眾多服務都會提供各種語言的 SDK 包，假如都能透過 gRPC 模式來傳輸，那就不需要大家一起來開發特定語言的 SDK 包。

[@IanHuang5566]

5:00 因為restAPI 而考慮 app lib version 這有點奇怪。一般來說 http protocol 在各語言中的要求滿低的，不需要到太新版就有支援。比如說 Java 早期板本就可以送 http REQ。

[@appleboy46]

那段我想強調的是，當你在寫 RESTful API 你就會考慮到各個語言的 Http Library 實作以及不同版本的特性，然而如果用 gRPC 則完全不用考慮，都可以透過 protoc 幫忙產生出各種不同語言 (Python, Go ...) 的套件。

[@林建忠-y7w]

希望大大有空可以介紹rabbitmq在這架構下的應用

[@appleboy46]

我自己寫一個 Queue Service 串接各種不同 Queue 服務，像是 NSQ, Nats, Rabbitmq, Redis .. 等，有時間來介紹一下 github.com/golang-queue

[@林建忠-y7w]

喔喔，感謝大大分享🙏