「grpcjava性能」grpc stream java

本篇文章给大家谈谈grpcjava性能，以及grpc stream java对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、为什么 Go 语言的性能还不如java
• 2、GRPC 浅析
• 3、gRPC服务开发和接口测试初探「Go」
• 4、GRPC的理解
• 5、Spring Cloud 整合Grpc-注册中心（Eureka/Consul）
• 6、Grpc原理

为什么 Go 语言的性能还不如java

Go语言自亮相以来并没有展示一个明确的方向，Google员工将Go语言称为一个“试验性语言”，称其试图融合Python等动态语言的开发速度和C或C++等编译语言的性能和安全。一位Go语言的支持者概括而言Go语言如下：简单、快速、安全、并发、快乐编程、开源；但Go语言缺乏方向以及其“集大成者”的尝试很容易会导致其学猫不成学狗也不成，沦为四不像。尽管如此，编者仍然觉得Go语言有相当大的潜力：很多开发者对它感兴趣——不仅它的最初设计者阵容强大，而且在参与修改源代码的人群中也不乏大牛级人物。这很有可能帮助Go语言找到适合自己的方向，开拓系统编程的新方向。

GRPC 浅析

IDL(proto buffer) + RPC

netty：异步/事件驱动的 网络应用程序服务器框架（高性能）

Http2：流式、双向

protobuf：序列化（节省网络带宽）

IDL定义示例：

Starting from a service definition in a .proto file, gRPC provides protocol buffer compiler plugins that generate client- and server-side code.

Http：如果没有API文档就不知道细节，

GRPC：IDL就相当于API文档，可以同时

开发顺序：

Http：先服务端后客户端

GRPC：可以同时

跨语言：都支持多语言

性能：GRPC远差于Thrift，因为用了Http2，各大server目前支持不完善

易用性：GRPC尚未完全提供连接池、服务自动发现、进程内负载均衡等高级特性，需要开发人员额外的封装；

多语言

Http2特性：如stream

易用性：GRPC尚未完全提供连接池、服务自动发现、进程内负载均衡等高级特性，需要开发人员额外的封装

gRPC服务开发和接口测试初探「Go」

之前写过了Grpc服务开发和接口测试初探【Java】，中间耽搁了一些时间，Go版本的gRPC测试开发实践才有时间学习使用。其中也是由于自己Go语言不够熟悉导致的。之前有段时间想暂时放弃Go语言的学习，导致了Go的生疏，原因是从Groovy到Java性能。

回归正题，Go语言版本的gRPC实践相对Java来说是比较简单的，但是总体的工具链是比较复杂的，可能是因为Go生态目前相比Java还是比较匮乏吧。下面我先简述一下大致的步骤：

以上步骤亲自操作可能会遇到一些小问题，我本人搜到的教程什么的也是乱七八糟，踩了一些坑。我没有整理出一个亲自实践之后的可行的教程，原因有二：

Go语言的gRPC的 proto 编写跟Java大致一致，只有一个报名的参数不太一样。下面是我的 Hello.proto 内容：

这里主要 go_package 网上搜到的配置方式有些不一样，我没有全都尝试，大家在搜索的资料时候，尽量先看看 syntax 这个参数的值，以及文章教程写作的时间，如果距离现在太久了，我建议直接关掉。搜索引擎有过滤功能，可以过滤掉过时的教程。

这里Go语言gRPC的一点优势，就是在一个项目中即可实现，Java需要先弄一个SDK这样。Go语言的gRPC的代码可以通过生成代码命令中的参数实现指定路径。我是放在了和 proto 文件的同级目录。

服务端代码也是比较格式化的内容，如下：

其中 pb.RegisterHelloServiceServer(s, Ser{}) 如果报错，请检查自己安装的工具 protoc-gen-go 或者 protoc-gen-gofast 版本，一般提取报错 message 搜索也能得到解决办法。

下面是客户端的代码，由于学艺不精，其中大部分参数的含义目前我也不是很清楚，特别是基于 stream 的请求响应的方式使用。后面我先把Java的学完，再回过头来看Go的，按照这个顺序学习和分享。

服务端输出：

忘记打日志了。没有输出

客户端输出：

Go语言的gRPC测试开发实践已经完事儿，大概率上我不会在工作中使用Go作为主力gRPC测试语言，后面测试实践内容还是会以Java为主。

GRPC的理解

grpc每个流只有一个grpc的数据帧，这个数据帧在传输的时候，会拆成多个http2的数据帧进行传输，然后在接受端，把所有http2的数据帧拼接成grpc的数据帧，再反序列化成请求的结构体。如果一次传输数据过大，在序列化和反序列化的时候，都会占用大量的cpu，不仅仅序列化，单纯的内存复制，也会占用大量cpu，而且，传输的时候，对带宽的影响也是很大的。因此，grpc不推荐一次传输大量数据，如果有大量数据要传输，则使用stream模式。【当然，grpc单次数据传输的大小限制是可以修改的，但是不建议你这么做】【默认最大消息大小为4MB

】

【不断修改增加服务端和客户端消息大小，每次请求不一定需要全部数据，会导致性能上和资源上的浪费】

【grpc协议层是基于http2设计的（但之前看一片测评文章，结构发现文件传输的时候速度有点慢，因为大量数据传输的场景瓶颈在于tcp，如果还在一个tcp上进行多路复用，那只会加剧锁竞争）】

【4 MB 的限制是为了保护没有考虑过消息大小限制的客户端/服务器。 gRPC 本身可以提高很多（100 MB），但大多数应用程序可能会受到轻微攻击或意外内存不足，从而允许该大小的消息。】

【grpc本质是为了提高单连接的利用率，如果单个stream上传输大量的数据，那么其他stream的数据就很难得到及时的传输，grpc适用于大量的请求，但是每次请求的传输数据量不大的情况】

【如果单次传输的数据量过大，建议从新开一个tcp连接，也就是用http1.1，因为在数据量很大的情况下，瓶颈在于底层的tcp】

【同理，在IM系统中，拉消息也建议使用http1.1的接口，避免占用大量的长连带宽，影响下行推送及时性】

【http1.1有维护连接池，每次请求都会独占一个tcp连接，所以，在传输大量数据的场景下，也不会影响到其他请求的数据传输，瓶颈在于机器性能】

grpc 连接池

Spring Cloud 整合Grpc-注册中心（Eureka/Consul）

       Spring Cloud分布式微服务应用，通常在微服务之间采用的Feign进行通信，实现简单快捷的调用，底层采用的HTTP形式；相对于gRPC或RPC协议调用来说，性能相对低下，因此我们可以采用开源技术框架gRPC来实现。

       微服务开发中，服务间的调用一般有两种方式：Feign或RestTemplate，但在实际使用过程中，尤其是Feign，存在各种限制及局限性，如：HTTP请求方式、返回类型等限制等。服务间调用是非常普遍频繁的，其性能也不是特别理想。

       为了解决上述问题，我们采用gRPC方式实现服务间调用，其显著特点就是性能之高(通信采用Netty)，通过proto文件定义的接口也是非常清晰而又灵活。

       gRPC是谷歌开源的一个高性能的、通用的RPC框架。和其他RPC一样，客户端应用程序可以直接调用远程服务的方法，就好像调用本地方法一样。它隐藏了底层的实现细节，包括序列化（XML、JSON、二进制）、数据传输（TCP、HTTP、UDP）、反序列化等，开发人员只需要关自业务本身，而不需要关注RPC的技术细节。与其他RPC框架一样，gRPC也遵循定义服务(类似于定义接口的思想)。gRPC客户端通过定义方法名、方法参数和返回类型来声明一个可以被远程调用的接口方法。由服务端实现客户端定义的接口方法，并运行一个gRPC服务来处理gPRC 客户端调用，gRPC客户端和服务端共用一个接口方法。

新建common项目，存放proto文件，服务端和客户端都依赖此项目。

* pom依赖

* 新建helloworld.proto文件，放在：src/main/proto/helloworld.proto

* pom.xml依赖

* 新建GrpcServerService

}

* yml配置

* pom.xml依赖配置

* 新建GrpcClientService

* yml配置

Consul和Eureka区别在于替换pom依赖、yml注册地址修改、启动类修改。

源码： 提取码: 28qs

源码：spring-boot-rpc

提取码: 28qs

Grpc原理

rpc调用原理框架如图:

-支持多语言的rpc框架，例如Google的grpc，facebook thrift， 百度的brpc

-支持特定语言的rpc框架， 例如新浪微博的Motan

-支持服务治理微服务化特性框架，其底层仍是rpc框架，例如 阿里的Dubbo

目前业内主要使用基于多语言的 RPC 框架来构建微服务，是一种比较好的技术选择，例如netflix ，API服务编排层和后端微服务之间采用微服务rpc进行通信

-支持C java js

-git地址

-原理图:

gRPC 的线程模型遵循 Netty 的线程分工原则，即：协议层消息的接收和编解码由 Netty 的 I/O(NioEventLoop) 线程负责；后续应用层的处理由应用线程负责，防止由于应用处理耗时而阻塞 Netty 的 I/O 线程

不过正是因为有了分工原则，grpc 之间会做频繁的线程切换，如果在一次grpc调用过程中，做了多次I/O线程到应用线程之间的切换，会导致性能的下降，这也是为什么grpc在一些私有协议支持不太友好的原因

缺点

改进:

优化后BIO线程模型采用了线程池的做法但是后端的应用处理线程仍然采用同步阻塞的模型，阻塞的时间取决对方I/O处理的速度和网络I/O传输的速度

grpc的线程模型主要包含服务端线程模型，客户端线程模型

2.1.1 I/O 通信线程模型

gRPC的做法是服务监听线程和I/O线程分离Reactor多个线程模型 其工作原理如下:

2.1.2 服务调度线程模型

gRPC 客户端线程模型工作原理如下图所示（同步阻塞调用为例)

相比于服务端，客户端的线程模型简单一些，它的工作原理如下：

grpc 线程模型

关于grpcjava性能和grpc stream java的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。