Hable sobre DUBBO

¿Qué es dubbo?

Dubbo es un framework Java RPC ligero y de alto rendimiento.

Proporciona tres capacidades principales: invocación de métodos remotos orientados a la interfaz, tolerancia inteligente a fallas y equilibrio de carga, y registro de descubrimiento de servicio automático . Proporcione una solución de llamadas de servicio remoto RPC transparente y de alto rendimiento, y una solución de gestión de servicios SOA.

¿Qué es Rpc?

RPC (Llamada a procedimiento remoto): llamada a procedimiento remoto, que es un protocolo que solicita servicios de un programa informático remoto a través de la red sin la necesidad de comprender la tecnología de red subyacente. Por ejemplo, si dos servicios diferentes A y B se implementan en dos máquinas diferentes, ¿qué pasa si el servicio A quiere llamar a un método en el servicio B? Por supuesto, se pueden usar solicitudes HTTP, pero puede ser lento y algunas optimizaciones no son buenas. La aparición de RPC es resolver este problema.

¿Cuál es el principio de RPC?

El consumidor del servicio (cliente) llama al servicio en una llamada local;
Después de recibir la llamada, el código auxiliar del cliente es responsable de reunir los métodos, parámetros, etc. en un cuerpo de mensaje capaz de transmitir la red;
El código auxiliar del cliente encuentra la dirección del servicio y envía el mensaje al servidor;
El código auxiliar del servidor se decodifica después de recibir el mensaje;
El código auxiliar del servidor llama al servicio local de acuerdo con el resultado de decodificación;
El servicio local se ejecuta y devuelve el resultado al apéndice del servidor;
El apéndice del servidor empaqueta el resultado devuelto en un mensaje y lo envía al consumidor;
El código auxiliar del cliente recibe el mensaje y lo decodifica;
El consumidor del servicio obtiene el resultado final.

¿Qué problema resuelve rpc?

Hacer llamadas entre diferentes servicios en un sistema distribuido o de microservicios tan simple como las llamadas locales

HTTP existente, ¿por qué usar RPC para llamadas de servicio?

rpc es un concepto, un diseño, para resolver el problema de llamadas entre diferentes servicios, generalmente incluirá el protocolo de transmisión y el protocolo de serialización .

Sin embargo, HTTP es un protocolo y el marco de trabajo RPC puede usar el protocolo HTTP como protocolo de transmisión o directamente usar TCP como protocolo de transmisión. El uso de diferentes protocolos generalmente se adapta a diferentes escenarios.

Los protocolos de transmisión incluyen: el protocolo http2 utilizado por el famoso [gRPC] ( grpc / grpc.io ) y el protocolo tcp para mensajes personalizados como dubbo.

Los protocolos de serialización incluyen: xml json basado en codificación de texto y protobuf binpack con codificación binaria.

¿Por qué utilizar el protocolo tcp personalizado rpc para la comunicación del proceso de fondo?

(Error) protocolo http en comparación con el protocolo de mensaje tcp personalizado, la sobrecarga adicional es el establecimiento y la desconexión de la conexión

http compatible con el protocolo de agrupación de conexiones de reutilización, es decir, para establecer cierto número de conexiones abiertas constantemente, y no frecuentan la creación y destrucción de conexión.

Lo segundo que hay que decir es que http también puede usar protobuf, un protocolo de serialización binario para codificar contenido, por lo que la mayor diferencia entre los dos todavía está en el protocolo de transmisión.

El paquete tcp del protocolo http1.1 comúnmente definido contiene demasiada información de desecho . Incluso si el protocolo de codificación es el cuerpo que usa un protocolo de codificación binario, los metadatos del mensaje son el par clave-valor del encabezado pero se usa la codificación de texto, que es muy simple Número de sección Como se muestra en la figura anterior, el número efectivo de bytes en el mensaje solo representa aproximadamente el 30%, es decir, el 70% del tiempo se usa para transmitir la codificación de residuos de metadatos. Por supuesto, el contenido real del mensaje puede ser más largo que esto, pero la proporción del encabezado también es muy considerable.

http es como mandarín, y rpc es como pirateo de pandillas.

La ventaja de hablar mandarín es que todos pueden entender y todos pueden hablar.

La ventaja de hablar en negro es que puede ser más ágil, más confidencial y más personalizable. La desventaja es que la parte que "habla" las palabras negras (lado del cliente) también debe entender, y una vez que todos hablan una palabra negra, es difícil cambiar las palabras negras.

¿Por qué usar dubbo?

Creo que es principalmente posible utilizar Dubbo a partir de las siguientes cuatro características proporcionadas por Dubbo:

Balanceo de carga

Cuando se despliega el mismo servicio en diferentes máquinas, se debe llamar al servicio en esa máquina.

Llamada de servicio de generación de enlaces

Con el desarrollo del sistema, hay cada vez más servicios, y la relación de dependencia entre los servicios se ha vuelto escalonada y complicada. Incluso es imposible saber qué aplicación debe iniciarse antes de qué aplicación. El arquitecto no puede describir completamente la relación arquitectónica de la aplicación. Dubbo puede ayudarnos a resolver cómo se llaman entre sí los servicios.

Presión de acceso al servicio y estadísticas de duración, programación de recursos y gobernanza

Administre la capacidad del clúster en tiempo real según la presión de acceso y mejore la utilización del clúster.

Degradación del servicio

Después de que un servicio cuelga, se llama al servicio de respaldo.

Arquitectura de Dubbo

Ilustración de la arquitectura de Dubbo

Proveedor: proveedor de servicios que expone el servicio.
Consumidor: consumidor de servicios que invoca servicios remotos
Registro: Registro de registro y descubrimiento de servicios.
Monitor: un centro de monitoreo que cuenta el número y el tiempo de las llamadas de servicio.
Contenedor: servicio ejecutando contenedor

Descripción de la relación de llamada:

El contenedor de servicios es responsable de iniciar, cargar y ejecutar el proveedor de servicios.
Cuando se inicia el proveedor de servicios, registra su propio servicio en el centro de registro.
Cuando comienzan los consumidores de servicios, se suscriben a los servicios que necesitan del centro de registro.
El centro de registro devuelve la lista de direcciones de proveedores de servicios a los consumidores. Si hay un cambio, el centro de registro enviará los datos modificados al consumidor en función de la larga conexión.
Los consumidores de servicios, de la lista de direcciones del proveedor, basados en el algoritmo de equilibrio de carga flexible, seleccionan un proveedor al que llamar, si la llamada falla, luego seleccionan otra llamada.
Los consumidores y proveedores de servicios acumulan tiempos de llamada y tiempos de llamada en la memoria, y envían regularmente datos estadísticos al centro de monitoreo cada minuto.

Estrategia de equilibrio de carga de Dubbo

¿Qué es el equilibrio de carga?

Por ejemplo, un servicio en nuestro sistema tiene un tráfico particularmente pesado. Implementamos este servicio en varios servidores. Cuando un cliente inicia una solicitud, varios servidores pueden procesar la solicitud. Entonces, cómo elegir el servidor que maneja la solicitud correctamente es muy importante. Si necesita un servidor para manejar la solicitud de servicio, el significado de implementar el servicio en varios servidores ya no existe. El equilibrio de carga es evitar que un solo servidor responda a la misma solicitud, lo que es fácil de causar problemas como el tiempo de inactividad del servidor y el bloqueo. Podemos sentir claramente su significado a partir de estas cuatro palabras de equilibrio de carga.

Balance de carga aleatorio (mecanismo de equilibrio de carga aleatorio basado en peso predeterminado)

Aleatorio, establezca la probabilidad aleatoria según el peso.

La estrategia aleatoria primero determinará si los pesos de todos los Invocadores son iguales. Si son todos iguales, entonces el procesamiento es relativamente simple. Use random.nexInt (longitud) para generar aleatoriamente el número de serie de un Invoker y seleccione el Invoker correspondiente según el número de serie. Si el peso del proveedor de servicios no está configurado en Dubbo Admin, entonces el peso de todos los Invocadores es el mismo, el valor predeterminado es 100 . Si los pesos son diferentes, debe establecer la probabilidad aleatoria en combinación con los pesos.

El algoritmo es más o menos el siguiente: supongamos que hay 4 invocadores.

invocador	peso
UN	10
si	20
C	20
re	30

El peso total de A, B, C y D es 10 + 20 + 20 + 30 = 80. Distribuya 80 números en la siguiente figura:

+-----------------------------------------------------------------------------------+
|          |                    |                    |                              |
+-----------------------------------------------------------------------------------+
1          10                   30                   50                             80

|-----A----|---------B----------|----------C---------|---------------D--------------|


---------------------15

-------------------------------------------37

-----------------------------------------------------------54复制代码

Hay un total de 4 áreas en la figura anterior, con longitudes de A, B, C y D ponderadas respectivamente. Use random.nextInt (10 + 20 + 20 + 30) para seleccionar aleatoriamente uno de 80 números. Luego determine dónde se distribuye el número. Por ejemplo, si el azar es 37, 37 se distribuye en el área C, luego elija Invoker C. 15 está en el área B, 54 está en el área D.

RoundRobin LoadBalance (no recomendado, mecanismo de equilibrio de carga de sondeo basado en el peso)

Round robin, establezca la proporción de round robin de acuerdo con los pesos después de la convención.

El balance de carga de sondeo es llamar a todos los proveedores en secuencia. Al igual que la estrategia de equilibrio de carga aleatorio, la estrategia de equilibrio de carga de sondeo también tiene el concepto de peso. El algoritmo de equilibrio de carga de sondeo permite que las llamadas RPC se distribuyan estrictamente de acuerdo con la proporción que establezcamos. Ya sea una pequeña cantidad de llamadas o una gran cantidad de llamadas.

Sin embargo, el algoritmo de equilibrio de carga de sondeo también tiene defectos. Hay un problema de solicitudes de acumulación lenta del proveedor. Por ejemplo: la segunda máquina es muy lenta, pero no se cuelga. Cuando la solicitud se transfiere a la segunda máquina, se queda atascada allí. Con el tiempo, todas las solicitudes Todos estancados en la segunda estación.

LeastActive LoadBalance Número mínimo de llamadas activas

El objetivo es que las máquinas más lentas reciban menos solicitudes.

El número mínimo de llamadas activas, la aleatoriedad del mismo número activo, el número activo se refiere a la diferencia entre los recuentos antes y después de la llamada.

Haga que el proveedor lento reciba menos solicitudes, porque el proveedor más lento tendrá una diferencia de conteo mayor antes y después de la llamada.

Cada servicio mantiene un contador de números activo. Cuando la máquina A comienza a procesar la solicitud, el contador se incrementa en 1, y en este momento A aún no ha completado el procesamiento. Si se completa el procesamiento, el contador se reduce en 1. La máquina B procesó la solicitud rápidamente después de recibirla. Entonces los números activos de A y B son 1, 0 respectivamente. Cuando se genera una nueva solicitud, la máquina B se selecciona para su ejecución (el número mínimo de activos B), de modo que la máquina lenta A recibe menos solicitudes.

Si solo hay un Invoker con el número activo más pequeño, devuelva el Invoker directamente. Si hay varios Invokers con el número activo más pequeño y los pesos no son iguales y el peso total es mayor que 0, entonces se genera un peso al azar en el rango de (0, totalWeight) Dentro Finalmente, elija el Invoker basado en los pesos generados aleatoriamente.

ConsistentHash LoadBalance Consistencia Hash

Las solicitudes con los mismos parámetros siempre se envían al mismo proveedor. (Si lo que necesita no es un equilibrio de carga aleatorio, sino un tipo de solicitud todo a un nodo, siga esta estrategia de coherencia hash).

Cuando un proveedor cuelga, la solicitud enviada originalmente al proveedor se basa en el nodo virtual y se comparte con otros proveedores sin causar cambios drásticos.

Tiempo de inactividad de Zookeeper y conexión directa a dubbo

Si el centro de registro del cuidador del zoológico deja de funcionar, el consumidor del servicio aún puede llamar a los servicios del proveedor por un período de tiempo. De hecho, utiliza el caché local para comunicarse, lo cual es solo una manifestación de la solidez de dubbo.

dubbo robustez

Si el centro de monitoreo se cae, no afectará el uso, solo se perderá parte de los datos muestreados
Una vez que la base de datos se cae, el centro de registro aún puede consultar la lista de servicios a través del caché, pero no puede registrar nuevos servicios.
Centro de registro de punto a punto, después de que cualquiera de ellos esté inactivo, cambiará automáticamente a otro
Una vez que todos los centros de registro están inactivos, los proveedores de servicios y los consumidores de servicios aún pueden comunicarse a través del caché local.
El proveedor de servicios no tiene estado, y si alguno está caído, no afectará el uso.
Después de que el proveedor de servicios esté completamente inactivo, la aplicación de consumidor de servicios no estará disponible y se volverá a conectar indefinidamente esperando que el proveedor de servicios se recupere

Servicio de Dubbo expuesto

Dubbo notificará a la clase ServiceBean que implementa ApplicationListener para volver a llamar al método de evento onApplicationEvent cuando se publique el evento ContextRefreshEvent en el último paso de actualizar el contenedor después de la instancia de Spring bean. Dubbo llamará al método de exportación de la clase padre ServiceBean ServiceConfig en este método, y Este método realmente implementa el lanzamiento del servicio (asíncrono o no asíncrono).

Acuerdo de Dubbo

dubbo

Una sola conexión larga y comunicación asíncrona NIO son adecuadas para llamadas de servicio con gran volumen de datos concurrentes y pequeños, y los consumidores son mucho más grandes que los proveedores . Protocolo de transmisión TCP, asincrónico, serialización hessiana;

rmi ：

Adopte el protocolo rmi estándar JDK para realizarlo, el parámetro de transmisión y el objeto de parámetro de retorno deben implementar la interfaz serializable, usar el mecanismo de serialización estándar de Java, usar la conexión corta de bloqueo, el tamaño del paquete de transmisión es mixto , el número de consumidores y proveedores es similar, y el archivo puede transferirse , Protocolo de transmisión TCP. Múltiples conexiones cortas, transmisión de protocolo TCP, transmisión síncrona, adecuada para llamadas de servicio remoto convencionales e interoperación rmi. Confiando en el paquete Common-Collections de la versión inferior, hay un agujero de seguridad en la serialización de Java;

servicio web

Basado en el protocolo de llamadas remotas de WebService, implementación CXF integrada, que proporciona interoperabilidad con WebService nativo. Múltiples conexiones cortas, basadas en transmisión HTTP, transmisión síncrona, adecuadas para la integración de sistemas y llamadas entre idiomas ;

http

El protocolo de llamadas remotas basado en el envío de formularios Http se implementa utilizando HttpInvoke de Spring. Múltiples conexiones cortas, el protocolo de transmisión HTTP , el tamaño de los parámetros entrantes, el número de proveedores es mayor que el de los consumidores , debe llamar a la aplicación y al navegador JS;

arpillera

El servicio Hessian integrado, basado en la comunicación HTTP, que utiliza el servicio de exposición Servlet, Dubbo embebió Jetty como la implementación predeterminada del servidor, proporcionando interoperabilidad con el servicio Hession. Múltiples conexiones cortas, transmisión HTTP sincrónica, serialización de Hesse, grandes parámetros entrantes, los proveedores son mayores que los consumidores, los proveedores están bajo presión y los archivos pueden transmitirse ;

memcache

Protocolo RPC basado en memcached

repetir

Protocolo RPC basado en redis

¿Está bloqueada la llamada entre los servicios de Dubbo?

El hilo empresarial realiza una solicitud y obtiene una instancia de Future.
El subproceso empresarial llama a future.get para bloquear la espera de que vuelva el resultado comercial.
Cuando se devuelven los datos comerciales, se entregan al grupo independiente de subprocesos del lado del consumidor para la deserialización y otros procesos, y se llama a future.set para devolver los resultados comerciales deserializados.
El hilo empresarial devuelve el resultado directamente

El hilo empresarial realiza una solicitud y obtiene una instancia de Future.
Antes de llamar a future.get (), primero llame a ThreadlessExecutor.wait (). Esperar hará que el subproceso comercial espere en una cola de bloqueo hasta que se agreguen elementos a la cola.
Cuando se devuelven los datos comerciales, se genera una Tarea ejecutable y se coloca en la cola ThreadlessExecutor
El hilo comercial toma la Tarea y la ejecuta en este hilo: deserializa los datos comerciales y los establece en Futuro.
El hilo empresarial devuelve el resultado directamente

En comparación con el antiguo modelo de grupo de subprocesos, el propio subproceso empresarial es responsable de supervisar y analizar los resultados devueltos, eliminando el consumo adicional de sobrecarga del grupo de subprocesos.

¿Cuál es la diferencia entre Dubbo y Spring Cloud?

Dubbo es un producto de la era SOA, y se centra principalmente en la invocación de servicios, distribución de tráfico, monitoreo de tráfico y fusibles.

Spring Cloud nació en la era de la arquitectura de microservicios, considerando todos los aspectos de la gobernanza de microservicios, además de confiar en las ventajas de Spring y Spring Boot

Los dos marcos tienen objetivos diferentes al principio: el gobierno del servicio de posicionamiento de Dubbo y Spring Cloud crean un ecosistema.

La capa inferior de Dubbo utiliza un marco NIO como Netty, que se transmite según el protocolo TCP y coopera con la serialización de Hession para completar la comunicación RPC.

Spring Cloud es una comunicación basada en la interfaz Rest del protocolo Http para llamar a un proceso remoto. En términos relativos, las solicitudes Http tendrán paquetes más grandes y ocuparán más ancho de banda. Sin embargo, REST es más flexible que RPC. El proveedor de servicios y la persona que llama dependen de un solo contrato, y no hay una dependencia fuerte a nivel de código. Esto es más apropiado en un entorno de microservicio que enfatiza la rápida evolución. En cuanto al énfasis en la comunicación La velocidad sigue siendo conveniente y flexible, teniendo en cuenta las circunstancias específicas.