How to configure intra-zone provider first in MSE - Microservices Engine: Central de Documentação do Alibaba Cloud

O recurso Intra-zone Provider First do Microservices Engine (MSE) é uma política de balanceamento de carga que identifica dinamicamente as zonas onde residem consumidores e provedores de service e roteia preferencialmente as requisições para os nós de service na mesma zona. Em comparação com o algoritmo tradicional round-robin, essa política reduz a transferência de tráfego entre zonas, diminui a latência de rede, melhora a velocidade de resposta do service e aumenta a capacidade de recuperação de desastres do sistema. Este tópico descreve como configure o recurso Intra-zone Provider First no MSE.

Funcionamento

Ao ative o recurso Intra-zone Provider First para um aplicativo, os aplicativos consumidores chamam preferencialmente as instâncias em sua própria zona. Por exemplo, se você ative o recurso para o Aplicativo P, os Aplicativos C1, C2 e C3 chamarão preferencialmente as instâncias do Aplicativo P em suas próprias zonas.

Atualmente, o recurso Intra-zone Provider First do MSE entra em vigor apenas para um único aplicativo provedor. Ou seja, após ative o recurso para um aplicativo, todos os consumidores desse aplicativo chamam preferencialmente as instâncias em suas próprias zonas ao chamar o aplicativo.

A figura a seguir mostra o modelo de chamada de aplicativo quando as chamadas Intra-zone Provider First não estão ativadas no MSE.

A figura a seguir mostra o modelo de chamada de aplicativo quando as chamadas Intra-zone Provider First estão ativadas no MSE.

Benefícios

O recurso Intra-zone Provider First é uma política de agendamento de tráfego para arquiteturas de microsserviços. Em uma arquitetura multizona, as chamadas intrazona oferecem os seguintes benefícios:

Menor latência do sistema — Chamadas entre zonas tornam-se chamadas intrazona, o que reduz o RT de todo o sistema.
Domínio de falha reduzido — As chamadas de microsserviços ficam confinadas à mesma zona. Se uma única zona falhar, o impacto limita-se a essa zona.

Termos

Zona — Área física dentro de uma região que possui fontes de alimentação e redes independentes. Uma região contém várias zonas. A latência de rede entre instâncias na mesma zona é menor do que a latência entre zonas diferentes.
Consumidores e provedores — Em cenários de microsserviços, quem inicia uma chamada é o consumidor do service, e quem fornece o service é o provedor. Na maioria dos casos, um aplicativo atua simultaneamente como provedor e consumidor.
RT — Tempo de ida e volta de uma requisição. O RT representa o tempo total desde o envio da requisição pelo cliente até o recebimento da resposta do servidor.
Instância — Conceito equivalente ao de nó no uso coloquial. Em cenários Kubernetes, um pod sob uma carga de trabalho de aplicativo é uma instância de aplicativo. Em cenários Elastic Compute Service (ecs), um único processo de aplicativo em uma instância ecs é uma instância de aplicativo.

Limiar de segurança

Após ative o recurso Intra-zone Provider First para um aplicativo, todos os consumidores chamam os provedores em suas próprias zonas. Nem todo aplicativo é implantado de forma estritamente uniforme entre as zonas. Um aplicativo pode ter muito poucos nós provedores em uma zona, e esses nós podem não suportar o tráfego enviado pelos consumidores dessa zona.

Por exemplo, suponha que os números de instâncias do seu aplicativo implantadas nas Zonas A, B e C sejam 3, 3 e 1. Se o recurso Intra-zone Provider First estiver ativado e o número de consumidores em cada zona for equilibrado, cada zona receberá um terço do tráfego. No entanto, a Zona C tem apenas uma instância. Essa instância precisará lidar com três vezes mais tráfego do que cada instância nas outras zonas, o que pode gerar riscos de estabilidade.

Para evitar que consumidores em uma zona como a Zona C chamem preferencialmente o aplicativo em sua própria zona, o recurso Intra-zone Provider First do MSE oferece uma configuração de limiar de segurança. Quando as chamadas Intra-zone Provider First estão ativadas para um aplicativo e a porcentagem de instâncias que o aplicativo implanta em uma zona é inferior ao limiar de segurança, os consumidores nessa zona não usam a política Intra-zone Provider First ao chamar o aplicativo. Em vez disso, as chamadas retornam à política padrão aleatória ou round-robin do framework de microsserviços.

Por exemplo, suponha que os números de instâncias do seu aplicativo implantadas nas Zonas A, B e C sejam 2, 2 e 1, representando 40%, 40% e 20% de todas as instâncias. Se você ative o recurso Intra-zone Provider First para o aplicativo e defina o limiar de segurança como 30%, os consumidores na Zona C não farão chamadas com prioridade intrazona, enquanto os consumidores nas Zonas A e B farão chamadas com prioridade intrazona conforme esperado.

Quando usar este recurso

O recurso Intra-zone Provider First destina-se principalmente a chamadas entre aplicativos implantados em várias zonas. O recurso suporta serviços Dubbo e Spring cloud. Kubernetes Services ainda não são suportados.

O uso do recurso Intra-zone Provider First é opcional. Ative-o quando desejar reduzir a latência geral das requisições do sistema e melhorar ainda mais sua disponibilidade global.

Aplicativos implantados uniformemente entre zonas — Use o recurso Intra-zone Provider First.
Aplicativos não implantados de forma estritamente uniforme entre zonas — Utilize o recurso Intra-zone Provider First, mas avalie e configure um limiar de segurança que impeça o tráfego do consumidor de atingir zonas com poucas instâncias. Para obter instruções, consulte Configure a security threshold.

Pré-requisitos

O MSE Microservices Governance deve estar ativado. Para obter instruções, consulte Activate Microservices Governance.
O aplicativo alvo e seus aplicativos consumidores devem estar conectados ao MSE Microservices Governance. Para obter instruções, consulte Enable Microservices Governance for Java microservice applications in an ACK or ACS cluster e Connect an ecs microservice to Microservices Governance.
O ambiente onde você implanta recursos deve conter várias zonas, e seus aplicativos devem estar implantados nessas zonas.
Se você usar a Professional Edition ou se seu namespace for um namespace Professional Edition, não será possível visualize a distribuição de instâncias e tráfego entre zonas. Para caminhos de upgrade, consulte Node and traffic distribution across zones.

Implantar seus aplicativos entre zonas

Caso utilize o Alibaba Cloud Container Service for Kubernetes (ACK) para gerencie e implantar seus aplicativos, certifique-se de que a configuração de rede do seu pool de nós contenha vSwitches em várias zonas. Essa configuração permite que suas cargas de trabalho sejam executadas em nós de zonas diferentes. Implante seus aplicativos em várias zonas adicionando uma restrição de distribuição de topologia à sua carga de trabalho em spec > template > spec, conforme mostrado no exemplo a seguir. Para obter informações sobre como configure uma carga de trabalho para implantação entre zonas, consulte Recommended high availability architecture configurations for clusters.
```
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway
```
Se o seu aplicativo estiver implantado em instâncias Alibaba Cloud ecs, selecione vSwitches em zonas diferentes para as instâncias ecs durante a crie delas. Em seguida, ao implantar o aplicativo, distribua manualmente as instâncias do aplicativo entre essas instâncias ecs.

Configure um limiar de segurança

O limiar de segurança determina se os consumidores em uma zona fazem chamadas com prioridade intrazona para um aplicativo. Para obter mais informações sobre como o limiar é avaliado, consulte Security threshold.

Antes de defina um valor, visualize a porcentagem de instâncias de cada zona na visualização Overall Data na aba Intra-zone Provider First. Esses dados estão disponíveis mesmo quando o recurso Intra-zone Provider First não está ativado para o aplicativo. Em seguida, configure o limiar de segurança com base na implantação atual dos seus aplicativos de negócios. O objetivo principal é proteger as instâncias em zonas com poucas instâncias contra sobrecarga de tráfego. Utilize os dois cenários a seguir como referência.

Cenário 1 (comum): o aplicativo está implantado uniformemente entre zonas. Nenhuma zona tem significativamente menos instâncias. Defina o limiar de segurança com um valor inferior à porcentagem média de instâncias de uma única zona, que corresponde ao inverso do número de zonas. Por exemplo, um aplicativo tem 2, 2 e 2 instâncias implantadas nas Zonas A, B e C. As instâncias em cada zona representam 33,33% de todas as instâncias, então você pode defina o limiar de segurança como 33%.

Cenário 2: o aplicativo não está implantado uniformemente entre zonas. Considere o número real de instâncias na zona que possui menos instâncias. Por exemplo, um aplicativo tem 2, 2 e 1 instâncias implantadas nas Zonas A, B e C. Como a Zona C tem menos instâncias, você deseja que os consumidores na Zona C não façam chamadas com prioridade intrazona. Nesse caso, defina o limiar de segurança como 30%. As instâncias nas Zonas A e B representam 40% de todas as instâncias cada, portanto, as chamadas com prioridade intrazona se aplicam. As instâncias na Zona C representam 20%, logo, as chamadas retornam à política de chamada padrão aleatória ou round-robin.

O limiar de segurança padrão é 20%. Esse valor é bastante baixo e destina-se principalmente a verificações e testes em ambientes de teste. Defina um valor apropriado com base na forma como seu aplicativo está atualmente implantado entre as zonas.

Procedimento

Antes de ative o recurso Intra-zone Provider First para um aplicativo, defina um security threshold adequado para o aplicativo.

Faça login no MSE console e selecione uma região na barra de navegação superior.
No painel de navegação à esquerda, escolha Microservices Governance > Application Governance. Na página exibida, clique em no cartão de recurso do aplicativo que você deseja gerencie.
No painel de navegação à esquerda, clique em em Traffic management.
Na parte superior da página, clique em na aba Intra-zone Provider First.
Clique em em {key, select, RAM {RAM} Overview {Overview} Identities {Identities} Users {Users} Groups {Groups} Roles {Roles} Settings {Settings} Permissions {Permissions} Grants {Grants} Troubleshoot {Troubleshooting} Policies {Policies} Integrations {Integrations} Providers {SSO} Applications {OAuth (Preview)} CloudSSO {CloudSSO} AccessAnalyzing {Access Analysis} Analyzers {Analyzers} Findings {Findings} Beta {Beta} Governance {Cloud Governance} AgentControl {Agent Management} other {{key}} } ao lado de Configuration Information. TODO: confirme the UI label of the edite entry next to Configuration Information. The managed conref key ramnext-console-aliyun-com/nav_menu inherited from the source appears to point at the RAM (Resource Access Management) console navigation menu rather than an MSE edite control; needs product-side confirmation.
Altere Enable Status para Enabled, insira o Security Threshold e clique em em OK. TODO: valid input format and value range of Security Threshold are not available in the source

Após clique em em OK, a configuração entra em vigor sem necessidade de reiniciar qualquer aplicativo. Quando um consumidor do aplicativo iniciar uma chamada para o aplicativo, o consumidor selecionará automática e preferencialmente uma instância na mesma zona.

Para confirme o resultado, execute as seguintes verificações:

Verifique se a seção Configuration Information exibe os valores de Enable Status e Security Threshold configurados.
Na visualização Overall Data na aba Intra-zone Provider First, compare a porcentagem de tráfego de cada zona com a porcentagem de instâncias dessa zona. Para detalhes sobre as visualizações e métricas disponíveis, consulte Node and traffic distribution across zones.

Para parar de usar o recurso Intra-zone Provider First para o aplicativo, altere Enable Status na mesma seção Configuration Information.

Observações de uso

Equilíbrio de implantação — Idealmente, aplicativos provedores e consumidores devem ser implantados de forma equilibrada. Nenhum aplicativo deve ter um número muito alto de instâncias em zonas específicas. Caso contrário, as cargas de tráfego podem ficar severamente desequilibradas após a ativação do recurso Intra-zone Provider First.
Lançamentos de service — Ao lançar um service, especialmente durante uma atualização contínua no Kubernetes, o número de instâncias em cada zona pode mudar em um curto período. Algumas zonas podem então apresentar uma porcentagem de instâncias que não atende ao limiar de segurança, resultando em chamadas entre zonas por um breve período.
Escopo de isolamento — Utilize o recurso Intra-zone Provider First apenas para isolamento no nível de tráfego, não para isolamento no nível de negócios. Ao usar esse recurso, certifique-se de que chamadas entre zonas sejam toleráveis.
Canary release ponta a ponta — Quando o limiar de segurança entra em vigor, o sistema calcula se as instâncias disponíveis em uma zona representam uma porcentagem do número total de nós que atende ao limiar de segurança. O número de instâncias disponíveis e o número total de instâncias são contados a partir das instâncias que permanecem após a filtragem do canary release ponta a ponta. Na maioria dos casos, um sistema de negócios usa canary release ponta a ponta apenas quando uma versão de negócios é lançada, portanto, você pode ignorar este item. Se o seu sistema usar canary release ponta a ponta para filtragem de rotas rotineiras, ou seja, fora das janelas de lançamento, preste atenção a este item.

Por exemplo, um aplicativo tem 2, 2 e 1 nós implantados nas Zonas A, B e C, sendo que um dos dois nós na Zona A e um dos dois nós na Zona B são nós canary. Para um aplicativo consumidor que usa a versão oficial na Zona A, os números efetivos de nós nas Zonas A, B e C são 1, 1 e 1, de modo que cada zona representa 33,33% dos nós efetivos. Se o limiar de segurança estiver definido como 35%, o recurso Intra-zone Provider First não entrará em vigor nas Zonas A e B para consumidores que usam a versão oficial. Para um consumidor que usa a versão canary na Zona A, os números efetivos de nós nas Zonas A, B e C são 1, 1 e 0, e o recurso Intra-zone Provider First entra em vigor para consumidores canary.

Observabilidade de tráfego no nível de zona

Distribuição de nós e tráfego entre zonas

O recurso Intra-zone Provider First oferece um grau de observabilidade. Após conectar seu aplicativo ao MSE Microservices Governance, você pode visualize a distribuição de implantação de instâncias do aplicativo e o tráfego que cada zona transporta na aba Intra-zone Provider First. Esses dados estão disponíveis independentemente de o recurso Intra-zone Provider First estar ativado ou não para o aplicativo.

A aba Intra-zone Provider First contém as seguintes seções:

Configuration Information — Exibe Enable Status e Security Threshold.
Visualização Overall Data — Mostra a porcentagem de instâncias, a porcentagem de tráfego, o número total de requisições, o RT, a taxa de sucesso e os gráficos de tendência correspondentes para cada zona.
Visualização Availability Zone — Mostra o número de requisições, o RT e a taxa de sucesso para cada zona.

Quando o recurso Intra-zone Provider First não está ativado, o tráfego é distribuído uniformemente entre as zonas.

Se você usar a Professional Edition ou se seu namespace for um namespace Professional Edition, não será possível visualize esses dados.

Para fazer upgrade de um namespace Professional Edition para um namespace Enterprise Edition, consulte Microservice namespace management.

Verificações de implantação e tráfego

Na página de observação do recurso Intra-zone Provider First, a seção Overall Data mostra o número de instâncias que o aplicativo implanta em cada zona. Se um aplicativo estiver implantado de forma severamente desigual entre as zonas, o gráfico refletirá isso. Implante seus aplicativos entre zonas para melhorar a disponibilidade geral do seu sistema.

Além disso, após ative o recurso Intra-zone Provider First para seu aplicativo, verifique se o tráfego em alguma zona está excessivamente alto ou baixo e se o tráfego que cada zona transporta corresponde ao número de nós implantados nessa zona. Por exemplo, uma zona pode ter muitos nós mas transportar pouco tráfego, ou ter poucos nós mas transportar uma grande quantidade de tráfego. Nesses casos, ajuste o limiar de segurança para evitar riscos de estabilidade causados por distribuição desequilibrada de tráfego.

Exemplo de comparação de RT

Se o recurso Intra-zone Provider First não estiver ativado, as chamadas de microsserviços usam a política padrão aleatória ou round-robin, o que resulta em muitas invocações de service entre zonas. No exemplo descrito nesta seção, o recurso não está ativado para o aplicativo, e o RT médio geral nos últimos 5 minutos é de 7,88 ms.

Após ative o recurso Intra-zone Provider First para todos os aplicativos ao longo de toda a cadeia de chamadas, o RT médio geral do aplicativo muda para 6,85 ms.

Depois que o recurso é ativado, o tráfego é distribuído uniformemente entre cinco zonas (cn-hangzhou-k, cn-hangzhou-j, cn-hangzhou-i, cn-hangzhou-h e cn-hangzhou-g), e cada zona transporta aproximadamente 20% do tráfego. A taxa geral de sucesso das requisições é de 100,00%, e o limiar de segurança está definido como 10,00%.