标签:cli 请求 fir 理想 结构 web protocol 计算 processor
RPC 技术原理
RPC ( Remote Procedure Call Protocol,远程过程调用协议 ): 客户端在不知道调用细节的情况下,调用存在于远程计算机上的某个对象,就像调用本地应用程序中的对象一样 。
1.RPC要点
RPC 是协议 : 既然是协议就只是一套规范规则,也就需要有人遵循这套规范来进行实现 。 目前典型的 RPC 实现包括 : dubbo (注意是小写的,不是大写的 DUBBO 服务治理框架〉 、 Apache Thrift、 GRPC 、 Hetty等 。
网络协议和网络I/O模型对其透明 : 既然 RPC 的客户端认为自己是在调用本地对象,那么传输层使用的是 TCP 还是 HTTP 协议, 又或者是一些其他的网络协议它就不需要关心了。
信息格式对其透明 : 这些调用与返回的参数会以某种信息格式传递给网络上的另外一台计算机,这个信息格式是怎样构成的,调用方就不需要关心了 ,
RPC 框架都应该有跨语言能力:当然,现实情况下由于一些 RPC 框架的特殊工作场景 ,也没有强行要求其提供跨语言能力,例如只工作在 Java 语言下的 RMI 就是这样一套 RPC 框架。
2.RPC要素
? Client: RPC 协议的调用者。最理想的情况是 RPC 调用者在完全不知道有 RPC 框架存在的情况下发起对远程服务的调用。但实际情况来说 Client 或多或少都需要指定RPC框架的一些细节。
? Server : 在 RPC 规范中 , 这个 Server 并不是提供 RPC 服务器 IP、端口监昕的模块 。 而是远程服务上业务逻辑的具体实现(在 Java 中就体现为 RPC 服务接口的具体实现) 。其中的代码是最普通的和业务相关的代码,甚至其接口实现类本身都不知道将被某一个 RPC 远程客户端调用。
? Proxy: RPC 代理存在于客户端 , 因为要实现客户端对 RPC 框架“透明”调用,那么客户端就不可能自行去管理消息格式 , 不可能自己去管理网络传输协议,也不可能自己去判断调用过程是否有异常。这一切工作在客户端都是交给RPC框架中的“代理”层来处理的。
? Message Protocol : 一次完整的 RPC Client-Server 的交互肯定要携带某种两端都能识别的,共同约定的消息格式。 RPC 的消息管理层专门对网络传输所承载的信息进行编号和解码操作。目前流行的技术趋势是不同 的 RPC 实现,为了加强自身框架的效率都有一套(或者几套)私有 的 消息格式 。例如后文我们将讲解的 一套 RPC 框架 Apache Thrift , 就 拥 有私有 化的 消息 协 议。当然 Ap ache Thri位 还支持通用的消息格式,如JSON )。
? Transfer/Network Protocol : 传输协议层负责管理 RPC 框架所使用的网络协议、网络I/O模型 。 例如 Hessian 的传输协议基于 Http (应用层协议) : 再例如 Apache Thrift的传输协议基于 TCP (传输层协议)。传输层还需要统一 RPC 客户端和 RPC 服务端所使用的网络I/O模型 。
? Processor:存在于 RPC 服务端,由于服务器端某一个 RPC 接口的实现特性(它并不知道自己是一个将要被 RPC 提供给第三方系统调用的服务)。所以在 RPC 框架中应该有一种“负责执行 RPC 接口实现”的角色。它的职责包括管理RPC接口的注册、判断客户端的请求权限、控制接口实现类的执行在 内的各种工作 。
? IDL :虽然 IDL (接口定义语言)并不是 RPC 实现中所必须的。但是需要跨语言的RPC 框架一定会有 IDL 部分的存在。这是因为要找到一个各种语言能够理解的消息结构、接口定义的描述形式 。 如果你的 RPC 实现没有考虑跨语言性,那么 IDL 部分就不需要。例如 Java RMI 就是一种专门在 Java 语言间进行使用的特殊的 RPC 框架,它设计之初就没有要求要有跨语言执行特性,所以 Java RMI 没有相应的 IDL 。
? 不同的 RPC 实现都有一定设计差异。例如生成 Proxy 的方式不一样 、 IDL 描述语言的语法不一样、服务注册的管理方式不一样、运行服务实现的方式不一样 、 采用的消息格式封装不一样、采用的网络协议不一样,等等。
3.典型的 RPC 框架介绍
1)Java RMI : Java RPC , Java Serializable, TCP, java
2)GRPC : Google, ProtoBuf, HTTP/2, 众多语言
3)Thrift :FaceBook, Thrift(私有二进制,LVQ,JSON), TCP, 众多语言
4)Hetty :Netty/Hessian, 私有二进制, HTTP, 众多语言
5)WebService: XFire/CXF, XML, HTTP, 众多语言
标签:cli 请求 fir 理想 结构 web protocol 计算 processor
原文地址:https://www.cnblogs.com/gispathfinder/p/9033142.html