Upload
messias-batista
View
777
Download
5
Embed Size (px)
Citation preview
Arquiteturas
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DISCIPLINA DE SISTEMAS DISTRIBUÍDOS
PROF. MESSIAS R. BATISTA
Estilos Arquitetônicos
2
Introdução
▫ Como é organizado um sistema distribuído?
▪ Distinguir organização lógica dos componentes de software;
▪ Realização física;
▫ Sistemas distribuídos
▪ Componentes de software
▫ Arquitetura de software
3
Introdução
▫ Arquitetura de software (ou de sistema)
▪ Arquiteturas centralizadas
▪ Arquiteturas descentralizadas
4
▫ Arquiteturas centralizadas
Tradicionais. Um único servidor implementa a maioria dos componentes;
▫ Arquiteturas descentralizadas
As máquina desempenham papéis mais ou menos iguais, bem como organizações híbridas.
“[...] uma meta importante de
sistemas distribuídos é separar aplicações das
plataformas subjacentes provendo uma camada de
middleware.
5
6
Middleware
▫ É necessário conseguir ummiddleware adaptativo;
▫ Sistemas distribuídos devemmonitorar seu funcionamento
▪ Sistemas autonômicos
7
Estilos Arquitetônicos
8
9
O quanto é crucial adotar uma
arquitetura desoftware para um projeto?
Estilo Arquitetônico
10
▫ Formulado com base nos componentes que ocompõe;
▫ A forma de conexão dos componentestambém é importante;
▫ Os dados trocados entre os componentes;
▫ A forma de configuração desse conjunto deelementos;
Composição do Sistema Distribuído com base no estilo arquitetônico
“Um componente é uma unidade modular com
interfaces requeridas e fornecidas bem definidas que é substituível dentro de seu
ambiente
11
Componente
12
▫ É passível de substituição;
▫ Necessário respeitar as interfaces;
E os conectores?
“Conector [...] é descrito como um mecanismo que serve de mediador da comunicação ou
da cooperação entre componentes
13
Componentes e Conectores
14
Importantes Estilos Arquitetônicos
15
1. Arquiteturas em camadas;
2. Arquiteturas baseadas em objetos;
3. Arquiteturas centradas em dados;
4. Arquiteturas baseadas em eventos;
Configurações a partir de Componentes e Conectores
Arquiteturas em camadas
16
▫ Componentes são organizados em camadas;
▫ O componente da camada Li pode chamar um componente subjacente Li-1;
▫ Modelo amplamente adotado pela comunidade de redes;
▫ Requisições descem pela hierarquia;
▫ Resultados (respostas) fluem para cima;
Arquiteturas em camadas
17
Arquiteturas em camadas
18
Arquitetura baseada em objetos
19
▫ Cada objeto corresponde a definição de um componente;
▫ Os componentes são conectados por uma chamada de procedimento remoto;
▫ É um modelo de arquitetura que se ajusta ao sistema cliente-servidor;
▫ Configuram-se em um estilo importante para sistemas de software de grande porte.
Arquitetura baseada em objetos
20
Arquitetura centrada em dados
21
▫ Processos se comunicam por meio de umrepositório comum;
▫ Tem grau de importância similar as baseadas emcamadas e objetos;
▫ Funcionamento:
Trabalha com o compartilhamento de arquivos.
Arquitetura centrada em dados
22
Arquitetura baseada em eventos
23
▫ Processos se comunicam por meio da propagação de eventos;
▫ Podem também transportar dados;
▫ Associa-se a sistemas publica/subscrever;
▫ Processos fracamente acoplados;
▪ Podem ser desacoplados;
▪ Ou, referencialmente desacoplados.
“A ideia básica é que processos
publiquem eventos após os quais o middleware assegura
que somente os processos que se subscreveram para
esses eventos os receberão.
24
Arquitetura baseada em eventos
25
Arquiteturas baseadas em eventos, podem se
complementar com arquiteturas baseadas em dados
Espaços compartilhadosde Dados
▫ Os processos são desacoplados no tempo;
▪ Não precisa que ambos estejam ativos para haver comunicação;
▫ Utilizam interfaces semelhantes à SQL;
▪ Os dados são acessados por descrição;
▫ Não precisam ser acessados por referência explícita.
26
“O que torna essas arquitetura de software importantes para
sistemas distribuídos é que todas elas visam obter
transparência de distribuição, em um nível razoável.
27
Arquiteturas de Sistemas
Arquiteturas
28
“Decidir a respeito de
componentes de software, sua interação e sua colocação leva a
um exemplo de uma arquitetura de software
também denominada arquitetura de sistema.
29
Arquiteturas Centralizadas
ArquiteturasArquiteturas de Sistemas
30
“[...] pensar em termos de clientes que requisitam
serviços de servidores nos ajuda a entender e gerenciar a complexidade de sistemas
distribuídos [...]
31
Servidor e Cliente
32
▫ Servidor
▪ É um processo que implementa umserviço específico;
▫ Cliente
▪ É um processo que requisita um serviçode um servidor enviando-lhe umarequisição e, na sequência, esperandopela resposta do servidor.
Comportamento
Comportamento de requisição-resposta
33
34
Fases da Requisição-Resposta
35
1. Um cliente requisita um serviço;
▪ Empacota uma mensagem para oservidor identificando o serviço que quer,junto com os dados necessários.
2. O servidor sempre vai esperar a chegada deuma requisição;
▪ Processará e empacotará os resultadosem uma mensagem de resposta que éenviado ao cliente;
Cuidados!
36▫ Protocolos que não exigem conexão são mais
eficientes;
▪ Eficiência: Faz a tarefa designa da maneiramenos custosa;
▫ Problema:
▪ as mensagens não podem se perder ou seremcorrompidas;
▫ Dificuldade:
▪ desenvolver um protocolo que seja resistentea ocasionais falhas de transmissão.
37
E se o cliente não receber a mensagem de resposta o
que fazer neste caso?
Analisando...
38
Transfira $10.000 de minha conta
Reenviar a resposta
Analisando...
39
Informe quanto dinheiro ainda tenho.
Reenviar a resposta
Soluções?
40
▫ Operações que podem ser repetidas várias vezessem causar dano são chamadas de idempotente;
▫ Não existe soluções únicas para tratamento demensagens perdida;
▫ Alternativa é a utilização de protocolos confiáveisorientados a conexão;
▫ Garantindo que sempre que um cliente requisitouum serviços, antes ele estabeleceu uma conexãocom o servidor e só em seguida enviou arequisição.
Não há!
Camadas de Aplicação
41
Camadas de Aplicação
42
▫ Como estabelecer uma distinção clara entreum cliente um servidor?
▪ Um servidor para um banco de dadosdistribuídos pode agir continuamente comoum cliente porque está repassandorequisições para diferentes servidores dearquivos responsáveis pela implementaçãodas tabelas do banco de dados.
▪ Processa consultas;
Abordagem 1
Camadas de Aplicação
43
É possível analisar criando uma distinção entre três níveis, seguindo o estilo
arquitetônico em camadas.
1. Nível de interface de usuário
2. Nível de processamento
3. Nível de dados
Abordagem 1
Camadas
1. Nível de interface de usuário
2. Nível de processamento
3. Nível de dados
44
45
“O nível de interface de
usuário conteúdo que é necessário para fazer
interface diretamente com o usuário como gerenciamento
de exibição.
46
“O nível de processamentonormalmente contem as
aplicações.
47
“O nível de dados gerencia os
dados propriamente ditos sobre os quais está sendo executada alguma ação.
48
Conclusão
1. Manipula a interação com ousuário;
2. Intermediária. Mantém afuncionalidade central daaplicação;
3. Age sobre o banco de dadosou sistema de arquivos;
49
50
Palavras-chave
Busca no banco de
Dados
51
Nível de Dados
52
▫ Os dados costumam ser persistentes, e isso éuma propriedade importante desse nível;
▫ Quando não aplicações utilizando esse nível, osdados continuam armazenados aguardando apróxima utilização;
▫ “O nível de dados consiste em um sistema dearquivo, porém é mais comum utilizar um bancode dados plenamente capacitado”;
▫ É implementado no lado do servidor;
Importante!
Nível de Dados
53
▫ É responsável por manter a consistência dosdados em diferentes aplicações;
▫ Pode utilizar recursos como triggers paramanipular disparos de informação;
▫ Ambientes orientados a negócios utilizam bancosde dados relacionais;
▫ A organização dos dados é independente dasaplicações;
Importante!
Nível de Dados
54
“[...] nem sempre bancos de dados relacionaissão a opção ideal. Um aspecto característico demuitas aplicações é que elas operam sobretipos de dados complexos cuja modelagem émais fácil em termos de objetos do que emtermos de relações”
Conhecem o termoPersistência Poliglota?
Importante!(Detalhe)
55
56
Arquiteturas Multidivididas
57
“A distinção entre três níveis
lógicos [...], sugere várias possibilidades para a
distribuição física de uma aplicação cliente-servidor por
várias máquinas.
58
Cliente-Servidor
59
▫ Máquina cliente
▪ Contém apenas os programas queimplementam o nível (parte do nível) deinterface de usuário.
▫ Máquina do servidor
▪ Contém o resto, ou seja, os programasque implementam o nível deprocessamento e de dados.
De fato, o que temos?
“Nessa organização, tudo é
manipulado pelo servidor, ao passo que, em essência, o
cliente nada mais é do que um terminal burro, possivelmente
com uma interface gráfica bonitinha.
60
61
62
Consideramos o fato de que o servidor pode ser
um cliente também?
É possível? Exemplifique.
63
“
Clientes gordosX
Clientes Magros
64
Distribuição vertical
65
“[...] da perspectiva e gerenciamento desistema, ter uma distribuição vertical podeajudar: funções são subdivididas lógica efisicamente por várias máquinas, e cadamáquina é projetada para um grupo específicode funções”
Arquiteturas Descentralizadas
ArquiteturasArquiteturas de Sistemas
66
Distribuição horizontal
67
“Em arquiteturas modernas, muitas vezes é adistribuição dos clientes dos servidores que conta àqual nos referimos como distribuição horizontal”
▫ O cliente ou o servidor podem ser subdivididosfisicamente em partes logicamente equivalentes;
▪ Cada parte opera em sua própria porção doconjunto;
▪ Busca-se o equilíbrio da carga;
▫ Exemplo: peer-to-peer
Peer-to-peer
68
“De uma perspectiva de alto nível, os processosque constituem um sistemas peer-to-peer sãotodos iguais, o que significa que as funções queprecisam ser realizadas são representadas portodo processo que constitui o sistemadistribuído”
Peer-to-peer
69
▫ Organizam os processos por meio de umatabela de hash distribuída (Distributed HashTable – DHT);
▫ DHT implementa um mapeamento de chavedo item para um nó baseando por distânciasmétricas;
Redes Estruturadas
Sistema Chord
70
Peer-to-peerRedes Estruturadas
71
Peer-to-peer
72
▫ Dependem de algoritmos aleatórios paraconstruir uma rede de sobreposição;
▫ Cada nó mantém uma lista de vizinhos, queé construída de modo aleatório;
▫ Admite-se que itens de dados sejamcolocados aleatoriamente em nós;
▫ A busca de um item de dado na rede érealizada por uma consulta em toda a rede;
Redes Não-Estruturadas
Peer-to-peer
73
▫ O grande foco desta arquitetura é ogerenciamento de associação ao grupo;
▫ Sua estrutura é similar a um gráficoaleatório;
▫ Cada nó mantém um lista de vizinhos, nósvivos;
▫ A lista de vizinhos é denominada visãoparcial;
Redes Não-Estruturadas
Peer-to-peer
74
▫ A construção de uma nova visão:
▪ Os nós descartam as entradas criadasentre eles;
▪ Ou, os nós descartam o maior númeropossível de entradas velhas;
Redes Não-Estruturadas
“[...] quando um nó quer se
juntar ao grupo, ele contata um outro nó arbitrário,
possivelmente de uma lista de pontos de acesso bem
conhecidos.
75
Problema!
76
Gargalo criado em apenas um nó!
Gerenciamento de Topologia de Redes de Sobreposição
77
“Embora possa parecer que
sistemas peer-to-peerestruturados e não
estruturados formem classes estritamente independentes, na
verdade pode não ser esse o caso.
78
79
Superpares (superpeers)
80
Superpares
81
▫ P2P não estruturados podem se tornar problemáticos à medida que crescem;
▫ Problema de escalabilidade:
▪ Não roteamento da requisição de pesquisa até um item de dado específico;
▪ Única técnica é enviar a pesquisa para toda a rede;
▫ Solução (possível):
▪ Nós intermediários, ou superpares;
Superpares
82
▫ Superpares:
▪ São organizados em redes P2P;
▪ Resultam em organização hierárquica;
▫ Todo par comum estará conectado como um cliente a um superpar;
▫ A relação cliente-superpar é fixa;
▪ Sempre que um cliente se junta à rede, ele se liga a um dos superpares e continua até sair da rede;
83
Arquiteturas Híbridas
ArquiteturasArquiteturas de Sistemas
84
“[...] soluções cliente-
servidor são combinadas com arquiteturas descentralizadas.
85
Sistemas de servidor de borda
86
Sistemas de Servidor de Borda
87
▫ São sistemas disponibilizados na internet onde servidores são colocados “na borda” da rede;
▫ Usuários finais, ou clientes em geral, se conectam com a Internet por meio de um servidor de borda;
▫ Sua finalidade é servir conteúdo;
▫ Um conjunto de servidores de borda podem ser usados para otimizar distribuição de conteúdo e de aplicação;
88
Sistemas Distribuídos Colaborativos
89
“Estruturas híbridas são
disponibilizadas notavelmente em sistemas distribuídos colaborativos.
A questão principal em muitos desses sistemas é conseguir dar a partida, para o que muitas vezes é
disponibilizado um esquema cliente-servidor tradicional.
90
BitTorrent
91▫ Quando um usuário final estiver procurando um
arquivo, ele também possa transferir porçõespara outros usuários;
▫ Assim, cria-se um conjunto de porções sendotransferidas;
▫ A importância do projeto está na colaboração;
▫ Problema: quando existe grande quantidade deusuários objetivando apenas obter os arquivos;
▫ Portanto, “um arquivo só pode ser transferidoquando o cliente que está transferindo estiverfornecendo conteúdo a mais alguém”;
92
Arquiteturas versusMiddleware
Arquiteturas
93
94
Falamos sobre middelware?
Onde eles se encaixam?
“
[...] o middleware forma uma camada entre aplicações e plataformas distribuídas
95
Lembrando
Middleware
96
▫ Finalidade: proporcionar um grau detransparência de distribuição;
▫ Seguem um estilo arquitetônico específico;
▫ A especificidade do estilo arquitetônico é parasimplificar projetos de aplicações;
▫ Apesar de sua finalidade, considera-se tê-lo paraser mais adaptável as requisições de aplicação;
Middleware
97
“Uma abordagem geral consideramelhor é fazer sistemas de middlewarede modo que sejam simples deconfigurar, adaptar e personalizarconforme necessário para umaaplicação.”
Interceptadores
98
Interceptador
99
▫ É um constructo de software que interromperá ofluxo de controle usual e permitirá que sejaexecutado um outro código;
▫ Funciona com alto suporte em sistemasdistribuídos orientado à objetos;
▫ Um objeto A pode chamar um método quepertence a um objeto B enquanto este residir emuma máquina diferente de A.
Interceptador
100
A invocação remoto é realizada em três etapas:
1. É oferecida ao objeto A uma interface local que éexatamente a mesma oferecida pelo objeto B. Asimplesmente chama o método disponível naquelainterface;
2. A chamada por A é transformada em uma invocação aobjeto genérico, possibilitada por meio de umainterface geral de invocação de objeto oferecida pelomiddelware na máquina em que A reside;
3. Por fim, a invocação a objeto genérico é transformadaem uma mensagem que é enviada por meio de umainterface de rede de nível de transporte como oferecidapelo sistema operacional local de A.
101
Abordagens gerais para o software adaptativo
102
Software Adaptativo
103
▫ Interceptadores oferecem um meio de adaptar omiddleware;
▫ A necessidade de adaptação surge do ambientedas aplicações distribuídos, que estão sempremudando;
▪ O middleware retira da aplicação a reação amudanças;
▫ Projetistas de middleware passam a considerar aconstrução de software adaptativo;
Abordagens gerais
104
E como podemos chegar ao software adaptativo?
Software Adaptativo
105
1. Separação de interesses;
2. Reflexão computacional;
3. Projeto baseado em componente;
Três técnicas
Software Adaptativo
106
▫ Separar as partes que implementam funcionalidade dasque cuidam de outras coisas;
▫ Neste contexto:
▪ Desenvolver um middleware para aplicaçõesdistribuídas é o mesmo que manipularfuncionalidades extras independentemente deaplicações;
▫ A dificuldade está na modularização;
▫ Modularizar e depois entrelaçar interesses cruzados é omesmo tema trabalhado por desenvolvimento desoftware orientado a aspecto;
Três técnicas1. Separação de Interesses
Software Adaptativo
107
▫ Pode ser compreendida como à capacidade de umprograma inspecionar-se, e adaptar-se quandonecessário;
▫ As linguagens de programações modernos, como oJava, permitem modificações em tempo de execução;
▫ Em sistemas distribuídos essa técnica ainda é umdesafio;
▪ Aplicar a técnica de reflexão a um extenso domíniode aplicação ainda está por acontecer;
Três técnicas2. Reflexão Computacional
Software Adaptativo
108
▫ É o suporte dado a adaptação por meio de composição;
▫ Sistemas que são configurados dinamicamente emtempo de execução suportam ligação tardia;
▪ Ligação tardia: técnica que tem sido aplicada comsucesso em ambientes que são necessário carregare descarregar módulos;
▫ A dificuldade está quando precisa existir a substituiçãode um componente e não é possível mapear os efeitosque haverá em outros componentes;
Três técnicas3. Projeto Baseado em Componente
Discussão
109
Discussão
110
▫ Situação: Requisitos extrafuncionais conflitam com ameta de transparência;
▫ Resultado: Middlewares com alta flexibilidade;
▫ “[...] assuntos como abertura são de igual importância,mas a necessidade de flexibilidade nunca foi tãopredominante como no caso do middleware”
▫ Assim, a necessidade se torna uma premissa:
▪ São necessárias softwares adaptativos no sentido deque permitir mudança à medida que o ambiente sealtera;
Discussão
111
Qual o argumento que sugere aexistência de um software adaptativono middleware de sistemasdistribuídos?
Discussão
112
“O argumento mais forte e por certo omais válido para suporte softwareadaptativo é que muitos sistemasdistribuídos não podem ser desligados”
Discussão
113
▫ Sistemas distribuídos devem ser capazes de reagira mudanças em seu ambiente;
▪ Exemplo: trocar de políticas de alocação derecursos;
▫ O desafio conclusivo é deixar estecomportamento reativo e sem a necessidade deintervenção humana;
Portanto...
Autogerenciamento em Sistemas Distribuídos
Arquiteturas
114
“Sistemas distribuídos – e em especial seu middleware associado – precisam fornecer soluções gerais de blindagem contra aspectos indesejáveis inerentes a redes, de modo que possam suportar o maior número possível de aplicações.
115
Autogerenciamento
116
▫ Transparência de distribuição total não é focoprincipal da maioria das aplicações;
▫ Existe portanto um foco no conceito de softwareadaptativo;
▫ Quando a adaptação precisa ser automática:
1. Precisa-se organizar os componentes do sistemasdistribuído de modo a promover monitoramento eajustes;
2. Necessário decidir onde devem ser executados osprocessos que manipulam a adaptação;
Sistemas Distribuídos
Computação Autonômica
117
São sistemas de realimentação decontrole de alto nível que permitamadaptação automática a mudanças.
Ou Sistemas Auto
O modelo de realimentação de controle
118
Modelo de Realimentação de Controle
119 ▫ Premissa: adaptações ocorrem por meio de um ou maislaços de realimentação de controle;
▫ Sistemas organizados por meios de laços sãoconhecidos como sistemas de realimentação decontrole;
▫ O núcleo de um sistema de realimentação decontrole é formado pelos componentes que precisamser gerenciados;
▫ O laço de realimentação de controle é formado por trêselementos:
▪ Componente de estimativa de medição;
▪ Componente de análise de realimentação;
▪ Medidas de ajustes (conjunto de componentes).
120
Resumo
121
Resumo
122
▫ Sistemas Distribuídos podem ser organizados demodos diferentes;
▫ Existe distinção entre arquitetura de software earquitetura de sistema;
▪ Arquitetura de sistemas: os componentesque compõem o sistemas distribuídos estãocolocados nas várias máquinas;
▪ Arquitetura de software: preocupa-se com aorganização lógica. Como é realizada ainteração e como são estruturados doscomponentes.
Importante!
Resumo
123
▫ Estilo arquitetônico reflete a interação eorganização dos componentes que integram umsistema distribuído;
▫ Organização cliente e servido como importanteestrutura de um sistemas distribuído;
▫ Arquiteturas descentralizadas como a peer-to-peer;
▫ Sistemas autogerenciadores aumenta acapacidade de adaptação do sistema e minimizama intervenção humana;
Importante!
Referências
124
TANENBAUM, A. S.; STEEN, M. V. SistemasDistribuídos: princípios e paradigmas. 2.ed. SãoPaulo, SP: Pearson Prentice Hall, 2008
Arquiteturas:Estilos Arquitetônicos
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DISCIPLINA DE SISTEMAS DISTRIBUÍDOS
PROF. MESSIAS R. BATISTA