O Realtime Compute for Apache Flink gerencia alterações de serviço e de versão do mecanismo por meio de duas políticas de ciclo de vida complementares:
Política de ciclo de vida do produto (PLP): rege a descontinuação de tipos de serviço (por exemplo, quando o Blink passou para o Realtime Compute for Apache Flink).
Política de ciclo de vida de runtime (RLP): rege o fim do suporte das versões do mecanismo Ververica Runtime (VVR).
Compreender essas políticas ajuda no planejamento de migrações antes que tipos de serviço ou versões do mecanismo atinjam o fim do suporte (EOS).
Escopo
A PLP e a RLP aplicam-se a todos os tipos de serviço e versões do Realtime Compute for Apache Flink. Para obter uma lista dos tipos de serviço e seus status de lançamento atuais, consulte Tipos de serviço.
Política de ciclo de vida do produto (PLP)
A PLP entra em vigor quando ocorre uma alteração significativa no serviço, como a atualização do Blink para o Realtime Compute for Apache Flink. O cronograma de cada fase da PLP não é fixo. Antes de iniciar a PLP, a equipe avalia a maturidade do novo tipo de serviço, a demanda de migração dos usuários, a fluidez do processo de migração e o impacto nos custos para os usuários.
Caso a PLP seja iniciada, os usuários recebem notificação com pelo menos quatro meses de antecedência por meio de comunicados, mensagens internas, e-mails ou mensagens de texto.
Fases de descontinuação
O diagrama a seguir ilustra o processo de descontinuação da PLP.
A tabela abaixo descreve cada fase e as ações permitidas durante esse período.
|
Fase |
Descrição |
Operações permitidas |
|
Do anúncio ao EOM |
Os usuários recebem notificação pelo menos quatro meses antes do fim da comercialização (EOM). |
Novas compras: não permitidoRenovações: permitidoCancelamento de assinatura: permitidoUpgrade ou downgrade de configuração: permitidoAtualizações temporárias: permitidoUpgrade ou downgrade de configuração durante renovação: permitidoNota: apenas modificações de configuração realizadas antes da fase EOFS são permitidas |
|
Do EOM ao EOFS |
O EOM possui duas subfases: EOM1 (novos pedidos de compra não aceitos) e EOM2 (novos pedidos de compra e dimensionamento não aceitos). Toda a fase EOM dura pelo menos quatro meses. |
Novas compras: não permitidoRenovações: não permitidoUpgrade ou downgrade de configuração: não permitidoCancelamento de assinatura: permitido |
|
Do EOFS ao EOS |
Fim do serviço completo (EOFS): nenhuma nova versão ou versão de correção é lançada; serviços de suporte (perguntas e respostas, resolução de problemas, compensação de SLA) deixam de ser fornecidos. |
Novas compras: não permitidoRenovações: não permitidoUpgrade ou downgrade de configuração: não permitidoCancelamento de assinatura: permitido |
|
EOS |
O tipo de serviço é descontinuado. Todos os serviços de suporte terminam. |
Nenhum serviço fornecido para este tipo de serviço |
Resumo das operações
A tabela a seguir indica quais operações estão disponíveis em cada fase da PLP.
|
Operação |
Do anúncio ao EOM |
Do EOM ao EOFS |
Do EOFS ao EOS |
EOS |
|
Novas compras |
Não permitido |
Não permitido |
Não permitido |
Não permitido |
|
Renovações |
Permitido |
Não permitido |
Não permitido |
Não permitido |
|
Cancelamento de assinatura |
Permitido |
Permitido |
Permitido |
— |
|
Upgrade ou downgrade de configuração |
Permitido |
Não permitido |
Não permitido |
Não permitido |
|
Atualizações temporárias |
Permitido |
— |
— |
— |
A tabela acima serve como referência rápida. Consulte a seção Fases de descontinuação para obter detalhes completos sobre cada fase.
Política de ciclo de vida de runtime (RLP)
A RLP rege o ciclo de vida das versões do mecanismo VVR, desde a disponibilidade geral (GA) até o EOS. O cronograma de cada fase da RLP não é fixo. Antes de iniciar a RLP, a equipe avalia a compatibilidade e a maturidade das novas versões, bem como a demanda dos usuários por atualizações.
Se a RLP for iniciada, os usuários receberão notificação com pelo menos três meses de antecedência por meio de comunicados, mensagens internas, e-mails ou mensagens de texto.
Regras principais
Versões de suporte de longo prazo (LTS): A última versão secundária de cada versão principal do VVR torna-se a versão LTS. Por exemplo, a versão LTS do VVR 6.x é a VVR 6.0.7. A Alibaba Cloud mantém exatamente duas versões LTS simultaneamente. Quando uma nova versão LTS é lançada, a versão LTS mais antiga atinge o EOS e não pode mais ser selecionada na criação de novos deployments.
Problemas críticos: Caso uma versão do VVR apresente falhas graves de segurança ou estabilidade, a Alibaba Cloud reduz a RLP para três meses e notifica os usuários afetados oportunamente via console ou comunicados.
Marcos da RLP
Marco | Descrição | Impacto nos deployments |
Disponibilidade geral (GA) | A versão é lançada oficialmente para uso em produção. | Deployments novos e não iniciados: podem selecionar qualquer versão do mecanismo que não esteja em EOS. |
EOS | O Realtime Compute for Apache Flink deixa de fornecer serviços ou suporte para esta versão. | Novos deployments: não podem selecionar esta versão. Importante Se uma versão secundária apresentar um defeito crítico que cause grandes perdas (como problemas de segurança ou imprecisão de dados), a equipe poderá retirar essa versão secundária e migrá-la para uma versão compatível. |
Notificações e suporte
Com base nas regras da política de ciclo de vida, a Alibaba Cloud compromete-se a:
Planejar o ciclo de vida de cada tipo de serviço e versão do mecanismo, fornecendo informações relevantes durante a consulta e o uso do serviço.
Notificar os usuários com pelo menos quatro meses de antecedência antes de cada marco da PLP (alterações no tipo de serviço).
Notificar os usuários com pelo menos três meses de antecedência antes de cada marco da RLP (alterações na versão do mecanismo).
Auxiliar os usuários na avaliação de riscos e fornecer soluções de migração antes que tipos de serviço ou versões do mecanismo atinjam o EOS.
As notificações são enviadas por meio de comunicados, mensagens internas, e-mails ou mensagens de texto.
Próximos passos
Para notas de lançamento das versões do mecanismo Apache Flink e histórico de atualizações da plataforma, consulte Notas de lançamento.
Para informações sobre o GeminiStateBackend e seu desempenho em comparação com o RocksDBStateBackend, consulte GeminiStateBackend.
Para atualizações de versão e avisos de atividades do produto, consulte Avisos de serviço do Realtime Compute for Apache Flink ou faça login no console do Realtime Compute for Apache Flink.