Todos os produtos
Search
Central de documentação

Auto Scaling:Use lifecycle hooks para garantir a disponibilidade do service

Última atualização: Jul 20, 2026

Ao associar um grupo de dimensionamento a um Classic Load Balancer (CLB), Application Load Balancer (ALB) ou Network Load Balancer (NLB), as instâncias desse grupo são adicionadas automaticamente ao grupo de servidores de backend para atender às solicitações dos clientes. Use lifecycle hooks para pausar esse processo e obter tempo para executar ações personalizadas e assegurar alta disponibilidade.

Conceitos principais

A tabela a seguir descreve os conceitos fundamentais deste tópico.

Parâmetro

Descrição

Referências

balanceador de carga

Um balanceador de carga distribui o tráfego recebido entre vários servidores de backend para aumentar o throughput, eliminar pontos únicos de falha e melhorar a disponibilidade.

O Alibaba Cloud Server Load Balancer (SLB) oferece três tipos de balanceadores de carga: Classic Load Balancer (CLB), Application Load Balancer (ALB) e Network Load Balancer (NLB).

Introduction to the Server Load Balancer (SLB) family

lifecycle hook

Um lifecycle hook permite gerencie o ciclo de vida de instâncias ECS ou ECI em um grupo de dimensionamento.

Lifecycle hook overview

Procedimento

Os exemplos a seguir usam um grupo de dimensionamento associado a uma instância CLB para demonstrar como os lifecycle hooks afetam os services da aplicação durante eventos de scale-out e scale-in.

Nota

Antes de começar, verifique se o grupo de dimensionamento está associado a uma instância CLB ou a um grupo de servidores de backend ALB ou NLB. Para mais informações, consulte Add and remove load balancers for a scaling group.

Cenário 1: Scale-out

Comparação de impacto

A tabela a seguir compara o comportamento da aplicação durante um evento de scale-out com e sem lifecycle hook.

Condição

Descrição

Sem lifecycle hook

Durante um evento de scale-out, novas instâncias ECS ou ECI são adicionadas diretamente ao grupo de dimensionamento. Isso inclui a adição ao grupo de servidores de backend da instância CLB associada, e elas começam a servir tráfego imediatamente. No entanto, a aplicação na instância precisa de tempo para iniciar. Se a aplicação receber solicitações antes de estar pronta, as solicitações falharão.

Com lifecycle hook

Em um evento de scale-out, antes que uma instância ECS ou ECI seja adicionada ao grupo de servidores de backend da instância CLB, um lifecycle hook pausa a nova instância. Essa pausa permite que a aplicação inicie completamente. Após o término do período de timeout do lifecycle hook, a instância é adicionada automaticamente ao grupo de servidores de backend para servir tráfego.

Procedimento e considerações

Para usar um lifecycle hook, crie-o primeiro. Para mais informações, consulte Create a lifecycle hook.

Ao criar um lifecycle hook, configure os seguintes parâmetros:

  • Defina Scaling Activity como Scale-out Event.

  • Recomendamos definir o Timeout Period como o tempo necessário para a aplicação em uma instância ECS ou ECI iniciar normalmente. O valor deve ser um número inteiro em segundos, e o intervalo permitido é 30 ≤ Timeout Period ≤ 21600.

    Nota

    Para encerrar o período de timeout antecipadamente, chame a operação de API CompleteLifecycleAction.

  • Configure Default Execution Policy como Continue.

Após a criação do lifecycle hook, as novas instâncias de um evento de scale-out entram primeiro no estado Pending Add e aguardam a expiração do período de timeout. Durante esse estado pendente, a aplicação na instância pode concluir o processo de inicialização. Quando o estado pendente termina, a instância é adicionada ao grupo de dimensionamento e registrada no grupo de servidores de backend da instância CLB. A instância então transita para o estado In Service e começa a servir tráfego, o que garante a disponibilidade do service.

Cenário 2: Scale-in

Comparação de impacto

A tabela a seguir compara o comportamento da aplicação durante um evento de scale-in com e sem lifecycle hook.

Condição

Descrição

Sem lifecycle hook

Durante um evento de scale-in, as instâncias selecionadas para encerramento são removidas imediatamente do grupo de dimensionamento. Isso inclui a remoção do grupo de servidores de backend da instância CLB associada, e elas param de servir tráfego. Se a instância tiver solicitações de cliente não processadas, essas solicitações serão descartadas, resultando em erros no lado do cliente.

Com lifecycle hook

Em um evento de scale-in, após uma instância ECS ou ECI ser removida do grupo de servidores de backend da instância CLB associada, um lifecycle hook pausa a instância. Isso permite que a instância termine de processar quaisquer solicitações em andamento. Depois que o período de timeout do lifecycle hook termina, a instância é removida do grupo de dimensionamento. Esse processo evita interrupções no lado do cliente.

Procedimento e considerações

Crie um lifecycle hook para o grupo de dimensionamento para lidar adequadamente com eventos de scale-in. Para mais informações, consulte Create a lifecycle hook.

Ao criar um lifecycle hook, configure os seguintes parâmetros:

  • Defina Scaling Activity como Scale-in Event.

  • Recomendamos configurar o Timeout Period como o maior tempo de processamento entre todas as solicitações. O valor é medido em segundos e deve ser um número inteiro, sendo que 30 ≤ Timeout Period ≤ 21.600.

    Nota

    Para encerrar o período de timeout antecipadamente, chame a operação de API CompleteLifecycleAction. Para mais informações, consulte CompleteLifecycleAction.

Depois que o lifecycle hook é criado, as instâncias selecionadas para encerramento são primeiramente removidas do grupo de servidores de backend da instância CLB associada. Em seguida, elas entram no estado Pending Remove e aguardam a expiração do período de timeout. Durante esse estado pendente, as instâncias terminam de processar quaisquer solicitações em andamento, mas não aceitam novas. Após o fim do estado pendente, as instâncias são removidas do grupo de dimensionamento. Esse processo garante a disponibilidade do service.