Esta página foi traduzida pela API Cloud Translation.

Balanceamento de carga nos servidores de back-end

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

O Apigee melhora a disponibilidade das suas APIs através do suporte incorporado para o equilíbrio de carga e a comutação por falha em várias instâncias de servidores de back-end.

Os servidores de destino desassociam os URLs de pontos finais concretos das configurações de pontos finais de destino. Em vez de definir um URL concreto na configuração, pode configurar um ou mais servidores de destino com nome. Em seguida, cada servidor de destino é referenciado pelo nome numa HTTPConnection de ponto final de destino.

Vídeos

Veja os seguintes vídeos para saber mais acerca do encaminhamento de APIs e do equilíbrio de carga através de servidores de destino

Vídeo	Descrição
Equilíbrio de carga através de servidores de destino	Equilibrar a carga das APIs entre os servidores de destino.
Encaminhamento de API com base no ambiente através de servidores de destino	Encaminhe uma API para um servidor de destino diferente com base no ambiente.

Acerca da configuração do servidor de destino

Uma configuração do servidor de destino consiste num nome, num anfitrião, num protocolo e numa porta, com um elemento adicional para indicar se o servidor de destino está ativado ou desativado. Um servidor de destino também pode ter um objeto <sSLInfo> opcional.

O código seguinte fornece um exemplo de uma configuração do servidor de destino:

{
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true"
}

Para mais informações sobre a API TargetServers, consulte organizations.environments.targetservers.

Consulte o esquema para TargetServer e outras entidades no GitHub.

Criar servidores de destino

Crie servidores de destino através da IU ou da API Apigee, conforme descrito nas secções seguintes.

Apigee na Cloud Console

Para criar servidores de destino através do Apigee na Cloud Console:

Na Google Cloud consola, aceda à página Gestão > Ambientes.

Aceder a Ambientes
Selecione o ambiente no qual quer definir um novo servidor de destino.
Clique em Servidores de destino na parte superior do painel.
Clique em + Criar servidor de destino.
Introduza um nome, um anfitrião, um protocolo e uma porta nos campos fornecidos. As opções para Protocolo são: HTTP para servidores de destino baseados em REST, gRPC - Destino para servidores de destino baseados em gRPC ou gRPC - Chamada externa. Consulte o artigo Criar proxies de API gRPC para ver informações sobre o suporte de proxies gRPC.
Opcionalmente, pode selecionar Ativar SSL. Consulte a vista geral dos certificados SSL.
Clique em Criar.

Apigee clássico

Para criar servidores de destino através da IU do Apigee clássico:

Inicie sessão na IU do Apigee.
Selecione Admin > Environments > TargetServers.
Na lista pendente Ambiente, selecione o ambiente para o qual quer definir um novo servidor de destino.
A IU do Apigee apresenta uma lista dos servidores de destino atuais no ambiente selecionado:
Clique em +Servidor de destino para adicionar um novo servidor de destino ao ambiente selecionado.
É apresentada a caixa de diálogo Adicionar servidor de destino:
Clique em Ativado para ativar o novo servidor de destino. definição imediatamente após a criar.
Introduza um nome, um anfitrião, um protocolo e uma porta nos campos fornecidos. As opções para Protocol são HTTP ou GRPC.

Opcionalmente, pode selecionar a caixa de verificação SSL. Para mais informações sobre estes campos, consulte TargetServers (vídeo 4MV4D).
Clique em Adicionar.
O Apigee cria a nova definição de servidor de destino.
Depois de criar um novo servidor de destino, pode editar o proxy da API e alterar o elemento <HTTPTargetConnection> para referenciar a nova definição.

API Apigee

As secções seguintes fornecem exemplos de utilização da API Apigee para criar e listar servidores de destino.

Criar um servidor de destino num ambiente através da API
Listar os servidores de destino num ambiente através da API

Para mais informações, consulte a API TargetServers.

Criar um servidor de destino num ambiente através da API

Para criar um servidor de destino denominado target1 que se liga a 1.mybackendservice.com na porta 80, use a seguinte chamada API:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Onde $TOKEN está definido como a sua chave de acesso OAuth 2.0, conforme descrito em Obter uma chave de acesso OAuth 2.0. Para informações sobre as opções de curl usadas neste exemplo, consulte a secção Usar o curl. Para uma descrição das variáveis de ambiente que pode usar, consulte o artigo Definir variáveis de ambiente para pedidos de API Apigee.

Segue-se um exemplo da resposta:

{
  "host" : "1.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Crie um segundo servidor de destino com a seguinte chamada da API. Ao definir dois servidores de destino, fornece dois URLs que um ponto final de destino pode usar para o equilíbrio de carga:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Segue-se um exemplo da resposta:

{
  "host" : "2.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Listar os servidores de destino num ambiente através da API

Para listar os servidores de destino num ambiente, use a seguinte chamada da API:

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

Segue-se um exemplo da resposta:

[ "target2", "target1" ]

Existem agora dois servidores de destino disponíveis para utilização por proxies de API implementados no ambiente test. Para equilibrar a carga do tráfego nestes servidores de destino, configure a ligação HTTP no ponto final de destino de um proxy de API para usar os servidores de destino.

Configurar um ponto final de destino para o balanceamento de carga em servidores de destino nomeados

Agora que tem dois servidores de destino disponíveis, pode modificar o elemento <HTTPTargetConnection> do ponto final de destino para fazer referência a esses dois servidores de destino pelo nome:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

A configuração acima é a configuração de balanceamento de carga mais básica. O balanceador de carga suporta três algoritmos de balanceamento de carga: RoundRobin, Weighted e LeastConnections. O Round Robin é o algoritmo predefinido. Uma vez que não é especificado nenhum algoritmo na configuração acima, os pedidos de saída do proxy de API para os servidores de back-end vão alternar, um a um, entre target1 e target2.

O elemento <Path> forma o caminho base do URI do ponto final de destino para todos os servidores de destino. Só é usado quando o <LoadBalancer> é usado. Caso contrário, é ignorado. No exemplo acima, um pedido que chegue a target1 será http://target1/test e assim sucessivamente para outros servidores de destino.

Para mais informações, consulte TargetEndpoint.

Configurar opções do balanceador de carga

Pode ajustar a disponibilidade configurando as opções de equilíbrio de carga e de comutação por falha ao nível do equilibrador de carga e do servidor de destino, conforme descrito nas secções seguintes.

Algoritmo

Define o algoritmo usado por <LoadBalancer>. Os algoritmos disponíveis são RoundRobin, Weighted e LeastConnections, cada um dos quais está documentado abaixo.

Ordem aleatória

O algoritmo predefinido, round robin, encaminha um pedido para cada servidor de destino pela ordem em que os servidores estão listados na ligação HTTP do ponto final de destino. Por exemplo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Ponderado

O algoritmo de equilíbrio de carga ponderado permite-lhe configurar cargas de tráfego proporcionais para os servidores de destino. O LoadBalancer ponderado distribui os pedidos aos servidores de destino em proporção direta à ponderação de cada servidor de destino. Por conseguinte, o algoritmo ponderado exige que defina um atributo weight para cada servidor de destino. Por exemplo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Neste exemplo, dois pedidos são encaminhados para target2 para cada pedido encaminhado para target1.

Menos ligações

Os balanceadores de carga configurados para usar o algoritmo de menor ligação encaminham os pedidos de saída para o servidor de destino com o menor número de ligações HTTP abertas. Por exemplo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Falhas máximas

O número máximo de pedidos com falhas do proxy de API para o servidor de destino que resulta no redirecionamento do pedido para outro servidor de destino.

Uma falha de resposta significa que o Apigee não recebe nenhuma resposta de um servidor de destino. Quando isto acontece, o contador de falhas é incrementado em um.

No entanto, quando o Apigee recebe uma resposta de um destino, mesmo que a resposta seja um erro HTTP (como 404 ou 500), isso conta como uma resposta do servidor de destino, e o contador de falhas é reposto. Para garantir que as respostas HTTP incorretas (como 500) também incrementam o contador de falhas para retirar um servidor não saudável da rotação do balanceamento de carga o mais rapidamente possível, pode adicionar o elemento <ServerUnhealthyResponse> com elementos filhos <ResponseCode> à configuração do balanceador de carga. O Apigee também contabiliza as respostas com esses códigos como falhas.

No exemplo seguinte, target1 vai ser removido da rotação após cinco pedidos com falhas, incluindo 404 e algumas respostas 5XX do servidor de destino.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>404</ResponseCode>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

O valor predefinido de MaxFailures é 0. Isto significa que o Apigee tenta sempre estabelecer ligação ao destino para cada pedido e nunca remove o servidor de destino da rotação.

É melhor usar MaxFailures > 0 com um monitor de estado. Se configurar MaxFailures > 0, o servidor de destino é removido da rotação quando o destino falha o número de vezes que indicar. Quando um monitor de saúde está em vigor, o Apigee coloca automaticamente o servidor de destino novamente em rotação depois de o destino estar novamente em funcionamento, de acordo com a configuração desse monitor de saúde. Consulte Monitorização do estado de funcionamento para mais informações.

Tenha em atenção que as chamadas de API normais e as chamadas iniciadas por um monitor de saúde contam para o número de falhas máximo.

Tenha também em atenção que a contagem de falhas de execução para cada servidor de destino é mantida com base no balanceador de carga. Por exemplo, suponhamos que um proxy tem dois pontos finais de destino e que cada um tem um equilibrador de carga, e que ambos os equilibradores de carga estão configurados para usar o mesmo conjunto de servidores de destino. Nesse caso, as falhas de um ponto final de destino só contam para o equilibrador de carga correspondente. Não afetam a rotação do outro ponto final de destino.

Em alternativa, se configurar MaxFailures > 0 e não configurar um monitor de estado, o Apigee retira automaticamente o servidor de destino da rotação quando é detetada a primeira falha. O Apigee verifica o estado do servidor de destino a cada cinco minutos e devolve-o à rotação quando responde normalmente.

Tentar novamente

Se a repetição estiver ativada, uma solicitação é repetida sempre que ocorre uma falha de resposta (erro de E/S ou tempo limite de HTTP) ou a resposta recebida corresponde a um valor definido por <ServerUnhealthyResponse>. Consulte a secção Falhas máximas acima para saber mais sobre a definição de <ServerUnhealthyResponse>.

Por predefinição, <RetryEnabled> está definido como true. Defina como false para desativar a repetição. Por exemplo:

<RetryEnabled>false</RetryEnabled>

IsFallback

Pode definir um (e apenas um) servidor de destino como o servidor alternativo. O balanceador de carga não usa o servidor alternativo até que todos os outros servidores de destino tenham sido removidos da rotação pelo balanceador de carga. Quando isto acontece, todo o tráfego é encaminhado para o servidor alternativo até que um dos outros servidores de destino volte a ser considerado em bom estado e seja devolvido à rotação. Por exemplo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

A configuração acima resulta no balanceamento de carga de round robin entre target1 e target2 até que target1 e target2 fiquem indisponíveis. Quando target1 e target2 estão indisponíveis, todo o tráfego é encaminhado para target3.

Se o servidor alternativo não estiver em bom estado, o Apigee não encaminha tráfego para o mesmo. Em alternativa, as chamadas da API devolvem um erro 503 "O serviço está temporariamente indisponível".

Caminho

O caminho define um fragmento de URI que vai ser anexado a todos os pedidos emitidos pelo servidor de destino para o servidor de back-end.

Este elemento aceita um caminho de string literal ou um modelo de mensagem. Um modelo de mensagem permite-lhe fazer a substituição de strings variáveis no tempo de execução. Por exemplo, na seguinte definição do ponto final de destino, o valor de {mypath} é usado para o caminho:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Configurar um servidor de destino para TLS/SSL

Se estiver a usar um servidor de destino para definir o serviço de back-end e o serviço de back-end requerer que a ligação use o protocolo HTTPS, tem de ativar o TLS/SSL na definição do servidor de destino. Isto é necessário porque a etiqueta host não lhe permite especificar o protocolo de ligação.

Nota: se definir o bloco sSLInfo no ponto final de destino e na definição do servidor de destino, o bloco na definição do servidor de destino tem precedência.

Configure o TLS/SSL unidirecional

Use a seguinte configuração para definir um servidor de destino com TLS/SSL unidirecional. Neste exemplo, o Apigee faz pedidos HTTPS ao serviço de back-end:

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

Configure a aplicação rigorosa do SSL

Para especificar a aplicação rigorosa de SSL na definição do servidor de destino, defina enforce como true no bloco sSLInfo, conforme mostrado no exemplo seguinte:

  {
    "name": "target1",
    "host": "mocktarget.apigee.net",
    "protocol": "http",
    "port": "443",
    "isEnabled": "true",
    "sSLInfo": {
      "enabled": "true",
      "enforce": "true"
    }
  }

Configure o TLS/SSL bidirecional

Se o serviço de back-end exigir TLS/SSL bidirecional ou mútuo, pode configurar o servidor de destino com as mesmas definições de configuração de TLS/SSL que os pontos finais de destino:

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

Configure o SSL rigoroso através da API

Para criar um servidor de destino com aplicação rigorosa de SSL através de uma chamada API:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "enforce":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

Monitorização da saúde

A monitorização do estado permite-lhe melhorar as configurações de equilíbrio de carga ao sondar ativamente os URLs do serviço de back-end definidos nas configurações do servidor de destino. Com a monitorização do estado ativada, os servidores de destino que estão inacessíveis ou devolvem uma resposta de erro são marcados como não íntegros. Um servidor de destino com falhas é automaticamente colocado novamente em rotação quando o monitor de estado determina que o servidor de destino está ativo. Não são necessários novos implementações de proxy.

Tem de definir <MaxFailures> como superior a 0 quando usar um monitor de saúde. Se o valor <MaxFailures> for definido como 0, o Apigee tenta sempre estabelecer ligação ao destino para cada pedido e não remove o servidor de destino da rotação.

Um monitor de estado funciona como um cliente simples que invoca um serviço de back-end através de TCP ou HTTP:

Um cliente TCP garante simplesmente que é possível abrir um socket.
Configura o cliente HTTP para enviar um pedido HTTP válido ao serviço de back-end. Pode definir operações HTTP GET, PUT, POST ou DELETE. A resposta da chamada do monitor HTTP tem de corresponder às definições configuradas no bloco <SuccessResponse>.

Êxitos e falhas

Quando ativa a monitorização do estado de funcionamento, o Apigee começa a enviar verificações de estado de funcionamento para o servidor de destino. Uma verificação de estado é um pedido enviado para o servidor de destino que determina se o servidor de destino está ou não em bom estado.

Uma verificação de funcionamento pode ter um de dois resultados possíveis:

Êxito: o servidor de destino é considerado em bom estado quando ocorre uma verificação de funcionamento bem-sucedida. Normalmente, isto é o resultado de um ou mais dos seguintes motivos:
- O servidor de destino aceita uma nova ligação à porta especificada, responde a um pedido nessa porta e, em seguida, fecha a porta dentro do prazo especificado. A resposta do servidor de destino contém Connection: close
- O servidor de destino responde a um pedido de verificação do estado com um código 200 (OK) ou outro código de estado HTTP que considere aceitável.
- O servidor de destino responde a um pedido de verificação do estado com um corpo da mensagem que corresponde ao corpo da mensagem esperado.
Quando o Apigee determina que um servidor está em bom estado, o Apigee continua ou retoma o envio de pedidos para o mesmo.
Falha: o servidor de destino pode falhar numa verificação de estado de várias formas, consoante o tipo de verificação. Pode ser registada uma falha quando o servidor de destino:
- Recusa uma ligação do Apigee à porta de verificação de funcionamento.
- Não responde a um pedido de verificação de estado dentro de um período especificado.
- Devolve um código de estado HTTP inesperado.
- Responde com um corpo da mensagem que não corresponde ao corpo da mensagem esperado.
Quando um servidor de destino falha numa verificação de estado, o Apigee incrementa a contagem de falhas desse servidor. Se o número de falhas para esse servidor atingir ou exceder um limite predefinido (<MaxFailures>), o Apigee deixa de enviar pedidos para esse servidor.

Ativar um monitor de saúde

Para criar um monitor de estado de funcionamento para um proxy de API, adicione o elemento <HealthMonitor> ao elemento <HTTPTargetConnection do ponto final de destino para o proxy.

Não é possível criar monitorizações de saúde na IU. Em alternativa, crie uma configuração de proxy e carregue-a como um ficheiro ZIP para o Apigee. Uma configuração de proxy é uma descrição estruturada de todos os aspetos de um proxy de API. As configurações de proxy consistem em ficheiros XML numa estrutura de diretórios predefinida. Para mais informações, consulte a referência de configuração do proxy de API.

`<HealthMonitor>` elementos de configuração

A tabela seguinte descreve os elementos de configuração <HealthMonitor>:

Nome	Descrição	Predefinição	Obrigatório?
`IsEnabled`	Um valor booleano que ativa ou desativa o monitor de estado de funcionamento.	falso	Não
`IntervalInSec`	O intervalo de tempo, em segundos, entre cada pedido de sondagem TCP ou HTTP.	0	Sim
`HTTPMonitor` ou `TCPMonitor`	Uma definição do cliente TCP ou HTTP a usar para sondar o servidor de destino.	N/A	Sim

Além destes elementos, a ativação de um monitor de estado requer que defina o elemento <MaxFailures> no bloco <HTTPTargetConnection> do elemento <TargetEndpoint> para um valor superior a 0. <MaxFailures> é usado para especificar o número máximo de pedidos com falhas do proxy de API para o servidor de destino que podem ocorrer antes de o pedido ser redirecionado para outro servidor de destino.

Por predefinição, <MaxFailures> é 0, o que significa que o Apigee não executa nenhuma ação corretiva. Quando configurar um monitor de estado, certifique-se de que define <MaxFailures> para um valor diferente de zero.

Monitorização da saúde através da monitorização TCP

O monitor de estado de funcionamento de exemplo descrito na configuração seguinte usa um monitor TCP para sondar cada servidor de destino abrindo uma ligação na porta 80 a cada cinco segundos. (A porta é opcional. Se não for especificado, a porta de monitorização TCP é a porta do servidor de destino.)

Nesta configuração de monitor de saúde de exemplo:

Se a ligação falhar ou demorar mais de 10 segundos a estabelecer ligação, a contagem de falhas aumenta 1 para esse servidor de destino.
Se a ligação for bem-sucedida, a contagem de falhas do servidor de destino é reposta para 0.

Pode adicionar um monitor de estado como um elemento secundário do elemento <HTTPTargetConnection> do ponto final de destino, conforme mostrado abaixo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

`<TCPMonitor>` elementos de configuração

A tabela seguinte descreve os elementos de configuração <TCPMonitor>:

Nome	Descrição	Predefinição	Obrigatório?
`ConnectTimeoutInSec`	Tempo em que a ligação à porta TCP tem de ser estabelecida para ser considerada um sucesso. A falha na ligação no intervalo especificado conta como uma falha, incrementando a contagem de falhas do balanceador de carga para o servidor de destino.	0	Sim
`Port`	Opcional. A porta na qual a ligação TCP vai ser estabelecida. Se não for especificado, a porta de monitorização TCP é a porta do servidor de destino.	0	Não

Monitorização da saúde através da monitorização HTTP

O monitor de estado de funcionamento de exemplo descrito na configuração seguinte usa um monitor HTTP que envia um pedido GET para o serviço de back-end uma vez a cada cinco segundos e adiciona um cabeçalho de autorização básica HTTP à mensagem de pedido.

Nesta configuração de monitor de saúde de exemplo:

A resposta esperada do serviço de back-end é um código de resposta HTTP 200.
O valor esperado para o cabeçalho de autorização básica HTTP personalizado ImOK é YourOK.
O elemento <UseTargetServerSSLInfo> está definido como true para usar os parâmetros SSL do bloco <SSLInfo> do servidor de destino.

Com esta configuração, os códigos de resposta e os valores dos cabeçalhos esperados são comparados com as respostas reais do serviço de back-end. Se a resposta não corresponder, o pedido é tratado como uma falha pela configuração do balanceador de carga.

Por predefinição, os monitorizadores de saúde não podem aceder a keystores, truststores ou outros parâmetros SSL dos respetivos servidores de destino. Para ativar o acesso a estes parâmetros para o seu monitor de saúde de forma a suportar o TLS mútuo, por exemplo, adicione <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> no bloco <Request>.

    <TargetEndpoint name="default">
      <HTTPTargetConnection>
        <LoadBalancer>
          <Algorithm>RoundRobin</Algorithm>
          <Server name="target1" />
          <Server name="target2" />
          <MaxFailures>5</MaxFailures>
        </LoadBalancer>
        <Path>/test</Path>
        <HealthMonitor>
          <IsEnabled>true</IsEnabled>
          <IntervalInSec>5</IntervalInSec>
          <HTTPMonitor>
            <Request>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
              <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
              <Port>80</Port>
              <Verb>GET</Verb>
              <Path>/healthcheck</Path>
              <Header name="Authorization">Basic 12e98yfw87etf</Header>
              <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
            </Request>
            <SuccessResponse>
              <ResponseCode>200</ResponseCode>
              <Header name="ImOK">YourOK</Header>
            </SuccessResponse>
          </HTTPMonitor>
        </HealthMonitor>
      </HTTPTargetConnection>
    </TargetEndpoint>

`<HTTPMonitor>` elementos de configuração

A tabela seguinte descreve os <HTTPMonitor>elementos de configuração de nível superior:

Nome	Descrição	Predefinição	Obrigatório?
`Request`	A mensagem de pedido de saída enviada pelo monitor de estado para os servidores de destino na rotação.	N/A	Sim
`SuccessResponse`	(Opcional) Opções de correspondência para a mensagem de resposta HTTP de entrada gerada pelo serviço de back-end sondado.	N/A	Não

Elementos de configuração <HTTPMonitor>/<Request>

Opções de configuração para a mensagem de pedido de saída enviada pelo monitor de estado para os servidores de destino na rotação. Tenha em atenção que <Request> é um elemento obrigatório.

Nome	Descrição	Predefinição	Obrigatório?
`ConnectTimeoutInSec`	Tempo, em segundos, em que a confirmação de ligação TCP ao serviço HTTP tem de ser concluída para ser considerada um êxito. A falha na ligação no intervalo especificado conta como uma falha, incrementando a contagem de falhas do LoadBalancer para o servidor de destino. Nota: se o valor especificado for 0, o Apigee usa um limite de tempo predefinido de 30 segundos.	0	Não
`SocketReadTimeoutInSec`	Tempo, em segundos, durante o qual os dados têm de ser lidos do serviço HTTP para serem considerados um êxito. A falha na leitura no intervalo especificado é contabilizada como uma falha, incrementando a contagem de falhas do LoadBalancer para o servidor de destino. Nota: se o valor especificado for 0, o Apigee usa um limite de tempo predefinido de 30 segundos.	0	Não
`Port`	A porta na qual a ligação HTTP ao serviço de back-end vai ser estabelecida.	Porta do servidor de destino	Não
`Verb`	O verbo HTTP usado para cada pedido HTTP de sondagem ao serviço de back-end.	N/A	Não
`Path`	O caminho anexado ao URL definido no servidor de destino. Use o elemento `Path` para configurar um "ponto final de sondagem" no seu serviço HTTP. Tenha em atenção que o elemento `Path` não suporta variáveis.	N/A	Não
`UseTargetServerSSLInfo`	Quando `UseTargetServerSSLInfo` é verdadeiro, os pedidos de monitorização do estado de funcionamento para um servidor de destino usam os parâmetros SSL do bloco SSLInfo ("sSLInfo") do servidor de destino. Caso contrário, os parâmetros SSL, como o protocolo, o keystore, o truststore, etc., não vão estar disponíveis para o monitor de estado.	falso	Não
`IncludeHealthCheckIdHeader`	Permite-lhe monitorizar os pedidos de verificação de estado nos sistemas a montante. O elemento `IncludeHealthCheckIdHeader` aceita um valor booleano e tem como predefinição `false`. Se o definir como `true`, existe um `Header` denominado `X-Apigee-Healthcheck-Id` que é injetado no pedido de verificação de estado. O valor do cabeçalho é atribuído dinamicamente e assume o formato `ORG/ENV/SERVER_UUID/N`, em que `ORG` é o nome da organização, `ENV` é o nome do ambiente, `SERVER_UUID` é um ID exclusivo que identifica o MP e `N` é o número de milissegundos decorridos desde 1 de janeiro de 1970. Exemplo do cabeçalho do pedido resultante: `X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123`	falso	Não
`Payload`	O corpo HTTP gerado para cada pedido HTTP de sondagem. Tenha em atenção que este elemento não é obrigatório para pedidos `GET`.	N/A	Não
`Header`	Um ou mais cabeçalhos e valores HTTP esperados para serem recebidos do serviço de back-end consultado. Todos os cabeçalhos ou valores HTTP na resposta que sejam diferentes dos especificados resultam numa falha, e a contagem do servidor de destino sondado é incrementada em 1. Pode definir vários elementos Header.	N/A	Não
`IsSSL`	Quando é verdadeiro, especifica que o pedido de monitorização do estado deve ser enviado através de HTTPS.	Falso	Não
`TrustAllSSL`	Especifica se a verificação do monitor HTTP confia automaticamente em todos os certificados SSL.	Falso	Não

Elementos de configuração <HTTPMonitor>/<SuccessResponse>

(Opcional) Opções de correspondência para a mensagem de resposta HTTP de entrada gerada pelo serviço de back-end consultado. As respostas que não correspondem incrementam a contagem de falhas em 1.

Nome	Descrição	Predefinição	Obrigatório?
`ResponseCode`	O código de resposta HTTP esperado para ser recebido do servidor de destino consultado. Um código diferente do código especificado resulta numa falha e no incremento da contagem para o serviço de back-end sondado. Pode definir vários elementos ResponseCode.	N/A	Não
`Header`	Um ou mais cabeçalhos e valores HTTP esperados para serem recebidos do serviço de back-end consultado. Todos os cabeçalhos ou valores HTTP na resposta que sejam diferentes dos especificados resultam numa falha, e a contagem do servidor de destino sondado é incrementada em 1. Pode definir vários elementos Header.	N/A	Não

Balanceamento de carga nos servidores de back-end Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Vídeos

Acerca da configuração do servidor de destino

Criar servidores de destino

Apigee na Cloud Console

Apigee clássico

API Apigee

Criar um servidor de destino num ambiente através da API

Listar os servidores de destino num ambiente através da API

Configurar um ponto final de destino para o balanceamento de carga em servidores de destino nomeados

Configurar opções do balanceador de carga

Algoritmo

Ordem aleatória

Ponderado

Menos ligações

Falhas máximas

Tentar novamente

IsFallback

Caminho

Configurar um servidor de destino para TLS/SSL

Configure o TLS/SSL unidirecional

Configure a aplicação rigorosa do SSL

Configure o TLS/SSL bidirecional

Configure o SSL rigoroso através da API

Monitorização da saúde

Êxitos e falhas

Ativar um monitor de saúde

<HealthMonitor> elementos de configuração

Monitorização da saúde através da monitorização TCP

<TCPMonitor> elementos de configuração

Monitorização da saúde através da monitorização HTTP

<HTTPMonitor> elementos de configuração

Elementos de configuração <HTTPMonitor>/<Request>

Elementos de configuração <HTTPMonitor>/<SuccessResponse>

Balanceamento de carga nos servidores de back-end

`<HealthMonitor>` elementos de configuração

`<TCPMonitor>` elementos de configuração

`<HTTPMonitor>` elementos de configuração