Resumo

  • A RFC 10053 permite que o CATS escolha um ponto de contato do serviço, visível ao cliente, com base em informações de rede e de computação. Esse contato pode atender uma ou várias instâncias internas; portanto, sua seleção não identifica, por si só, qual instância processou a solicitação.
  • As métricas do contato podem agregar várias instâncias de serviço, e um agente de métricas também pode combinar vários contatos. A rota selecionada ou uma média aparentemente estável descreve a superfície de encaminhamento, não a execução de uma solicitação específica nem o resultado do serviço.

A porta de entrada aparece; o processamento interno, não

Imagine um pedido de renderização gráfica enviado a um identificador de serviço. O sistema compara dois locais: um oferece uma rota mais curta; o outro tem mais capacidade computacional disponível. Ele escolhe um contato alcançável e manda a solicitação para lá. Para o cliente, esse contato é a entrada do serviço. Pode processar a solicitação diretamente ou decidir qual instância interna fará o trabalho.

A RFC 10053 separa esses papéis de propósito. Uma instância de serviço é o conjunto de recursos em execução organizado segundo a lógica do provedor. O ponto de contato do serviço é uma função voltada ao cliente que recebe solicitações e pode atender uma ou várias instâncias. Também pode distribuir o trabalho internamente, como um balanceador. A RFC diz que o encaminhamento além desse contato fica oculto tanto para os clientes quanto para os componentes do CATS.

Isso limita o significado de “o CATS escolheu o serviço”. O CATS Path Selector, ou C-PS, usa dados compartilhados por agentes de métricas de serviço e de rede para escolher um CATS-Forwarder de saída e, possivelmente, um contato e uma rota. A escolha determina por onde a solicitação entra na estrutura do provedor. Ela não aponta automaticamente a instância interna que executa o processamento.

Toda métrica tem um escopo — e ele pode se ampliar

A RFC 10053 alerta que a seleção talvez não revele a instância que o cliente realmente invoca, inclusive em estruturas hierárquicas ou recursivas. Assim, as métricas do contato podem agregar dados de várias instâncias de serviço. A Seção 4.2 também permite que um CATS Service Metric Agent agregue métricas de vários contatos, mantenha cada uma separada ou faça as duas coisas. São pontos de agregação distintos: um pode resumir as condições de instâncias atrás de um contato; o outro pode reunir métricas de contatos antes de distribuí-las aos seletores.

Isso não quer dizer que uma métrica agregada seja falsa. Quer dizer que seu escopo precisa estar explícito. Uma média do contato pode ajudar a escolher uma entrada sem explicar as solicitações mais lentas, qual backend recebeu uma requisição específica ou qual foi o resultado. Uma métrica agregada por local pode facilitar a escala sem equivaler à medição de cada contato. A RFC deixa as escolhas de implantação a cargo do provedor e não define um algoritmo único de seleção.

O CATS Traffic Classifier pode manter os pacotes de uma solicitação no contato escolhido. A Seção 4.4 descreve a afinidade com a instância de contato: os pacotes de um fluxo ficam no mesmo contato e no mesmo caminho para reduzir reordenação e variações imprevisíveis de latência. É uma propriedade útil de encaminhamento, mas não torna transparente a distribuição interna. A estrutura não define um registro que associe cada decisão do CATS à instância backend e ao resultado da solicitação.

Pense em um contato que distribui lotes de análise geoespacial entre várias instâncias. Se uma delas ficar mais lenta após uma mudança de carga, a métrica agregada do contato ainda pode parecer aceitável. O CATS pode continuar escolhendo esse contato sem enxergar o desequilíbrio nem saber quais solicitações foram afetadas. Essa é uma consequência possível do limite de visibilidade descrito na RFC, não um incidente observado nem um resultado medido em determinado provedor.

A separação é intencional. A RFC 10053 afirma que o provedor mantém controle sobre recursos internos e lógica do serviço; a forma como ele estrutura o serviço está fora do escopo do CATS. O CATS combina condições de rede e computação para encaminhar tráfego, mas não especifica como inspecionar o agendador backend do provedor. A operadora de rede não deve inferir além dos sinais disponíveis; o provedor tampouco deve tratar um contato selecionado como prova do resultado de uma solicitação individual.

A RFC 10054 amplia o enunciado do problema e os requisitos do CATS. Aqui, a pergunta é mais delimitada: o que se sabe depois que o tráfego chega ao contato escolhido? A resposta depende dos registros e da telemetria que o provedor opte por expor à parte. As RFCs não exigem uma API universal de despacho backend, rastreamento por solicitação ou recibo de resultado. Uma implantação pode criar esses controles, mas é necessário verificar sua existência separadamente.

Sem evidência adicional, a trilha termina no contato

A distinção importa quando uma mudança de encaminhamento parece reduzir a latência, mas a equipe da aplicação observa resultados irregulares. A rota e o contato escolhido explicam para onde os pacotes foram enviados. Sem evidência do lado do provedor, não mostram qual instância interna tratou cada solicitação, se ela dependia de um componente degradado ou se a resposta cumpriu a meta do serviço.

Um relatório preciso pode dizer: “O CATS selecionou este contato com estas métricas e este escopo.” Para afirmar “este backend processou a solicitação com sucesso”, é preciso evidência do serviço. Para afirmar “o serviço melhorou”, é necessário medir resultados ligados à solicitação ou ao grupo relevante. São afirmações distintas, ainda que depois apareçam juntas em uma plataforma de observabilidade.

A RFC 10053 é uma estrutura arquitetural limitada a um único provedor de serviço. Ela não fixa o algoritmo de seleção nem o desenho interno do serviço. Serve para mostrar o limite do encaminhamento, não para prometer que o contato escolhido revelará cada decisão posterior.

Fontes e escopo