1 rpc框架原理
rpc调用原理框架如图:
2 业内比较成熟的rpc框架
支持多语言的主要分为3类
-支持多语言的rpc框架，例如Google的grpc，facebook thrift， 百度的brpc
-支持特定语言的rpc框架， 例如新浪微博的Motan
-支持服务治理微服务化特性框架，其底层仍是rpc框架，例如 阿里的Dubbo
目前业内主要使用基于多语言的 RPC 框架来构建微服务，是一种比较好的技术选择，例如netflix ，API服务编排层和后端微服务之间采用微服务rpc进行通信
3 GRPC框架介绍
-支持C java js
-git地址 https://github.com/grpc/grpc-java
-原理图:
4 GRPC服务端创建流程
- NettyServer的创建，gRpc服务端的创建，初始化nettyServer，nettyServer负责监听socket地址，实习基于HTTP2协议的写入
- 绑定IDL定义服务接口实现类，grpc和一些RPC框架的不同是，服务的接口实现类并不是同过反射实现的，而是通过proto工具生成的代码，服务启动后，将服务的接口实现类注册到gRpc内部的服务注册中心上，请求消息来后，便可以通过服务名和方法名调用 ，直接调用启动的时候注册的服务实例，bu不需要反射进行调用，性能更优
-
ServerImpl 负责整个 gRPC 服务端消息的调度和处理，创建 ServerImpl 实例过程中，会对服务端依赖的对象进行初始化，例如 Netty 的线程池资源,gRPC 的线程池、内部的服务注册类（InternalHandlerRegistry)
image.png
4.1 gRpc消息接入流程
-
gRPC消息由netty /http/2 协议负责接入，通过grpc 注册的Http2Framelister将解码后的Http header和Http body 发送到gRPC的NettyServerHandler ，实现netty http/2的消息接入
gRPC 请求消息接入流程如下:
image.png
4.2 gRPC消息响应模型
4.3 Netty Server 线程模型
gRPC 的线程模型遵循 Netty 的线程分工原则，即：协议层消息的接收和编解码由 Netty 的 I/O(NioEventLoop) 线程负责；后续应用层的处理由应用线程负责，防止由于应用处理耗时而阻塞 Netty 的 I/O 线程
不过正是因为有了分工原则，grpc 之间会做频繁的线程切换，如果在一次grpc调用过程中，做了多次I/O线程到应用线程之间的切换，会导致性能的下降，这也是为什么grpc在一些私有协议支持不太友好的原因
gRpc 的线程模型
1. BIO线程模型 ，例如tomcat的BIO线程模型
缺点
改进:
优化后BIO线程模型采用了线程池的做法但是后端的应用处理线程仍然采用同步阻塞的模型，阻塞的时间取决对方I/O处理的速度和网络I/O传输的速度
2 异步非阻塞的线程模型
grpc的线程模型主要包含服务端线程模型，客户端线程模型
服务端线程模型主要包括
- 服务端的写入，客户端的接入线程（HTTP/2 Acceptor）
- 网络I/O的读写线程
- 服务接口调用线程
客户端线程模型主要包含
- 客户端的链接 （HTTP/2 Connector）
- 网络I/O读写线程
- 接口调用线程
- 响应回调通知线程
2.1服务调度线程模型
2.1.1 I/O 通信线程模型
gRPC的做法是服务监听线程和I/O线程分离Reactor多个线程模型 其工作原理如下:
2.1.2 服务调度线程模型
2.2客户端线程模型概述
gRPC 客户端线程模型工作原理如下图所示（同步阻塞调用为例)
2.2.1 I/O 通信线程模型
相比于服务端，客户端的线程模型简单一些，它的工作原理如下：
2.2.2 客户端调用线程模型
grpc 线程模型
