Los despliegues, el escalado y los reinicios son operaciones habituales en cualquier aplicación en línea. La función de inicio controlado de Microservices Engine (MSE) protege las aplicaciones durante cada etapa del arranque mediante tres capacidades: registro de servicio diferido, calentamiento con tráfico bajo y sonda de disponibilidad del servicio.
Descripción general de la función
Registro diferido
Durante el arranque de la aplicación, una instancia proveedora de microservices se registra en un registro de servicios. Una vez completado el registro, las aplicaciones consumidoras pueden suscribirse e invocar al proveedor. En las aplicaciones Java basadas en el framework Spring, este registro suele ocurrir después de que se actualiza el contexto de Spring. Si la aplicación tiene tareas de inicialización asíncronas pendientes, registrarse de inmediato puede provocar errores en las solicitudes. Por ejemplo, una aplicación de MaxCompute podría necesitar descargar varios cientos de megabytes de datos desde Object Storage Service (OSS) antes de poder atender peticiones. Si se registra inmediatamente después de arrancar, el tráfico entrante fallará porque los recursos aún no están listos. La función de registro de servicio diferido permite establecer un periodo de espera que retrasa el registro del servicio, lo cual garantiza que la aplicación esté completamente inicializada antes de comenzar a recibir tráfico.
Calentamiento con tráfico bajo
Una instancia recién iniciada suele encontrarse en un "estado frío", en el que debe cargar bajo demanda los pools de conexiones, precalentar las cachés y realizar la compilación JIT (just-in-time) del código crítico. Su capacidad para procesar solicitudes es mucho menor que la de una instancia que lleva tiempo ejecutándose. En el peor de los casos, el servicio podría bloquearse, lo que provocaría una gran cantidad de tiempos de espera agotados y errores en las solicitudes.
El siguiente ejemplo muestra la diferencia en el tiempo de respuesta entre dos solicitudes a una misma instancia: una realizada antes de que los recursos se carguen por completo y otra después. Si llega un gran volumen de solicitudes mientras la instancia todavía está cargando recursos, todas podrían bloquearse.
[arthas@37035]$ trace com.alibaba.mse.consumer.TestController eurekaRest -n 5 \
--skipJDKMethod false
Press Q or Ctrl+C to abort.
Affect(class count: 1 , method count: 1) cost in 105 ms, listenerId: 1
`---ts=2022-02-14 21:28:02;thread_name=http-nio-18099-exec-1;id=39;is_daemon=true;priority=5;TCCL=org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedWebappClassLoader@60e5272
`---[464.275852ms] com.alibaba.mse.consumer.TestController:eurekaRest()
`---[464.018509ms] org.springframework.web.client.RestTemplate:getForObject() #50
`---ts=2022-02-14 21:28:08;thread_name=http-nio-18099-exec-3;id=3b;is_daemon=true;priority=5;TCCL=org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedWebappClassLoader@60e5272
`---[8.46028ms] com.alibaba.mse.consumer.TestController:eurekaRest()
`---[8.402525ms] org.springframework.web.client.RestTemplate:getForObject() #50El calentamiento con tráfico bajo regula el flujo proveniente de las aplicaciones consumidoras hacia una nueva instancia de servicio en el momento de su lanzamiento. Esto evita la degradación del rendimiento por arranque en frío y protege a la instancia ante un aumento repentino de tráfico. El volumen de tráfico aumenta de forma gradual hasta alcanzar la duración de calentamiento configurada; después de ese punto, la instancia recibe tráfico con normalidad.
El calentamiento con tráfico bajo utiliza el tráfico generado por consumidores en línea. Por ello, es necesario que los consumidores del servicio también estén conectados a MSE Microservices Governance. Para obtener más información sobre cómo funciona esta función, consulte How low-traffic warm-up works.
Sonda de disponibilidad del servicio
Kubernetes ofrece un mecanismo de sonda de disponibilidad (readiness probe). Durante un despliegue, cuando una nueva instancia supera su sonda de disponibilidad, la instancia anterior se termina (el comportamiento exacto depende de la estrategia de despliegue). Sin embargo, Kubernetes considera que una aplicación está lista en cuanto se abre un puerto, y no puede determinar cuándo un microservicio ha finalizado realmente su inicialización. Esto puede provocar que Kubernetes marque un servicio como disponible antes de que se haya registrado en el registro de servicios y termine la instancia anterior, lo que genera errores de tipo service no provider/instance en los consumidores.
La sonda de disponibilidad del servicio proporciona un endpoint HTTP no intrusivo a través de un agente que comprueba si la aplicación ha completado su registro. Devuelve un código de estado 500 mientras el registro está incompleto y 200 una vez que el registro se completa correctamente. Al configurar la sonda de disponibilidad de Kubernetes para usar este endpoint, se garantiza que los consumidores siempre cuenten con un proveedor disponible durante los despliegues, lo que previene los errores de "no provider".
Uso del inicio controlado
Requisitos previos
Notas de uso
Actualmente, el inicio controlado solo es compatible con instancias que utilizan un registro de microservices (como Nacos) para el descubrimiento de servicios. No es compatible con instancias de microservices que dependen de Kubernetes Services para el descubrimiento.
En aplicaciones Spring Cloud, el calentamiento con tráfico bajo solo es compatible con aquellas que usan Nacos, ZooKeeper o Eureka como registro.
La función de calentamiento con tráfico bajo para Spring Cloud se implementa con base en los balanceadores de carga predeterminados de Spring Cloud:
ZoneAwareLoadBalancer,RoundRobinLoadBalanceroRandomLoadBalancer. Si modifica la configuración del balanceador de carga de su aplicación, esta función dejará de operar correctamente.Para que el calentamiento con tráfico bajo funcione, tanto las aplicaciones proveedoras como las consumidoras deben estar conectadas a MSE Microservices Governance. Esta función no aplica a aplicaciones como gateways que reciben tráfico externo directamente a través de API expuestas.
Procedimiento
Paso 1: Habilitar el inicio controlado
Inicie sesión en la consola de MSE y seleccione una región en la barra de navegación superior.
En el panel de navegación izquierdo, vaya a . En la página que aparece, haga clic en la tarjeta de recurso de la aplicación que desea gestionar.
En la página de detalles de la aplicación, haga clic en Traffic management en el panel de navegación izquierdo y luego en la pestaña Graceful Start/Shutdown.
En la sección Configuration Information, haga clic en Edit, active el interruptor Graceful Start y luego haga clic en OK.
Paso 2: Configurar la sonda de disponibilidad de Kubernetes
Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.
-
En la página Clusters, haga clic en el clúster deseado. En el panel de navegación izquierdo, vaya a Workload > Stateless. Localice su aplicación desplegada y haga clic en Edit en la columna Actions. En la sección Health Check, haga clic en Enable junto a Readiness y configure los siguientes parámetros. Cuando termine, haga clic en Update.
Path: /readiness. (Si su aplicación utiliza una versión del agente anterior a la 4.1.10, establezca la ruta en /health. Para verificar la versión del agente, vaya a la consola de MSE. Vaya a Microservices Governance > Application Governance, haga clic en su aplicación y seleccione Node details. La versión del agente se muestra a la derecha).
Port:
55199.Initial Delay (s): Se recomienda establecer este valor por encima de la suma del tiempo de arranque de la aplicación y la duración de registro diferido configurada (el valor predeterminado es 0 s). No obstante, la función seguirá operando correctamente aunque no siga esta recomendación.
Para obtener información sobre otros parámetros, consulte Create a stateless workload (Deployment). Después de reiniciar la aplicación, la sonda de disponibilidad solo se superará una vez que se complete el registro del servicio.
Esta operación reiniciará su aplicación de inmediato. Si se encuentra en un entorno de producción, ejecute esta operación durante una ventana de mantenimiento programada.
(Opcional) Configurar la duración del registro diferido
Este ajuste es opcional y puede configurarse según las necesidades de su negocio. Para más detalles, consulte delayed service registration. Siga estos pasos:
Siga el Paso 1 y el Paso 2 para ir a la página de inicio controlado, habilitar la función y configurar la sonda de disponibilidad del servicio en Kubernetes.
Modifique la Configuration Information de Graceful Start and Shutdown. Haga clic en la flecha a la izquierda del módulo Graceful Start para expandir sus ajustes. En el campo Delayed Registration Duration (s), introduzca un valor y luego haga clic en OK.
La duración de registro diferido configurada surtirá efecto la próxima vez que arranque la aplicación.
(Opcional) Ajustar la duración del calentamiento con tráfico bajo
Al habilitar el inicio controlado, esta función se activa automáticamente con una duración de calentamiento predeterminada de 120 segundos. Puede ajustar dicha duración según las necesidades de su negocio:
Siga el Paso 1 y el Paso 2 para ir a la página de inicio controlado, habilitar la función y configurar la sonda de disponibilidad del servicio en Kubernetes.
Modifique la Configuration Information de Graceful Start and Shutdown. Haga clic en la flecha a la izquierda del módulo Graceful Start para expandir sus ajustes. Haga clic en Advanced Options. En el campo Low-traffic Warm-up Duration (s), introduzca un valor y luego haga clic en OK.
Si el consumidor del servicio que se está calentando es un gateway nativo de nube de MSE, el calentamiento con tráfico bajo configurado aquí no surtirá efecto. En su lugar, configure los ajustes de calentamiento en el gateway nativo de nube de MSE. En la consola del gateway, haga clic en la instancia de gateway deseada. En el panel de navegación izquierdo, vaya a Routes > Services. Localice el servicio y, en la columna Actions, haga clic en More > Policies. En la pestaña Policies, dentro de Traffic Management > Load Balancing Configuration, haga clic en Edit y ajuste el parámetro Warm-up Time. Tenga en cuenta que la curva QPS de calentamiento predeterminada del gateway es lineal, lo cual difiere ligeramente de la curva cuadrática que ofrece MSE Microservices Governance, pero el efecto práctico es similar.
La duración ajustada del calentamiento con tráfico bajo surtirá efecto la próxima vez que arranque la aplicación.
La función de calentamiento con tráfico bajo opera en el lado del consumidor mediante el cálculo de pesos para cada instancia proveedora según sus tiempos de arranque. Luego utiliza un algoritmo de balanceo de carga para incrementar gradualmente el tráfico hacia la aplicación recién iniciada. Este proceso ayuda a calentar el servicio. Esto también requiere que el consumidor del servicio esté conectado a MSE Microservices Governance.
Al utilizar la función de calentamiento con tráfico bajo por primera vez, se recomienda usar la duración de calentamiento predeterminada. Si observa que el calentamiento no es efectivo o provoca pérdida de tráfico, puede optimizarlo ajustando este parámetro.
Para garantizar un calentamiento suficiente, consulte Best practices for low-traffic warm-up.
Observación del inicio controlado
Después de aplicar estas configuraciones, podrá consultar los tiempos de arranque y apagado de las instancias, junto con la curva QPS, en la página Graceful Start and Shutdown la próxima vez que arranque su aplicación.
Inicie sesión en la consola de MSE y seleccione una región en la barra de navegación superior.
En el panel de navegación izquierdo, vaya a . En la página que aparece, haga clic en la tarjeta de recurso de la aplicación que desea gestionar.
En la página de detalles de la aplicación, haga clic en Traffic management en el panel de navegación izquierdo y luego en la pestaña Graceful Start/Shutdown.
-
En la subpestaña Start and Shutdown Overview, haga clic en una instancia a la izquierda. A la derecha podrá consultar los cambios de QPS y los eventos relacionados ocurridos durante la fase de arranque.
Observará que eventos como el registro del servicio, el inicio del calentamiento y la finalización del calentamiento ocurren en secuencia. El evento 'Kubernetes readiness probe passed' también ocurre después del evento 'service registration'. La curva QPS aumenta gradualmente hasta alcanzar su valor máximo durante la duración del calentamiento (120 s de forma predeterminada) en lugar de dispararse de golpe. Si la secuencia de eventos o la forma de la curva QPS no cumplen con sus expectativas durante el arranque, consulte FAQ para solucionar problemas.
En una configuración típica, la sonda de disponibilidad de Kubernetes de la aplicación se configura para usar el endpoint 55199/readiness, y su tiempo mínimo de disponibilidad (minReadySeconds) se establece en 120 segundos, coincidiendo con la duración de calentamiento predeterminada.