Service Mesh para microservicios C#: cómo sobrevivir en el zoológico de .NET

¿Sus microservicios .NET están fuera de control? Conozca — Service Mesh

Imagine: tiene cinco, diez, o quizás cincuenta microservicios C#. Se comunican entre sí a través de HTTP, gRPC o RabbitMQ. Todo funciona... hasta que deja de hacerlo. Timeouts, reintentos, circuit breakers, balanceo de carga, autenticación entre servicios — cada desarrollador escribe lo mismo desde cero. ¿Le suena familiar?

Esto se llama el «problema del zoológico de microservicios» — cuando la lógica de negocio se ahoga en código de infraestructura. Y aquí entra en escena Service Mesh — un patrón arquitectónico que saca toda la cocina de red fuera de su código C#. En este artículo, analizaremos cómo domar Service Mesh en el mundo .NET, escribiremos código real y entenderemos si vale la pena.

¿Qué es Service Mesh en palabras simples (para un desarrollador C#)

Service Mesh es una capa de infraestructura dedicada para gestionar la comunicación entre servicios. Imagine que cada uno de sus microservicios C# recibe un «asistente invisible» — un proxy sidecar (generalmente Envoy o Linkerd-proxy). Este proxy intercepta todo el tráfico entrante y saliente del servicio y hace todo el trabajo sucio por usted:

\n
• Descubrimiento de servicios — adiós a las URL hardcodeadas.
\n
• Balanceo de carga — distribución inteligente de solicitudes.
\n
• Reintentos y timeouts — intentos automáticos ante fallos.
\n
• Circuit Breaker — protección contra fallos en cascada.
\n
• Cifrado mTLS — seguridad "lista para usar".
\n
• Observabilidad (Observability) — métricas, trazabilidad, logs.
\n

La principal ventaja para C#: su código se mantiene limpio. Usted escribe solo la lógica de negocio, y toda la magia de red la asume Service Mesh. Las implementaciones más populares: Istio (pesado, pero potente) y Linkerd (ligero, rápido, escrito en Rust).

Escribiendo un microservicio C# listo para Service Mesh

Para entender la magia, creemos un microservicio .NET simple en C# y preparémoslo para trabajar con Service Mesh. Usaremos gRPC — el protocolo ideal para la comunicación interna de microservicios.

Paso 1: Creamos un servicio gRPC en C#

Abra la terminal y ejecute:

dotnet new grpc -n OrderService\ncd OrderService

Añadamos un archivo proto simple Protos/orders.proto:

syntax = "proto3";\n\nservice OrderGrpc {\n  rpc GetOrder (OrderRequest) returns (OrderResponse);\n}\n\nmessage OrderRequest {\n  string order_id = 1;\n}\n\nmessage OrderResponse {\n  string order_id = 1;\n  string status = 2;\n  double total = 3;\n}

Implementamos el servicio en Services/OrderService.cs:

public class OrderService : OrderGrpc.OrderGrpcBase\n{\n    private readonly ILogger<OrderService> _logger;\n\n    public OrderService(ILogger<OrderService> logger)\n    {\n        _logger = logger;\n    }\n\n    public override Task<OrderResponse> GetOrder(OrderRequest request, ServerCallContext context)\n    {\n        _logger.LogInformation("Solicitud de pedido {OrderId}", request.OrderId);\n        // Aquí podría estar su lógica de negocio\n        return Task.FromResult(new OrderResponse\n        {\n            OrderId = request.OrderId,\n            Status = "Confirmado",\n            Total = 99.99\n        });\n    }\n}

Ejecutamos:

dotnet run

El servicio funciona en el puerto 5001 (por defecto para gRPC). Ahora imagine que tiene 20 servicios de este tipo. ¿Cómo gestionar su comunicación? Aquí es donde entra Service Mesh.

Configuración de Istio para microservicios C#: paso a paso

Supongamos que su clúster Kubernetes ya está configurado. Instalamos Istio:

istioctl install --set profile=demo -y

Ahora habilitamos la inyección automática de