分布式 RPC架构简单理解

水深无声 2022-06-06 05:06 215阅读 0赞

## RPC框架 ##

RPC（Remote Promote Call） 一种进程间通信方式。允许像调用本地服务一样调用远程服务。

RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式（TCP或者UDP）、序列化方式（XML/JSON/二进制）和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

## RPC框架实现的几个核心技术点： ##

（1）远程提供者需要以某种形式提供服务调用相关的信息，包括但不限于服务接口定义、数据结构、或者中间态的服务定义文件。例如Facebook的 Thrift的IDL文件，Web service的WSDL文件；服务的调用者需要通过一定的图景获取远程服务调用相关的信息。

（2）远程代理对象：服务调用者用的服务实际是远程服务的本地代理。说白了就是通过动态代理来实现。

（3）通信：RPC框架与具体的协议无关。

（4）序列化：毕竟是远程通信，需要将对象转化成二进制流进行传输。不同的RPC框架应用的场景不同，在序列化上也会采取不同的技术

## RPC面临的挑战 ##

在大规模服务化之前，应用可能只是通过RPC框架，简单的暴露和引用远程服务，通过配置URL地址进行远程服务调用，路由则通过F5负载均衡器等进行简单的负载均衡。

当服务越来越多的时候，服务的URL配置管理变得更加困难。单纯的使用RPC就有点吃不消。所以在大规模分布式集群中，RPC只是作为集群的一个方法调用手段。例如在Hadoop的进程间交互都是通过RPC来进行的，比如Namenode与Datanode直接，Jobtracker与Tasktracker之间等。

## RPC与WebServie ##

讲道理，我觉得RPC与WebService很像.可以说WebService是在RPC发展的基础之上。WebService是运行在web上的一个服务

RPC使用C/S方式，发送请求到服务器，等待服务器返回结果。

Web Service提供的服务是基于web容器的，底层使用http协议，类似一个远程的服务提供者，比如天气预报服务，对各地客户端提供天气预报，是一种请求应答的机制，是跨系统跨平台的。就是通过一个servlet，提供服务出去。

## RPC与JMS ##

在RPC中，当一个请求到达RPC服务器时，这个请求就包含了一个参数集和一个文本值，通常形成“classname.methodname”的形式。这就向RPC服务器表明，被请求的方法在为“classname”的类中，名叫“methodname”。然后RPC服务器就去搜索与之相匹配的类和方法，并把它作为那种方法参数类型的输入。这里的参数类型是与RPC请求中的类型是匹配的。一旦匹配成功，这个方法就被调用了，其结果被编码后返回客户方。

JMS 一般只是一个点发出一个Message到Message Server,发出之后一般不会关心谁用了这个message。JMS可以做到异步调用完全隔离了客户端和服务提供者，能够抵御流量洪峰；JMS获得消息可以进行延迟处理，而RPC一般是进行实时调用。

相比较其他的通信而言，RPC的侧重点在于方法。并且是C/S架构方式

![这里写图片描述][803118-20170314190016948-135397649.png]

**MVC架构**：当业务规模很小时，将所有功能都不熟在同一个进程中，通过双机或者负载均衡器实现负债分流；此时，分离前后台逻辑的MVC架构是关键。

**PRC架构**：当垂直应用越来越多，应用之间交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。此时，用于提高业务复用及拆分的RPC框架是关键。

**SOA架构**：随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的SOA服务治理是关键。

**微服务架构**：通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降。

[803118-20170314190016948-135397649.png]: /images/20220606/b3a47e4db6174417a8886975edd0dc07.png