Golang 微服务为什么选择使用 gRPC 作为通信协议?
01 介绍
我们在之前的文章中,连续使用四篇文章的篇幅介绍过 gRPC 的相关知识,如果有读者朋友还未阅读,可以按需翻阅一下前面的四篇关于 gRPC 的文章。
本文我们介绍 Golang 语言微服务架构的软件系统为什么选择使用 gRPC 作为分布式应用之间的通信协议。
02 进程间通信
微服务架构的软件系统由多个分布式应用组成,进程间通信技术将分布式应用相互连接。进程间通信一般包含两种实现方式,其中一种是同步的请求和响应,另外一种是异步的消息传递。
在我们微服务项目开发中,进程间通信的传统方式是使用 RESTful 服务的方式实现同步的请求和响应。实际上,通过 HTTP 和 JSON 将应用程序构建为 RESTful 服务已经是构建微服务的标准方法。
但是随着微服务数量增多,RESTful 服务的方式实现进程间通信越来越低效,因为 RESTful 服务使用文本传输,微服务之间缺乏强类型接口,并且 REST 架构不能强制应用程序使用等问题,所以 RESTful 服务的方式已经不能满足需求。
基于以上原因,gRPC 进程间通信应运而生,gRPC 扩展性强、松耦合,比 RESTful 服务更高效,所以越来越多的公司将进程间通信协议替换为 gRPC。
03 gRPC 的优点和缺点
优点:
gRPC 进程间通信与 RESTful 服务不同的是,它没有使用文本传输,而是使用基于 protocol buffers 的二进制协议,二进制传输的效率远远高于文本传输的效率,并且 gRPC 是基于 HTTP/2 实现的 protocol buffers 协议,从而使进程间通信更加高效。
gRPC 与 RESTful 服务不同的是,gRPC 先要定义服务接口,然后再去实现细节。因此,gRPC 可以约束多语言开发的分布式应用程序,使分布式应用程序更加可靠,可扩展。
gRPC 使用 protocol buffers 定义服务接口,可以支持多种语言,并且强制约束了不同语言的分布式应用程序之间进程间通信使用的类型,可以使分布式应用程序更加稳定。
缺点:
gRPC 也不是十全十美,在项目开发中,有时需要给三方提供接口服务,尤其是外部公司的三方,因为 gRPC 具有接口契约和强类型等特点,会限制面向外部服务的灵活性,所以 gRPC 可能不适合面向外部的服务。
在面向浏览器和 APP 应用等客户端接口开发时,因为它们对 gRPC 的支持还处于初级阶段,大部分公司还是选择使用 REST 接口进行通信,所以我们在选择进程间通信协议时,还是要根据实际使用场景做出最佳选择。
04 总结
本文我们介绍目前进程间通信使用比较多的 RESTful 服务方式和 gRPC 方式,随着微服务架构的服务中,分布式服务数量越来越多的背景下,RESTful 服务的方式已经不能满足需求。
我们通过简述 RESTful 服务方式的局限性,和 gRPC 的优势,介绍了微服务架构选择 gRPC 通信协议的原因。
相关文章
- B站接入层网络演进实践
- 角速度、线速度之外,描述宇宙还有另一种方式?AI发现新变量登Nature子刊
- 软件工程师的硬件抓狂指南
- 不堆概念、换个角度聊多线程并发编程
- 华为鸿蒙3.0正式发布,这次破了安卓圈?
- 谷歌团队推出新Transformer,优化全景分割方案
- 谁来助我与算法共舞——算法管理中的领导力
- 最新的目标检测的深度架构 参数少一半、速度快3倍+
- 挑战OpenAI!以色列AI21 Labs推最新语言模型:侏罗纪-X
- 普林斯顿陈丹琦:如何让「大模型」变小
- 小哥自创AI防拖延系统,一玩手机就被“闪瞎”
- 跨全端SDK技术演进
- 教大模型自己跳过“无用”层,推理速度×3性能不变,谷歌MIT这个新方法火了
- 2022年程序员最新薪资调查出炉
- 从业务开发中学习和理解架构设计
- 三板斧!助你成为优秀软件工程师
- 坚持了16年,这次百度秀了什么?
- 人人都能用的多语种大语言模型来了!支持59种语言,参数1760亿
- Google开源Carbon语言,旨在成为C++的继任者
- 论文党有福了!微软Edge浏览器增加“引文”功能:一键生成文献引用格式