El apagado gradual es imperceptible para los consumidores de su aplicación en línea, quienes pueden seguir utilizándola sin interrupciones durante el reinicio o la detención. De forma predeterminada, Enterprise Distributed Application Service (EDAS) admite el apagado gradual para aplicaciones de Spring Cloud. No necesita configurar el apagado gradual para las aplicaciones de Spring Cloud.
Contexto
El apagado gradual garantiza que las solicitudes de servicio de los consumidores se procesen correctamente cuando se detienen las aplicaciones. En un escenario ideal, las aplicaciones se actualizan de manera segura y confiable cuando no existen solicitudes de servicio activas. Sin embargo, esta situación es extremadamente rara en la práctica.
Una solución tradicional consiste en ejecutar manualmente los siguientes pasos: eliminar el tráfico, detener la aplicación, actualizarla y luego reiniciarla. Si utiliza esta solución para actualizar su aplicación, la continuidad del negocio de los clientes no se ve afectada.
Una solución innovadora es utilizar un mecanismo automatizado en el nivel de contenedor o framework. Esta solución permite eliminar automáticamente el tráfico y procesar todas las solicitudes recibidas para que el proceso de actualización sea imperceptible para su negocio y que las tareas de operación y mantenimiento durante la actualización sean eficientes. El apagado gradual es un ejemplo de esta solución innovadora.
Beneficios del apagado gradual de EDAS
Si utiliza la solución de apagado gradual proporcionada por Spring Cloud de código abierto, debe usar shutdown hooks, Spring Boot Actuator y Ribbon. Esta solución requiere esfuerzo adicional de desarrollo y puede provocar pérdida de tráfico hacia los registros durante un breve periodo.
EDAS integra el apagado gradual en el proceso de versión para implementarlo automáticamente cuando usted detiene, despliega, revierte, reduce horizontalmente o restablece aplicaciones. En comparación con el apagado gradual de Spring Cloud de código abierto, el apagado gradual de EDAS ofrece a continuación ventajas.
Categoría | Spring Cloud de código abierto | EDAS |
Versión | Al llamar a ServiceRegistryEndpoint, debe usar Spring Boot Actuator y actualizarlo a la versión compatible con la versión de Spring Cloud in use. | EDAS admite Spring Cloud Dalston o versiones posteriores. No necesita realizar operaciones adicionales. |
Registro de servicios y pérdida de tráfico | Spring Cloud de código abierto depende de registros que pueden causar pérdida de tráfico:
| EDAS no depende de registros. No se produce pérdida de tráfico. |
Escenario |
| Puede apagar de forma gradual las aplicaciones desplegadas en clústeres de ECS y Kubernetes desde la consola de EDAS. Las operaciones y configuraciones de las aplicaciones no se ven afectadas. |
Caché del cliente | Configure un intervalo de tiempo adecuado para que Ribbon actualice la caché en los clientes. Si el intervalo es demasiado largo, se produce pérdida de tráfico al apagar la aplicación de forma gradual. Si el intervalo es demasiado corto, se compromete el rendimiento del servicio. | Cuando apaga aplicaciones de forma gradual, EDAS proporciona un mecanismo mejorado para que Ribbon actualice la caché en los clientes. EDAS actualiza automáticamente la caché mediante un método de respuesta reactiva. Esto elimina la necesidad de actualizar la caché manualmente. |
Comprobar si el apagado gradual está en vigor
Compruebe si el apagado gradual está en vigor para sus aplicaciones según sus requisitos de negocio. EDAS proporciona a continuación aplicaciones de demostración: Provider y Consumer. Utilice estas aplicaciones de demostración en un clúster de Container Service for Kubernetes (ACK) para verificar si el apagado gradual funciona correctamente.
Procedimiento
Descargue las aplicaciones de demostración Provider y Consumer.
-
Despliegue Provider y Consumer en un clúster de ACK.
Provider tiene dos instancias desplegadas y Consumer tiene una instancia desplegada. Para obtener más información sobre cómo desplegar las aplicaciones de demostración, consulte Deploy applications.

-
Consulte el estado de las llamadas iniciadas desde Consumer hacia Provider.
-
Inicie sesión en el pod donde se despliega Consumer y ejecute los siguientes comandos para acceder continuamente a los servicios de Provider:
#!/usr/bin/env bash while true do echo `curl -s -XGET http://localhost:18091/user/rest` done -
Consulte las respuestas de las llamadas.

Las respuestas anteriores muestran que Consumer accede aleatoriamente a dos instancias de Provider. Las direcciones IP de las instancias son 172.20.0.221 y 172.20.0.223.
ImportanteNo cierre la ventana de respuesta.
-
Reduzca horizontalmente una instancia de Provider y reinicie la instancia. Para obtener más información, consulte Application lifecycle management of Kubernetes clusters.
-
Consulte nuevamente las respuestas de las llamadas para comprobar si el apagado gradual está en vigor.

Consulte el estado de las llamadas de Consumer para verificar si el apagado gradual está en vigor. Revise los registros de Consumer. Si los registros indican que no se produjeron excepciones, la indisponibilidad de la instancia resulta imperceptible para Consumer.
Las respuestas anteriores muestran que Consumer accede únicamente a la instancia restante de Provider. La dirección IP de la instancia es 172.20.0.221. Durante el proceso de acceso no se producen excepciones en las llamadas y Consumer no se ve afectado.