Os recursos de alta disponibilidade do MSE Microservices Registry ajudam a criar aplicações mais resilientes. Estas práticas recomendadas dividem-se por escopo: alta disponibilidade de instância, de descoberta de serviços e de gerenciamento de configurações. Este tópico usa a Professional Edition do MSE Microservices Registry como exemplo.
Versões recomendadas
spring-cloud-alibaba: 2.2.6.RELEASE ou superior.Dubbo: 2.7.12 ou superior.spring-boot: 2.3.x ou anterior. Não recomendamos as versões 2.4.x devido a problemas de compatibilidade.
Alta disponibilidade para instâncias do Microservices Registry
-
High-availability architecture
Nenhum serviço oferece 100% de disponibilidade. Para garantir alta confiabilidade e segurança dos dados, implante a instância com pelo menos três nós. Se um nó falhar, o tráfego será redirecionado para outro nó em segundos, e o sistema removerá automaticamente o nó com defeito do cluster.
A Professional Edition do Microservices Registry baseia-se na arquitetura Nacos 2.0. Esse design aprimora a recuperação de desastres e reduz a dependência da infraestrutura subjacente para garantir alta disponibilidade. Para obter mais informações, consulte Seleção de edição de instância.
-
Multi-zone deployment
Cada região do MSE contém várias zonas. Aplicações em zonas diferentes na mesma região apresentam baixa latência de rede (inferior a 3 ms) e se beneficiam do isolamento de falhas. Uma instância multizona implanta servidores físicos em zonas distintas. Caso ocorra uma falha na Zona A, o tráfego é rapidamente redirecionado para a Zona B. Esse processo é transparente e não exige alterações no código da aplicação. Basta configurar a quantidade de nós, e o MSE gerencia automaticamente a implantação em várias zonas.
Figura 1. Arquitetura ativa-ativa de três nós do MSE
Figura 2. Arquitetura de recuperação de desastres em vários níveis
Alta disponibilidade na descoberta de serviços
Na descoberta de serviços, consumers e providers possuem recursos distintos de alta disponibilidade: os consumers oferecem Push-through protection, enquanto os providers suportam disaster recovery.
Consumers
Um consumer assina uma lista de instâncias de provider no registro. Quando o registro passa por mudanças, como dimensionamento ou atualizações, ou enfrenta eventos inesperados, como interrupção de rede em toda a zona ou falha de energia, as assinaturas podem falhar e afetar a disponibilidade do consumer.
Configure a proteção contra lista vazia no lado do consumer para evitar que ele receba uma lista de instâncias vazia durante uma interrupção.
Sem proteção contra lista vazia: Se um consumer receber uma lista vazia, o serviço será interrompido e reportará um erro.
Com proteção contra lista vazia: Caso um consumer receba uma lista vazia, o mecanismo de proteção ativado descartará a atualização e ajudará a manter a disponibilidade do serviço.
Configuration
Este recurso tem suporte apenas no nacos-java-client 1.4.1 e versões posteriores. Para versões compatíveis do Spring Cloud e Dubbo, consulte Versões recomendadas.
-
Aplicações Spring Cloud
Adicione a seguinte propriedade à configuração:
spring.cloud.nacos.discovery.namingPushEmptyProtection=true -
Aplicações Dubbo
Adicione o seguinte parâmetro ao registry.url:
namingPushEmptyProtection=true
Persistent caching
Quando a proteção contra lista vazia está ativada, o diretório de cache pode ser perdido se o contêiner da aplicação for reiniciado. Para evitar isso, torne o diretório de cache persistente, por exemplo, montando um volume.
O diretório de cache está localizado em: ${user.home}/nacos/naming/${namespaceId}.
Providers
O recurso de recuperação de desastres para providers ajuda a prevenir falhas em cascata no cluster durante picos de tráfego.
Providers registrados com versões 2.x do nacos-java-client não têm suporte ao recurso de recuperação de desastres no lado do provider.
-
Without disaster recovery
Quando um aumento repentino nas solicitações dos consumers eleva a utilização dos providers, alguns deles podem falhar:
O registro remove o nó com falha e redireciona todo o tráfego dele para os nós restantes.
A carga nos nós de provider restantes aumenta, tornando-os mais propensos a falhar também.
Por fim, todos os nós de provider podem falhar e causar uma interrupção total do serviço.
-
With disaster recovery
Quando um aumento repentino nas solicitações dos consumers eleva a utilização dos providers, alguns deles podem falhar:
O registro marca o nó com falha como não íntegro.
Se a porcentagem de nós não íntegros exceder o limiar de proteção, a recuperação de desastres será ativada. O registro então retorna todos os nós registrados (íntegros e não íntegros) para os consumers.
Essa estratégia evita uma interrupção total do serviço ao distribuir o tráfego entre todos os nós registrados, mesmo que alguns não estejam íntegros.
Enable disaster recovery
-
Supported instance types
Instâncias persistentes: Suporte total.
-
Instâncias não persistentes:
nacos-java-client1.x: Por padrão, instâncias não íntegras são removidas após 30 segundos. Uma instância removida não entra no cálculo do limiar de proteção, o que impede a ativação da política de recuperação de desastres.nacos-java-client2.x: Sem suporte. As instâncias ficam offline imediatamente após a perda da conexão persistente; portanto, a política de recuperação de desastres não pode ser acionada.
-
Configure by using the command line
-
Atualize o limiar para um serviço específico
curl -X PUT "${nacos.address}/nacos/v1/ns/service?namespaceId=public&serviceName=my-provider&protectThreshold=0.6"${nacos.address}: Endereço do Microservices Registry.namespaceId: ID do namespace. Valor padrão: public.serviceName: Nome do serviço para uma aplicação Spring Cloud ou nome da interface para uma aplicação Dubbo.
-
Consulte a configuração do limiar
curl -X GET "${nacos.address}/nacos/v1/ns/service?namespaceId=public&serviceName=my-provider" -
Resposta
{"namespaceId":"public","groupName":"DEFAULT_GROUP","name":"my-provider","protectThreshold":0.7,"metadata":{},"selector":{"type":"none"},"clusters":[]}
-
Microservices Governance high availability configuration
Melhore ainda mais a disponibilidade da aplicação utilizando recursos do Microservices Governance, como inicialização e encerramento graceful, remoção de instâncias discrepantes e degradação de serviço.
Alta disponibilidade no gerenciamento de configurações
A alta disponibilidade do gerenciamento de configurações depende de dois aspectos principais: o cache no lado do cliente e os diretórios de backup, além dos recursos de limitação de taxa em várias camadas do centro de configurações.
As seguintes capacidades de alta disponibilidade para gerenciamento de configurações estão habilitadas por padrão na Professional Edition do Microservices Registry. Nenhuma ação é necessária.
-
Client
Cache directory: Sempre que o cliente recupera dados do centro de configurações, ele salva a configuração mais recente em um diretório de cache local. Se o servidor ficar indisponível, o cliente recorre a esse cache local.
Backup directory: Caso o servidor esteja indisponível, atualize manualmente os arquivos no diretório de backup local. O cliente prioriza o carregamento a partir deste diretório, simulando uma atualização de configuração enviada pelo servidor.
-
Configuration Center
Além da alta disponibilidade no nível de infraestrutura, o serviço do centro de configurações implementa limitação de taxa multidimensional para aumentar a estabilidade. Isso inclui limites para o máximo de conexões por nó e conexões por IP de cliente. Também abrange limitação de taxa para publicações de configurações por segundo e por minuto, oferecendo controle granular para configurações individuais. Essas medidas ajudam a mitigar o risco de tempo de inatividade do servidor causado por tráfego anormal.