Arquiteturas e Paradigmas em Sistemas Distribuídos §

---

1. Conceitos Fundamentais da Computação Distribuída §

Arquitetura Cliente-Servidor §

É o modelo mais básico da computação em rede. Nele, um programa (cliente, como o app no seu celular) faz uma requisição para outro programa (servidor, um computador potente na nuvem) que possui os dados ou a lógica. O servidor processa a requição e envia uma resposta ao cliente.

Analogia (O Restaurante): Pense em um restaurante. Você (o Cliente) faz um pedido (requisição) ao garçom. O garçom leva o pedido à cozinha (o Servidor), que prepara o prato (processa os dados) e o envia de volta para você.

API (Application Programming Interface) §

Uma API é um “contrato” que define como dois sistemas de software devem conversar. Ela especifica quais requisições podem ser feitas, como fazê-las e quais respostas esperar.

Analogia (O Cardápio): A API é o cardápio do restaurante. Ele diz exatamente o que você pode pedir (ex: “Listar Clientes”, “Criar Pedido”) e o formato para pedir. Você não precisa saber como a cozinha (sistema) funciona por dentro, apenas como usar o cardápio (API).

REST (Representational State Transfer) §

REST não é uma tecnologia, mas um estilo arquitetural, um conjunto de “boas maneiras” para criar APIs leves e fáceis de usar na web.

Analogia (A Etiqueta do Restaurante): Se a API é o cardápio, o REST são as regras de etiqueta do restaurante.

Princípios Fundamentais:

1. Recursos: Tudo é um “recurso” identificado por um endereço (URL). Ex: /clientes/123 é o recurso “cliente de ID 123”.
2. Verbos HTTP: Usamos os verbos-padrão do “idioma” da web (HTTP) para manipular esses recursos:
   • GET: Para ler um recurso (Ex: GET /clientes/123 -> “Me dê os dados do cliente 123”).
   • POST: Para criar um novo recurso (Ex: POST /clientes -> “Crie este novo cliente”).
   • PUT: Para atualizar um recurso (Ex: PUT /clientes/123 -> “Substitua os dados do cliente 123 por estes”).
   • DELETE: Para remover um recurso (Ex: DELETE /clientes/123 -> “Apague o cliente 123”).
3. Stateless (Sem Estado): Cada pedido do cliente deve conter toda a informação que o servidor precisa. O servidor não “guarda a sessão” ou lembra de pedidos anteriores.
   • Analogia: O garçom não reconhece você a cada pedido. A cada nova interação, você precisa dizer: “Eu, da mesa 10, gostaria de…”

Arquitetura de Microserviços §

É uma abordagem para desenvolver um sistema grande como uma suíte de pequenos serviços independentes. Cada serviço é focado em uma única responsabilidade de negócio (ex: serviço de “Pagamentos”, serviço de “Estoque”, serviço de “Usuários”).

Analogia (Food Trucks vs. Cozinha Central):

• O Monolito (nosso sistema atual) é uma grande cozinha de restaurante que faz tudo: pizza, sushi e churrasco. Se a fritadeira quebrar, a cozinha inteira para. Se ficar muito movimentado, você tem que construir outra cozinha inteira igual.
• Microserviços são como uma praça de food trucks. Um só faz pizza, outro só faz sushi. Eles são independentes. Se o food truck de sushi tiver problemas, o de pizza continua vendendo. Se o de pizza ficar popular, você pode trazer mais um food truck de pizza (escalabilidade) sem mexer nos outros.

Comunicação Síncrona vs. Assíncrona §

• Síncrona (A Ligação Telefônica): O solicitante (Cliente) envia um pedido e espera ativamente pela resposta. O sistema fica “travado” até o retorno. É simples, mas pode gerar gargalos se o servidor demorar.

• Assíncrona (O E-mail): O solicitante (Cliente) envia um pedido e não espera pela resposta. Ele segue fazendo outras coisas. Quando o servidor termina, ele envia uma notificação (ou o cliente checa depois). Isso é ótimo para tarefas demoradas (ex: “Gerar relatório de vendas do mês”).

Orquestração vs. Coreografia §

Como os food trucks (microserviços) conversam para entregar um pedido complexo?

• Orquestração (O Maestro): Existe um serviço central, o “Maestro” (Orquestrador), que dita a ordem. Ele diz: “Serviço A, pegue o pedido. Agora, Serviço B, valide o pagamento. Agora, Serviço C, despache o item”. É mais fácil de monitorar, mas cria um ponto central de falha.
• Coreografia (A Pista de Dança): Não há um líder. Cada serviço ouve “eventos” no sistema e reage a eles. O Serviço A publica: “Pedido Criado!“. O Serviço B ouve isso e reage: “Opa, vou validar o pagamento”. O Serviço C ouve o “Pagamento Aprovado” e reage: “Opa, vou despachar o item”. É mais resiliente e desacoplado, mas muito mais difícil de rastrear o fluxo completo.

2. Análise Comparativa §

A escolha da arquitetura e tecnologia certas depende do contexto.

Tema	Conceito 1: Monolito (Nosso sistema atual)	Conceito 2: Microserviços (Nossa meta)	Pontos de Comparação
Arquitetura	Um único “blocão” de código. Toda a lógica (pagamentos, usuários, estoque) está junta.	O sistema é dividido em pequenos serviços independentes (serviço de pagamento, serviço de usuário, etc.).	Vantagens (Monolito): Simples de começar, testar e implantar (no início). Desvantagens (Monolito): Difícil de atualizar (um deploy para tudo), uma falha derruba o sistema todo, difícil de escalar (temos que escalar tudo junto, mesmo que só os pagamentos estejam lentos). Vantagens (Microserviços): Escalabilidade (só escalamos o serviço que precisa), Resiliência (se o serviço de “recomendações” falhar, o de “pagamentos” continua), Times independentes podem trabalhar em paralelo. Desvantagens (Microserviços): Muito mais complexo de gerenciar, monitorar e garantir a comunicação.
Estilo de API	SOAP (Modelo antigo, comum em sistemas legados)	REST (Padrão moderno da web)	Protocolo: SOAP é um protocolo rígido, REST é um estilo arquitetural flexível. Formato de Dados: SOAP usa quase exclusivamente XML, que é “pesado”. REST usa comumente JSON, que é muito mais leve e rápido. Flexibilidade: SOAP é burocrático e complexo. REST é simples, leve e fácil de ser consumido por apps mobile e navegadores.
Comunicação	RPC / gRPC (Comunicação interna)	REST (Comunicação externa/interna)	Acoplamento: RPC (Chamada de Procedimento Remoto) é mais acoplado; um serviço “chama uma função” em outro. REST é desacoplado; um serviço “manipula um recurso” em outro. Desempenho: gRPC (uma versão moderna do RPC do Google) é extremamente rápido, pois usa formatos binários e o protocolo HTTP/2. É muito mais rápido que REST com JSON. Caso de Uso: Recomendamos REST para APIs públicas (para parceiros) e para nossos apps mobile. Recomendamos gRPC para a comunicação interna de alta frequência entre nossos microserviços, onde a performance é crítica.

3. Estudo de Caso: Netflix §

A Netflix é o exemplo mais famoso de migração de um monolito (que não aguentava o crescimento) para microserviços.

• Como utiliza: Praticamente tudo na Netflix é um microserviço. O serviço que faz login é um; o que busca o catálogo de filmes é outro; o que processa seu pagamento é outro; e o que decide quais filmes recomendar para você é um quarto serviço.

• APIs: Quando você abre o app (cliente), ele faz uma chamada para uma API “de fachada” (chamada de Backend for Frontend). Essa API, por sua vez, age como o “maestro” (orquestração) e chama dezenas de outros microserviços internos para coletar seu perfil, suas recomendações, o “Top 10” e montar a tela inicial em milissegundos.

• Benefícios Alcançados:

  1. Resiliência: Se o serviço de recomendação falhar, a Netflix não “cai”. Ela simplesmente exibe um catálogo genérico ou uma mensagem de erro apenas naquela parte da tela, mas você ainda pode buscar e assistir a um filme.

  2. Escalabilidade Massiva: Na sexta-feira à noite (pico de audiência), eles podem escalar apenas os serviços de streaming e catálogo, sem precisar gastar dinheiro escalando o serviço de “alterar e-mail da conta”.

  3. Inovação: Eles podem testar um novo algoritmo de recomendação em 1% dos usuários sem afetar os outros 99% e sem precisar reimplantar o sistema inteiro.

  • Desafios Enfrentados:

    • Observabilidade: Gerenciar milhares de serviços é um desafio. Eles tiveram que criar suas próprias ferramentas (como o Chaos Monkey, que desliga serviços aleatoriamente em produção para testar a resiliência) para saber o que estava acontecendo.
    • Latência: Uma chamada de API que se desdobra em 50 chamadas internas pode ficar lenta. Isso exige um enorme esforço de otimização de rede e cache (memória de curto prazo).

4. Reflexão Crítica e Recomendações §

• Quando NÃO vale a pena usar microserviços? Não devemos usar microserviços se o sistema for pequeno, se o time for muito reduzido (ex: 3 desenvolvedores) ou se estivermos na fase de validação de um produto novo (MVP). A complexidade dos microserviços (o “imposto” operacional) só se paga em sistemas complexos e de grande escala.

• O modelo REST tem limitações? Quais? Sim. Às vezes, para montar uma tela, o app precisa fazer 5 chamadas REST diferentes (ex: buscar usuário, depois buscar pedidos, depois buscar endereços), o que é lento (chamamos essa “falta de dados” de under-fetching). Em outros casos, a API devolve dados demais que não precisávamos (o over-fetching). Tecnologias como o GraphQL (um estilo de API concorrente) resolvem isso permitindo que o cliente peça exatamente os dados que quer em uma única chamada.

• APIs podem existir em sistemas monolíticos? Com certeza. Nosso sistema monolítico atual pode (e deveria) ter APIs. Uma API é apenas a “porta da frente” do sistema. Um monolito pode expor uma API para que nosso aplicativo de celular ou um parceiro de negócios possa consumir nossos dados de forma controlada, mesmo que toda a lógica esteja em um único “blocão”.

Referências §

---

https://github.com/traue/25.2_comp_dist_cc6d/blob/main/04_APIs/README.md

Netflix Technology Blog: “Rebuilding Netflix Video Processing Pipeline with Microservices”

Netflix Technology Blog: “Mastering the Chaos - A Netflix Guide to Microservices”

Netflix Technology Blog - Microservices