De 0 a 1: comprender completamente las llamadas remotas RPC

Editor|Hu Weiwei

¿Qué es RPC? La explicación dada por la Enciclopedia Baidu es: "RPC (Protocolo de llamada a procedimiento remoto): un protocolo para solicitar servicios de programas informáticos remotos a través de la red sin comprender la tecnología de red subyacente".

Este concepto todavía suena abstracto, y está bien. Sigue mirando hacia atrás. Explicaré los aspectos conceptuales con suficiente claridad para que puedas comprender completamente el contenido básico de RPC.

Hay dos formas principales de comunicación entre procesos en OpenStack, una es la API RESTFul basada en el protocolo HTTP y la otra es la llamada RPC.

Entonces, ¿cuáles son las diferencias entre estos dos métodos en los escenarios de aplicación?

Las personas experimentadas lo sabrán:

Primero te haré dos preguntas y luego seguiré leyendo:

1. ¿Cuál es la diferencia entre RPC y REST? la diferencia? 2. ¿Por qué utilizar RPC?

Primera pregunta: ¿Cuál es la diferencia entre RPC y REST?

Debes pensar que esta pregunta es extraña, sí, incluyéndome a mí, pero si buscas en Internet, encontrarás artículos comparativos similares en todas partes. Estoy pensando que muchos principiantes pueden comparar dos cosas no relacionadas debido a su base débil. Siendo ese el caso, para darle un poco más de información sobre la rareza de RPC, comencemos con el resto con el que está muy familiarizado.

01, diferentes categorías

REST es la abreviatura de transferencia de estado representacional, que se utiliza para describir la transferencia de estado representacional en chino (refiriéndose a una instantánea de los datos de recursos en un momento determinado, incluido el contenido y el formato de presentación de los datos de recursos (XML, JSON) y otra información)

REST es un estilo de arquitectura de software. Una aplicación típica de este estilo es HTTP. Debido a su simplicidad y gran escalabilidad, los desarrolladores lo prefieren ampliamente.

RPC es la abreviatura de Protocolo de llamada a procedimiento remoto (Protocolo de llamada a procedimiento remoto en chino, es una llamada a procedimiento remoto, que permite al cliente llamar al servicio (método) del servidor como un servicio (método) local. ).

RPC se puede transmitir basándose en el protocolo TCP/UDP o HTTP. Es lógico que RPC y REST no sean lo mismo y no deban discutirse juntos. Pero ¿quién hizo que REST fuera tan popular? Actualmente es el estándar de diseño API más popular para aplicaciones de Internet. En cierto sentido, lo que llamamos REST en realidad se refiere al protocolo HTTP.

02. Utilizar de diferentes maneras

03. Diferente orientación a objetos.

Desde el punto de vista del diseño, RPC, la llamada llamada a procedimiento remoto, está orientada a métodos, REST, la llamada transferencia de estado concreta, está orientada a recursos, y también existe la -llamado SOA, la llamada arquitectura orientada a servicios está orientada a mensajes, por lo que no entraré en detalles sobre esta conexión.

04. Los protocolos de serialización son diferentes.

Las llamadas de interfaz suelen constar de dos partes, serialización y protocolo de comunicación.

Protocolo de comunicación, como se mencionó anteriormente, REST se basa en el protocolo HTTP, mientras que RPC se puede transmitir basándose en el protocolo TCP/UDP o HTTP.

Los protocolos de serialización comunes incluyen: json, xml, hession, protobuf, thrift, text, bytes, etc. REST normalmente usa JSON o XML, mientras que RPC usa JSON-RPC o XML-RPC.

A través de los puntos anteriores, sabemos que existen diferencias obvias entre REST y RPC.

Luego la segunda pregunta: ¿Por qué utilizar RPC?

Entonces, ¿por qué utilizamos RPC? ¿No podemos confiar simplemente en la API RESTful? ¿Por qué necesitamos hacer tantos acuerdos complejos? Zha dijo que realmente no se puede aprender.

En este punto, los siguientes puntos son solo mis conjeturas personales y son solo para comunicación:

Dicho todo esto, ¿cómo debo elegir entre los dos? He resumido los dos puntos siguientes para su referencia:

"Llamada remota" significa que la implementación específica del método llamado no está en el programa local, sino en otro lugar (distribuido a varios servidores). La persona que llama sólo quiere el resultado de la operación de la función, no los detalles específicos de la implementación de la función.

Todos hablan sin práctica.

A continuación, utilizaré tres métodos diferentes para permitirle comprender completamente cómo se implementan las llamadas remotas rpc.

01, basado en xml-rpc

Python puede implementar RPC utilizando SimpleXMLrpcServer en la biblioteca estándar, que se basa en el protocolo XML-RPC.

Con este módulo, abrir un servidor rpc se vuelve muy sencillo. Ejecute el siguiente código:

Con el servidor rpc, el siguiente paso es el cliente rpc. Debido a que XML-RPC se usa arriba, rpc clinet necesita usar la biblioteca xmlrpclib.

Luego, podemos llamar remotamente las funciones del servidor rpc anterior a través del objeto server_proxy.

SimpleXMLRPCServer es un servidor de un solo subproceso. Esto significa que si varios clientes realizan varias solicitudes al mismo tiempo, las otras solicitudes deben esperar a que se complete la primera antes de continuar.

No es difícil lograr concurrencia multiproceso utilizando SimpleXMLRPCServer. Simplemente cambie el código al siguiente.

02, basado en json-rpc

SimpleXMLRPCServer es una llamada remota basada en xml-rpc. Como se mencionó anteriormente, además de xml-rpc, también existe el protocolo json-rpc.

Entonces, ¿cómo implementa Python el protocolo json-rpc?

La respuesta es mucho. Muchos frameworks web ya implementan json-rpc por sí mismos, pero debemos buscar una solución más limpia e independiente de estos frameworks. Encontré dos opciones.

El primero es jsonrpclib.

El segundo es python-jsonrpc.

Veamos primero el primer jsonrpclib.

Es muy similar a SimpleXMLRPCServer en la biblioteca estándar de Python (debido a que su nombre de clase es SimpleJSONRPCServer, las personas que no saben la verdad realmente piensan que son hermanos). Se puede decir que jsonrpclib se escribió después de la biblioteca estándar SimpleXMLRPCServer.

Su importación es ligeramente diferente a la de SimpleXMLRPCServer, porque SimpleJSONRPCServer se distribuye en la biblioteca jsonrpclib.

Servidor de red informática

Cliente

Veamos el segundo python-jsonrpc, que parece un poco complicado de escribir.

Servidor de red informática

Cliente

El proceso de llamada es el siguiente

Aún recuerdo la API de zabbix mencionada anteriormente, porque tengo He estado expuesto a él, así que también hablemos de ello. La API de Zabbix también se implementa según el protocolo json-rpc 2.0.

Debido a que hay mucho contenido, solo le mostraré cómo se llama a zabbix: especifique directamente el método para llamar al servidor zabbix y qué parámetros se pasan a este método.

03, basado en zerorpc

Los dos métodos de llamada remota de rpc mencionados anteriormente, si es lo suficientemente cuidadoso, puede encontrar que son ambos), actualizaré y complementaré el contenido de notificar.

El módulo OpenStack RPC proporciona tres métodos de llamada RPC, rpc.call y RPC. Elenco y RPC. Fanout_cast, utilizado para enviar y recibir solicitudes RPC.

Rpc.llamada y. No hay mucha diferencia en el código de implementación de rpc.cast, excepto que se tomará el parámetro wait_for_reply=True al llamar, pero no cast.

Para comprender el mecanismo de llamada de rpc, primero debes conocer varios conceptos de oslo_messaging. Hay cuatro métodos principales:

Transporte: el método de implementación subyacente de las funciones RPC. La siguiente es la ruta de acceso a la cola de mensajes de Rabbitmq.

El transporte consiste en definir cómo acceder al middleware de mensajes.

Por ejemplo, si usa Rabbitmq, debería haber una línea de configuración transport_url en nova.conf. Puede ver claramente que Rabbitmq está designado como middleware de mensajes y que el usuario, la contraseña, el host y el puerto para conectarse a Rabbitmq están configurados.

Target se utiliza para indicar si el servidor RPC escucha el intercambio de temas, nombres de servidores y monitores de servidores, o si transmite fanout.

Para recibir el mensaje, el servidor rpc necesita definir el objetivo, al igual que el número de la casa.

Para enviar un mensaje, el cliente rpc también necesita un destino para indicar dónde se enviará el mensaje.

Punto final: es un objeto que otros pueden llamar de forma remota.

Los servidores RPC exponen puntos finales, cada uno de los cuales contiene una serie de métodos que pueden ser llamados por clientes remotos a través del transporte. Intuitivamente, puede consultar el código para crear un servidor rpc con nova-conductor. El punto final aquí es nova/Manager.py:Conductor Manager.

Dispatcher: Dispatcher, este es solo un concepto de servidor rpc.

Solo a través de él el servidor puede saber quién manejará la solicitud rpc recibida y cómo manejarla.

En el lado del cliente, esto especifica qué método llamar.

En el lado del servidor, ¿cómo sabes ejecutar este método? Ese es el trabajo del despachador. Encuentra este método desde el punto final, lo ejecuta y finalmente regresa.

Serializador: Clase base para serializar o deserializar datos entre objetos y mensajes de Python (notificaciones).

Hay cuatro métodos principales:

Cada oyente de notificaciones está vinculado a un ejecutor para controlar cómo se distribuyen las notificaciones recibidas. De forma predeterminada, se utiliza el ejecutor de bloqueo (consulte la sección de ejecución para conocer características específicas).

La imitación es un método de aprendizaje muy eficaz. Aquí extraigo el contenido principal basado en el método de llamada de OpenStack y escribo una demostración simple. Aquellos que estén interesados ​​en OpenStack pueden obtener más información al respecto. La mayoría de las personas pueden omitir este capítulo directamente.

Tenga en cuenta que el siguiente código no se puede ejecutar directamente y es necesario configurar el método de conexión Rabbitmq. Puede escribirlo en el archivo de configuración y leerlo desde cfg. CONF pasa get_transport, o puede escribirse directamente en formato URL y pasarse a get_transport como parámetro. Y en el entorno de nova u otros componentes de openstack (porque se requiere la variable de entorno ctxt)

Cliente rpc simple

Servidor rpc simple

Fin

¿Recomendaciones de artículos populares

? Facebook lanza Money Libra; Google gasta mil millones de dólares para construir casas para los pobres; ¿se lanza Raspberry Pi 4 de cuarta generación | Developer Weekly

? ¿WebRTC unificará el mundo del audio y el vídeo en tiempo real?

? Xiaomi Cui Baoqiu: ¿Xiaomi AIoT adopta profundamente el código abierto

? ¿Futurewei, la organización de investigación y desarrollo de Huawei en Estados Unidos, planea escindirse?

? ¡Un conductor experimentado le enseña cómo escribir código que nadie se atreve a mantener!

? ¿Qué ventajas técnicas tiene Python? ¿Qué es mejor que otros idiomas?

? Si no puedes ir a Turing en la Universidad de Pekín o a Yao Class en la Universidad de Tsinghua, ¿dónde más puedes especializarte en IA?

? Historia de la cadena pública | Diez años de agitación desde el comienzo del sistema Hongmeng hasta el crecimiento de todas las cosas...

? ¿Es necesaria la contenedorización para la informática de punta?

? Jack Ma fue una vez un ídolo, ¡pero al final perdió los 140 mil millones que le dejó Ali!

Cada "look" en el que haces clic, lo considero seriamente mi favorito.