Baixar para ler offline
Comunicação_e_Middleware_na_Prática - SD
- 1. Comunicação e Middleware naPrática Conectando Conceitos Teóricos a Sistemas Distribuídos Reais
- 2. Revisão Rápida "Vimos arquiteturas.Mas como elas conversam e coordenam?" Nas aulas anteriores, estudamos diferentes arquiteturas de sistemas distribuídos: cliente-servidor, peer-to-peer, microserviços, entre outras. Mas uma arquitetura sozinha não funciona. Os componentes precisam trocar informações, coordenar ações e sincronizar estados. A comunicação é o elemento fundamental que permite que sistemas distribuídos operem como um todo coeso, mesmo estando geograficamente separados. Hoje vamos explorar como essa comunicação acontece na prática, preparando terreno para as próximas unidades sobre processos, sincronização e coordenação.
- 3. A Comunicação éo Coração dos Sistemas Distribuídos Assim como o coração bombeia sangue para todo o corpo, a comunicação é o mecanismo que mantém os sistemas distribuídos vivos e funcionais. Sem ela, componentes isolados não conseguem formar um sistema coeso. Troca de Dados Permite que serviços compartilhem informações essenciais para operação conjunta Coordenação de Ações Garante que múltiplos processos trabalhem de forma sincronizada e ordenada Sincronização de Estados Mantém consistência entre réplicas e componentes distribuídos Resiliência e Escalabilidade Permite que o sistema cresça e se adapte a falhas sem perder funcionalidade
- 4. Modelos de Comunicação Síncrono Esperaresposta imediata, como uma ligação telefônica. O processo fica bloqueado até receber retorno. RPC, REST Assíncrono Não espera resposta imediata, como uma carta ou e-mail. O processo continua sua execução. Mensageria (Kafka, MQTT) Orientado a Mensagens Troca de eventos via filas e brokers intermediários que garantem entrega. Microserviços, IoT Modelo Descrição Uso Típico Síncrono Espera resposta (tipo ligação telefônica) RPC, REST Assíncrono Não espera resposta (tipo carta ou e-mail) Mensageria (Kafka, MQTT) Orientado a Mensagens Troca de eventos via filas/brokers Microserviços, IoT
- 5. Modelo Síncrono Analogia: LigaçãoTelefônica Como uma chamada telefônica, a comunicação síncrona exige que ambas as partes estejam presentes ao mesmo tempo. O cliente faz a chamada e aguarda até receber a resposta do servidor. Na comunicação síncrona, o processo cliente envia uma requisição e bloqueia sua execução até receber a resposta do servidor. Durante esse tempo, o cliente fica em estado de espera. Bloqueante: O cliente aguarda a resposta antes de continuar Acoplamento temporal: Cliente e servidor devem estar ativos simultaneamente Resposta imediata: O resultado é obtido na mesma chamada Simplicidade: Modelo mais intuitivo e fácil de programar Cliente envia requisição Servidor Cliente aguarda (bloqueado)... Cliente Servidor envia resposta Cliente continua execução Quando Usar RPC (Remote Procedure Call) ▸ APIs REST tradicionais ▸ Consultas a bancos de dados ▸ Operações que precisam de resposta imediata ▸ Sistemas bancários e transacionais ▸
- 6. Modelo Assíncrono O queé? Comunicação onde o remetente não espera uma resposta imediata. O processo continua sua execução sem bloquear. Analogia "Como enviar uma carta ou e-mail: você envia a mensagem e continua suas atividades. A resposta pode chegar depois." Características Não bloqueante: O cliente não fica aguardando resposta Desacoplamento temporal: Não precisam estar ativos ao mesmo tempo Maior escalabilidade: Processa grandes volumes sem travar Complexidade adicional: Requer callback ou polling Uso Típico Mensageria (Kafka, RabbitMQ, MQTT), processamento em background, notificações, pipelines de dados Fluxo de Comunicação Assíncrona 1 CLIENTE Envia requisição/mensagem 2 CLIENTE Continua executando outras tarefas 3 SERVIDOR/FILA Processa a mensagem no seu próprio tempo 4 RESPOSTA (OPCIONAL) Callback ou notificação quando pronto Vantagem chave: Cliente não fica bloqueado, aumentando throughput do sistema
- 7. Modelo Orientado aMensagens No modelo orientado a mensagens, a comunicação acontece através da troca de eventos via filas e brokers. Os componentes não se comunicam diretamente, mas sim através de intermediários que gerenciam o fluxo de mensagens. Características Principais • Desacoplamento: Produtor e consumidor não precisam estar ativos simultaneamente • Persistência: Mensagens ficam armazenadas até serem consumidas • Escalabilidade: Múltiplos consumidores podem processar mensagens em paralelo • Confiabilidade: Garantias de entrega e processamento de mensagens Casos de Uso Típicos Arquiteturas de Microserviços Internet das Coisas (IoT) Processamento de Eventos em Tempo Real Integração de Sistemas Legados Fluxo de Comunicação via Mensagens Produtor Broker / Fila Consumidor 1. Produtor envia mensagem/evento para o broker 2. Broker armazena e gerencia a fila de mensagens 3. Consumidor(es) processam mensagens de forma assíncrona
- 8. Tipos de Comunicaçãoe Ferramentas Agora que entendemos os modelos de comunicação, vamos explorar as tecnologias concretas que implementam esses modelos em sistemas distribuídos reais. Estilo Tecnologia Quando Usar Exemplo Real RPC Chamadas remotas tipo função Simplicidade, sistemas internos Sistemas bancários antigos RMI RPC com objetos (Java) Sistemas Java legados Aplicações corporativas REST / HTTP API Comunicação via HTTP Web, microserviços Netflix, Google, GitHub gRPC RPC em alta performance (Protobuf) Nuvem, stream, baixa latência Google, Kubernetes Mensageria Kafka, RabbitMQ, MQTT Processamento assíncrono, IoT Uber, IoT, AI pipelines Cada tecnologia tem suas vantagens e trade-offs. A escolha depende dos requisitos específicos do sistema: performance, escalabilidade, simplicidade, compatibilidade.
- 9. RPC - RemoteProcedure Call Chamadas Remotas Tipo Função RPC (Remote Procedure Call) é um protocolo que permite que um programa execute um procedimento (função) em outro espaço de endereçamento, geralmente em uma máquina remota, como se fosse uma chamada local. Como Funciona o RPC 1 Cliente chama procedimento remoto como se fosse local 2 Stub do cliente serializa parâmetros (marshalling) 3 Mensagem é enviada pela rede ao servidor 4 Stub do servidor desserializa parâmetros 5 Servidor executa o procedimento local 6 Resultado retorna ao cliente pelo mesmo caminho Síncrono Transparência Serialização Protocolo Quando Usar Vantagens Exemplo Real Sistemas Bancários Legados: Muitos bancos ainda utilizam RPC para comunicação entre seus sistemas internos, onde um servidor de transações chama procedimentos remotos em servidores de conta, auditoria e autorização de forma transparente. Cliente aguarda resposta Parece chamada local Marshalling automático Comunicação estruturada Simplicidade na comunicação entre sistemas • Sistemas internos de baixa latência • Aplicações cliente-servidor tradicionais • Quando transparência de rede é desejada • Abstração da complexidade de rede • Sintaxe familiar (chamada de função) • Suporte a múltiplas linguagens • Reutilização de código existente •
- 10. RMI - RemoteMethod Invocation RPC com Objetos em Java O que é RMI? RMI (Remote Method Invocation) é uma API Java que permite invocar métodos em objetos localizados em diferentes JVMs (Java Virtual Machines), como se fossem chamadas locais. É essencialmente RPC orientado a objetos. Específico para Java Orientado a Objetos Transparência Comunicação Síncrona Quando Usar Arquitetura RMI Cliente Stub Rede Skeleton Servidor Exemplo Real Sistemas bancários corporativos: Aplicações Java legadas usam RMI para comunicação entre servidores de transação, permitindo que objetos de conta bancária sejam manipulados remotamente com segurança de tipos. Funciona apenas entre aplicações Java, usando serialização nativa de objetos Permite passar objetos completos como parâmetros e retorno, não apenas tipos primitivos Cliente interage com stub local que abstrai a comunicação remota Chamadas bloqueiam até receber resposta do servidor remoto Sistemas Java legados e corporativos ▸ Aplicações empresariais (ERP, CRM) ▸ Ambientes homogêneos (100% Java) ▸ Sistemas internos com baixa interoperabilidade ▸ Aplicação Java Proxy local Receptor remoto Objeto Remoto
- 11. REST / HTTPAPI Comunicação via HTTP REST (Representational State Transfer) é um estilo arquitetural que utiliza o protocolo HTTP para comunicação entre sistemas. É o padrão mais popular para APIs web modernas devido à sua simplicidade e ampla adoção. Métodos HTTP Principais GET Buscar recursos POST Criar recursos PUT Atualizar recursos DELETE Remover recursos PATCH Atualização parcial OPTIONS Verificar métodos Princípios REST Stateless: Cada requisição contém todas as informações necessárias Recursos: Tudo é representado como recursos com URIs únicos Representações: JSON, XML ou outros formatos de dados HATEOAS: Links para navegação entre recursos relacionados Exemplo de Requisição REST GET /api/users/123 HTTP/1.1 Host: api.exemplo.com Accept: application/json Resposta: HTTP/1.1 200 OK Content-Type: application/json { "id": 123, "nome": "João Silva", "email": "joao@exemplo.com" } Quando Usar Exemplos Reais Netflix, Google, GitHub, Twitter: Todas utilizam APIs REST para permitir que aplicações web, mobile e terceiros consumam seus serviços de forma padronizada e escalável. APIs públicas e privadas para web e mobile ✓ Arquiteturas de microserviços ✓ Integração entre sistemas heterogêneos ✓ Aplicações que precisam de cache HTTP ✓ Sistemas com múltiplos clientes (web, mobile, IoT) ✓
- 12. gRPC RPC de AltaPerformance com Protocol Buffers gRPC é um framework moderno de RPC desenvolvido pelo Google que utiliza HTTP/2 para transporte e Protocol Buffers para serialização, oferecendo comunicação extremamente rápida e eficiente entre serviços. Características Principais 1 HTTP/2 2 Protocol Buffers 3 Suporte Multi-linguagem 4 Streaming Bidirecional gRPC vs REST gRPC é até 7x mais rápido que REST em cenários de alta carga, com payloads até 10x menores graças ao Protocol Buffers. Ideal para comunicação interna entre microserviços. Arquitetura gRPC Cliente gRPC Define .proto Stub Gerado HTTP/2 + Protobuf Rede Desserialização Servidor gRPC Executa método Serviço Implementado Quando Usar Microserviços em nuvem Baixa latência Streaming de dados Apps móveis Comunicação interna IoT e edge computing Exemplos Reais Google: Usa gRPC internamente para comunicação entre serviços Kubernetes: API interna baseada em gRPC para alta performance Multiplexação de streams, compressão de headers, comunicação bidirecional Serialização binária compacta, muito mais eficiente que JSON Geração automática de código para C++, Java, Python, Go, Node.js, etc. Permite comunicação em tempo real nos dois sentidos
- 13. Mensageria Kafka, RabbitMQ, MQTT Sistemasde mensageria são middlewares que facilitam a comunicação assíncrona entre aplicações através de filas e tópicos, garantindo entrega confiável, desacoplamento e escalabilidade. Principais Tecnologias Apache Kafka Plataforma de streaming distribuída para processamento de eventos em tempo real com alta throughput Uso: Pipelines de dados, event sourcing, logs distribuídos RabbitMQ Message broker tradicional com suporte a múltiplos protocolos (AMQP, MQTT, STOMP) Uso: Filas de tarefas, microserviços, processamento assíncrono MQTT Protocolo leve para IoT com baixo consumo de banda e bateria Uso: IoT, dispositivos móveis, sensores, telemetria Benefícios da Mensageria Desacoplamento: Produtores e consumidores não precisam se conhecer Escalabilidade: Múltiplos consumidores processam mensagens em paralelo Confiabilidade: Persistência e garantias de entrega de mensagens Resiliência: Buffer contra picos de carga e falhas temporárias Comparação Rápida Tecnologia Throughput Melhor Para Kafka Muito Alto Streaming, big data RabbitMQ Médio-Alto Filas complexas, roteamento MQTT Baixo-Médio IoT, baixa latência Quando Usar Mensageria Processamento assíncrono de tarefas pesadas Integração entre microserviços Pipelines de dados e analytics em tempo real Sistemas de notificações e alertas Event sourcing e CQRS Comunicação IoT e dispositivos móveis Exemplos Reais Uber: Usa Kafka para processar trilhões de eventos por dia Netflix: Kafka para analytics e recomendações em tempo real IoT: MQTT é o padrão para comunicação entre sensores e gateways
- 14. Como Funciona aMensageria: Kafka Produtor 1 Produtor 2 KAFKA BROKER (Cluster) Tópico A P0 P1 P2 Tópico B P0 P1 Tópico C P0 P1 P2 P3 Consumidor 1 Consumidor 2 Consumidor 3 Produtores enviam mensagens para tópicos → Broker armazena em partições → Consumidores leem de forma paralela Conceitos-Chave Tópico: Canal lógico onde mensagens são publicadas Partição: Subdivisão de um tópico para paralelismo Broker: Servidor Kafka que armazena mensagens Produtor: Aplicação que envia mensagens Consumidor: Aplicação que lê mensagens Consumer Group: Grupo de consumidores que dividem a leitura Vantagens do Kafka Alta throughput (milhões de msgs/seg) Escalabilidade horizontal Durabilidade e replicação Retenção configurável de mensagens Múltiplos consumidores independentes Processamento em tempo real Usado por Uber, Netflix, LinkedIn, Airbnb, Twitter
- 15. O Papel doMiddleware Middleware é uma camada de software que atua como intermediário entre aplicações distribuídas, abstraindo a complexidade da comunicação em rede e fornecendo serviços essenciais para sistemas distribuídos. Por que Middleware é Necessário? Sistemas distribuídos enfrentam desafios únicos: heterogeneidade de plataformas, falhas de rede, latência variável, e complexidade de coordenação. O middleware resolve esses problemas oferecendo uma camada de abstração que simplifica o desenvolvimento e aumenta a confiabilidade. Problemas que o Middleware Resolve Complexidade de Rede Abstrai protocolos, endereçamento e comunicação entre máquinas Heterogeneidade Permite integração entre diferentes linguagens, sistemas operacionais e plataformas Falhas Distribuídas Gerencia timeouts, retries e recuperação de falhas de comunicação Balanceamento e Escalabilidade Distribui carga entre múltiplos servidores e facilita crescimento horizontal Middleware como Solução Resultado
- 16. Transparência de Rede Comoo Middleware Abstrai a Complexidade Distribuída Transparência é a capacidade do middleware de ocultar aspectos da distribuição, fazendo com que recursos remotos pareçam locais. O objetivo é simplificar o desenvolvimento e permitir que programadores trabalhem como se tudo estivesse em uma única máquina. Transparência de Localização Oculta onde os recursos estão fisicamente localizados. O usuário acessa recursos sem saber se estão na mesma máquina ou em outro continente. Exemplo DNS, URLs, RPC Transparência de Replicação Oculta a existência de múltiplas cópias de recursos. O sistema gerencia réplicas automaticamente para aumentar disponibilidade e desempenho. Exemplo CDNs, bancos de dados distribuídos Transparência de Falhas Oculta falhas e recuperação de componentes. O middleware detecta problemas e tenta recuperar automaticamente sem intervenção do usuário. Exemplo Retry automático, failover Benefícios da Transparência Simplicidade no Desenvolvimento: Programadores não precisam lidar com detalhes de rede Portabilidade: Código pode ser movido entre ambientes sem modificações Manutenibilidade: Mudanças na infraestrutura não afetam aplicações Desafios da Transparência Latência: Chamadas remotas são sempre mais lentas que locais Debugging: Problemas distribuídos são mais difíceis de diagnosticar Trade-off: Transparência total pode ocultar informações importantes sobre desempenho
- 17. Funções Essenciais doMiddleware Função Descrição Exemplo de Tecnologia Transparência de Rede Abstrai a localização física dos recursos, fazendo com que chamadas remotas pareçam locais. O desenvolvedor não precisa se preocupar se o serviço está na mesma máquina ou em outro continente. RPC, RMI, gRPC Stub/Skeleton ocultam detalhes de rede Serialização / Marshalling Converte objetos e estruturas de dados em formato transmissível pela rede (bytes) e reconstrói no destino. Garante que dados complexos possam ser enviados entre sistemas heterogêneos. Protocol Buffers (gRPC), JSON (REST), Java Serialization (RMI) Protobuf é até 10x mais compacto que JSON Tolerância a Falhas Implementa mecanismos de retry, timeout, circuit breaker e fallback para lidar com falhas de rede e serviços indisponíveis. Aumenta a resiliência do sistema distribuído. Kafka (replicação), RabbitMQ (acknowledgments), Service Mesh (Istio) Kafka replica mensagens em múltiplos brokers Balanceamento de Carga Distribui requisições entre múltiplas instâncias de serviços para otimizar uso de recursos, evitar sobrecarga e melhorar tempo de resposta. Essencial para escalabilidade horizontal. NGINX, HAProxy, Kubernetes Service, API Gateway Round-robin, least connections, IP hash Descoberta de Serviços Permite que clientes encontrem dinamicamente a localização de serviços disponíveis sem configuração estática. Fundamental em ambientes cloud onde IPs mudam frequentemente. Consul, Eureka, Zookeeper, Kubernetes DNS Service registry + health checks Gerenciamento de Filas Armazena mensagens temporariamente em filas, garantindo entrega mesmo quando consumidores estão offline. Desacopla produtores de consumidores e permite processamento assíncrono. Kafka, RabbitMQ, Amazon SQS, Azure Service Bus Garantias: at-most-once, at-least-once, exactly- once Middleware moderno combina múltiplas funções para criar uma camada robusta de comunicação. Por exemplo, gRPC oferece transparência + serialização eficiente, enquanto Kafka fornece filas + tolerância a falhas + balanceamento.
- 18. Estudos de CasosReais Como Grandes Empresas Usam Comunicação e Middleware Vamos analisar como empresas líderes de tecnologia aplicam os conceitos de comunicação e middleware na prática, combinando diferentes tecnologias para construir sistemas distribuídos robustos e escaláveis. Netflix REST + gRPC + Kafka WhatsApp MQTT + Erlang Uber Kafka + REST + gRPC Bancos RPC + RMI + SOAP O que Vamos Aprender
- 19. Caso Netflix Arquiteturade Microserviços em Escala Global Contexto e Desafios A Netflix é uma das maiores plataformas de streaming do mundo, servindo mais de 230 milhões de assinantes em mais de 190 países. A arquitetura precisa lidar com picos massivos de tráfego, personalização em tempo real e alta disponibilidade. 1B+ Requisições por dia 700+ Microserviços 99.99% Disponibilidade Stack de Comunicação 1 REST APIs Comunicação externa com clientes (web, mobile, TV) e integração com parceiros Interface pública e comunicação cliente-servidor 2 gRPC Comunicação interna de alta performance entre microserviços críticos (catálogo, recomendação) Baixa latência para chamadas síncronas internas 3 Apache Kafka Streaming de eventos para analytics, logs, monitoramento e processamento assíncrono em tempo real Trilhões de eventos processados diariamente Fluxo de Comunicação na Netflix Cliente faz requisição App envia requisição REST para API Gateway Microserviços comunicam via gRPC Serviço de catálogo chama recomendação com gRPC Eventos enviados para Kafka Ações do usuário viram eventos para analytics Processamento em tempo real Kafka Streams processa dados para personalização Lições Aprendidas Híbrido é melhor: REST para clientes, gRPC para serviços internos Event-driven: Kafka permite desacoplamento e escalabilidade massiva Resiliência: Circuit breakers e fallbacks em todas as chamadas
- 20. Casos Reais: WhatsAppe Uber WhatsApp Desafio Entregar mensagens instantâneas para mais de 2 bilhões de usuários com latência mínima, alta disponibilidade e baixo consumo de bateria em dispositivos móveis. Solução Tecnológica MQTT (Message Queue Telemetry Transport) Protocolo leve de mensageria pub/sub ideal para conexões instáveis e dispositivos com recursos limitados Erlang/OTP Linguagem funcional projetada para sistemas distribuídos de alta concorrência e tolerância a falhas FreeBSD Sistema operacional otimizado para performance de rede em servidores Fluxo de Mensagem 1 Cliente envia mensagem via MQTT 2 Servidor Erlang processa e roteia 3 Mensagem armazenada temporariamente 4 Entrega ao destinatário quando online Resultados 100B+ Mensagens por dia 2B+ Usuários ativos 50 Engenheiros (2014) 99.9% Disponibilidade Uber Desafio Processar milhões de eventos por segundo (localização de motoristas, solicitações de viagens, pagamentos) com consistência e baixa latência para matching em tempo real. Solução Tecnológica Apache Kafka Streaming de eventos para processar trilhões de mensagens: localização GPS, estado de viagens, analytics REST APIs Comunicação entre microserviços para operações síncronas (solicitação de viagem, perfil de usuário) gRPC Comunicação interna de alta performance entre serviços críticos de matching e roteamento Fluxo de Viagem 1 App envia solicitação via REST API 2 Evento publicado no Kafka 3 Serviço de matching usa gRPC para encontrar motorista 4 Atualizações de localização via Kafka em tempo real Resultados Mensageria em Tempo Real para Bilhões Coordenação em Tempo Real de Milhões de Viagens
- 21. Conclusão Comunicação e middlewaresão os pilares que sustentam sistemas distribuídos modernos 1 Modelos de Comunicação Síncrono, assíncrono e orientado a mensagens atendem diferentes necessidades de sistemas distribuídos 2 Tecnologias na Prática RPC, REST, gRPC e Kafka são escolhidos com base em requisitos de latência, throughput e escalabilidade 3 Papel do Middleware Abstrai complexidade, garante transparência e fornece serviços essenciais como tolerância a falhas Conectando com as Próximas Unidades Agora que entendemos como os sistemas se comunicam, estamos preparados para explorar processos distribuídos, sincronização e coordenação — os mecanismos que garantem que essas comunicações funcionem de forma coerente e consistente em ambientes distribuídos. Próximos Tópicos Processos Distribuídos Sincronização Coordenação