Implantações, dimensionamentos e reinicializações são operações rotineiras para qualquer aplicação online. O recurso de inicialização elegante do Microservices Engine (MSE) protege as aplicações durante cada etapa da inicialização por meio de três capacidades: registro atrasado de service, aquecimento com baixo tráfego e sonda de prontidão de service.
Visão geral do recurso
Registro atrasado
Uma instância provedora de microsserviço se registra em um registry durante a inicialização da aplicação. Após a conclusão do registro, as aplicações consumidoras podem assinar e chamar o provedor. Em aplicações Java desenvolvidas com o framework Spring, o registro geralmente ocorre após a atualização do contexto do Spring. Se a aplicação possuir tarefas de inicialização assíncronas ainda não concluídas, o registro imediato pode causar erros nas requisições. Por exemplo, uma aplicação MaxCompute pode precisar baixar várias centenas de megabytes de dados do Object Storage Service (OSS) antes de atender requisições. Caso se registre logo após a inicialização, o tráfego recebido falhará porque os recursos não estarão prontos. O recurso de registro atrasado de service permite definir um período de atraso que posterga o registro do service, garantindo a inicialização completa da aplicação antes do recebimento de tráfego.
Aquecimento com baixo tráfego
Uma instância recém-iniciada frequentemente se encontra em "estado frio", no qual precisa carregar pools de conexões sob demanda, pré-aquecer caches e executar a compilação just-in-time (JIT) de códigos críticos. Sua capacidade de processamento de requisições é muito inferior à de uma instância em execução prolongada. No pior cenário, o service pode travar, resultando em grande quantidade de timeouts e erros de requisição.
O exemplo a seguir ilustra a diferença no tempo de resposta entre duas requisições para uma mesma instância: uma feita antes do carregamento completo dos recursos e outra depois. Se muitas requisições chegarem enquanto a instância ainda estiver carregando recursos, todas poderão ser bloqueadas.
[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() #50O aquecimento com baixo tráfego controla o fluxo das aplicações consumidoras para uma nova instância de service no momento da inicialização. Isso evita a degradação de desempenho típica de cold-start e protege a instância contra picos repentinos de tráfego. O volume de requisições aumenta gradualmente até atingir a duração do aquecimento configurada; após esse período, a instância passa a receber tráfego normalmente.
O aquecimento com baixo tráfego utiliza o tráfego proveniente de consumidores online. Isso exige que os consumidores do service também estejam conectados ao MSE Microservices Governance. Para mais detalhes sobre o funcionamento desse recurso, consulte How low-traffic warm-up works.
Sonda de prontidão de service
O Kubernetes oferece um mecanismo de sonda de prontidão. Durante uma implantação, assim que uma nova instância passa na sonda de prontidão, a instância antiga é encerrada (o comportamento exato depende da estratégia de implantação). Contudo, o Kubernetes considera a aplicação pronta assim que uma porta está aberta, sem conseguir determinar quando um microsserviço realmente terminou sua inicialização. Isso pode levar o Kubernetes a marcar o service como pronto antes que ele se registre no registry e, em seguida, encerrar a instância antiga, causando erros de service no provider/instance para os consumidores.
A sonda de prontidão de service fornece um endpoint HTTP não intrusivo por meio de um agente, que verifica se a aplicação concluiu o registro. Ela retorna um código de status 500 enquanto o registro está incompleto e 200 após o sucesso do registro. Ao configurar a sonda de prontidão do Kubernetes para usar esse endpoint, você garante que os consumidores sempre tenham um provedor disponível durante as implantações, prevenindo erros de "no provider".
Como usar a inicialização elegante
Pré-requisitos
Observações de uso
Atualmente, a inicialização elegante é suportada apenas para instâncias que utilizam um registry de microsserviços (como o Nacos) para descoberta de serviços. Não há suporte para instâncias de microsserviços que dependem de Kubernetes Services para descoberta.
No caso de aplicações Spring Cloud, o aquecimento com baixo tráfego só é compatível com aplicações que usam Nacos, ZooKeeper ou Eureka como registry.
A implementação do aquecimento com baixo tráfego para Spring Cloud baseia-se nos balanceadores de carga padrão do Spring Cloud:
ZoneAwareLoadBalancer,RoundRobinLoadBalancerouRandomLoadBalancer. Se você modificar a configuração do balanceador de carga da sua aplicação, esse recurso não funcionará.Para que o aquecimento com baixo tráfego funcione, tanto as aplicações provedoras quanto as consumidoras devem estar conectadas ao MSE Microservices Governance. Esse recurso não se aplica a aplicações como gateways que recebem tráfego externo diretamente por meio de APIs expostas.
Procedimento
Etapa 1: Ativar a inicialização elegante
Faça login no console do MSE e selecione uma região na barra de navegação superior.
No painel de navegação à esquerda, escolha . Na página exibida, clique em no cartão de recursos da aplicação que deseja gerenciar.
Na página de detalhes da aplicação, clique em Traffic management no painel de navegação à esquerda e clique em na aba Graceful Start/Shutdown.
Na seção Configuration Information, clique em Edite, ative o toggle Graceful Start e clique em OK.
Etapa 2: Configure a sonda de prontidão do Kubernetes
Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
-
Na página Clusters, clique em no cluster desejado. No painel de navegação à esquerda, escolha Workload > Stateless. Localize sua aplicação implantada e clique em Edit na coluna Actions. Na seção Health Check, clique em Enable ao lado de Readiness e configure os parâmetros abaixo. Ao finalizar, clique em Update.
Path: /readiness. (Se sua aplicação utilizar uma versão do agente anterior a 4.1.10, defina o caminho como /health. Para verificar a versão do agente, acesse o console do MSE. Acesse Microservices Governance > Application Governance, clique em na sua aplicação e selecione Node details. A versão do agente será exibida à direita.)
Port:
55199.Initial Delay (s): Recomendamos definir este valor como maior que a soma do tempo de inicialização da aplicação com a duração do registro atrasado configurada (o padrão é 0s). No entanto, o recurso continua funcionando corretamente mesmo que você não siga essa recomendação.
Para informações sobre outros parâmetros, consulte Crie a stateless workload (Deployment). Após a reinicialização da aplicação, a sonda de prontidão só terá sucesso depois que o registro do service for concluído.
Esta operação reiniciará sua aplicação imediatamente. Em ambientes de produção, execute este procedimento durante uma janela de manutenção programada.
(Opcional) Configure a duração do registro atrasado
Esta configuração é opcional e pode ser ajustada conforme suas necessidades de negócio. Para mais detalhes, consulte delayed service registration. Siga estas etapas:
Siga a Etapa 1 e a Etapa 2 para acessar a página de inicialização elegante, ativar o recurso e configure a sonda de prontidão de service do Kubernetes.
Modifique as Configuration Information de Graceful Start and Shutdown. Clique em na seta à esquerda do módulo Graceful Start para expandir suas configurações. No campo Delayed Registration Duration (s), insira um valor e clique em OK.
A duração configurada para o registro atrasado entrará em vigor na próxima inicialização da aplicação.
(Opcional) Ajustar a duração do aquecimento com baixo tráfego
Ao ativar a inicialização elegante, esse recurso é habilitado automaticamente com uma duração padrão de aquecimento de 120 segundos. Você pode ajustar essa duração conforme suas necessidades de negócio:
Siga a Etapa 1 e a Etapa 2 para acessar a página de inicialização elegante, ativar o recurso e configure a sonda de prontidão de service do Kubernetes.
Modifique as Configuration Information de Graceful Start and Shutdown. Clique em na seta à esquerda do módulo Graceful Start para expandir suas configurações. Clique em Advanced Options. No campo Low-traffic Warm-up Duration (s), insira um valor e clique em OK.
Caso o consumidor do service em aquecimento seja um gateway nativo da cloud do MSE, o aquecimento com baixo tráfego configurado aqui não terá efeito. Em vez disso, configure os parâmetros de aquecimento no próprio gateway nativo da cloud do MSE. No console do gateway, clique em na instância desejada. No painel de navegação à esquerda, escolha Routes > Services. Localize o service e, na coluna Actions, clique em More > Policies. Na aba Policies, em Traffic Management > Load Balancing Configuration, clique em Edite e ajuste a configuração de Warm-up Time. Observe que a curva padrão de QPS de aquecimento do gateway é linear, diferindo levemente da curva quadrática fornecida pelo MSE Microservices Governance, mas o efeito prático é semelhante.
A duração ajustada do aquecimento com baixo tráfego entrará em vigor na próxima inicialização da aplicação.
O recurso de aquecimento com baixo tráfego atua no lado do consumidor, calculando pesos para cada instância provedora com base em seus horários de inicialização. Em seguida, utiliza um algoritmo de balanceamento de carga para aumentar gradualmente o tráfego destinado à aplicação recém-iniciada. Esse processo ajuda a aquecer o service. Isso também requer que o consumidor do service esteja conectado ao MSE Microservices Governance.
Ao utilizar o recurso de aquecimento com baixo tráfego pela primeira vez, recomendamos usar a duração padrão de aquecimento. Se você observar que o aquecimento é ineficaz ou causa perda de tráfego, otimize o processo ajustando esse parâmetro.
Para garantir um aquecimento adequado, consulte Best practices for low-traffic warm-up.
Monitorando a inicialização elegante
Após aplicar essas configurações, você poderá visualizar os horários de inicialização e desligamento das instâncias, juntamente com a curva de QPS, na página Graceful Start and Shutdown na próxima vez que sua aplicação for iniciada.
Faça login no console do MSE e selecione uma região na barra de navegação superior.
No painel de navegação à esquerda, escolha . Na página exibida, clique em no cartão de recursos da aplicação que deseja gerenciar.
Na página de detalhes da aplicação, clique em Traffic management no painel de navegação à esquerda e clique em na aba Graceful Start/Shutdown.
-
Na subaba Start and Shutdown Overview, clique em uma instância à esquerda. À direita, você poderá visualizar as alterações de QPS e os eventos relacionados ocorridos durante a fase de inicialização.
Você verá eventos como registro de service, início do aquecimento e fim do aquecimento ocorrerem em sequência. O evento 'Kubernetes readiness probe passed' também ocorre após o evento de 'registro de service'. A curva de QPS aumenta gradualmente até seu valor máximo durante a duração do aquecimento (padrão de 120s), em vez de apresentar um pico repentino. Se a sequência de eventos ou o formato da curva de QPS não corresponderem às suas expectativas durante a inicialização, consulte FAQ para solução de problemas.
No exemplo mostrado na figura, a sonda de prontidão do Kubernetes da aplicação está configurada para usar o endpoint 55199/readiness, e seu tempo mínimo de prontidão (minReadySeconds) está definido como 120 segundos, correspondendo à duração padrão do aquecimento.