本篇文章为大家展示了RPC远程调用该如何理解，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。今天我又给自己挖坑了，打算将 rpc 远程调用的知识，好好地梳理一下，花了周末整整两天的时间。什么是RPC呢？百度百科给出的解释是这样的：“RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议”。这个概念听起来还是比较抽象，没关系，继续往后看，后面概念性的东西，我会讲得足够清楚，让你完全掌握 RPC 的基础内容。在后面的篇章中还会结合其在 OpenStack 中实际应用，一步一步揭开 rpc 的神秘面纱。## 01. 既 REST，何 RPC ？在 OpenStack 里的进程间通信方式主要有两种，一种是基于HTTP协议的RESTFul API方式，另一种则是RPC调用。那么这两种方式在应用场景上有何区别呢？有使用经验的人，就会知道：* 前者（RESTful）主要用于**各组件之间**的通信（如nova与glance的通信），或者说用于组件对外提供调用接口
* 而后者（RPC）则用于**同一组件中各个不同模块之间**的通信（如nova组件中nova-compute与nova-scheduler的通信）。关于OpenStack中基于RESTful API的通信方式主要是应用了WSGI，这个知识点，我在前一篇文章中，有深入地讲解过，你可以点击查看。对于不熟悉 OpenStack 的人，也别担心听不懂，这样吧，我给你提两个问题：1. RPC 和 REST 区别是什么？
2. 为什么要采用RPC呢？**第一个问题：RPC 和 REST 区别是什么？**你一定会觉得这个问题很奇怪，是的，包括我，但是你在网络上一搜，会发现类似对比的文章比比皆是，我在想可能很多初学者由于基础不牢固，才会将不相干的二者拿出来对比吧。既然是这样，那为了让你更加了解陌生的RPC，就从你熟悉得不能再熟悉的 REST 入手吧。**01、所属类别不同**REST，是Representational State Transfer 的简写，中文描述表述性状态传递（是指某个瞬间状态的资源数据的快照，包括资源数据的内容、表述格式(XML、JSON)等信息。）REST 是一种软件架构风格。 这种风格的典型应用，就是HTTP。其因为简单、扩展性强的特点而广受开发者的青睐。而RPC 呢，是 Remote Procedure Call Protocol 的简写，中文开发云主机域名描述是远程过程调用，它可以实现客户端像调用本地服务(方法)一样调用服务器的服务(方法)。RPC 是一种基于 TCP 的通信协议，按理说它和REST不是一个层面上的东西，不应该放在一起讨论，但是谁让REST这么流行呢，它是目前最流行的一套互联网应用程序的API设计标准，某种意义下，我们说 REST 可以其实就是指代 HTTP 协议。**02、使用方式不同****从使用上来看**，HTTP 接口只关注服务提供方，对于客户端怎么调用并不关心。接口只要保证有客户端调用时，返回对应的数据就行了。而RPC则要求客户端接口保持和服务端的一致。* REST 是服务端把方法写好，客户端并不知道具体方法。客户端只想获取资源，所以发起HTTP请求，而服务端接收到请求后根据URI经过一系列的路由才定位到方法上面去
* PRC是服务端提供好方法给客户端调用，客户端需要知道服务端的具体类，具体方法，然后像调用本地方法一样直接调用它。**03、面向对象不同**从设计上来看，RPC，所谓的远程过程调用 ，是面向方法的 ，REST：所谓的 Representational state transfer ，是面向资源的，除此之外，还有一种叫做 SOA，所谓的面向服务的架构，它是面向消息的，这个接触不多，就不多说了。**04、序列化协议不同**接口调用通常包含两个部分，序列化和通信协议。通信协议，上面已经提及了，REST 是 基于 HTTP 协议，而 RPC 可以基于 TCP/UDP，也可以基于 HTTP 协议进行传输的。常见的序列化协议，有：json、xml、hession、protobuf、thrift、text、bytes等，REST 通常使用的是 JSON或者XML，而 RPC 使用的是 JSON-RPC，或者 XML-RPC。通过以上几点，我们知道了 REST 和 RPC 之间有很明显的差异。**第二个问题：为什么要采用RPC呢？**那到底为何要使用 RPC，单纯的依靠RESTful API不可以吗？为什么要搞这么多复杂的协议，渣渣表示真的学不过来了。关于这一点，以下几点仅是我的个人猜想，仅供交流哈：1. RPC 和 REST 两者的定位不同，REST 面向资源，更注重接口的规范，因为要保证通用性更强，所以对外最好通过 REST。而 RPC 面向方法，主要用于函数方法的调用，可以适合更复杂通信需求的场景。
2. RESTful API客户端与服务端之间采用的是同步机制，当发送HTTP请求时，客户端需要等待服务端的响应。当然对于这一点是可以通过一些技术来实现异步的机制的。
3. 采用RESTful API，客户端与服务端之间虽然可以独立开发，但还是存在耦合。比如，客户端在发送请求的时，必须知道服务器的地址，且必须保证服务器正常工作。而 rpc + ralbbimq中间件可以实现低耦合的分布式集群架构。说了这么多，我们该如何选择这两者呢？我总结了如下两点，供你参考：* REST 接口更加规范，通用适配性要求高，建议对外的接口都统一成 REST（也有例外，比如我接触过 zabbix，其 API 就是基于 JSON-RPC 2.0协议的）。而组件内部的各个模块，可以选择 RPC，一个是不用耗费太多精力去开发和维护多套的HTTP接口，一个RPC的调用性能更高（见下条）
* 从性能角度看，由于HTTP本身提供了丰富的状态功能与扩展功能，但也正由于HTTP提供的功能过多，导致在网络传输时，需要携带的信息更多，从性能角度上讲，较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据，传输数据更小，性能更高。## 02. 实现远程调用的三种方式“远程调用”意思就是：被调用方法的具体实现不在程序运行本地，而是在别的某个地方（分布到各个服务器），调用者只想要函数运算的结果，却不需要实现函数的具体细节。**01、基于 xml-rpc**Python实现 rpc，可以使用标准库里的 SimpleXMLRPCServer，它是基于XML-RPC 协议的。有了这个模块，开启一个 rpc server，就变得相当简单了。执行以下代码:“`
import SimpleXMLRPCServerclass calculate:
def add(self, x, y):
return x + y def multiply(self, x, y):
return x * y def subtract(self, x, y):
return abs(x-y) def divide(self, x, y):
return x/yobj = calculate()
server = SimpleXMLRPCServer.SimpleXMLRPCServer((“localhost”, 8088))
# 将实例注册给rpc server
server.register_instance(obj)print “Listening on port 8088”
server.serve_forever()
“`有了 rpc server，接下来就是 rpc client，由于我们上面使用的是 XML-RPC，所以 rpc clinet 需要使用xmlrpclib 这个库。“`
import xmlrpclibserver = xmlrpclib.ServerProxy(“http://localhost:8088”)
“`然后，我们通过 server_proxy 对象就可以远程调用之前的rpc server的函数了。“`
>> server.add(2, 3)
5
>>> server.multiply(2, 3)
6
>>> server.subtract(2, 3)
1
>>> server.divide(2, 3)
0
“`SimpleXMLRPCServer是一个单线程的服务器。这意味着，如果几个客户端同时发出多个请求，其它的请求就必须等待第一个请求完成以后才能继续。若非要使用 SimpleXMLRPCServer 实现多线程并发，其实也不难。只要将代码改成如下即可。“`
from SimpleXMLRPCServer import SimpleXMLRPCServer
from SocketServer import ThreadingMixIn
class ThreadXMLRPCServer(ThreadingMixIn, SimpleXMLRPCServer):passclass MyObject:
def hello(self):
return “hello xmlprc”obj = MyObject()
server = ThreadXMLRPCServer((“localhost”, 8088), allow_none=True)
server.register_instance(obj)print “Listening on port 8088”
server.serve_forever()
“`**02、基于json-rpc**SimpleXMLRPCServer 是基于 xml-rpc 实现的远程调用，上面我们也提到 除了 xml-rpc 之外，还有 json-rpc 协议。那 python 如何实现基于 json-rpc 协议呢？答案是很多，很多web框架其自身都自己实现了json-rpc，但我们要独立这些框架之外，要寻求一种较为干净的解决方案，我查找到的选择有两种第一种是 `jsonrpclib““
pip install jsonrpclib -i https://pypi.douban.com/simple
“`第二种是 `python-jsonrpc““
pip install python-jsonrpc -i https://pypi.douban.com/simple
“`先来看第一种 [jsonrpclib](https://github.com/joshmarshall/jsonrpclib/)它与 Python 标准库的 SimpleXMLRPCServer 很类似（因为它的类名就叫做 SimpleJSONRPCServer ，不明真相的人真以为它们是亲兄弟）。或许可以说，jsonrpclib 就是仿照 SimpleXMLRPCServer 标准库来进行编写的。它的导入与 SimpleXMLRPCServer 略有不同，因为SimpleJSONRPCServer分布在jsonrpclib库中。服务端“`
from jsonrpclib.SimpleJSONRPCServer import SimpleJSONRPCServerserver = SimpleJSONRPCServer((‘localhost’, 8080))
server.register_function(lambda x,y: x+y, ‘add’)
server.serve_forever()
“`客户端“`
import jsonrpclibserver = jsonrpclib.Server(“http://localhost:8080”)
“`[图片上传中…(image-e0730d-1610601786095-15)]
import pyjsonrpcclass RequestHandler(pyjsonrpc.HttpRequestHandler): @pyjsonrpc.rpcmethod
def add(self, a, b):
“””Test method”””
return a + bhttp_server = pyjsonrpc.ThreadingHttpServer(
server_address=(‘localhost’, 8080),
RequestHandlerClass=RequestHandler
)
print “Starting HTTP server …”
print “URL: http://localhost:8080”
http_server.serve_forever()
“`客户端“`
import pyjsonrpchttp_client = pyjsonrpc.HttpClient(
url=”http://localhost:8080/jsonrpc”
)
“`[图片上传中…(image-a950f0-1610601786095-14)]
pip install zerorpc -i https://pypi.douban.com/simple
“`服务端代码“`
import zerorpcclass caculate(object):
def hello(self, name):
return ‘hello, {}’.format(name) def add(self, x, y):
return x + y def multiply(self, x, y):
return x * y def subtract(self, x, y):
return abs(x-y) def divide(self, x, y):
return x/ys = zerorpc.Server(caculate())s.bind(“tcp://0.0.0.0:4242”)
s.run()
“`客户端“`
import zerorpcc = zerorpc.Client()
c.connect(“tcp://127.0.0.1:4242”)
“`[图片上传中…(image-47df9-1610601786095-12)]
zerorpc –server –bind tcp://127.0.0.1:1234 time
“`在客户端，就可以用这条命令来远程调用这个 time 函数。“`
zerorpc –client –connect tcp://127.0.0.1:1234 strftime %Y/%m/%d
“`[图片上传中…(image-6cb105-1610601786095-10)]
2. 一个队列可以有多个receiver，队列里的一个消息只能发给一个receiver。
3. 一个消息可以被发送到一个队列中，也可以被发送到多个多列中。多队列情况下，一个消息可以被多个receiver收到并处理。Openstack RPC中这两种情况都会用到。## 05. OpenStack中如何使用RPC？前面铺垫了那么久，终于到了讲真实应用的场景。在生产中RPC是如何应用的呢？其他模型我不太清楚，在 OpenStack 中的应用模型是这样的[图片上传中…(image-ecd481-1610601786095-8)]
2. oslo.messaging.notify（实现了事件的通知机制）因为 notify 实现是太简单了，所以这里我就不多说了，如果有人想要看这方面内容，可以收藏我的博客([python-online.cn](http://python-online.cn)) ，我会更新补充 notify 的内容。OpenStack RPC 模块提供了 rpc.call，rpc.cast, rpc.fanout_cast 三种 RPC 调用方法，发送和接收 RPC 请求。* rpc.call 发送 RPC **同步请求**并返回请求处理结果。
* rpc.cast 发送 RPC **异步请求**，与 rpc.call 不同之处在于，不需要请求处理结果的返回。
* rpc.fanout_cast 用于发送 RPC 广播信息无返回结果rpc.call 和 rpc.rpc.cast 从实现代码上看，他们的区别很小，就是call调用时候会带有wait_for_reply=True参数，而cast不带。要了解 rpc 的调用机制呢，首先要知道 oslo_messaging 的几个概念* transport：RPC功能的底层实现方法，这里是rabbitmq的消息队列的访问路径 transport 就是定义你如何访连接消息中间件，比如你使用的是 Rabbitmq，那在 nova.conf中应该有一行`transport_url`的配置，可以很清楚地看出指定了 rabbitmq 为消息中间件，并配置了连接rabbitmq的user，passwd，主机，端口。 “`
transport_url=rabbit://user:passwd@host:5672
“` [图片上传中…(image-cefa55-1610601786090-6)]
def get_transport(conf, url=None, allowed_remote_exmods=None):
return _get_transport(conf, url, allowed_remote_exmods,
transport_cls=RPCTransport)
“`* target：指定RPC topic交换机的匹配信息和绑定主机。 target用来表述 RPC 服务器监听topic，server名称和server监听的exchange，是否广播fanout。 “`
class Target(object):
def __init__(self, exchange=None, topic=None, namespace=None,
version=None, server=None, fanout=None,
legacy_namespaces=None):
self.exchange = exchange
self.topic = topic
self.namespace = namespace
self.version = version
self.server = server
self.fanout = fanout
self.accepted_namespaces = [namespace] + (legacy_namespaces or [])
“` rpc server 要获取消息，需要定义target，就像一个门牌号一样。 [图片上传中…(image-dbec91-1610601786090-5)]
2. deserialize_entity(ctxt, entity) ：对entity做反序列化，其中ctxt是已经deserialize过的，entity是要处理的。
3. serialize_context(ctxt) ：将Request context变成字典类型
4. serialize_entity(ctxt, entity) ：对entity做序列化，其中ctxt是已经deserialize过的，entity是要处理的。
* executor：服务的运行方式，单线程或者多线程 每个notification listener都和一个executor绑定，来控制收到的notification如何分配。默认情况下，使用的是blocking executor(具体特性参加executor一节） “`
oslo_messaging.get_notification_listener(transport, targets, endpoints, executor=’blocking’, serializer=None, allow_requeue=False, pool=None)
“`rpc server 和rpc client 的四个重要方法1. `reset()`：Reset service.
2. `start()`：该方法调用后，server开始poll,从transport中接收message,然后转发给dispatcher.该message处理过程一直进行，直到stop方法被调用。executor决定server的IO处理策略。可能会是用一个新进程、新协程来做poll操作，或是直接简单的在一个循环中注册一个回调。同样，executor也决定分配message的方式，是在一个新线程中dispatch或是….. *
3. `stop()`:当调用stop之后，新的message不会被处理。但是，server可能还在处理一些之前没有处理完的message,并且底层driver资源也还一直没有释放。
4. `wait()`：在stop调用之后，可能还有message正在被处理，使用wait方法来阻塞当前进程，直到所有的message都处理完成。之后，底层的driver资源会释放。## 06. 模仿OpenStack写rpc调用模仿是一种很高效的学习方法，我这里根据 OpenStack 的调用方式，抽取出核心内容，写成一个简单的 demo，有对 OpenStack 感兴趣的可以了解一下，**大部分人也可以直接跳过这章节**。以下代码不能直接运行，你还需要配置 rabbitmq 的连接方式，你可以写在配置文件中，通过 get_transport 从cfg.CONF 中读取，也可以直接将其写成url的格式做成参数，传给 get_transport 。**简单的 rpc client**“`
#coding=utf-8
import oslo_messaging
from oslo_config import cfg# 创建 rpc client
transport = oslo_messaging.get_transport(cfg.CONF, url=””)
target = oslo_messaging.Target(topic=’test’, version=’2.0′)
client = oslo_messaging.RPCClient(transport, target)# rpc同步调用
client.call(ctxt, ‘test’, arg=arg)
“`**简单的 rpc server**“`
#coding=utf-8
from oslo_config import cfg
import oslo_messaging
import time# 定义endpoint类
class ServerControlEndpoint(object):
target = oslo_messaging.Target(namespace=’control’,
version=’2.0′) def __init__(self, server):
self.server = server def stop(self, ctx):
if self.server:
self.server.stop()class TestEndpoint(object): def test(self, ctx, arg):
return arg# 创建rpc server
transport = oslo_messaging.get_transport(cfg.CONF, url=””)
target = oslo_messaging.Target(topic=’test’, server=’server1′)
endpoints = [
ServerControlEndpoint(None),
TestEndpoint(),
]
server = oslo_messaging.get_rpc_server(transport, target,endpoints,executor=’blocking’)
try:
server.start()
while True:
time.sleep(1)
except KeyboardInterrupt:
print(“Stopping server”)server.stop()
server.wait()
“`上述内容就是RPC远程调用该如何理解，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注开发云行业资讯频道。
相关推荐: 企业应用架构演化探讨：从微服务到Service Mesh
导读当下微服务的实践方案中，Spring Cloud，Dubbo作为主流的落地方案，在企业应用架构中发挥越来越重要的作用。本文探讨企业应用架构如何从微服务架构向Service Mesh架构演化，并形成落地方案。需要特别说明：本文讨论的架构目前适用于普通的企业级…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
