Service Mesh e Microsserviços TypeScript: Guia Completo 2024

Quando há microsserviços demais

Você escreveu seu primeiro microsserviço em TypeScript. Ele funciona. Depois o segundo, o terceiro, o décimo. E de repente você percebe que mais tempo é gasto não escrevendo lógica de negócios, mas sim fazendo com que os microsserviços consigam se comunicar uns com os outros. Timeouts, retries, balanceamento de carga, criptografia de tráfego, métricas — tudo isso precisa ser implementado em cada serviço separadamente.

É aqui que entra em cena o Service Mesh — uma tecnologia que remove toda a infraestrutura de comunicação do código para uma camada separada. E sim, ele funciona perfeitamente com microsserviços TypeScript. Neste artigo, vamos explorar como isso funciona na prática, com exemplos reais de código.

O que é Service Mesh em termos simples

Imagine que cada um dos seus microsserviços TypeScript é um funcionário em um grande escritório. Sem o Service Mesh, cada funcionário precisa passar seus próprios cabos, configurar o telefone e garantir que não está sendo espionado. Com o Service Mesh, um departamento de TI especializado cuida disso, conectando um "assistente pessoal" (sidecar proxy) a cada funcionário.

No mundo da tecnologia, esse assistente é chamado de Envoy Proxy, e toda essa infraestrutura é gerenciada por um orquestrador como Istio ou Linkerd. O melhor de tudo é que seu código TypeScript permanece praticamente intocado.

Principais recursos do Service Mesh

\n
• Traffic Management — roteamento inteligente, testes A/B, lançamentos canários
\n
• Security — criptografia automática mTLS entre serviços
\n
• Observability — métricas, logs, tracing "prontos para uso"
\n
• Resilience — retries, circuit breaker, timeouts no nível da infraestrutura
\n

Por que os microsserviços TypeScript se beneficiam especialmente do Service Mesh

TypeScript é uma linguagem com um sistema de tipos poderoso, mas seu ambiente de execução principal (Node.js) nem sempre é conhecido pelo desempenho de entrada e saída. Quando você escreve um microsserviço em TypeScript, cada requisição HTTP extra, cada implementação manual de retries ou handshake TLS é uma carga adicional no Event Loop.

O Service Mesh assume essa carga. Seu código TypeScript permanece limpo: ele apenas recebe requisições e responde a elas, enquanto o Envoy cuida de toda a "parte de encanamento". Isso é especialmente importante quando você tem dezenas de microsserviços — cada um com sua própria lógica de repetição e timeouts.

Exemplo prático: Microsserviço TypeScript sob Service Mesh

Vamos imaginar que temos dois microsserviços em TypeScript: user-service e order-service. O order-service precisa obter dados do usuário. Sem o Service Mesh, escreveríamos algo como:

// Sem Service Mesh — gerenciamento manual de HTTP\nimport axios from 'axios';\n\nclass UserClient {\n    private baseUrl = 'http://user-service:3000';\n    private retries = 3;\n\n    async getUser(id: string): Promise<User> {\n        for (let i = 0; i < this.retries; i++) {\n            try {\n                const response = await axios.get(`${this.baseUrl}/users/${id}`, {\n                    timeout: 5000,\n                    httpsAgent: new https.Agent({ rejectUnauthorized: true })\n                });\n                return response.data;\n            } catch (error) {\n                if (i === this.retries - 1) throw error;\n                await delay(1000 * Math.pow(2, i));\n            }\n        }\n    }\n}

E com o Service Mesh, isso se transforma em:

// Com Service Mesh — apenas uma requisição HTTP\nimport axios from 'axios';\n\nclass UserClient {\n    async getUser(id: string): Promise<User> {\n        const response = await axios.get(`http://user-service/users/${id}`);\n        return response.data;\n    }\n}

Percebeu a diferença? Toda a complexidade — retries, timeouts, criptografia — f