文章目录
- 如何看待如火如荼的 gRPC
-
- 风光无限的 gRPC
- 什么是 gRPC
- gRPC 主打特性
-
- 基于 HTTP2
-
- 多路复用
- 流控
- 推送
- 头部压缩
- 其他...
- 基于 protobuf 协议
- 市场占有率攀升
- 附录
了解更多,请关注 公众号 “ code 杂坛 “!
如何看待如火如荼的 gRPC
风光无限的 gRPC
随着 云原生时代的到来,服务架构呈现微服务化,服务之间的通信框架 gRPC 向传统的 Json/Xml 模式发起挑战!
了解更多,请关注 公众号 “ code 杂坛 “!
什么是 gRPC
gRPC 正在成为云原生时代通信层事实上的标准。
gRPC 在 2015 年被 Google 开源,旨在解决移动及智能设备在通信中的性能及消耗问题。
随着云原生技术的兴起,其成为了 CNCF 明星孵化项目,正逐步在云原生架构及组件中承担主要通信职责,比如 envoy、Service Mesh、Istio….
gRPC 主打特性
gRPC 的如火如荼,发展迅猛,除了主导通信协议指定标准的 Google 推波助澜外,其出色的性能也是大家有目共睹的。
了解更多,请关注 公众号 “ code 杂坛 “!
基于 HTTP2
gRPC 主打特性之一基于 HTTP2.0 协议。HTTP 目前有三个主要协议,分别为 HTTP1.0、HTTP.1.1、HTTP2.0。
在 HTTP2.0 中针对 HTTP 1 系列 中存在的问题做了功能优化及补充,主要在下面几点:
多路复用
- 在 HTTP1 系列中,请求模型效率有限。一个请求对应一个连接,只有等服务端响应之后,才会处理下个请求。在海量请求下,这就需要建立多个连接。在长连接的技术下,虽然可减少连接频繁建立/销毁的消耗,但处理效率始终是不高的。
- 在 HTTP2 中,支持不间断的发送请求,且支持优先级策略。通过将每个请求打散成多帧,组合成流进行发送。服务端会根据优先级策略对优先级不同的流进行重组传输,以流中帧的标识进行请求重组,进而传递给不同的服务处理。
了解更多,请关注 公众号 “ code 杂坛 “!
流控
- 在 HTTP2 中,支持对流的帧标识进行限制。当数据接收端负载过大、或停止某类型的服务等特殊场景,可向数据发送端进行流控。
- 举个例子,比如 用户同时下载了多集电视剧,可发现某集看过了会立马暂停或删除此集任务,这时 client 就可以通知 server 立即停止发送此集表示的帧数据,进而阻止无效资源的占用。
推送
- 在 HTTP2 中,直接支持 双向流的推送。传统的数据流是通过 client 请求 server 发起,而双向流的 Push 是值,server 可直接 推送流 给 client 。
- 举个例子,在 APP 开机时,平台往往会设置 开屏广告,增加营收的同时对服务进行热加载。而对于广告的投放策略之一就是由 server 直接将一批广告 推送 到 手机进行缓存,下次 APP 启动直接读缓存,进而提升广告曝光成功率。
头部压缩
- 在 HTTP1 系列中,请求 Header 内容每次不会变化太多,且当服务注入 cookie 过多数据时很容易膨胀,没有相应的压缩传输优化方案。
- 在 HTTP2 中,提供 Header 的压缩机制。通过提供高效的压缩算法,进而减少数据包的数量,减少带宽的同时,降低请求延迟。在 Header 的数据注入机制上,也提供了精简的配置方案。
其他…
了解更多,请关注 公众号 “ code 杂坛 “!
基于 protobuf 协议
gRPC 主打特性之一基于 protobuf 数据序列号协议。
protobuf 是一种新颖、高效的数据序列化协议。相对传统的 JSON/XML 文本格式基于字符传输,其进行更加高效的序列化算法,且以二进制格式基于值进行传输。
在有效的带宽中,同样的数据包,protobuf可以传输更多次。且数据越小,序列化越快,大幅度提升带宽使用率。
在云原生架构中,服务之间的极高通信效率及带宽利用率,不仅可以大幅降低资源成本,又能指数级提升服务性能指标,往往是架构优化中的必备手段!像 gRPC 这样的优质框架多来点才好!
市场占有率攀升
gRPC 的两大特性奠定了其市场占有率不断上升的基石,也是各大技术生态纷纷牵手的原因。
了解更多,请关注 公众号 “ code 杂坛 “!
附录
你不可能从现在预测到未来,只有回头看时,才会发现事物之间的联系。所以你必须相信,那些生命中的点点滴滴,将会在你未来的生命里,以某种方式串联起来。你必须始终相信一些东西——你的勇气、宿命、生活、因缘,随便什么,它们将给你追寻内心真正所想的自信,带你走离平凡,变得与众不同。
了解更多,请关注 公众号 “ code 杂坛 “!