grpc协议,grpc协议 http
手机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框架，例如 阿里的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 线程模型
gRPC 4种rpc定义方法与3种stub介绍
有关gRPC官方介绍（ ）如下：
gRPC是一个能在不同语言不同平台中进行高效通信的服务。gRPC默认使用Protocol Buffers数据格式：
Protocol Buffers以.proto作为拓展名，是一系列以name-value键值对的形式存储的数据格式。
Protocol Buffers从开源到现在已经经过很长时间，目前已经到了proto3版本，有着更加简化的语法，更加有用的特性，能够支持更多的语言。你可以从 proto3 language guide 和? reference documentation 看到更多有用的东西。另外.proto的文件格式能够从 formal specification 获取到更详细的讲解。
每个参数带有一个唯一的标识符，这些标识符被用来在message的二进制中被识别出来。不是代表每个数据的数值。
有了gRPC，我们可以在.proto文件中定义我们的服务，并用gRPC支持的任何语言生成客户端和服务器，它可以在从大型数据中心内的服务器到您自己的平板电脑的各种环境中运行，不同语言和环境之间的所有复杂通信都由gRPC为您处理。我们还获得了使用协议缓冲区的所有优点，包括高效的序列化、简单的IDL和容易的接口更新。
声明定义proto使用3版本，如果不生命默认2版本号。
在proto文件中定义java_package，指定了我们要用于生成的Java类的包。如果.proto文件中没有显式的java_package选项，那么默认情况下将使用proto包（使用“package”关键字指定）。
使用service定义服务。然后在service中使用rpc方法定义，gRPC允许使用4种不同的定义方式，定义方法。
区别在客户端调用Grpc中Stub发送请求方法时：
可以使用message定义所有的request and response types，在service中使用到的数据格式。
grpc-源码-网络模型
golang 的grpc库是
grpc server端和服务端网络协议是在tcp基础上的 http2协议，http2协议负责grpc基础的数据传输、连接管理、流控等， 具体的业务层service 定义是基于 protobuf的
整个的网络过程和关键点如下图
说明：
TCP KeepAlive则是为了探测/保鲜（心跳检测，连接错误检测）：用于探测对端的状态及网络情况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)，也有保鲜功能。比如如防止nat超时。TCP keepalive则是通过发送发送侦测包实现。在Linux中通过net.ipv4.tcp_keepalive_intvl，net.ipv4.tcp_keepalive_probes，net.ipv4.tcp_keepalive_time配置。比如gnet 网络框架中的实现
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 连接池
国信证券Zebra微服务架构简介
我们从0到1设计开发了国信微服务架构，他是一个完整的，从前到后的架构。我们希望逐步分享出来，后续也会将此架构开源。
1、配置依赖最小化；
2、开发速度最大化；
3、环境部署最简化；? ?
选用grpc,因为grpc有以下几个优势：
1、多语言支持；
2、社区活跃，生命力强，七月份发布1.5版本；
3、支持ios、Android，支持SSL和自定义鉴权（支持国密），可以简单实现客户端到后台的多路复用、rpc调用；
4、只有通信层依赖于grpc，所以容易替换；
5、grpc使用pb协议，此协议在互联网上广泛使用，生命力强；
6、支持流stream，在流的基础上实现了Server Push，方便做变更通知，不再需要客户端做费力的Long Pull；
方案基于进程内LB方案，结合分布式一致的组件etcd3，进行设计开发，具备以下功能：
1、服务自动注册；
2、服务自动发现；
3、负载均衡；
4、注册中心异常保护；
5、异常通报下发；
6、服务降级；
可视化服务管理平台，展示服务信息，包含功能如下：
1、server展示，包括ip地址、端口号、应用名称、接口名称；
2、api展示，显示proto文件内容；
3、api测试；
4、服务监控展示；
5、服务依赖动态图展示；
api网关基于vert.x实现，后期考虑采用原生netty进行升级：
1、由统一的入口来调用微服务的API；
2、API鉴权；
3、反向代理、数据剪裁、数据聚合；
4、流量控制；
5、监控报警；
6、TCP、HTTP等多协议支持；
基于springboot进行业务开发：
1、权限管理，服务接口授权；
2、服务端流量控制；
3、业务线程池管理；
4、调用端和服务端TCP连接数管理；
5、服务过载快速失败；
6、TCP心跳保活；
7、调用链分析埋点；
8、超时管理；
9、泛化调用；
参考Prometheus搭建监控中心，具有以下功能：
1、服务流量上报；
2、服务访问ip上报；
3、服务平均耗时情况上报；
4、异常上报；
5、日志收集服务；
6、调用链埋点；
对配置信息进行统一管理，可做到一次打包，各个环境都可使用，具有以下功能：
1、资源类配置与业务类配置分离；
2、作用域分离（分为四大作用域：GLOBAL、IDC、SET、NODE）；
3、配置中心异常容错；