Realtime Compute for Apache Flink gère les modifications de service et les changements de version du moteur grâce à deux politiques de cycle de vie complémentaires :
Politique de cycle de vie des produits (PLP) : régit l'arrêt des types de service (par exemple, lors de la transition de Blink vers Realtime Compute for Apache Flink)
Politique de cycle de vie de l'exécution (RLP) : régit la fin de prise en charge des versions du moteur Ververica Runtime (VVR)
Comprendre ces politiques vous aide à planifier les migrations avant que les types de service ou les versions du moteur n'atteignent la fin de prise en charge (EOS).
Périmètre
Les politiques PLP et RLP s'appliquent à tous les types de service et à toutes les versions de Realtime Compute for Apache Flink. Pour obtenir la liste des types de service et leur statut de publication actuel, consultez la rubrique Types de service.
Politique de cycle de vie des produits (PLP)
La politique PLP s'applique lorsqu'une modification majeure du service survient, par exemple lors de la mise à jour de Blink vers Realtime Compute for Apache Flink. Le calendrier de chaque phase de la PLP n'est pas fixe. Avant de lancer la PLP, l'équipe évalue la maturité du nouveau type de service, la demande de migration des utilisateurs, la fluidité du processus de migration et l'impact financier sur les utilisateurs.
Si la PLP est lancée, les utilisateurs sont notifiés au moins quatre mois à l'avance via des annonces, des messages internes, des e-mails ou des SMS.
Phases d'arrêt
Le schéma suivant illustre le processus d'arrêt de la PLP.
Le tableau ci-dessous décrit chaque phase et les actions possibles durant celle-ci.
|
Phase |
Description |
Opérations autorisées |
|
De l'annonce à la fin de commercialisation (EOM) |
Les utilisateurs sont notifiés au moins quatre mois avant la fin de commercialisation (EOM). |
Nouveaux achats : non autorisés |
|
De la EOM à la fin du service complet (EOFS) |
La phase EOM comprend deux sous-phases : EOM1 (les nouvelles commandes d'achat ne sont pas acceptées) et EOM2 (les nouvelles commandes d'achat et de mise à l'échelle ne sont pas acceptées). La phase EOM entière dure au moins quatre mois. |
Nouveaux achats : non autorisés |
|
De la EOFS à la fin de prise en charge (EOS) |
Fin du service complet (EOFS) : aucune nouvelle version ni version correctrice n'est publiée ; les services de support (questions-réponses, résolution des problèmes, compensation SLA) ne sont plus fournis. |
Nouveaux achats : non autorisés |
|
EOS |
Le type de service est arrêté. Tous les services de support prennent fin. |
Aucun service fourni pour ce type de service |
Résumé des opérations
Le tableau ci-dessous indique les opérations disponibles à chaque phase de la PLP.
|
Opération |
De l'annonce à la EOM |
De la EOM à la EOFS |
De la EOFS à la EOS |
EOS |
|
Nouveaux achats |
Non autorisés |
Non autorisés |
Non autorisés |
Non autorisés |
|
Renouvellements |
Autorisés |
Non autorisés |
Non autorisés |
Non autorisés |
|
Désabonnement |
Autorisé |
Autorisé |
Autorisé |
— |
|
Mise à niveau ou rétrogradation de la configuration |
Autorisée |
Non autorisée |
Non autorisée |
Non autorisée |
|
Mises à jour temporaires |
Autorisées |
— |
— |
— |
Le tableau ci-dessus sert de référence rapide. Consultez la section Phases d'arrêt pour obtenir tous les détails sur chaque phase.
Politique de cycle de vie de l'exécution (RLP)
La politique RLP gère le cycle de vie des versions du moteur VVR, de la disponibilité générale (GA) à la fin de prise en charge (EOS). Le calendrier de chaque phase de la RLP n'est pas fixe. Avant de lancer la RLP, l'équipe évalue la compatibilité et la maturité des nouvelles versions ainsi que la demande des utilisateurs concernant les mises à jour de version.
Si la RLP est lancée, les utilisateurs sont notifiés au moins trois mois à l'avance via des annonces, des messages internes, des e-mails ou des SMS.
Règles clés
Versions avec support à long terme (LTS) : La dernière version mineure de chaque version majeure de VVR devient la version LTS. Par exemple, la version LTS de VVR 6.x est la VVR 6.0.7. Alibaba Cloud maintient exactement deux versions LTS simultanément. Lorsqu'une nouvelle version LTS est publiée, la version LTS la plus ancienne atteint la fin de prise en charge (EOS) et ne peut plus être sélectionnée lors de la création de nouveaux déploiements.
Problèmes critiques : Si une version VVR présente des problèmes de sécurité ou de stabilité critiques, Alibaba Cloud réduit la durée de la RLP à trois mois et notifie les utilisateurs concernés en temps utile via la console ou des annonces.
Jalons de la RLP
Jalon | Description | Impact sur les déploiements |
Disponibilité générale (GA) | La version est officiellement publiée pour une utilisation en production. | Nouveaux déploiements et déploiements non démarrés : peuvent sélectionner n'importe quelle version du moteur dont la prise en charge n'a pas pris fin. |
EOS | Realtime Compute for Apache Flink ne fournit plus de services ni de support pour cette version. | Nouveaux déploiements : impossible de sélectionner cette version. Important Si une version mineure présente un défaut critique entraînant des pertes majeures (telles que des problèmes de sécurité ou des erreurs d'exactitude des données), l'équipe peut retirer cette version mineure et effectuer une migration vers une version compatible. |
Notifications et support
Conformément aux règles des politiques de cycle de vie, Alibaba Cloud s'engage à :
Planifier le cycle de vie de chaque type de service et version du moteur, et fournir les informations pertinentes lors de la consultation et de l'utilisation du service
Notifier les utilisateurs au moins quatre mois avant chaque jalon de la PLP (modifications des types de service)
Notifier les utilisateurs au moins trois mois avant chaque jalon de la RLP (modifications des versions du moteur)
Aider les utilisateurs à évaluer les risques et fournir des solutions de migration avant que les types de service ou les versions du moteur n'atteignent la fin de prise en charge (EOS)
Les notifications sont envoyées via des annonces, des messages internes, des e-mails ou des SMS.
Étapes suivantes
Pour consulter les notes de version du moteur Apache Flink et l'historique des mises à niveau de la plateforme, voir les Notes de version.
Pour plus d'informations sur GeminiStateBackend et ses performances par rapport à RocksDBStateBackend, consultez GeminiStateBackend.
Pour les mises à jour de version et les avis d'activité produit, consultez les Avis de service de Realtime Compute for Apache Flink ou connectez-vous à la console Realtime Compute for Apache Flink.