Aspire and Service Discovery

O Problema: A Fragilidade dos Endpoints "Hard-coded"

Imagine um cenário comum: você tem um serviço de frontend (uma Blazor Web App, por exemplo) que precisa consumir dados de uma API de backend. Em um desenvolvimento simples, a abordagem mais direta seria configurar a URL da API no arquivo appsettings.json do frontend:

{
  "WeatherApi": {
    "BaseAddress": "https://localhost:7123"
  }
}

Embora funcional para um protótipo local, essa abordagem se torna um grande obstáculo em ambientes do mundo real por várias razões:

• Portas Dinâmicas: Em ambientes de contêineres, as portas são frequentemente atribuídas dinamicamente. A porta 7123 na sua máquina pode ser diferente em outro ambiente ou mesmo em outra execução.
• Múltiplos Ambientes: Manter arquivos de configuração diferentes para desenvolvimento, teste, homologação e produção é complicado e propenso a erros.
• Escalabilidade: Se você escalar sua API para múltiplas instâncias, para qual delas o frontend deve apontar? É necessário um balanceador de carga, o que adiciona outra camada de endereço fixo para gerenciar.

O vídeo a seguir, de Milan Jovanović, introduz exatamente esse problema, mostrando como a comunicação entre serviços com URLs fixas funciona e por que ela não é flexível.

A solução para essa rigidez é um mecanismo dinâmico chamado Service Discovery. A ideia é simples: em vez de os serviços conhecerem os endereços físicos uns dos outros, eles se referem uns aos outros por um nome lógico (ex: users-api), e uma infraestrutura se encarrega de traduzir esse nome lógico para um endereço de rede real em tempo de execução.

A Solução do Aspire: Service Discovery via Orquestração

O .NET Aspire implementa o service discovery de uma maneira elegante, integrando-o diretamente ao seu modelo de orquestração no AppHost. Você não precisa de um "servidor de registro" externo como Consul ou Eureka para o desenvolvimento local; o próprio AppHost atua como a fonte da verdade.

O mecanismo se baseia em três conceitos principais:

1. Declaração de Dependência no AppHost: O AppHost define o grafo de dependências da sua aplicação.
2. Injeção de Configuração por Variáveis de Ambiente: O AppHost injeta os endereços reais dos serviços nas variáveis de ambiente dos serviços que os consomem.
3. Resolução no Cliente: Uma biblioteca no lado do cliente (incluída pelos ServiceDefaults) sabe como ler essas variáveis de ambiente e resolver os nomes lógicos para os endereços físicos.

1. Declarando a Dependência com WithReference()

O ponto de partida é o arquivo Program.cs do seu projeto AppHost. Quando um serviço precisa se comunicar com outro, você expressa essa dependência usando o método de extensão .WithReference().

Veja um exemplo:

// Program.cs do projeto .AppHost

var builder = DistributedApplication.CreateBuilder(args);

// 1. O serviço de backend (API) é definido e recebe um nome lógico: "products"
var productsApi = builder.AddProject<Projects.MyStore_ProductsApi>("products");

// 2. O serviço de frontend é definido e...
var frontend = builder.AddProject<Projects.MyStore_Store>("store")
    // 3. ...declaramos que ele tem uma referência para a API "products".
    .WithReference(productsApi);

builder.Build().Run();

Ao usar .WithReference(productsApi), você está dizendo ao Aspire: "O serviço store precisa conhecer o endereço do serviço products."

2. Consumindo o Serviço com um Nome Lógico

Agora, no código do serviço store (o consumidor), em vez de usar uma URL fixa, você configura seu HttpClient para usar um URI especial que combina o esquema (http ou https) com o nome lógico do serviço de destino.

// Program.cs do projeto 'store' (consumidor)

// Configura um HttpClient para se comunicar com a API
builder.Services.AddHttpClient<ProductsClient>(client =>
{
    // Usa um nome lógico, não um endereço físico!
    // "https+http" tenta HTTPS primeiro, depois fallback para HTTP.
    client.BaseAddress = new Uri("https+http://products");
});

A string "https+http://products" não é uma URL válida para a internet. É uma convenção que o mecanismo de service discovery do Aspire entende.

3. O Mecanismo por Baixo dos Panos: Variáveis de Ambiente

Aqui está a parte crucial, o "como funciona" que é tão importante para um entendimento profundo.

Quando o AppHost inicia, ele faz o seguinte:

1. Inicia o serviço productsApi, que recebe um endereço dinâmico, por exemplo, https://localhost:7123.
2. Ao iniciar o serviço store, por causa da chamada .WithReference(), o AppHost injeta variáveis de ambiente especiais no ambiente do store. Essas variáveis seguem um padrão:
   • services__products__https__0 = https://localhost:7123
   • services__products__http__0 = http://localhost:5123

Quando o HttpClient no serviço store tenta fazer uma requisição para https://products/api/items, o seguinte acontece:

1. Um HttpMessageHandler especial, adicionado pelo pacote Microsoft.Extensions.ServiceDiscovery (que faz parte dos ServiceDefaults), intercepta a requisição.
2. Ele reconhece que products é um nome de serviço lógico.
3. Ele consulta as variáveis de ambiente em busca de services__products__....
4. Ele encontra o endereço real (ex: https://localhost:7123) e substitui https://products por ele, enviando a requisição para https://localhost:7123/api/items.

O vídeo a seguir, de James Montemagno, demonstra exatamente esse fluxo. Ele adiciona uma referência e depois inspeciona o Aspire Dashboard para mostrar as variáveis de ambiente que foram injetadas.

Para reforçar o que você viu, este artigo do Telerik fornece uma excelente explicação textual do mesmo mecanismo.

Visualizando o Fluxo Completo

Vamos resumir o processo inteiro com um diagrama.

No Aspire Dashboard, você pode ver essa mágica acontecer. Ao inspecionar um serviço que consome outro, você encontrará as variáveis de ambiente que o Aspire injetou.

Conclusão

Nesta lição, você aprendeu como o .NET Aspire simplifica drasticamente a comunicação entre serviços. Ao abstrair os endereços de rede por trás de nomes lógicos, o Aspire cria aplicações mais robustas, portáteis e fáceis de manter.

Principais Pontos:

• Service Discovery resolve o problema de endpoints fixos em sistemas distribuídos, permitindo que os serviços se encontrem dinamicamente.
• O Aspire implementa um modelo de service discovery baseado em orquestração, onde o AppHost é a fonte da verdade para o ambiente de desenvolvimento.
• O método .WithReference() no AppHost é a chave para estabelecer uma dependência de comunicação entre dois serviços.
• O mecanismo subjacente depende da injeção de variáveis de ambiente (com o formato services__{nome-logico}__{protocolo}__{indice}) e de um HttpMessageHandler do lado do cliente que traduz nomes lógicos em endereços físicos.

Com este conhecimento, você está agora equipado para construir aplicações com múltiplos serviços que se comunicam de forma transparente, independentemente de estarem rodando na sua máquina local ou em um ambiente de nuvem complexo.

Próxima lição:
Agora que entendemos como os serviços se encontram, vamos aprofundar em como implementar essa comunicação de forma limpa e segura no código .NET. A próxima lição abordará como configurar e injetar HttpClients tipados para comunicação entre serviços usando os padrões de referência de serviço do Aspire, uma prática recomendada para um código mais manutenível e testável.