Vous êtes sur la page 1sur 63

Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos


Arquitetura de Sistemas Distribuídos
• Conceito de Arquitetura de Software

• Principais elementos arquiteturais

• Modelos Arquiteturais

• Evolução das Arquiteturas

• Estilos Arquiteturais
Conceito de Arquitetura de Software

• é a estrutura de um sistema, que consiste de


componentes de software, das propriedades
externamente visíveis desses componentes e dos
relacionamentos entre eles.

• é a estrutura ou organização dos mais


significativos componentes do sistema e suas
interações.
Principais elementos arquiteturais

Componentes
• é uma unidade modular com interfaces
requeridas e fornecidas bem definidas que é
substituível dentro do seu ambiente.

• são elementos de uma arquitetura que


geralmente implementam: processamento
(funcionalidade ou comportamento); estado
(informação ou dados); interação ( interconexão,
comunicação, coordenação e mediação).
Principais elementos arquiteturais

Componentes
• pode ser uma simples operação ou complexo
como um sistema inteiro. Pode ser visto pelo
usuário (humano ou outro software) somente
através da sua interface pública.
Principais elementos arquiteturais

Conectores
• tipo de componente responsável pela interação
entre componentes.
• em sistemas desktop convencionais os
conectores são geralmente representados por
simples chamadas de procedimento (procedure
call) ou acesso a dados compartilhados.
• em sistemas complexos eles passam a ter
identidades, papéis e artefatos de implementação
único.
Modelos arquiteturais

• Define a forma pela qual os componentes dos


sistemas interagem e a maneira pela qual eles
são mapeados em uma rede de computadores
subjacente (Coulouris, 2005).
Evolução das arquiteturas
Evolução das arquiteturas

Arquiteturas 1 camada (Mainframes)


• Dominantes até década de 80 como arquitetura
corporativa
• Terminais burros somente para apresentar as
informações.
Evolução das arquiteturas

Arquiteturas 1 camada (Mainframes)


Desvantagens:
– Manutenção difícil e cara, proporcional a sua
eficiência.
– Problemas de congestionamento na entrada
do servidor devido a chegada de pedidos
– Congestionamento no tratamento da
informação (sistema central responsável por
tudo, até pela interface)
– Problema básico: interface não amigável
Evolução das arquiteturas
Evolução das arquiteturas

Arquitetura Cliente/Servidor
Vantagens:
▫ Camada de apresentação no Cliente utiliza
processamento local (aproveita PCs da empresa).
▫ Oferecer sistemas com interfaces gráficas
amigáveis
▫ Integrar o desktop e os dados corporativos.
Evolução das arquiteturas

Arquitetura Cliente/Servidor
Desvantagens:
• Escalabilidade limitada
• Enormes problemas de manutenção (mudanças
na lógica de aplicação forçava instalações)
• Cada cliente uma conexão com o SGBD
Evolução das arquiteturas
Evolução das arquiteturas

Arquitetura 3 Camadas
• A arquitetura cliente/servidor em 2 camadas
sofria de vários problemas:
– Falta de escalabilidade (conexões a bancos
de dados)
– Enormes problemas de manutenção
(mudanças na lógica de aplicação forçava
instalações)
• Dificuldade de acessar fontes heterogêneas
Evolução das arquiteturas

Arquitetura 3 Camadas
Vantagens:
• Perda de performance é compensada com
ganho de flexibilidade.
• Aumento da escalabilidade e confiabilidade do
sistema.
• Problemas de manutenção foram reduzidos,
pois mudanças nas camadas de aplicação e de
dados não necessitam de novas instalacões no
desktop.
Evolução das arquiteturas

Arquitetura 3 Camadas
Desvantagens:
• Integração via Internet
– Problema que a maioria não foi projetada
para internet
• Integração entre sistemas 3-
3-tiers
– falta de padronização
Evolução das arquiteturas
Evolução das arquiteturas
Evolução das arquiteturas

Arquitetura n-camadas
• A arquitetura em 3 camadas original sofre de
problemas:
– A instalação inicial dos programas no desktop
é cara.
– O problema de manutenção ainda persiste
quando há mudanças na camada de
apresentação.
– Não se pode instalar software facilmente num
desktop que não está sob seu controle
administrativo
Evolução das arquiteturas

Arquitetura n-camadas
• Uso do Browser como Cliente Universal/Thin
Client
• A camada de aplicação se quebra em duas: Web
e Aplicação
• Evita
Evita--se instalar qualquer software no desktop e
portanto, problemas de manutenção.
• Pode
Pode--se chamar de 3 camadas porque às vezes
as camadas Web e Aplicação freqüentemente
rodam na mesma máquina (pequenos volumes)..
Evolução das arquiteturas
Arquitetura n-camadas
Desvantagens:
• Complexidade
• Fazer aplicações distribuídas multicamadas é
difícil. Tem que:
– Implementar tolerância a falhas
– Implementar gerência de transações
distribuídas
– Implementar balanceamento de carga
– Implementar resource pooling
– Muito middleware envolvido
Evolução das arquiteturas

Arquitetura n-camadas
Desvantagens:
• Informação redundante
• Dificuldade e o custo de desenvolvimento e
manutenção.
• Cresce exponencialmente com o número de
camadas
Evolução das arquiteturas

• O truque é introduzir middleware num


servidor de aplicação que ofereça esses
serviços automaticamente. Além do mais,
as soluções oferecidas (J2EE, . Net) são
baseadas em componentes.
Por quê definir uma arquitetura para
Sistemas Distribuídos ?
• Sistemas distribuídos são complexas peças
de software.

• Componentes estão espalhados por diversas


máquinas.

• Sistemas devem ser organizados


adequadamente: organização lógica do
conjunto de componentes e organização física
Estilos arquiteturais

• Estilos arquiteturais definem decisões gerais de


projeto que impõem restrições e que podem
precisar ser detalhadas em decisões mais
específicas para o sistema em questão.

• Não são definidos detalhes acerca de


componentes utilizados, suas interfaces e seus
mecanismos de interação. O arquiteto deve
detalhar estas decisões e adaptá-
adaptá-las para o
contexto específico de uma aplicação em
particular.
Estilos arquiteturais
• Estilos em Camada

• Estilos com Memória Compartilhada

• Estilos Baseados em Evento

• Peer
Peer--to
to--Peer
Estilos arquiteturais
• Estilos em Camada
– a arquitetura é separada em camadas
ordenadas, onde um programa de uma camada
pode solicitar serviços de uma camada inferior.
– Virtual Machines – várias camadas
– Client
Client--Server - duas camadas com conexões
em rede
Estilos arquiteturais
• Estilos em Camada - Virtual Machine
Estilos arquiteturais
• Estilos em Camada – Client
Client--Server
Estilos arquiteturais
• Estilos com Memória Compartilhada
– caracterizado pela presença de múltiplos
componentes que acessam o mesmo
repositório de dados e se comunicam através
deste repositório.
–- programas independentes acessam e se
comunicam exclusivamente através de um
repositório global, conhecido como
blackboard..
blackboard
Estilos arquiteturais
• Estilos com Memória Compartilhada
Exemplo: conjunto de ferramentas CASE integrada
Estilos arquiteturais
• Estilos com Memória Compartilhada
Estilos arquiteturais
• Estilos Baseados em Evento
– caracterizados por componentes
independentes que se comunicam somente
através de eventos transmitidos por um
barramento (conector).
– altamente indicado para sistemas com
componentes concorrentes altamente
desacoplados onde, em um determinado
momento, um componente pode estar ou
criando ou consumindo informação.
Estilos arquiteturais
• Estilos Baseados em Evento
– Nesta arquitetura, processos demonstram o
interesse por um evento ou conjunto de
eventos (processo se subscreve) e esperam
pela notificação de qualquer um desses
eventos, gerados por um processo notificador.
– O produtor publica uma informação em um
gerenciador de eventos (middleware) e os
consumidores se subscresvem para receber
as informações deste gerenciador. Eventos e
notificações.
Estilos arquiteturais
• Estilos Baseados em Evento
Estilos arquiteturais
• Peer-to
Peer- to--Peer (P2P)
– consiste em uma rede de peers autônomos
fracamente acoplados.
– cada peer atua como um cliente e como um
servidor.
– peers se comunicam utilizando protocolo de
rede (ex.: napster, gnutella, emule, PPLive)
– descentraliza tanto a informação quanto o
controle, fazendo com que a descoberta de
recursos seja um aspecto importante.
Estilos arquiteturais
• Peer-to
Peer- to--Peer (P2P)
– na descoberta de recursos em sistemas P2P
puro:
• a solicitação é lançada na rede como um
todo
• a requisição se propaga até que a
informação seja descoberta
• se a informação é encontrada o peer
obtém o endereço direto do outro peer e
contacta diretamente.
Estilos arquiteturais
• Peer-to
Peer- to--Peer (P2P)
– na descoberta de recursos em sistemas P2P híbrido:
• processo é otimizado por a presença de peers
especiais, especializados na localização de outros
peers ou disponibilização de diretórios que localizam
as informações. Ex.: napster (utiliza um servidor
central para indexação das músicas e localização de
outros peers).
– estilo popular nas aplicações de compartilhamento de
arquivos, utilizado também B2B commerce, chat, redes
de sensores.
Estilos arquiteturais
• Peer--to
Peer to--Peer (P2P)
Arquiteturas de Sistemas

• Como diversos sistemas distribuídos são


realmente organizados ?

• Onde são colocados os componentes de


software ?

• Onde é estabelecida a interação entre as


peças de software ?
Arquiteturas de Sistemas

• Arquiteturas Centralizadas
– Cliente
Cliente--Servidor: terminais bancários

• Arquiteturas Descentralizada
– Peer
Peer--to
to--Peer (P2P): E-
E-Chords

• Arquiteturas Híbridas
– Peer
Peer--to
to--Peer (P2P): BitTorrent, PPLive
Arquiteturas Centralizadas

• Modelo Cliente-
Cliente-Servidor
– processos são divididos em dois grupos

– Servidor: processo que implementa um


serviço específico

– Cliente: processo que requisita um serviço ao


servidor
• Requisição -> Resposta
Arquiteturas Centralizadas
Arquiteturas Centralizadas
Arquiteturas Centralizadas

• Modelo Cliente-
Cliente-Servidor: questões, questões!!
• Clientes e Servidores multithreads?
• Comunicação???
• Qual o tipo de aplicação?
• Sem conexão, não confiável (UDP)?
• Com conexão, confiável (TCP)?
Arquiteturas Centralizadas

● Considerando aplicações cliente-


cliente-servidor que
visam dar suporte ao acesso de usuários a banco
de dados:
– Nível de interface
– Nível de processamento
– Nível de dados
Arquiteturas Centralizadas
Arquiteturas Centralizadas

Com a distinção entre três níveis lógicos, como


distribuir fisicamente uma aplicação
cliente--servidor por várias máquinas?
cliente
– Arquitetura de duas divisões físicas
– Arquitetura de três divisões físicas
Arquiteturas Centralizadas
Arquiteturas Centralizadas
Arquiteturas Centralizadas
Arquiteturas Centralizadas
Arquiteturas Centralizadas
Arquiteturas Centralizadas
Arquiteturas Descentralizadas

• Clientes e servidores são fisicamente


subdivididos em partes logicamente equivalentes,
mas cada parte está operando em sua própria
porção do conjunto completo de dados, o que
equilibra a carga!!!!

• Interação entre os processos é simétrica: cada


processo agirá como um cliente e um servidor ao
mesmo tempo.
Arquiteturas Descentralizadas

Sistemas P2P – questões, questões, questões!!


● Como organizar os peers em uma rede de
sobreposição ?
● Como difundir o conteúdo?
● Como incentivar os peers a colaborarem?
Arquiteturas Descentralizadas
Arquiteturas Descentralizadas
Arquiteturas Descentralizadas
Arquiteturas Descentralizadas
Arquiteturas Descentralizadas
Arquiteturas Descentralizadas

Vous aimerez peut-être aussi