Arquiteturas para Sistemas Distribuídos I Pedro Ferreira Departamento de Informática Faculdade de Ciências da Universidade de Lisboa
Tópicos Estilos Arquiteturais: formas de desenhar o software do SD Organização do software do SD em componentes e conetores Alguns estilos amplamente utilizados:» Camadas» Objetos» Eventos» Espaço de dados partilhado Componente de software: unidade modular de software com interfaces de entrada e saída bem definidas, que é substituível no seu ambiente. Arquiteturas de Sistemas: organização do SD Centralizados (e.g., modelo cliente-servidor) Descentralizados (e.g., peer to peer puro ) Híbridos (e.g., sistemas colaborativos) Conetor: mecanismo de mediação da comunicação, coordenação ou cooperação entre componentes.
Estilos Arquiteturais: Camadas Componentes são organizados em camadas Interrogações ou pedidos geralmente descem Respostas geralmente sobem Um componente de uma camada L i só pode chamar componentes da camada L i-1 Muito usado na comunidade de redes Modelo OSI Pilha TCP/IP Nota: este modelo pode ser usado tanto na organização do software de um nó (e.g., pilha TCP/IP), como na organização de um sistema distribuído (e.g., arquitetura 3 camadas na Web).
Estilos Arquiteturais: Objetos Cada objeto contém estado e suporta uma série de operações que podem ser invocadas por outros objetos Os conetores entre os objetos representam invocações de métodos (possivelmente remotas, e.g., RPC) Mais uma vez, pode ser usado tanto na organização interna do software num nó (programação OO) quanto na organização de um sistema distribuído (plataformas para objetos distribuídos como JavaRMI ou CORBA) Arquiteturas baseadas em camadas e objetos são as mais importantes hoje em dia
Estilos Arquiteturais: Eventos Os processos (componentes) comunicam através da propagação de eventos que podem ou não conter dados Os eventos são transportados por um componente chamado Event bus (middleware) Uma instanciação representativa deste estilo arquitetural são os sistemas publish/subscribe: Alguns processos registam o interesse em certos tipos de eventos Outros processos publicam eventos O middleware é responsável por notificar os processos apenas de eventos em que eles estão interessados Este modelo oferece desacoplamento espacial: Os processos não necessitam conhecer os endereços de outros
Estilos Arquiteturais: Espaço de dados partilhado Combina o estilo arquitetural baseado em eventos com uma arquitetura centrada em dados, dando origem ao espaço de dados partilhado Os componentes colocam dados e eventos num espaço de memória partilhada (middleware) Muitos sistemas que seguem este estilo oferecem linguagens de consultas tipo SQL para acesso aos dados Além do desacoplamento espacial, este estilo arquitetural oferece desacoplamento temporal: Os processos não precisam estar ativos ao mesmo tempo para interagir [33-36] Neste estilo só há interação se o espaço de dados estiver ativo. Isto significa que este componente é critico para qualquer aplicação que siga este estilo. O mesmo se aplica para o Event Bus no estilo anterior.
Arquiteturas de Sistemas Centralizadas Descentralizadas Híbridas
Arquiteturas Centralizadas Determinados elementos do sistema que são responsáveis pela execução de tarefas fundamentais para nossa aplicação distribuída Tem-se em geral uma divisão de papéis entre os processos que oferecem serviços e os processos que requisitam estes serviços Modelo Cliente-Servidor : Sistema estruturado como um grupo de processos servidores, que oferecem serviços requisitados por processos, clientes Clientes Servidores Rede (LAN, WAN, com ou sem fios,...) Os papeis de clientes e servidores num sistema distribuído podem-se sobrepor nalgumas máquinas, i.e., alguns servidores são clientes de outros servidores
Comunicação entre Clientes e Servidores Numa rede local, a comunicação pode ser baseada num protocolo sem ligação em que as operações suportadas são os pedidos e respostas Cliente Sistema Operativo Pedido Resposta Servidor Sistema Operativo send(dest, buffer_ptr) receive(addr, buffer_ptr) Vantagens: simplicidade e eficiência Nível OSI 7 Numa WAN, utilizam-se protocolos fiáveis e com ligação (e.g., TCP/IP) pior desempenho necessário estabelecer ligação antes de enviar/receber dados Pedido/Resposta Dados Físico 6 5 4 3 2 1
Divisão do Processamento Cliente-Servidor Em muitas aplicações é difícil a separação clara entre clientes e servidores, uma vez que o mesmo programa pode servir ao mesmo tempo as duas funções Considerando em particular aplicações que suportam o acesso a bases de dados, muitas vezes utiliza-se a seguinte divisão three-tiered architecture (Nota: divisão lógica, não em máquinas) nível de interface com o utilizador» programas que permitem a interação dos utilizadores com as aplicações (e.g., interface tipo caráter ou interface com janelas X) nível de processamento» programas que realizam a funcionalidade esperada da aplicação (e.g., numa aplicação de gestão de ações, corresponde aos programas que fazem as simulações económicas) nível de dados» programas que gerem e armazenam os dados/informação que é processada pelas aplicações (e.g., sistema de ficheiros ou uma base de dados)
Exemplo: Motor de Busca na Internet
Arquiteturas Cliente-Servidor A organização mais simples para uma aplicação cliente-servidor consiste em utilizar apenas dois tipos de máquinas máquinas cliente que contêm apenas a interface do utilizador máquinas servidor que contêm o resto, i.e., os programas que realizam o processamento e armazenamento dos dados Na prática pode-se fazer outro tipo de divisão das tarefas executadas nas duas máquinas cliente e servidor Arquitecturas com dois níveis (de máquinas)
Arquiteturas Cliente-Servidor Clientes Magros (thin clients) Menor escalabilidade Mais trabalho no servidor, que portanto gasta mais tempo para atender cada pedido Pior desempenho O cliente faz muito pouca coisa localmente, e portanto está sujeito às condições de comunicação Facilidade de gestão A maior parte do software está centralizada no servidor, e portanto é muito mais fácil de gerir e atualizar Clientes Gordos (fat clients) Maior escalabilidade O trabalho é deslocado do servidor para o cliente, portanto o servidor atende mais rapidamente mais clientes Melhor desempenho Muitas operações são processadas localmente e não estão sujeitas a latência da rede Mais difícil de gerir Qualquer atualização ou configuração deve ser feita nas máquinas dos clientes (que podem ser muitas)
Arquiteturas Cliente-Servidor Clientes Magros (thin clients) Menor escalabilidade Mais trabalho no servidor, que portanto gasta mais tempo para atender cada pedido Pior desempenho O cliente faz muito pouca coisa localmente, e portanto está sujeito às condições de comunicação Facilidade de gestão A maior parte do software está centralizada no servidor, e portanto é muito mais fácil de gerir e atualizar Clientes Gordos (fat clients) Maior escalabilidade O trabalho é deslocado do servidor para o cliente, portanto o servidor atende mais rapidamente mais clientes Melhor desempenho Muitas operações são processadas localmente e não estão sujeitas a latência da rede Mais difícil de gerir Qualquer atualização ou configuração deve ser feita nas máquinas dos clientes (que podem ser muitas) Exemplo de Cliente Magro: Aplicações Web. Exemplo de Cliente Gordo: aplicações desktop que funcionam em intranets corporativas.
Arquiteturas Cliente-Servidor [36-43] A arquitetura não precisa de ser necessariamente baseada apenas em duas máquinas; pode envolver um número maior Exemplo: Arquitetura com três níveis (de máquinas).