Realtime Compute for Apache Flink gestiona los cambios en el servicio y en las versiones del motor mediante dos políticas de ciclo de vida complementarias:
Política de ciclo de vida del producto (PLP): rige la descontinuación de tipos de servicio (por ejemplo, cuando Blink pasó a ser Realtime Compute for Apache Flink).
Política de ciclo de vida del entorno de ejecución (RLP): rige el fin de servicio de las versiones del motor Ververica Runtime (VVR).
Comprender estas políticas le permite planificar migraciones antes de que los tipos de servicio o las versiones del motor lleguen al fin de servicio (EOS).
Alcance
La PLP y la RLP aplican a todos los tipos de servicio y versiones de Realtime Compute for Apache Flink. Para consultar la lista de tipos de servicio y su estado de versión actual, consulte Service types.
Política de ciclo de vida del producto (PLP)
La PLP se aplica cuando ocurre un cambio importante en el servicio; por ejemplo, cuando Blink se actualizó a Realtime Compute for Apache Flink. El cronograma de cada fase de la PLP no es fijo. Antes de iniciar la PLP, el equipo evalúa la madurez del nuevo tipo de servicio, la demanda de migración de los usuarios, la fluidez del proceso de migración y el impacto en costos para los usuarios.
Si se inicia la PLP, se notifica a los usuarios con como mínimo cuatro meses de anticipación mediante anuncios, mensajes internos, correos electrónicos o mensajes de texto.
Fases de descontinuación
El siguiente diagrama muestra el proceso de descontinuación de la PLP.
La siguiente tabla describe cada fase y las acciones disponibles durante la misma.
|
Phase |
Description |
Allowed operations |
|
Del anuncio al EOM |
Se notifica a los usuarios con como mínimo cuatro meses de anticipación al fin de comercialización (EOM). |
Nuevas compras: no permitidas Renovaciones: permitidas Cancelación de suscripción: permitida Actualización o reducción de configuración: permitida Actualizaciones temporales: permitidas Actualización o reducción de configuración durante la renovación: permitida Nota: solo se permiten modificaciones de configuración realizadas antes de la fase EOFS |
|
Del EOM al EOFS |
El EOM tiene dos subfases: EOM1 (no se aceptan nuevos pedidos de compra) y EOM2 (no se aceptan nuevos pedidos de compra ni de escalado). La fase completa de EOM dura como mínimo cuatro meses. |
Nuevas compras: no permitidas Renovaciones: no permitidas Actualización o reducción de configuración: no permitida Cancelación de suscripción: permitida |
|
Del EOFS al EOS |
Fin de servicio completo (EOFS): no se publican nuevas versiones ni parches; dejan de proporcionarse servicios compatibles (preguntas y respuestas, resolución de problemas, compensación por SLA). |
Nuevas compras: no permitidas Renovaciones: no permitidas Actualización o reducción de configuración: no permitida Cancelación de suscripción: permitida |
|
EOS |
El tipo de servicio se descontinúa. Finalizan todos los servicios compatibles. |
No se proporcionan servicios para este tipo de servicio |
Resumen de operaciones
La siguiente tabla muestra las operaciones disponibles en cada fase de la PLP.
|
Operation |
Announcement to EOM |
EOM to EOFS |
EOFS to EOS |
EOS |
|
Nuevas compras |
No permitido |
No permitido |
No permitido |
No permitido |
|
Renovaciones |
Permitido |
No permitido |
No permitido |
No permitido |
|
Cancelación de suscripción |
Permitido |
Permitido |
Permitido |
— |
|
Actualización o reducción de configuración |
Permitido |
No permitido |
No permitido |
No permitido |
|
Actualizaciones temporales |
Permitido |
— |
— |
— |
La tabla anterior es una referencia rápida. Consulte la sección Fases de descontinuación para obtener todos los detalles de cada fase.
Política de ciclo de vida del entorno de ejecución (RLP)
La RLP rige el ciclo de vida de las versiones del motor VVR, desde la disponibilidad general (GA) hasta el EOS. El cronograma de cada fase de la RLP no es fijo. Antes de iniciar la RLP, el equipo evalúa la compatibilidad y madurez de las nuevas versiones, así como la demanda de los usuarios para actualizarlas.
Si se inicia la RLP, se notifica a los usuarios con como mínimo tres meses de anticipación mediante anuncios, mensajes internos, correos electrónicos o mensajes de texto.
Reglas clave
Versiones compatibles a largo plazo (LTS): La última versión menor de cada versión principal de VVR se convierte en la versión LTS. Por ejemplo, la versión LTS de VVR 6.x es VVR 6.0.7. Alibaba Cloud mantiene exactamente dos versiones LTS simultáneamente. Cuando se publica una nueva versión LTS, la versión LTS más antigua llega al EOS y ya no se puede seleccionar al crear nuevos despliegues.
Problemas críticos: Si una versión de VVR presenta problemas críticos de seguridad o estabilidad, Alibaba Cloud reduce la RLP a tres meses y notifica oportunamente a los usuarios afectados mediante la consola o anuncios.
Hitos de la RLP
Hito | Descripción | Impacto en los despliegues |
Disponibilidad general (GA) | La versión se publica oficialmente para uso en producción. | Despliegues nuevos y no iniciados: pueden seleccionar cualquier versión del motor que no esté en EOS. |
EOS | Realtime Compute for Apache Flink deja de proporcionar servicios y soporte para esta versión. | Nuevos despliegues: no pueden seleccionar esta versión. Importante Si una versión menor tiene un defecto crítico que causa pérdidas importantes (como problemas de seguridad o de precisión de datos), el equipo puede retirar dicha versión menor y migrarla a una versión compatible. |
Notificaciones y soporte
De acuerdo con las reglas de la política de ciclo de vida, Alibaba Cloud se compromete a:
Planificar el ciclo de vida de cada tipo de servicio y versión del motor, y proporcionar información relevante durante la consulta y el uso del servicio.
Notificar a los usuarios con como mínimo cuatro meses de anticipación a cada hito de la PLP (cambios en el tipo de servicio).
Notificar a los usuarios con como mínimo tres meses de anticipación a cada hito de la RLP (cambios en la versión del motor).
Ayudar a los usuarios a evaluar riesgos y proporcionar soluciones de migración antes de que los tipos de servicio o las versiones del motor lleguen al EOS.
Las notificaciones se envían mediante anuncios, mensajes internos, correos electrónicos o mensajes de texto.
Pasos siguientes
Para consultar las notas de la versión del motor Apache Flink y el historial de actualizaciones de la plataforma, consulte Notas de la versión.
Para obtener información sobre GeminiStateBackend y su rendimiento en comparación con RocksDBStateBackend, consulte GeminiStateBackend.
Para consultar actualizaciones de versiones y avisos de actividad del producto, consulte Avisos de servicio de Realtime Compute for Apache Flink o inicie sesión en la consola de Realtime Compute for Apache Flink.