La diferencia entre Sentinel y Hystrix
Hystrix se centra en el aislamiento y la tolerancia a fallos basada en disyuntores o las llamadas a disyuntores fallarán rápidamente y pueden proporcionar un mecanismo de reversión, mientras que Sentinel se centra en los siguientes aspectos:
Diversificación. Control de tráfico
Actualización Meltdown
Protección de carga del sistema
Monitoreo y consola en tiempo real
Puedes ver la diferencia en los problemas resueltos por los dos. Grande, comparemos a continuación
El diseño del modelo de recursos de Hystrix utiliza el modelo de comando, que encapsula las llamadas de recursos externos y la lógica de reversión en un objeto de comando (HystrixCommand?/?). y la ejecución subyacente se basa en la implementación de RxJava. Cada comando creado tiene una clave de comando y una clave de grupo (utilizadas para diferenciar recursos) y una política de aislamiento correspondiente (aislamiento de grupo de subprocesos o aislamiento de señal). En el modo de aislamiento del grupo de subprocesos, debe configurar los parámetros correspondientes del grupo de subprocesos (nombre del grupo de subprocesos, capacidad, tiempo de espera de la cola, etc.) y luego el comando se ejecutará en el grupo de subprocesos especificado de acuerdo con la política de tolerancia a fallas especificada. en el modo de aislamiento de Semaphore, debe configurar el número máximo de concurrencias y luego Hystrix limitará las llamadas concurrentes cuando se ejecute el comando.
Sentinel está diseñado para ser más simple. En comparación con la fuerte dependencia de Hystrix Command de las reglas de aislamiento, la definición de recursos y la configuración de reglas de Sentinel están menos acopladas, lo que afecta directamente la ejecución de los comandos. En el momento de la ejecución, Hystrix analiza las reglas de aislamiento del Comando para crear un programador RxJava y programar la ejecución en él, y el grupo de subprocesos subyacente del programador es el grupo de subprocesos configurado en modo de grupo de subprocesos, o simplemente encapsulado en modo Semaphore en el programador en el que se encuentra el programa actual. El subproceso se ejecuta y Sentinel no especifica el modo de ejecución y no le importa si la aplicación es un grupo de subprocesos. Sentinel no especifica un modo de ejecución ni se centra en cómo se ejecuta la aplicación. El principio de Sentinel es muy simple: de acuerdo con las reglas de la configuración del recurso correspondiente, se implementa la correspondiente estrategia actual de limitación/degradación/protección de carga para el recurso. En Sentinel, la definición de recursos y la configuración de reglas están separadas. Los usuarios primero definen recursos (puntos enterrados) para la lógica empresarial correspondiente a través de la API Sentinel y luego pueden configurar reglas cuando sea necesario. Hay dos métodos para enterrar puntos:
método try-catch (a través de SphU.entry(...)
if-else (a través de SphO.entry(...)) , El usuario ejecuta excepciones/respaldos en if-else (a través de SphO.entry(...)), el usuario ejecuta excepciones en las que se devuelve false excepto directamente en el estado de la memoria a través de "loadRules?API". También registre varias fuentes de datos externas para proporcionar reglas dinámicas.
Puede cambiar dinámicamente la configuración de las reglas en función de las condiciones actuales en tiempo real del sistema, y la fuente de datos enviará los cambios a Sentinel y entrarán en vigor de inmediato.
El aislamiento es una de las funciones principales de Hystrix. Proporciona dos estrategias de aislamiento: aislamiento del grupo de subprocesos (modo Bulkhead) y aislamiento de señales. El más recomendado y utilizado es el aislamiento del grupo de subprocesos. Se producen diferentes llamadas de servicio en diferentes grupos de subprocesos. En caso de colas, tiempos de espera y otras situaciones de bloqueo, los grupos de subprocesos pueden fallar rápidamente y proporcionar un mecanismo de respaldo. El beneficio del aislamiento del grupo de subprocesos es un mayor aislamiento y el grupo de subprocesos de un determinado recurso se puede procesar sin afectar otros recursos, pero el costo es la sobrecarga del cambio de contexto de subprocesos, especialmente para llamadas de baja latencia que tienen un mayor impacto.
Sin embargo, en la práctica, el aislamiento del grupo de subprocesos no aporta muchos beneficios. En primer lugar, demasiados grupos de subprocesos pueden tener un impacto significativo en el rendimiento. Considere esta situación en Tomcat y otros contenedores de Servlet que usan Hystrix, la cantidad de subprocesos en Tomcat es muy grande (puede llegar a docenas o más de cien si se combina con el grupo de subprocesos creado por Hystrix para cada recurso, *). *** El número total de subprocesos será muy grande (cientos de subprocesos), por lo que el cambio de contexto provocará una pérdida muy grande. Además, el aislamiento del modelo de grupo de subprocesos es más completo, lo que permite a Hystrix manejar las colas y los tiempos de espera de diferentes grupos de subprocesos de recursos por separado, pero este es en realidad el problema que la fusión de tiempo de espera y el control de flujo deben resolver si el componente tiene. funciones de control de flujo y fusión de tiempo de espera, entonces el aislamiento del grupo de subprocesos no es tan necesario.
Sentinel proporciona aislamiento de señalización a través del control de flujo en modo de subprocesos concurrentes. Este aislamiento es muy liviano y limita la cantidad de llamadas simultáneas a un recurso en lugar de crear explícitamente un grupo de subprocesos, por lo que la sobrecarga es pequeña pero efectiva. Combinado con el modo de degradación del disyuntor basado en el tiempo de respuesta, puede degradarse automáticamente cuando el tiempo de respuesta promedio de recursos inestables es largo, evitando que demasiadas llamadas lentas llenen la cantidad de subprocesos simultáneos y afecten a todo el sistema. El aislamiento de Semaphore de Hystrix es relativamente simple y no puede degradar automáticamente las llamadas lentas. Solo puede esperar a que el cliente expire por sí solo, por lo que aún puede ocurrir un bloqueo en cascada.
La comparación de la degradación de los fusibles entre Sentinel y Hystrix se basa básicamente en el modelo de fusibles
Tanto Sentinel como Hystrix admiten la degradación de los fusibles según la tasa de falla (relación anormal). En este punto, todas las llamadas al recurso se bloquean hasta el final del período de tiempo especificado. Como se mencionó anteriormente, Sentinel también admite la degradación del disyuntor según el tiempo de respuesta promedio. Cuando el tiempo de respuesta del servicio continúa aumentando, se puede usar para interrumpir automáticamente el servicio, denegar más solicitudes y no recuperarse hasta un cierto período de tiempo. el tiempo ha pasado. Esto evita que llamadas extremadamente lentas provoquen bloqueos en cascada.
Comparación de implementaciones de estadísticas de indicadores en tiempo real
Las implementaciones de estadísticas de indicadores en tiempo real de Hystrix y Sentinel se basan en ventanas deslizantes. Antes de Hystrix 1.5, las ventanas deslizantes se implementaban en. en forma de matrices circulares. Las operaciones de bloqueo y CAS actualizan las estadísticas para cada depósito. Hystrix 1.5 comienza a reconstruir la implementación de estadísticas de medición en tiempo real y abstrae la estructura de datos de las estadísticas de medición en un flujo de reacción para facilitar a los consumidores el uso de la información de medición. Al mismo tiempo, la capa inferior se ha transformado en un modelo basado en eventos basado en RxJava. Los eventos se publican cuando la llamada del servicio tiene éxito/falla/se agota el tiempo de espera y, a través de una serie de transformaciones y agregaciones, se obtienen datos métricos en tiempo real. Finalmente se obtiene un flujo que puede ser aprovechado por disyuntores o cuadros de consumo.
Sentinel actualmente abstrae la interfaz estadística de métricas y la capa inferior puede tener diferentes implementaciones. La implementación predeterminada actual es una ventana deslizante basada en LeapArray, y se introducirán implementaciones como flujos reactivos según sea necesario en el futuro. .
Funciones de Sentinel
Además de la misma característica mencionada anteriormente, Sentinel también ofrece las siguientes características:
¿Ligero y de alto rendimiento?
Sentinel es un componente de gestión de tráfico de alta disponibilidad y con todas las funciones. Su núcleo centinela no tiene dependencias redundantes. Después del empaquetado, es muy liviano y los desarrolladores pueden introducirlo. confianza." ¿sentinel-core? "sin tener que preocuparse por las dependencias, y Sentinel proporciona varios puntos de extensión para que los usuarios puedan pasar fácilmente a sentinel-core según sea necesario. Los usuarios pueden escalar fácilmente para satisfacer sus necesidades y cambiar sin problemas a Sentinel
La introducción de Sentinel afecta muy poco al rendimiento. Solo cuando el negocio supere los 25 W QPS, el impacto será obvio (5-10), y cuando el QPS no sea demasiado grande, el impacto será casi insignificante.
Control de flujo
Sentinel puede aplicar diferentes métricas operativas para diferentes llamadas, como QPS, llamadas simultáneas y otros factores. (por ejemplo, QPS, número de llamadas simultáneas, carga del sistema, etc.) como base y realizar control de flujo en llamadas de recursos para dar forma adecuada a las solicitudes aleatorias.
Sentinel admite múltiples políticas de configuración de tráfico para ajustar automáticamente el tráfico a la forma correcta cuando el QPS es demasiado alto. Los más habituales son:
Modo de rechazo directo: rechaza las solicitudes que superen el umbral.
Modo de precalentamiento de inicio lento: cuando el flujo aumenta, el caudal se controla para que el caudal aumente lentamente y aumente gradualmente hasta el límite superior del umbral dentro de un cierto período de tiempo, dando al sistema frío un tiempo de precalentamiento para evitar que el sistema frío se abrume.
¿Modo zoom? El modo de escalado implementado mediante el algoritmo de embudo controla estrictamente el intervalo de tiempo para el paso de solicitudes, mientras que las solicitudes apiladas se pondrán en cola y las solicitudes que excedan el período de tiempo de espera se rechazarán directamente.
Sentinel Hystrix
Estrategia de aislamiento basada en el aislamiento del grupo de subprocesos/aislamiento del semáforo del número de concurrencia
Estrategia de degradación del disyuntor basada en el tiempo de respuesta o la tasa de fallas
Los indicadores en tiempo real implementan una ventana deslizante (basada en RxJava)
La configuración de reglas admite múltiples fuentes de datos.
La extensibilidad proporciona múltiples puntos de extensión en el formulario. de complementos
Compatibilidad con la próxima versión basada en anotaciones
No admite información de enlace de llamada para llamadas sincrónicas
No admite límite de tráfico basado en QPS/ número de concurrencia a admitir según la relación de llamadas del límite de tráfico
No admite soporte de configuración de tráfico de inicio lento, no admite modo homogéneo
No admite protección de carga del sistema
Las API de monitoreo en tiempo real son diversa y relativamente simple
Consola lista para usar, puede configurar reglas, ver monitoreo secundario, descubrir máquinas, etc. Imperfecto
Se adapta a marcos comunes como Servlet, Spring Cloud, Dubbo, gRPC, etc. Servlet, Spring Cloud Netflix
Se adapta a marcos comunes, como Spring Cloud, Dubbo, gRPC , etc. Nube Netflix
Fuente del artículo /educast/article/details/88735339