RPC——Introducción al protocolo RPC y explicación detallada de sus principios

wx común:CodingTechWork

introducir

Marco RPC

concepto

1. Protocolo de llamada a procedimiento remoto RPC (Remote Procedure Call Protocol).
2. RPC es un protocolo para solicitar servicios de programas informáticos remotos a través de una red sin necesidad de conocer la tecnología de red subyacente.
3. La función principal de RPC es que las llamadas de método entre diferentes servicios son tan convenientes como las llamadas locales.

Marco o tecnología RPC de uso común

1. Marco de servicio de nivel de aplicación: Ali's Dubbo/Dubbox, Google gRPC, Spring Boot/Spring Cloud.
2. Protocolos de comunicación remota: RMI, Socket, SOAP (HTTP XML), REST (HTTP JSON).
3. Marco de comunicación: MINA y Netty

gRPC convencional, Thrift, Dubbo

1. gRPC: gRPC es el software de código abierto de Google, gRPC se basa en el protocolo HTTP2.0 y HTTP2.0 es una versión mejorada del protocolo HTTP basado en binario, y la capa subyacente es compatible con el marco Netty.
2. Thrift: Thrift es un proyecto de código abierto de Facebook, que es un marco de desarrollo de servicios en varios idiomas. El usuario solo necesita realizar la segunda apertura, que es transparente para la comunicación RPC subyacente.
3. Dubbo: Dubbo es el marco de serialización y protocolo de componentes de código abierto de Alibaba, que se puede conectar y desarrollar en función del marco Spring.La interfaz remota se basa en la interfaz Java y es adecuada para la arquitectura de microservicios.

¿Por qué hay RPC?

1. 服务化: microservicio, llamada remota entre servicios multiplataforma;
2. 分布式系统架构: los servicios distribuidos realizan llamadas remotas entre máquinas;
3. 服务可重用: Desarrollar un servicio de capacidad pública para llamadas remotas por múltiples servicios.
4. 系统间交互调用: Hay dos servidores A y B. La aplicación a en el servidor A necesita llamar al método proporcionado por la aplicación b en el servidor B, pero la aplicación a y la aplicación b no están en el mismo espacio de memoria y no se pueden llamar directamente. En este momento, debe expresarse a través de la transmisión de la red. Se requiere la semántica de la llamada y los datos que se transferirán.

Escenas a utilizar

1. 大型网站: Internamente involucra múltiples subsistemas con muchos servicios e interfaces.
2. 注册发现机制: como Nacos, Dubbo, etc., generalmente tienen un centro de registro, y el servicio tiene múltiples instancias, y la persona que llama no tiene percepción de a qué instancia se llama.
3. security`: No exponer los recursos.
4. 服务化治理: Arquitectura de Microservicios, Arquitectura Distribuida.

arquitectura

diagrama de arquitectura

Un proceso de llamada RPC

1. El cliente (Cliente) invoca el servicio a través de invocación local (invocación de interfaz);
2. Después de recibir la solicitud de llamada, el stub del cliente (Client Stub) es responsable de ensamblar y serializar información como métodos y parámetros de entrada en un cuerpo de mensaje capaz de transmisión por red (serializar el objeto del cuerpo del mensaje en un flujo binario);
3. El stub del cliente (Client Stub) encuentra la dirección del servicio remoto y envía el mensaje al servidor a través de la red (envía el mensaje a través de sockets);
4. El stub del servidor (Server Stub) realiza la operación de deserialización después de recibir el mensaje, es decir, decodificación (deserialización del flujo binario en un objeto de mensaje);
5. El stub del servidor (Server Stub) llama al servicio local para el procesamiento relacionado a través del resultado de la decodificación;
6. Servidor (Servidor) procesamiento de negocios de servicio local;
7. El servidor (Server) devuelve el resultado del procesamiento al stub del servidor;
8. El stub del servidor (Server Stub) serializa el resultado del procesamiento (serializa el objeto del mensaje de resultado en una secuencia binaria);
9. El servidor stub (Server Stub) envía el resultado serializado al cliente a través de la red (enviando mensajes a través de sockets);
10. El stub del cliente (Stub del servidor) recibe el mensaje y realiza la deserialización y descodificación (desserialización del flujo binario resultante en un objeto de mensaje);
11. El cliente obtiene el resultado final.

Funciones básicas

componentes importantes

1. Cliente: Cliente, llamante de servicio.
2. Stub de cliente: Stub de cliente, que almacena la información de dirección del servidor, empaqueta la información de datos de parámetros de solicitud del cliente en un mensaje de red y luego lo envía al servidor a través de la transmisión de red.
3. Stub del servidor: Stub del servidor, que recibe y desempaqueta el mensaje de solicitud enviado por el cliente, y luego llama al servicio local para su procesamiento.
4. Servidor: Servidor, el verdadero proveedor del servicio.
5. servicio newtwork: transporte subyacente, tcp o http

realización de funciones

  La realización de funciones se divide principalmente en direccionamiento de servicios, serialización y deserialización, y funciones de transmisión de red.

Función de direccionamiento de servicios

Mapeo de ID de llamada

1. Local: en la llamada al método local, el cuerpo de la función se especifica directamente a través del puntero de función, pero en la llamada remota, debido a que los espacios de direcciones de los dos procesos son completamente diferentes, el puntero de función no funciona.
2. Remoto: Todas las funciones o métodos en RPC tienen su propio ID, el cual es único en todos los procesos. Cuando el cliente realiza una llamada de procedimiento remoto, debe adjuntar esta ID, es decir, el cliente verificará la tabla para encontrar la ID de llamada correspondiente y luego la pasará al servidor, y el servidor también verificará la tabla para determinar lo que el cliente necesita para llamar a la función, y luego ejecutar el código de la función correspondiente.
3. La tabla de mapeo de Call ID es generalmente una tabla hash.

ejemplo tecnico

Es necesario consultar las instancias de servicio de la otra parte a través del centro de registro de servicios.

1. Nacos integra OpenFeign para implementar llamadas RPC.
2. Spring Cloud integra Dubbo para implementar llamadas RPC.

Funciones de serialización y deserialización

descripción general

1. Serialización: convierta objetos de mensaje en flujos binarios.
2. Deserialización: convierte un flujo binario en un objeto de mensaje.

necesidad

1. La llamada remota implica la transmisión de datos. En la llamada local, solo necesita insertar los datos en la pila y luego dejar que la función los lea desde la pila.
2. Sin embargo, para la transmisión remota de datos, dado que el cliente y el servidor no están en el mismo servidor e involucran diferentes procesos, los parámetros no se pueden pasar a través de la memoria. En este caso, el cliente necesita convertir los parámetros de la solicitud en un flujo de bytes (codificación) y pass Al servidor, el servidor luego convierte el flujo de bytes en un formato que puede leer (decodificar), que es el proceso de serialización y deserialización. Por el contrario, el valor de retorno del servidor se serializa y deserializa al cliente a la inversa.

Ventajas de la serialización

1. Convierta el objeto del mensaje en un flujo de bytes binarios, lo cual es conveniente para la transmisión de red.
2. Multiplataforma y multilenguaje. Por ejemplo, un cliente escrito en Python solicita que los parámetros de serialización se transmitan a un servidor escrito en Java para la deserialización.

Función de transmisión de red

efecto

1. El cliente transmite el ID de llamada y el flujo de bytes de parámetros serializados al servidor.
2. El servidor devuelve el resultado de la llamada serializada al cliente.

protocolo

  Existen principalmente protocolos TCP, UDP y HTTP.

Basado en el protocolo TCP

1. El cliente y el servidor establecen una conexión Socket.
2. El cliente serializa el nombre de la interfaz, el nombre del método y los parámetros que se llamarán a través del Socket y luego lo pasa al servidor.
3. El servidor deserializa y luego usa la reflexión para llamar al método correspondiente y devuelve el resultado al cliente.

Basado en el protocolo HTTP

1. El cliente envía solicitudes al servidor, como GET, POST, PUT, DELETE y otras solicitudes.
2. El servidor realiza llamadas a métodos de acuerdo con diferentes parámetros de solicitud y URL de solicitud, y devuelve resultados de datos JSON o XML.

Comparación de TCP y HTTP

1. La llamada RPC basada en el protocolo TCP, debido a que es la pila de protocolo subyacente, puede personalizar los campos del protocolo de manera más flexible, lo que puede reducir la sobrecarga de la red, mejorar el rendimiento y lograr un mayor rendimiento y concurrencia. Sin embargo, la capa inferior es compleja y el costo de implementación es alto.
2. La llamada RPC implementada en base al protocolo HTTP ha sido encapsulada y serializada, pero HTTP pertenece al protocolo de capa de aplicación, y la cantidad de bytes ocupados por la transmisión HTTP es mayor que la de TCP, y la eficiencia de transmisión es menor que la de TCP .

Comparación entre RPC y Restful API

centrarse en diferentes

1. RPC se centra en las operaciones
2. Restful se centra en los recursos

eficiencia de transmisión

1. RPC es más eficiente y el protocolo TCP se puede personalizar para controlar el volumen de los paquetes de solicitud.
2. Restful es menos eficiente y se basa en el protocolo HTTP.

la complejidad

1. La implementación de RPC es complicada y se debe prestar atención al direccionamiento del servicio, la serialización y deserialización y la transmisión de red, y el proceso de llamada es engorroso.
2. La implementación de Restful es simple, no es necesario prestar atención a la serialización y deserialización, la transmisión de red y el proceso de llamada es conveniente.

Escenas a utilizar

1. RPC es adecuado para llamadas de servicio internas de la empresa, como llamadas de servicio en diferentes plataformas entre departamentos, con un bajo consumo de rendimiento, alta eficiencia de transmisión y una implementación complicada.
2. HTTP se utiliza principalmente en entornos heterogéneos externos, llamadas de interfaz de navegador, llamadas de interfaz de terceros, etc.