RPC (Remote Procedure Call): Remote Procedure Call, que es una solicitud de servicio desde un equipo remoto a través de una red, sin la necesidad de comprender la idea de la tecnología de red subyacente.
RPC es una idea tecnología y no una especificación o protocolo, y un marco de tecnología de RPC comunes son:
- marco de los servicios a nivel de aplicación: Ali Dubbo / Dubbox, Google GRPC, Primavera de arranque / Nube Primavera.
- protocolos de comunicación a distancia: RMI, zócalo, SOAP (HTTP XML), ocio (HTTP JSON).
- Marco de Comunicación: Mina y Netty.
RPC populares marco de código abierto, o más, hay Alibaba Dubbo, de Facebook Thrift, GRPC de Google, Finagle de Twitter y así sucesivamente.
Nos centramos en las tres formas siguientes:
- GRPC: Google anunció el software de código abierto se basa en HTTP 2.0 *** protocolo y soporta varios lenguajes de programación común. marco RPC se basa en el protocolo HTTP, utilizando el marco subyacente para apoyar Netty.
- Ahorro: Facebook es RPC marco de código abierto, es un marco importante de desarrollo de servicios entre idiomas.
Mientras el usuario desarrollo secundario en la línea por encima de ella, la aplicación subyacente para comunicaciones RPC son transparentes. Pero esta necesidad de los usuarios a aprender las características lingüísticas de un campo en particular, o tener un cierto costo.
- Dubbo: Ali Group es un marco de código abierto RPC muy conocida que se utiliza ampliamente en muchas empresas de Internet y aplicaciones empresariales. Y el acuerdo marco de serialización puede tapar características es extremadamente distintas.
marco completo de RPC
En un escenario típico usando el RPC, incluyendo el descubrimiento de servicio, la carga, tolerante a fallos, transmisión de red, etc. secuencia de montaje, en el que "protocolo RPC", e indica la secuencia de cómo los procedimientos de transmisión de la red.
Figura 1: Gráfico completa RPC
El siguiente es un diagrama de arquitectura de diseño de Dubbo, en capas complejidad clara, funcional:
Figura 2: Gráfico de Dubbo
funcionalidad principal RPC
la función principal del RPC es implementar un RPC módulo de función más importante, la imagen de arriba es la sección "protocolo RPC":
Figura 3: La funcionalidad de núcleo RPC
Una función básica RPC tiene cinco componentes principales, a saber: un cliente, el cliente de código auxiliar, módulo de transmisión de la red, el servidor de código auxiliar, el servidor y similares.
Figura 4: RPC núcleo diagrama de funciones
A continuación se describe el marco esencial núcleo RPC:
- Client (Cliente): persona que llama al servicio.
- resguardo del cliente (Cliente del trozo): el almacenamiento de la información de la dirección del servidor, la información de parámetros de petición de datos empaquetados en el mensaje de red del cliente antes de enviarlo al servidor a través de la red.
- servidor de código auxiliar (stub del servidor): la recepción de una solicitud enviada por el cliente descomprime el mensaje y luego llamar el proceso de servicio local.
- Server (Servidor): verdaderos proveedores de servicios.
- Servicio de red: el transporte subyacente, puede ser TCP o HTTP.
las funciones básicas de RPC para lograr
función básica de RPC se compone de cinco módulos, si se desea implementar una RPC propia, la forma más fácil de lograr los tres puntos técnicos son:
- direccionamiento
- Serializar y deserializar el flujo de datos
- La transmisión por red
direccionamiento
Direccionamiento a través de mapeo de la identificación de llamada. En una llamada local, el cuerpo de la función se especifica directamente por el puntero de función, pero en la llamada de larga distancia, el puntero de función no es suficiente, ya que el espacio de direcciones de ambos procesos son completamente diferentes.
Así que en la RPC, todas las funciones deben tener su propia identificación. Esta identificación es la única certeza en todos los procesos.
El cliente al realizar una llamada a procedimiento remoto, debe incluir esta identificación. A continuación, también necesitamos el cliente y el servidor de función, respectivamente, y mantenemos una tabla de correspondencia de identificación de llamadas.
Cuando un cliente necesita una llamada remota, comprobará esta tabla, encontrar la adecuada identificación de llamada, y luego pasarlo al servidor, el servidor también look-up table para determinar la función de la necesidad del cliente a la llamada, a continuación, realizar la adecuada código de función.
Implementación: el registro de servicios.
Para llamar al servicio, en primer lugar es necesario registrarse un centro de servicio para preguntar cuáles son los otros instancia de servicio. registro de servicios dubbo es configurable, el funcionario recomendó Zookeeper.
historias de ejecución: RMI (Remote Method Invocation, invocación de método remoto) es la implementación de RPC en sí.
Figura 9: Gráfico de RMI
Registro (descubrimiento de servicios): Con el JNDI liberación y servicio de llamadas RMI. De hecho, JNDI es un registro, el servidor servirá para poner el registro, el cliente obtiene el objeto de servicio desde el registro.
servicio RMI después de la necesidad lado de servicio para registrarse para lograr el servidor RMI, entonces el cliente de la dirección especificada servicio de búsqueda de RMI, los métodos de llamadas de servicio para completar el correspondiente método de invocación remota.
Registro es una función muy importante, cuando el servidor de servicios de desarrollo terminados a la exposición externa, si el servicio no se ha registrado, el cliente es incapaz de llamada, incluso si el extremo de servicio del servicio allí.
Serialización y de-serialización
El cliente cómo los parámetros pasados a la función de control remoto? En una llamada local, sólo tenemos que argumentos en la pila, y luego se deje función de ir a leer la pila en la línea.
Sin embargo, en la llamada a procedimiento remoto, el cliente con el servidor es un proceso diferente, no a través de la memoria de parámetros de paso.
Esta vez tenemos que poner el cliente primer argumento convertido en un flujo de bytes, transcurrido después del final del servicio, entonces el flujo de bytes en un formato que se puede leer.
Sólo los datos binarios pueden ser transmitidos en la red, y la serialización de-serialización se define como:
- El proceso de convertir un objeto en un flujo binario se llama serialización
- El flujo binario en un proceso objeto se llama deserialización
Este proceso se llama serialización y de-serialización. Del mismo modo, el valor devuelto por el servidor también puede requerir proceso de deserialización serialización.
La transmisión por red
Red de Transmisión: llamadas remotas a menudo se utilizan en la red, cliente y el servidor están conectados a través de una red.
Todos los datos se transmiten a través de la red son necesarios, y por lo tanto hay una necesidad de una capa de transporte de red. La red de transporte a las necesidades a nivel de byte de parámetro después de la ID de llamada y la corriente en serie con el servidor, y luego llama a la parte de atrás serializada resultado al cliente.
Mientras tanto se puede completar, se puede usar como la capa de transporte. Por lo tanto, en realidad se utiliza el protocolo no está limitada, para completar la línea de transmisión.
Aunque la mayoría marco RPC utiliza el protocolo TCP, UDP, pero en realidad lata, y GRPC simplemente utilizar HTTP2.
conexiones TCP son los más comunes, un breve análisis de las conexiones basadas en TCP: conexiones TCP por lo general se pueden conectar según sea necesario (necesidad de llamar al establecer un corte de conexión inmediatamente después del final de la llamada), también puede ser una conexión de largo (cliente después de que se establece la conexión y el servidor para mantener la retención a largo plazo, independientemente de si los paquetes de datos enviados en este momento, se pueden usar con un mecanismo de detección del ritmo cardiaco normal conexión establecida está vivo válido), múltiples llamadas de procedimiento remoto para compartir la misma conexión.
Por lo tanto, para lograr un marco RPC, sólo tiene que darse cuenta de los tres puntos siguientes básicamente completado:
- Llamar ID mapa: cuerdas de función se pueden usar directamente, también puede utilizar el ID de número entero. tabla de asignación general es una tabla hash.
- Serialización deserialización: Usted puede escribir su propia, o puede utilizar FlatBuffers protobuf similares.
- Transmisión biblioteca de red: Usted puede escribir su propio zócalo, o con Asio, ZeroMQ, Netty y similares.
núcleo RPC del protocolo de transporte de red
Se describe en el tercio para lograr una RPC, la necesidad de red para seleccionar el modo de transmisión.
Figura 10: la red de transmisión
red RPC opcional en una variedad de transmisión, se puede seleccionar el protocolo TCP, el protocolo UDP, HTTP protocolo.
Tiene implicaciones diferentes para cada protocolo en el rendimiento y la eficiencia general, la forma de elegir los protocolos de transporte de red correctos? Ante todo quiere entender varios protocolo de transporte de trabajo en el RPC.
TCP basado en el protocolo llamadas RPC
Por la persona que llama está conectado con los servicios de entrar en servicio Socket, el servicio por la persona que llama mediante el nombre de interfaz Socket tendrá que llamar de nuevo a la prestación de servicios de nombre del método y parámetros proveedor de serialización, deserializar proveedor de servicios y luego utilizar la reflexión para llamar a métodos relacionados.
*** Los resultados se devuelven al servicio de la persona que llama, todo el protocolo basado en TCP llamadas RPC de la misma.
Sin embargo, en el ejemplo de las aplicaciones serán una serie de paquetes, tales como RMI se transmite serializable objetos Java en el protocolo TCP.
llamadas RPC basado en el protocolo HTTP
Este método es más como una página web para acceder a la misma, excepto que devuelve un único resultado es más sencillo.
Es el proceso general: enviar una solicitud al proveedor del servicio por los servicios de la persona que llama, una petición de este tipo puede ser una manera de GET, POST, PUT, DELETE y similares, el proveedor de servicios puede realizar la solicitud de acuerdo con las diferentes formas procesamiento diferente, o algún método sólo permite que ciertos métodos de petición.
La llamada al método específico se lleva a cabo de acuerdo a la URL llamada al método y los parámetros necesarios para el método puede ser el resultado de la transmisión de la persona que llama al servicio o datos XML JSON pasado el análisis de datos, los datos *** devolver resultados JOSN o XML.
Debido a que hay una gran cantidad de servidor web de código abierto, como Tomcat, por lo que es más fácil de aplicar, simplemente hacer lo mismo proyecto Web.
Comparación de dos maneras
RPC llamadas en base a la implementación del protocolo TCP, debido a la pila de protocolos TCP en la parte inferior, una mayor flexibilidad para personalizar el campo de protocolo, reducir la sobrecarga de la red y mejorar el rendimiento y lograr un mayor rendimiento y concurrente.
Pero requiere más atención al detalle complejidad y alto costo de la implementación subyacente. Mientras que diferentes plataformas, como Andrews, iOS similares, necesidad de desarrollar diferentes kits a las peticiones de transmisión y la correspondiente resolución, la carga de trabajo, y una respuesta rápida es difícil de satisfacer las necesidades del usuario.
HTTP basada en protocolo de aplicación puede usar petición RPC los datos de respuesta JSON o XML y.
El JSON y XML como formato estándar universal (utilizando el protocolo HTTP también requiere la serialización y de-serialización, pero este no es el contenido de interés bajo el acuerdo, madurar programa Web ya ha hecho el contenido serializado), herramienta de análisis de código abierto ha sido bastante madura, desarrollo secundario será muy conveniente y simple en él.
Sin embargo, puesto que el protocolo de capa superior es el protocolo HTTP, la información de contenido transmitida contiene el mismo número de bytes ocupado por la transmisión utilizando el protocolo HTTP será mayor que el número de bytes ocupado por el protocolo de transmisión TCP.
Por lo tanto, en la misma red, el mismo contenido de transmisión a través de HTTP de protocolo, basada en la eficiencia de datos de eficiencia del protocolo TCP es menor, ocupado por la transmisión de información lleva más tiempo, por supuesto, los datos comprimidos, se pueden cerrar la brecha.
RabbitMQ uso de la arquitectura de RPC
OpenStack mediante llamadas a la API REST entre el servicio y el servicio, y luego usar las llamadas RPC a cada módulo de función de los servicios internos.
Debido al uso RPC para desacoplar el módulo de función de servicio interno, tal servicio OpenStack tiene escalabilidad, y bajo acoplamiento.
infraestructura OpenStack RPC cola de mensaje añadido RabbitMQ, con el propósito de esto es para garantizar la seguridad y la estabilidad en proceso de mensajería RPC.
Cómo utilizar OpenStack RabbitMQ llamadas de implementación de RPC siguiente análisis.
Perfil RabbitMQ
El siguiente extracto sabía casi:
Por ejemplo, los principiantes, para un restaurante para explicar lo que estos tres son derecha. *** No es apropiado, pero debería ser suficiente para explicar la diferencia entre los tres.
RPC: Supongamos que usted es un camarero del restaurante, el cliente a su pedido, pero no se puede cocinar, por lo que los platos recogidos Houchu decirle al cliente lo que el punto de atención al cliente después del punto, llamada RPC (Remote Procedure Call) porque el chef de cocina es otra persona (un proceso en el mundo de la informática es la máquina remota) con respecto a los términos del camarero. El cocinero hace los platos valor de retorno es RPC.
Tarea cola y cola de mensajes: esencialmente la cola, por lo que sólo da un ejemplo de una cola de tareas. Suponiendo que el restaurante en la cima de muchos clientes, pero sólo unos pocos cocineros, los camareros tenía que pulsar una sola orden de la lista en la mesa de la cocina, de uno en uno para los cocineros hacen, este grupo es la lista de cola de tareas chefs de cada uno terminado un plato, es fuera de la mesa con el fin de continuar la cocción y luego eliminar una lista.
El papel de intercambio en la siguiente figura:
Figura 11: papel RabbitMQ en el RPC
Los beneficios de usar RabbitMQ:
- paso mutación síncrono: Se puede utilizar el grupo de subprocesos para convertirse en la sincronización asíncrona, pero el inconveniente es lograr su propio grupo de subprocesos, y el acoplamiento fuerte. Message Queue Server puede convertirse fácilmente en solicitud de petición de sincronización asíncrona.
- Poli bajo alta acoplamiento interno: desacoplamiento, fuerte dependencia reductor.
- El recorte de flujo: *** solicitud valor de ajuste cola de mensajes, a un umbral de error para descarte o pantalla.
- Mejorar el rendimiento de las comunicaciones de red: TCP sobrecarga de crear y destruir un apretón de manos, de 3 vías grande como para crear, destruir cuatro veces para romper miles de enlaces a la cima causará un enorme desperdicio de recursos, y el identificador del sistema operativo el número de TCP por segundo es también una restricciones cuantitativas, dará lugar a cuellos de botella de rendimiento.
RabbitMQ usando canal de comunicación, la comunicación directa sin necesidad de utilizar TCP. Un canal de hilo una, hilos de múltiples pluralidad de canales, una conexión TCP común.
*** conexión TCP de canales puede ser acomodado (que la capacidad del disco suficientemente duro), sin causar un cuello de botella.
Hay tres tipos de intercambiadores de RabbitMQ
RabbitMQ mediante el cambio (switch), y en Cola (colas) para aplicar la cola de mensajes.
En RabbitMQ Hay tres tipos de interruptores, cada tipo de interruptor tiene características muy distintas.
Sobre la base de estos tres tipos de interruptores, OpenStack llamar dos maneras de completar la RPC. En primer lugar se describen brevemente tres interruptores.
Figura 12: Gráfico de RabbitMQ
① tipo intercambiador de difusión (Fanout)
Esta clase no conmutador analiza el mensaje recibido de enrutamiento Key, reenviar el mensaje a la forma predeterminada todos unidos con la cola del interruptor.
Figura 13: Switch Broadcast
② tipo de intercambio directo (Directo)
Tales interruptores requieren coincidencia exacta de enrutamiento Key y Key, como el enrutamiento Key = nubes mensaje Binding, entonces el mensaje puede ser reenviado artículo Encuadernación Mensajes clave = Cloud de la cola.
Figura 14: interruptores directos
③ intercambiador de tema (Tema Exchange)
Tal coincidencia Encuadernación Key cambiar el modo de enrutamiento de mensajes Key, reenviar el mensaje a todas las colas con delimitada.
Encuadernación comodines de apoyo clave, donde "*" corresponde a una frase, "#" para que coincida con varias frases (incluyendo el cero).
Figura 15: interruptores Tema
Nota: Las anteriores cuatro imágenes de la huerta blog, si la infracción, por favor, póngase en contacto con el autor: https: //www.cnblogs.com/dwlsxj/p/RabbitMQ.html.
Al enviar un mensaje de enrutamiento productor Clave = FCE, esta vez sólo se encuentran Cola1, se encamina a la cola.
Enrutamiento Clave = ACE Si este tiempo serán enviados simultáneamente a la Queue2 Cola1 y, si la clave de enrutamiento = AFB, donde un mensaje sólo se envía a la Queue2.
Nova implementar dos llamadas RPC basado RabbitMQ:
- RPC.CALL (llamada)
- RPC.CAST (notificación)
En donde de manera RPC.CALL basado en una petición y respuesta, solicitud RPC.CAST sólo proporcionan una vía, dos tipos de formas un típico llamadas RPC en Nova en ambos escenarios.
RPC.CALL
RPC.CALL es un bidireccional flujo de comunicación, es decir, el mensaje de petición RabbitMQ sistema de recepción generada por el productor de mensajes, el mensaje consumidor después de un respectivo resultados del procesamiento de la parte posterior del sistema para el programa de llamada.
Figura 16: Esquema RPC.CALL
Un usuario crea un tablero de instrumentos de la máquina virtual, interfaz NOVA-API para transmitir después de la encapsulación de mensajes.
NOVA-API como productores de mensajes, el mensaje se envía a la cola de mensajes RPC.CALL manera por intercambiador de Tema.
En este momento, los consumidores Nova de computación como un mensaje, y recibe la información para iniciar el proceso realizado por la máquina virtual de software de virtualización subyacente correspondiente.
Después de que el usuario de la máquina virtual que se ha iniciado satisfactoriamente, Nova-Compute un productor de mensajes a través de interruptor directo y respondiendo a una cola de mensajes de la máquina virtual se inicia la espalda mensaje de respuesta de éxito a Nova-API.
En esta Nova-API a los consumidores recibir el mensaje como un mensaje y notifica al usuario de la máquina virtual se inicia correctamente.
RPC.CALL funciona de la siguiente figura:
Figura 17: RPC.CALL implementación específica de la figura.
Flujo de trabajo:
- Reply_to nombre de la cola especificada por el cliente, marca correlation_id la persona que llama cuando se crea un mensaje.
- A través de la cola, el servidor recibe el mensaje. Llame a la función de procesamiento, y luego regresar.
- Reply_to volver cola se especifica la cola, y llevar correlation_id.
- mensaje de retorno llega al cliente, el cliente llama a una función que devuelve un correlation_id según determinación.
Si hay varios hilos simultáneamente para la invocación de método remoto, entonces habrá una gran cantidad de mensajes enviados por los dos lados que se establecen entre la transferencia de la conexión del cliente servidor de socket, antes y después de la orden puede ser aleatoria.
Después servidor procesa los resultados, los resultados envían un mensaje al cliente, el cliente recibe una gran cantidad de mensajes, ¿cómo saber qué mensaje es el resultado de lo que originalmente llamado hilo?
Client cada hilo llamando a un interfaz frontal Socket remoto, generar un identificador único, es decir, ID de petición (Request ID es necesario para garantizar la conexión en la que un zócalo único), generalmente AtomicLong utiliza a menudo para generar un número de identificación único de 0 comience a acumular.
RPC.CAST
RPC.CAST llamadas a procedimiento remoto y RPC.CALL similares, pero la falta de un proceso de respuesta de mensajes del sistema.
Tema productor envía un mensaje al interruptor de petición de mensaje del sistema Tema, Tema conmutador envía la cola de mensajes al mensaje común acuerdo con el mensaje de enrutamiento clave.
cola de mensajes compartido acoplado a todos los consumidores Tema recibe la solicitud de mensaje del sistema, y pasarlo al servidor para procesar la respuesta.
Su flujo de llamadas como se muestra:
Figura 18: Esquema RPC.CAST
diseño de conectividad
RabbitMQ aplicación de la red general de RPC ideas de diseño: los consumidores están conectados a largo, corto emisor está conectado. Pero se puede controlar libremente conector que conecta a largo y corto.
El consumidor medio está conectado larga y listo para recibir mensajes de proceso; e implican RabbitMQ colas, Cambio de auto-borrado, etc. sin necesidades especiales no necesitan conexiones cortas. El remitente puede utilizar conexiones cortas, ocupan poco tiempo el número de puerto, excepto recursos del puerto.
Nova en el diseño de código RPC:
API reparador y simple comparación RPC
arquitectura REST API
REST *** Varias características son: recursos, interfaz unificada, URI, y sin estado.
① Recursos
El llamado "recurso" es una entidad en la red, o es una información específica de la red. Puede ser un trozo de texto, una imagen, una canción, un servicio que es una realidad concreta.
② interfaz unificada
estilo REST arquitectura predeterminada, las operaciones de metadatos, es decir CRUD (crear, leer, actualizar, y la eliminación, es decir, los datos de verificación de cambio supresiones) operación, respectivamente, correspondiente al método HTTP: GET para obtener recursos, POST de nuevos recursos (que puede se utiliza para actualizar el recurso), puestos a recursos de actualización, eliminar para eliminar el recurso, de manera que una interfaz unificada para la manipulación de datos, sólo a través del método HTTP, puede completar la investigación de todas las adiciones y supresiones de cambiar el funcionamiento de los datos.
③URL
Podemos señalar a un recurso con un URI (localizador uniforme de recursos), es decir, cada URI corresponde a un recurso particular.
Para obtener este recurso, puede acceder a su URI, URI, por tanto, se convierten en un recurso para cada dirección o identificador.
④ sin estado
La llamada sin estado, es decir, todos los recursos están disponibles a través de un URI, y esto no tiene nada que ver con la localización de otros recursos, otros recursos no cambiarán debido al cambio. No hay diferencia entre el estado y el estado, dar un ejemplo sencillo de explicar.
Tales como los salarios del personal de consulta, los salarios tienen que estar conectado si el sistema de consulta, consulta la página para entrar en los salarios, después de la aplicación de las medidas pertinentes para obtener los salarios, a continuación, este caso es el Estado.
Dado que la consulta librar cada paso de las operaciones dependen de la etapa anterior de la operación, siempre y cuando la pre-operación no tiene éxito, las operaciones subsiguientes no se pueden ejecutar.
Si introduce un URI empleados para obtener los salarios especificados, a continuación, este caso no tiene estado, porque los salarios no reciben depende de otros recursos o de estado.
Y en este caso, un recurso es el salario, con el URI correspondiente a uno, el recurso puede ser obtenida por el método HTTP GET, que es un típico estilo REST.
resumen
RPC se utiliza principalmente para llamadas de servicio dentro de la empresa, el rendimiento de bajo consumo, alta eficiencia de transmisión, complejidad de la implementación.
HTTP se utiliza principalmente para entornos heterogéneos externas, llamadas de la interfaz del navegador, llamadas de interfaz de la aplicación, las llamadas y otras interfaces de terceros.
escenarios de uso de RPC (sitios de gran tamaño, muchos subsistemas internos, la interfaz mucho el caso del uso de RPC):
- Eslabón largo. No siempre salen según la comunicación HTTP para ser como 3 vías mano reduciendo la sobrecarga de la red.
- mecanismo de liberación de registro. RPC marco general tiene un registro, hay una gran cantidad de seguimiento y gestión; publicar, fuera de las interfaces de línea de montaje, la expansión dinámica de la persona que llama no es consciente de la operación unificada.
- Seguridad, no hay exposición a operaciones de recursos.
- soporte de servicio de micro. Es la reciente popular servicio orientado a la arquitectura, la gestión de servicios, el marco RPC es un fuerte apoyo.
