Principio de tolerancia a fallos de microservicio Resilience4j
4.1 Introducción a la tolerancia a fallos de microservicios
En condiciones de alto acceso concurrente, como Tmall Double 11, el tráfico continúa aumentando y la frecuencia de las llamadas mutuas entre servicios aumenta repentinamente, lo que hace que la carga del sistema sea demasiado alta. En este momento, la estabilidad de los servicios en los que se basa el sistema ha disminuido. un impacto en el sistema El impacto es muy grande y hay muchos factores inciertos que causan una avalancha, como la interrupción de la conexión de la red, el tiempo de inactividad del servicio, etc. Los componentes generales de microservicio tolerantes a fallas proporcionan métodos como limitación de corriente, aislamiento, degradación y disyuntor, que pueden proteger eficazmente nuestro sistema de microservicio.
4.1.1 Aislamiento
El sistema de microservicio A llama a B y B llama a C. Si C falla, se bloqueará una gran cantidad de recursos de subprocesos que llaman a B. Lentamente, la cantidad de subprocesos de B continuará aumentando hasta que la CPU se agote al 100%. El microservicio general no está disponible, entonces es necesario aislar el servicio no disponible.
4.1.1.1 Aislamiento del grupo de subprocesos
El aislamiento del grupo de subprocesos se logra a través del grupo de subprocesos de Java. El servicio B llama al servicio C y recibe un número fijo de subprocesos, como 12 subprocesos. Si el servicio C está inactivo en este momento, incluso si ingresa una gran cantidad de solicitudes, el servicio Se llamará a C. La interfaz solo ocupará 12 subprocesos y no ocupará otros recursos de subprocesos de trabajo, por lo que el servicio B no experimentará fallas en cascada. El principio de aislamiento del grupo de subprocesos se muestra en la Figura 4-2.
4.1.1.2 Aislamiento de semáforo
隔离信号量隔离是使⽤Semaphore来实现的，当拿不到信号量的时候直接拒接因此不会出现超时占⽤其他⼯作线程的情况。代码如下。
Semaphore semaphore = new Semaphore(10,true);
//获取信号量
semaphore.acquire();
//do something here
//释放信号量
semaphore.release();
4.1.1.3 La diferencia entre el aislamiento del grupo de subprocesos y el aislamiento del semáforo
线程池隔离针对不同的资源分别创建不同的线程池，不同服务调⽤都发⽣在不同的线程池中，在线程池排队、超时等阻塞情况时可以快速失败。线程池隔离的好处是隔离度⽐较⾼，可以针对某个资源的线程池去进⾏处理⽽不影响其它资源，但是代价就是线程上下⽂切换的 overhead ⽐较⼤，特别是对低延时的调⽤有⽐较⼤的影响。⽽信号量隔离⾮常轻量级，仅限制对某个资源调⽤的并发数，⽽不是显式地去创建线程池，所以 overhead ⽐较⼩，但是效果不错，也⽀持超时失败。
| categoría | Aislamiento del grupo de subprocesos | Aislamiento de semáforo |
| hilo | A diferencia del hilo de llamada, se utiliza el hilo creado por el grupo de hilos. | Lo mismo que llamar al hilo |
| gastos generales | Hacer cola, cambiar, programar y otros gastos generales | Mayor rendimiento sin cambio de hilo |
| Ya sea para admitir asincrónico | Apoyo | no apoyo |
| Ya sea para admitir el tiempo de espera | Apoyo | apoyo |
| Soporte de concurrencia | Admite el control a través del tamaño del grupo de subprocesos | Admite control mediante semáforo máximo |
4.1.2 Fusión
当下游的服务因为某种原因突然变得不可⽤或响应过慢，上游服务为了保证⾃⼰整体服务的可⽤性，不再继续调⽤⽬标服务，直接返回，快速释放资源。如果⽬标服务情况好转则恢复调⽤。熔断器模型，如图所示
La máquina de estados del modelo de fusible tiene 3 estados.
Closed：关闭状态（断路器关闭），所有请求都正常访问。
Open：打开状态（断路器打开），所有请求都会被降级。熔断器会对请求情况计数，当⼀定时间内失败请求百分⽐达到阈值，则触发熔断，断路器会完全打开。
Half Open：半开状态，不是永久的，断路器打开后会进⼊休眠时间。随后断路器会⾃动进⼊半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进⾏休眠计时。
4.1.3 Bajar de categoría
降级是指当⾃身服务压⼒增⼤时，系统将某些不重要的业务或接⼝的功能降低，可以只提供部分功能，也可以完全停⽌所有不重要的功能。⽐如，下线⾮核⼼服务以保证核⼼服务的稳定、降低实时性、降低数据⼀致性，降级的思想是丢⻋保帅。
举个例⼦，⽐如，⽬前很多⼈想要下订单，但是我的服务器除了处理下订单业务之外，还有⼀些其他的服务在运⾏，⽐如，搜索、定时任务、⽀付、商品详情、⽇志等等服务。然⽽这些不重要的服务占⽤了JVM的不少内存和CPU资源，为了应对很多⼈要下订单的需求，设计了⼀个动态开关，把这些不重要的服务直接在最外层拒绝掉。这样就有跟多的资源来处理下订单服务（下订单速度更快了）
4.1.4 Limitación de corriente
限流，就是限制最⼤流量。系统能提供的最⼤并发有限，同时来的请求⼜太多，就需要限流，⽐如商城秒杀业务，瞬时⼤量请求涌⼊，服务器服务不过来，就只好排队限流了，就跟去景点排队买票和去银⾏办理业务排队等号道理相同。下⾯介绍下四种常⻅的限流算法。
1. Algoritmo de depósito con fugas
2. Algoritmo de depósito de tokens
3. Algoritmo de ventana de tiempo fija
4. Algoritmo de ventana de tiempo deslizante
4.1.4.1.Algoritmo de depósito con fugas
La idea del algoritmo del balde con fugas es que un balde con fugas con una capacidad fija expulsa gotas de agua a una velocidad constante y fija. Si el cubo está vacío, no es necesario que fluyan gotas de agua. El agua puede fluir hacia el balde que gotea de cualquier manera. Si las gotas de entrada exceden la capacidad del cubo, las gotas de entrada se desbordan (se descartan) y la capacidad del cubo con fugas permanece sin cambios.
4.1.4.2.Algoritmo de depósito de tokens
Algoritmo de depósito de tokens: suponiendo que el límite es 2r/s, los tokens se agregan al depósito a una velocidad fija de 500 milisegundos. Se puede almacenar un máximo de b tokens en el depósito. Cuando el depósito está lleno, los tokens recién agregados se descartan o rechazan. Cuando llega un paquete de tamaño n bytes, se eliminan n tokens del depósito y el paquete se envía a la red. Si hay menos de n tokens en el depósito, el token no se eliminará y el paquete tendrá un flujo limitado (ya sea descartado o almacenado en búfer para esperar). El principio de limitación de corriente del depósito de tokens se muestra en la figura.
El servidor que limita la corriente del depósito de tokens puede cambiar la velocidad de generación de tokens y la capacidad del depósito según el rendimiento real del servicio y el período de tiempo. Una vez que es necesario aumentar la tasa, la tasa de tokens colocados en el depósito aumenta según sea necesario.
生成令牌的速度是恒定的，⽽请求去拿令牌是没有速度限制的。这意味着当⾯对瞬时⼤流量，该算法可以在短时间内请求拿到⼤量令牌，⽽且拿令牌的过程并不是消耗很⼤。
4.1.4.3 Algoritmo de ventana de tiempo fija
Dentro de un período de tiempo fijo, se puede permitir la entrada de un número fijo de solicitudes. Si se excede la cantidad, será rechazado o se le pondrá en cola para esperar el siguiente período de tiempo para ingresar. Este método de implementar la limitación de contracorriente está limitado dentro de un intervalo de tiempo. Si el usuario solicita antes del final del intervalo de tiempo anterior (pero no excede el límite) y al mismo tiempo inicia la solicitud en el intervalo de tiempo actual (también no excede el límite), límite), dentro de cada intervalo de tiempo, estas solicitudes son normales, pero las solicitudes dentro de un período de tiempo crítico excederán el límite del sistema, lo que puede causar que el sistema se abrume.
Dado que el algoritmo de contador tiene un defecto en el punto crítico de tiempo, es vulnerable a ataques en un período de tiempo muy corto alrededor del punto crítico de tiempo. Por ejemplo, se establece que una determinada interfaz se puede solicitar hasta 100 veces por minuto, por ejemplo, no hay solicitud de datos en el período de tiempo 12:00:00-12:00:59, pero no hay solicitud de datos. En el período de tiempo de 12:00:59 a 12:01:00, de repente se produjeron 100 solicitudes simultáneas y luego entró en el siguiente ciclo de conteo, el contador se borró y hubo 100 solicitudes entre las 12:01:00 y 12:01. :01. En otras palabras, alrededor del punto crítico de tiempo, puede haber el doble de solicitudes que el umbral al mismo tiempo, lo que resulta en una sobrecarga de solicitudes de procesamiento en segundo plano, lo que resulta en capacidades operativas insuficientes del sistema e incluso una falla del sistema.
4.1.4.4 Algoritmo de ventana de tiempo deslizante
滑动窗⼝算法是把固定时间⽚进⾏划分，并且随着时间移动，移动⽅式为开始时间点变为时间列表中的第⼆时间点，结束时间点增加⼀个时间点，不断重复，通过这种⽅式可以巧妙的避开计数器的临界点的问题。
滑动窗⼝算法可以有效的规避计数器算法中时间临界点的问题，但是仍然存在时间⽚段的概念。同时滑动窗⼝算法计数运算也相对固定时间窗⼝算法⽐较耗时。
4.2 Introducción a la Resiliencia4j
4.2.1 Introducción a la Resiliencia4j
Netflix的Hystrix微服务容错库已经停⽌更新，官⽅推荐使⽤Resilience4j代替Hystrix，或者使⽤Spring Cloud Alibaba的Sentinel组件
Módulo principal:
resilience4j-circuitbreaker: 熔断
resilience4j-ratelimiter: 限流
resilience4j-bulkhead: 隔离
resilience4j-retry: ⾃动重试
resilience4j-cache: 结果缓存
resilience4j-timelimiter: 超时处理
Fallback 调用失败后异常处理