RPC implementado accidentalmente

Prefacio

Con el creciente número de personas que prestan atención al proyecto cim recientemente, la cantidad de preguntas y errores planteados también ha aumentado, y es inevitable que la limpieza del código vuelva a surgir en el proceso de solucionar los problemas.

Mirando lo que escribí hace uno o dos años, siempre sospecho que realmente vino de mis propias manos. En algunos lugares, no pude evitarlo y comencé un largo camino hacia la reconstrucción.

Antes y después de la comparación
, presentaré brevemente el proyecto cim antes de comenzar. El siguiente es su diagrama de arquitectura:

En pocas palabras, es un sistema de mensajería instantánea IM, que consta principalmente de las siguientes partes:

• El servidor de mensajería instantánea es, naturalmente, el servidor, que se utiliza para mantener una conexión prolongada con el cliente.

• El cliente IM-cliente puede considerarse simplemente como una herramienta de cliente similar a QQ; por supuesto, las funciones ciertamente no son tan ricas y solo proporcionan algunas funciones simples de envío y recepción de mensajes.

• El servicio de enrutamiento de ruta, que se utiliza principalmente para la autenticación de clientes, reenvío de mensajes, etc., proporciona algunas interfaces http, que se pueden utilizar para ver el estado del sistema, el número en línea y otras funciones.

Por supuesto, tanto el servidor como el enrutamiento se pueden expandir horizontalmente.

Este es un diagrama de flujo de envío de mensajes. Suponga que ahora están implementados dos servidores A y B y un servicio de enrutamiento; entre ellos, ClientA y ClientB mantienen conexiones largas con los servidores A y B, respectivamente.

Cuando ClientA envía un saludo a ClientB, el flujo de mensajes completo se muestra en la figura:

1. Primero envíe el mensaje al servicio de ruta a través de http.

2. El servicio de enrutamiento sabe que ClientB está conectado a ServerB; luego envía el mensaje al ServerB a través de http.

3. Finalmente, ServerB envía el mensaje a través del canal de conexión largo con ClientB, y el mensaje se envía con éxito.

Aquí intercepté el código para que ClientA inicie una solicitud para enrutar:

Puede ver que este es el uso de okhttp para iniciar una solicitud http. Aunque esta función se puede implementar, no es elegante.

Por ejemplo: supongamos que necesitamos conectarnos a la interfaz de Alipay, enviar una solicitud http aquí, naturalmente, no es un problema; pero para que los departamentos internos de Alipay se llamen directamente a la interfaz de los demás, la solicitud http original ya no debería usarse.

Debe ser un paquete de API proporcionado por el proveedor de servicios, y los consumidores de servicios solo necesitan confiar en este paquete para implementar llamadas de interfaz.

Por supuesto, al final se puede utilizar http o un protocolo privado personalizado.

También es similar a cuando usamos Dubbo o SpringCloud, generalmente confiamos directamente en un paquete api, de modo que podemos llamar a servicios remotos como llamar a un método local y proteger completamente los detalles subyacentes, ya sea usando http u otros protocolos privados. No importa, no le importa en absoluto a la persona que llama.

¿Eso tiene un gusto interno? ¿No es esta la explicación oficial de RPC?

Correspondiente a esto es la misma razón, Cliente, Ruta, Servidor son esencialmente un sistema, y ​​sus llamadas de interfaz mutua también deben ser RPC.

Entonces mi refactorización se volvió así:

¿Es el código mucho más conciso, como llamar a un método local, y esto también tiene varias ventajas:

• Los detalles subyacentes están completamente protegidos, y el negocio se puede realizar mejor y el código se puede mantener.

• Incluso si el proveedor de servicios modifica los parámetros, se puede descubrir rápidamente durante la compilación y la llamada es completamente inconsciente como antes, por lo que también aumenta el riesgo.

Ahora
hablemos de cómo se implementa.

De hecho, como se menciona en la "Aplicación práctica de agentes dinámicos" anterior, el principio es similar.

Si no quiere saber quién llama, debe crear un objeto proxy de interfaz; el proceso de codificación, llamada y decodificación se implementa en este objeto proxy.

En realidad, lo que corresponde a aquí es crear un objeto proxy routeApi, la clave es este código:

RouteApi
 routeApi 
=

new

ProxyManager
<>(
RouteApi
.
class
,
 routeUrl
,
 okHttpClient
).
getInstance
();

El código fuente completo es el siguiente:

La función getInstance () devuelve el objeto de interfaz que necesita ser proxy; y ProxyInvocation es una clase que implementa la interfaz InvocationHandler. Este conjunto de códigos es un enfoque de tres puntos para usar JDK para implementar un proxy dinámico.

Mirando el código fuente de ProxyInvocation, encontrará que cuando llamamos a cualquier método de la interfaz proxy, aquí se ejecutará el método invoke ().

El método invoke () implementa naturalmente el proceso de codificación, llamada remota y decodificación mencionado en la figura anterior; creo que es fácil de entender para todos, porque no es el foco de esta discusión, no lo presentaré demasiado.

Resumen
De hecho, comprenderlos hace que sea más fácil comprender el código fuente central de los frameworks RPC como Dubbo La idea general es similar, excepto que se usa el protocolo privado, por lo que la codificación y decodificación serán diferentes.

Entonces, si desea implementar un marco RPC usted mismo, puede consultar esta idea y probarlo.Cuando ejecuta un helloworld RPC con su propio código, la sensación es que ha integrado un marco de terceros como Dubbo y SpringCloud con usted mismo. Totalmente diferente.

Todo el código fuente de este artículo:

https://github.com/crossoverJie/cim