手机grpc通道连接成功什么意思
gRPC协议是一个高性能。
通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(ProtocolBuffers)序列化协议开发，且支持众多开发语言。
本文作者深入研究了gRPC协议，对协议本身作出解构。gRPC是基于HTTP/2协议的，要深刻理解gRPC，理解下HTTP/2是必要的。
这里先简单介绍一下HTTP/2相关的知识，然后再介绍下gRPC是如何基于HTTP/2构建的。
Grpc原理
rpc调用原理框架如图:
-支持多语言的rpc框架，例如Google的grpc，facebook thrift， 百度的brpc
-支持特定语言的rpc框架， 例如新浪微博的Motan
-支持服务治理微服务化特性框架，其底层仍是rpc框架，例如 阿里的Du***o
目前业内主要使用基于多语言的 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 线程模型
gRPC入坑记
概要
由于gRPC主要是谷歌开发的，由于一些已知的原因，gRPC跑demo还是不那么顺利的。单独写这一篇，主要是gRPC安装过程中的坑太多了，记录下来让大家少走弯路。
主要的坑：
本文讲解gRPC demo的同时，会介绍如何解决这些坑。本文对应的Github地址： 。该仓库存储了demo示例，以及部分系统编译好的二进制包，大家觉得有些步骤里耗时实在太长了，可以直接clone该仓库，复制二进制包到对应目录（仅限测试开发，生产环境还是老老实实自己编译吧）。
升级GCC
gRPC命令行工具编译需要使用 GCC4.8及以上版本。CentOS6系列的内置版本是GCC4.7。
如果你的系统GCC版本=4.8，可以忽略本节。如果仅使用golang、java，请忽略本节。
如果需要升级gcc至4.8或更高版本，建议直接采用安装SCL源之后安装devtoolset-6（devtoolset-6目前gcc版本为6.3），因为devtoolset-4及之前的版本都已经结束支持，只能通过其他方法安装。
升级到gcc 6.3：
需要注意的是scl命令启用只是 临时 的，退出shell或重启就会恢复原系统gcc版本。如果要长期使用gcc 6.3的话：
这样退出shell重新打开就是新版的gcc了。其它版本同理。
升级到gcc 7.3：
已经停止支持的devtoolset4(gcc 5.2)及之前版本的安装方法，可能比较慢，大家感兴趣的话可以尝试。
编译gRPC命令行工具
gRPC分C、JAVA、GO、NodeJS版本，C版本包括C++, Python, Ruby, Objective-C, PHP, C#，这些语言都是基于C版本开发的，共用代码库一个代码库。
如果使用C版本的gRPC，最终要从源码里编译出下列工具：
这些工具作为插件供proto编译器使用。需要先下载 grpc/grpc github上的源码。
这里有2个坑：
1、grpc/grpc仓库比较大，鉴于国内访问的网速，建议使用国内镜像。码云（）提供了同步更新的镜像地址：
这样下载速度提高了不少。
2、git submodule update这个命令实际就是在下载.gitmodules文件里定义的第三方依赖项到third_party目录，这个依赖项有很多，大家可以打开.gitmodules文件查看下详情。依赖的仓库都在github上，下载没几个小时是下载不下来的，就等着慢慢下载吧。
回头想想，我们花费了很多时间，结果只是为了得到grpc的proto编译插件。
PHP相关支持
PHP暂时不支持作为grpc的服务端。作为客户端是可以的，需要机器安装：
其中protoc和protobuf c扩展已经在 Protobuf 小试牛刀 介绍过了，这里不再赘述。上一小节里如果安装成功，那么grpc_php_plugin也是有了的。下面介绍如何安装PHP版的gRPC库。
安装grpc c扩展：
要求：GCC编译器需要4.8及以上版本。可以使用pecl安装：
也可以指定版本：
或者下载源码（）安装：
grpc/grpc代码库里也有PHP扩展的C源码，在grpc/src/php/ext/grpc目录，进去也可以直接编译。
编译完成后在php.ini里添加，使用php --ri grpc可以查看信息。
安装完C扩展后，还需要使用composer安装grpc的库：
gRPC示例
编写gRPC proto
一共定义了三个文件：
其中 User 作为 Model定义，Response 用于 RPC统一返回定义，GreeterService 则是服务接口定义。
限于篇幅，proto文件详见 仓库的proto目录。
GreeterService.proto文件内容如下：
这里面定义了一个service，相当于定义了一个服务接口，我们把方法名、参数定义好了，后面需要去实现它。由于gRPC不支持PHP作为服务端，这里我们使用Golang作为服务端。
首先需要使用proto工具编译出golang的代码：
执行成功，会在 Pb_Go目录里生成Go代码:
如果需要生成PHP客户端的代码，则需要使用grpc php的命令行工具grpc_php_plugin，前面小结如果执行成功，这个工具已经有了。然后：
最终生成的文件：
注意：编译那里如果我们不加--grpc_out=../$out --plugin=protoc-gen-grpc=/usr/local/bin/grpc_php_plugin，生成的PHP类是没有GreeterClient的。这个文件是gRPC编译工具自动生成的，用于连接gRPC服务端。
go编写服务
我们用Golang写服务端。上面虽然生成了Golang的部分代码，但真正的服务还没有写呢。
main.go
首先我们新建个main.go，代码不多，我直接贴出来：
然后就可以编译了。
有个大坑：go build main.go的时候会先下载go.mod里定义的依赖（依赖比较多，详情查看：），其中下面这条非常慢，仓库太大了，虽然重定向到github：
为了快速下载，我在码云上做了镜像，地址：gitee.com/52fhy/google-api-go-client 。改了之后下载快多了。
编译成功后，生成了二进制文件main。我们可以直接运行：
go test
为了测试我们写的服务是否正常，可以写测试用例：
test_client.go
运行：
运行有点慢，感觉依赖的库多了。
php客户端
使用gRPC PHP客户端，确保你已经安装了：
示例：
client_test.php
运行后输出：
常见问题
1、CentOS6使用 go mod获取第三方依赖包unknown revision xxx错误
解决：其实go mod调用链中会用到一些git指令，当git版本比较旧时，调用失败产生错误，并给出歧义的提示信息。方法就是升级git版本，CentOS6自带的git是1.7版本。升级完毕后，再尝试go mod。
快速升级方法：
centos6:
2、PHP报错：Fatal error: Class 'GoogleProtobufInternalMessage' not found
解决：请安装PHP的protobuf c扩展。
3、PHP报错：Fatal error: Class 'GrpcbaseStub' not found
解决：使用composer require grpc/grpc安装grpc。另外对应的grpc C扩展也要安装。
4、下载 github release包很慢怎么办?
解决：下载Mac版 Free Download Manager 下载工具可以解决Github 下载缓慢或失败问题。速度嗖嗖的。
参考
1、为CentOS 6、7升级gcc至4.8、4.9、5.2、6.3、7.3等高版本
2、centos 6.x/7.x使用yum升级git版本 - 夜空
3、Protobuf 小试牛刀 - 飞鸿影
(本文完)
GRPC状态码
使用grpc的时候，线上php客户端调用go服务端，出现2/5/14等状态码，没有做日志输出，导致问题查了很长时间，最终问题是因为连接没有close掉，php连接数不够了。
grpc的状态码在google.golang.org/grpc/codes：code码跟http的状态码是一个道理，整理下状态码的含义：
0：Ok：请求成功
1：Canceled：操作已取消
2：Unknown：未知错误。如果从另一个地址空间接收到的状态值属 于在该地址空间中未知的错误空间，则可以返回此错误的示例。 没有返回足够的错误信息的API引发的错误也可能会转换为此错误
3：InvalidArgument：表示客户端指定了无效的参数。 请注意，这与FailedPrecondition不同。 它表示无论系统状态如何（例如格式错误的文件名）都有问题的参数
4：DeadlineExceeded：意味着操作在完成之前过期。 对于更改系统状态的操作，即使操作成功完成，也可能会返回此错误。 例如，服务器的成功响应可能会延迟足够的时间以使截止日期到期
5：NotFound：表示找不到某个请求的实体（例如文件或目录）
6：AlreadyExists：表示尝试创建实体失败，因为已经存在
7：PermissionDenied：表示调用者没有执行指定操作的权限。它不能用于因耗尽某些资源而引起的拒绝（使用ResourceExh***sted代替这些错误）。如果调用者无法识别，则不能使用它（使用Un***thenticated代替这些错误）
8：ResourceExh***sted：表示某些资源已耗尽，可能是每个用户的配额，或者整个文件系统空间不足
9：FailedPrecondition：表示操作被拒绝，因为系统不处于操作执行所需的状态。例如，要删除的目录可能不是空的，rmdir操作应用于非目录等。可能帮助服务实现者判断FailedPrecondition，Aborted和Unavailable之间的试金石测试：使用不可用如果客户端只能重试失败的呼叫。如果客户端应该在更高级别重试（例如，重新启动读取 - 修改 - 写入序列），则使用中止。如果客户端不应该重试直到系统状态被明确修复，则使用FailedPrecondition。例如，如果“rmdir”由于目录非空而失败，应该返回FailedPrecondition，因为客户端不应该重试，除非他们首先通过从目录中删除文件来修复该目录。如果客户端在资源上执行条件REST获取/更新/删除并且服务器上的资源与条件不匹配，则使用FailedPrecondition。例如，在相同的资源上发生冲突的读取 - 修改 - 写入
10：Aborted：表示操作被中止，通常是由于并发问题（如序列器检查失败，事务异常终止等）造成的。请参阅上面的试金石测试以确定FailedPrecondition，Aborted和Unavailable之间的差异
11：OutOfRange：表示操作尝试超过有效范围。 例如，寻找或阅读文件末尾。 与InvalidArgument不同，此错误表示如果系统状态更改可能会解决的问题。 例如，如果要求读取的偏移量不在[0,2 ^ 32-1]范围内，则32位文件系统将生成InvalidArgument，但如果要求从偏移量读取当前值，则它将生成OutOfRange 文件大小。 FailedPrecondition和OutOfRange之间有相当多的重叠。 我们建议在应用时使用OutOfRange（更具体的错误），以便遍历空间的调用者可以轻松查找OutOfRange错误以检测何时完成
12：Unimplemented：表示此服务中未执行或未支持/启用操作
13：Internal： 意味着底层系统预期的一些不变量已被打破。 如果你看到其中的一个错误，那么事情就会非常糟糕
14：Unavailable：表示服务当前不可用。这很可能是一种暂时性情况，可能会通过退避重试来纠正。请参阅上面的试金石测试以确定FailedPrecondition，Aborted和Unavailable之间的差异
15：DataLoss：指示不可恢复的数据丢失或损坏
16：Un***thenticated：表示请求没有有效的操作认证凭证
17：_maxCode：这个是***的状态码
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 连接池
关于grpc和grpc加油站的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。