Estrategia de tolerancia a fallos incorporada y estrategia de tolerancia a fallos incorporada personalizada
¿Por qué necesita una estrategia de tolerancia a fallas incorporada?
En un sistema distribuido, un problema con ciertos nodos en el clúster es un evento de alta probabilidad, por lo tanto, en el proceso de diseño de un marco RPC distribuido, la falla debe tratarse como un ciudadano de primera clase del diseño. Después de que una llamada falla, cómo elegir la estrategia de selección de fallas es una cuestión de opiniones diferentes.Cada estrategia puede tener su propio escenario de aplicación único. Por lo tanto, como marco, se debe proporcionar una variedad de estrategias para diferentes escenarios para que los usuarios elijan.
En el diseño de Dubbo, a través de la abstracción de la interfaz del clúster, un grupo de información del proveedor llamable se combina en un invocador unificado
para que los llamantes llamen. Después de filtrar las reglas de enrutamiento y seleccionar la dirección de equilibrio de carga, se selecciona una dirección específica para llamar. Si la llamada falla, el procesamiento de tolerancia a fallas se realizará de acuerdo con la estrategia de tolerancia a fallas configurada por el clúster.
Dubbo tiene una serie de estrategias de tolerancia a fallas integradas de forma predeterminada. Si no puede satisfacer las necesidades del usuario, puede configurarlo mediante estrategias personalizadas de tolerancia a fallas.
Estrategia de tolerancia a fallas incorporada
Dubbo desarrolló principalmente las siguientes estrategias:
- Conmutación por error (no se pudo cambiar automáticamente)
- A prueba de fallas (a prueba de fallas)
- Fallar rapido
- Failback (recuperación automática después de un fallo)
- Bifurcación (llamada paralela)
- Difusión (llamada de difusión)
Estos nombres son relativamente similares y los conceptos son más fáciles de confundir. A continuación se explica uno por uno.
Conmutación por error (no se pudo cambiar automáticamente)
La conmutación por error es un concepto común en los sistemas de alta disponibilidad. El servidor generalmente tiene dos conjuntos de configuraciones de máquina principal y de respaldo. Si el servidor principal falla, cambiará automáticamente al servidor en espera, asegurando así la alta disponibilidad general.
Dubbo también tomó prestada esta idea y la utilizó como la estrategia de tolerancia a fallas predeterminada de Dubbo. Cuando la llamada falla, de acuerdo con el número configurado de reintentos, se seleccionará automáticamente una dirección disponible de otras direcciones disponibles para llamar hasta que la llamada sea exitosa o se alcance el límite superior de reintentos.
El número de reintentos configurado por defecto en Dubbo es 2, es decir, contando la primera llamada, se llamará hasta 3 veces.
El método de configuración y la estrategia de tolerancia a fallos se pueden configurar en el proveedor de servicios o en el llamador del servicio. La configuración del número de reintentos es más flexible, se puede configurar a nivel de servicio o a nivel de método. El orden específico de prioridad es:
Configuración del nivel del método del llamador del servicio> Configuración del nivel del servicio del llamador del servicio> Configuración del nivel del método del proveedor del servicio> Configuración del nivel del servicio del proveedor del servicio
El método de configuración en el
proveedor xml , configuración de nivel de servicio
<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" cluster="failover" retries="2" />
Proveedor de servicios, configuración a nivel de método
<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService"cluster="failover">
<dubbo:method name="sayHello" retries="2" />
</dubbo:service>
Persona que llama al servicio, configuración del nivel de servicio
<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="failover" retries="1"/>
Llamador de servicio, configuración a nivel de método:
<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="failover">
<dubbo:method name="sayHello" retries="3" />
</dubbo:reference>
La Conmutación por falla puede reintentar automáticamente la falla, protegiendo a la persona que llama de los detalles de la falla, pero la estrategia de Conmutación por falla también trae algunos efectos secundarios:
- Reintentar agregará gastos generales adicionales, como un mayor uso de recursos. En un sistema de alta carga, los reintentos adicionales pueden empeorar el sistema.
- Reintentar aumentará el tiempo de respuesta de la llamada. En algunos casos, volver a intentarlo puede incluso provocar una pérdida de recursos. Considere un escenario de llamada, A-> B-> C, si un tiempo de espera de 100 ms se establece en A, la primera llamada de B-> C se ha completado durante más de 100 ms, pero desafortunadamente B-> C falló, esta vez Reintentar, pero de hecho, volver a intentarlo en este momento no tiene sentido, por lo que, en opinión de A, esta llamada se agotó y A puede haber comenzado a ejecutar otra lógica.
A prueba de fallas (a prueba de fallas)
El núcleo de la estrategia de seguridad ante fallas es que, incluso si falla, no afectará a todo el flujo de llamadas. Usado generalmente en sistemas o procesos de derivación, su falla no afecta la corrección del negocio principal. En términos de implementación, cuando falla una llamada, este error será ignorado, se registrará un registro y al mismo tiempo se devolverá un resultado vacío. Desde la perspectiva ascendente, la llamada es exitosa.
Los escenarios de aplicación se pueden utilizar para operaciones como la escritura de registros de auditoría.
Método de configuración específico:
proveedor de servicios, configuración de nivel de servicio
<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" cluster="failsafe" />
Persona que llama al servicio, configuración del nivel de servicio
<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="failsafe"/>
La configuración del llamador del servicio tiene prioridad sobre la configuración del proveedor de servicios.
Fallar rapido
En algunos escenarios comerciales, ciertas operaciones pueden ser no idempotentes. Si la llamada se inicia repetidamente, puede causar datos sucios, etc. Por ejemplo, llamar a un servicio, que incluye una operación de escritura en la base de datos, si la operación de escritura se completa, pero se produce un error en el proceso de envío del resultado a la persona que llama, entonces parece que la llamada falló en la llamada, pero los datos se han escrito llevar a cabo. En este caso, volver a intentarlo puede no ser una buena estrategia. En este momento, debe utilizar la estrategia Failfast. Si la llamada falla, se informará un error de inmediato. Deje que la persona que llama decida la siguiente operación y asegure la idempotencia del negocio.
Método de configuración específico:
proveedor de servicios, configuración de nivel de servicio
<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" cluster="failfast" />
Persona que llama al servicio, configuración del nivel de servicio
<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="failfast"/>
La configuración del llamador del servicio tiene prioridad sobre la configuración del proveedor de servicios.
Failback (recuperación automática después de un fallo)
La conmutación por recuperación generalmente se asocia con los dos conceptos de conmutación por error. En un sistema de alta disponibilidad, cuando el host falla,
después de que el interruptor principal / en espera se realiza a través de la Conmutación por falla, el sistema debe tener la capacidad de restaurar automáticamente la configuración original después de que se restaure la falla.
En la estrategia Failback en Dubbo, si la llamada falla, la falla es equivalente a Failsafe y se devolverá un resultado vacío. A diferencia de Failsafe, la estrategia Failback agregará esta llamada a la lista de fallas en la memoria. Para las llamadas fallidas en esta lista, se realizará un reintento asincrónico en otro subproceso. Si el reintento falla nuevamente, Ignore, incluso si la llamada de reintento tiene éxito, el llamador original no lo notará. Por lo tanto, suele ser adecuado para algunas operaciones asincrónicas que no requieren un alto rendimiento en tiempo real y no requieren valores de retorno.
Método de configuración específico:
proveedor de servicios, configuración de nivel de servicio
<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" cluster="failsafe" />
Persona que llama al servicio, configuración del nivel de servicio
<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="failsafe"/>
La configuración del llamador del servicio tiene prioridad sobre la configuración del proveedor de servicios.
De acuerdo con la implementación actual, la estrategia de Failback tiene algunas limitaciones. Por ejemplo, la lista de llamadas fallidas en la memoria no tiene límite superior, lo que puede causar acumulación. El intervalo de ejecución de reintentos asincrónicos no se puede ajustar. El valor predeterminado es 5 segundos.
Bifurcación (llamada paralela)
Entre las estrategias antes mencionadas, se consideran principalmente desde la perspectiva de cómo compensar el fallo de la llamada. La estrategia de Forking es diferente de las estrategias antes mencionadas. Es una idea típica de cambiar el costo por tiempo. Es decir, se inician múltiples llamadas al mismo tiempo en la primera llamada y, siempre que una de las llamadas sea exitosa, se considera exitosa. Esta estrategia se puede utilizar en escenarios donde los recursos son suficientes y la tolerancia a fallas es baja.
Método de configuración específico:
Proveedor de servicios, configuración de nivel de servicio
<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" cluster="forking" />
Persona que llama al servicio, configuración del nivel de servicio
<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="forking"/>
La configuración del llamador del servicio tiene prioridad sobre la configuración del proveedor de servicios.
Difusión (llamada de difusión)
En algunos escenarios, puede ser necesario realizar operaciones en todos los proveedores del servicio, en este caso se puede utilizar la estrategia de llamada de difusión. Esta estrategia llamará a todos los proveedores uno por uno, siempre que alguno de los proveedores tenga un error, la llamada se considerará un error. Normalmente se utiliza para notificar a todos los proveedores que actualicen la información de recursos locales, como cachés o registros.
Método de configuración específico:
proveedor de servicios, configuración de nivel de servicio
<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" cluster="broadcast" />
Persona que llama al servicio, configuración del nivel de servicio
<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="broadcast"/>
La configuración del llamador del servicio tiene prioridad sobre la configuración del proveedor de servicios.
Comparación de varias estrategias
La siguiente tabla hace una comparación simple de varias estrategias,
| Nombre de la estrategia | ventaja | Desventaja | Escenarios de aplicación principales |
|---|---|---|---|
| Conmutación por falla | Escudo de información de falla de la persona que llama | Aumente la RT, la sobrecarga de recursos adicionales, el desperdicio de recursos | Escenas que no son sensibles a la llamada rt |
| Fallar rapido | La empresa percibe rápidamente el estado de falla y toma decisiones autónomas | Genera más mensajes de error | Las operaciones no idempotentes requieren una percepción rápida de los escenarios de falla |
| A prueba de fallos | Incluso si falla, no afectará el proceso principal | Insensible a la información fallida, se requiere monitoreo adicional | Sistema de derivación, escenarios donde la falla no afecta la corrección del proceso central |
| Failback | Reintento asincrónico automático en caso de error | Las tareas de reintento pueden acumularse | Algunas operaciones asincrónicas que no requieren rendimiento en tiempo real y no requieren valores de retorno |
| Bifurcando | Inicie múltiples llamadas en paralelo para reducir la probabilidad de falla | Consumen recursos de la máquina adicionales y necesitan garantizar la idempotencia de las operaciones | Escenarios con recursos suficientes, baja tolerancia a fallas y altos requisitos en tiempo real |
| Transmitir | Operaciones de soporte para todos los proveedores de servicios | Alto consumo de recursos | Notificar a todos los proveedores que actualicen la información de los recursos locales, como el caché o el registro. |
Estrategia personalizada de tolerancia a fallas
Si la estrategia de tolerancia a fallas incorporada mencionada anteriormente no puede satisfacer sus necesidades, también puede implementar una estrategia de tolerancia a fallas personalizada de manera extendida.
puerto de extensión
com.alibaba.dubbo.rpc.cluster.Cluster
Configuración extendida
<dubbo:service cluster="xxx" />
XxxCluster.java:
package com.xxx;
import org.apache.dubbo.rpc.cluster.Cluster;
import org.apache.dubbo.rpc.cluster.support.AbstractClusterInvoker;
import org.apache.dubbo.rpc.cluster.Directory;
import org.apache.dubbo.rpc.cluster.LoadBalance;
import org.apache.dubbo.rpc.Invoker;
import org.apache.dubbo.rpc.Invocation;
import org.apache.dubbo.rpc.Result;
import org.apache.dubbo.rpc.RpcException;
import java.util.List;
public class XxxCluster implements Cluster {
@Override
public <T> Invoker<T> join(Directory<T> directory) throws RpcException {
return new AbstractClusterInvoker<T>() {
@Override
protected Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
//定义你的容错策略
}
};
}
}