Durante mucho tiempo, no he descubierto la diferencia entre RPC (es decir, llamada de procedimiento remoto) y llamadas HTTP. ¡Permítanme reír aquí~ Ingenuos! Este artículo presenta brevemente las dos formas de arquitectura C/S, en primer lugar, su diferencia más esencial, es decir, RPC se basa principalmente en el protocolo TCP/IP, mientras que el servicio HTTP se basa principalmente en el protocolo HTTP; todos sabemos que el protocolo HTTP está sobre el protocolo de la capa de transporte TCP, así que en términos de eficiencia, ¡RPC es por supuesto mejor! Hablemos en detalle de los servicios RPC y los servicios HTTP.
Modelo de red OSI de siete capas
Antes de hablar de la diferencia entre RPC y HTTP, considero necesario entender el modelo de estructura de red de siete capas de OSI (aunque en la práctica son básicamente cinco capas), que pueden dividirse en las siguientes capas: (de arriba a abajo)
- La primera capa: capa de aplicación. Se definen interfaces para la comunicación y transmisión de datos en la red;
- La segunda capa: la capa de representación. Definir el formato de transmisión, las especificaciones de codificación y decodificación de datos en diferentes sistemas, etc.;
- La tercera capa: la capa de conversación. Gestionar las sesiones de usuario y controlar el establecimiento e interrupción de conexiones lógicas entre usuarios.
- La cuarta capa: la capa de transporte. Gestiona la transmisión de datos de extremo a extremo en la red;
- Capa 5: Capa de red. Definir cómo se transfieren los datos entre dispositivos de red;
- Sexta capa: capa de enlace. Los paquetes de datos de la capa de red superior se encapsulan en tramas de datos para facilitar la transmisión de la capa física.
- Capa 7: Capa física. Esta capa se centra principalmente en transmitir estos datos binarios.
En la práctica práctica, no existe una capa de presentación ni una capa de sesión en la estructura de cinco capas del protocolo. Cabe decir que se fusionan con la capa de aplicación. Deberíamos centrarnos en la capa de aplicación y la capa de transporte. Porque HTTP es un protocolo de capa de aplicación, mientras que TCP es un protocolo de capa de transporte. Bueno, ahora que conocemos el modelo de capas de red, podemos entender mejor por qué los servicios RPC son mejores que los HTTP
Servicios RPC
Los servicios RPC se introducen desde tres perspectivas: arquitectura RPC, llamadas asíncronas síncronas y los populares frameworks RPC.
Arquitectura RPC
Hablemos de la arquitectura básica de los servicios RPC. Permítanme que te roben una imagen vergonzosamente~ Podemos ver claramente que una arquitectura RPC completa contiene cuatro componentes principales, a saber: Cliente, Servidor, Cliente Stub y Server Stub, que pueden entenderse como un stub. Hablemos de estos componentes por separado:
- Cliente, el que llama al servicio.
- Servidor, el verdadero proveedor de servicios.
- El stub del cliente almacena el mensaje de dirección del servidor y luego empaqueta los parámetros de la solicitud del cliente en un mensaje de red, y lo envía a la parte del servicio de forma remota a través de la red.
- El stub del lado del servidor recibe los mensajes enviados por el cliente, desempaqueta los mensajes y llama a métodos locales.
RPC se utiliza principalmente en grandes empresas, porque las grandes empresas cuentan con muchos sistemas, líneas de negocio complejas y las ventajas de eficiencia son muy importantes. Esto se hace en el desarrollo real, y los proyectos generalmente se gestionan usando Maven. Por ejemplo, tenemos un servicio del sistema que procesa órdenes, primero declara todas sus interfaces (aquí específicamente la interfaz en Java) y luego empaqueta todo el proyecto en un paquete jar. ¿Por qué hacer esto? El objetivo principal es reducir el tamaño del paquete jar en el lado del cliente, porque cada vez que se lanza un paquete, demasiados paquetes jar siempre afectan a la eficiencia. También desacopla el cliente y el servidor para mejorar la portabilidad del código.
Llamadas síncronas y asíncronas
¿Qué es la llamada síncrona? ¿Qué es una llamada asincrónica? Una llamada síncrona es cuando el cliente espera a que la llamada complete la ejecución y devuelve el resultado. Las llamadas asíncronas significan que el cliente no espera a que se ejecute la llamada para devolver el resultado, pero puede seguir recibiendo la notificación del resultado de retorno a través de la función de devolución de llamada. Si al cliente no le importa el resultado, puede convertirse en una decisión unilateral. Este proceso es algo similar a las interfaces llamables y ejecutables en Java, cuando ejecutamos de forma asíncrona, si necesitamos conocer el resultado de la ejecución, podemos usar la interfaz llamable y obtener la información del resultado de la ejecución asíncrona a través de la clase Future. Si no te importa el resultado de ejecución, puedes usar la interfaz ejecutable porque no devuelve el resultado, claro, también es posible llamar, no necesitamos el futuro.
Marco RPC popular
Todavía existen muchos frameworks RPC de código abierto populares. Aquí tienes tres puntos destacados:
- gRPC es un software de código abierto recientemente anunciado por Google, basado en el último protocolo HTTP 2.0, y soporta muchos lenguajes de programación comunes. Sabemos que HTTP 2.0 es una versión mejorada del protocolo HTTP basada en binario, y los principales navegadores lo están soportando a gran velocidad. Este framework RPC se basa en el protocolo HTTP, y el subyacente utiliza el soporte del framework Netty.
- Thrift es un proyecto de código abierto para Facebook, principalmente un marco de desarrollo de servicios multi-idioma. Dispone de un generador de código para generar automáticamente un marco de código de servicio para el archivo de definición IDL que define. Los usuarios solo necesitan realizar desarrollos secundarios antes de ella, y la comunicación subyacente del RPC es transparente. Sin embargo, para los usuarios, todavía existe un cierto coste para aprender el idioma de un campo específico.
- Dubbo es un conocido framework RPC de código abierto del Grupo Alibaba, ampliamente utilizado en muchas empresas de Internet y aplicaciones empresariales. Tanto los protocolos como los frameworks de serialización pueden conectarse. La misma interfaz remota se basa en la Interfaz Java y depende del framework Spring para un desarrollo sencillo. Puede empaquetarse fácilmente en un solo archivo y ejecutarse de forma independiente, lo cual es coherente con el concepto actual de microservicios.
Te digo en secreto que el grupo ya no usa mucho el dubbo,La que se usa más comúnmente ahora se llama HSF, también conocido como "tan cómodo". Puede que haya código abierto más adelante, así que esperemos y veremos.
Servicio HTTP
De hecho, hace mucho tiempo, siempre he caracterizado el modelo de desarrollo empresarial como desarrollo de interfaces HTTP, que es lo que a menudo llamamos interfaces de servicio al estilo RESTful. De hecho, es un método de comunicación que se utiliza a menudo en las primeras etapas de resolución de islas de información en casos de pocas interfaces y menos interacción entre sistemas; Las ventajas son simples, directas y fáciles de desarrollar. Utiliza el protocolo HTTP ya preparado para la transmisión. Recordamos que cuando hacíamos desarrollo en segundo plano en la empresa antes, principalmente desarrollábamos interfaces, y también teníamos que escribir un documento grande de interfaz que indicaba estrictamente cuál era la entrada y la salida. Explica el método de solicitud de cada interfaz y los aspectos a los que deben prestarse atención en los parámetros de la solicitud. Por ejemplo, el siguiente ejemplo:
EXPONERhttp://www.httpexample.com/restful/buyer/info/share
La interfaz puede devolver una cadena JSON o un documento XML. El cliente procesa entonces esta información devuelta, permitiendo un desarrollo más rápido. Sin embargo, para grandes empresas, cuando hay muchos subsistemas internos y muchas interfaces, se muestran las ventajas del marco RPC; en primer lugar, es un enlace largo y no es necesario estrechar la mano tres veces como en http cada vez, reduciendo la sobrecarga de red; en segundo lugar, el marco RPC generalmente cuenta con un centro de registro y una supervisión y gestión enriquecedora; La publicación, las interfaces offline, la expansión dinámica, etc., son operaciones no perceptivas y unificadas para el llamante.
resumen
En términos generales, los servicios RPC son principalmente para grandes empresas, mientras que los servicios HTTP son principalmente para pequeñas empresas, porque RPC es más eficiente y las iteraciones de desarrollo de servicios HTTP serán más rápidas. En resumen, qué tipo de marco elegir no depende de lo que sea popular en el mercado, sino de evaluar completamente el proyecto completo, para comparar cuidadosamente el impacto de los dos marcos de desarrollo en el proyecto y, finalmente, decidir cuál es el más adecuado para el proyecto. No debemos usar RPC para todos los proyectos solo por usar, sino adaptarnos a las condiciones locales y analizar la situación específica.
|
Publicado en 1/4/2019 14:02:45
|
|
|
|
