Introdução a sistemas

distribuídos
Professor: Marcos Bião
Revisão

• Citem exemplos de recursos de hardware ou software que

podem ser compartilhados com sucesso. Dê exemplos
práticos de compartilhamento.
Revisão

• O que é transparência? Cite exemplos.

Índice

• Introdução
• Arquitetura em SD
• Referências
Introdução

• O que é arquitetura?
• Arte e ciência de projetar e supervisionar a construção de edifícios ou outras
estruturas que, por envolverem uma ordenação plástica aliada a concepções
técnicas e funcionais, possam expressar os valores estéticos e as necessidades
práticas das sociedades em seus diferentes momentos e, desse modo, abrigar
os diversos tipos de atividades humanas; arquitetônica.

Dicionário Aurélio
Introdução

• O que é arquitetura?
• Um modelo de arquitetura define a forma que os componentes do
sistema interagem e a maneira que eles são mapeados em uma
rede de computadores

Sistemas distribuídos – Coulouris – 4ªed

Introdução

• Base para garantir que a estrutura do sistema atenderá sua atual e provável
futura demanda em termos de atributos de qualidade
• Descrição simplificada e abstrata dos componentes do sistema:
• Funcionalidades (ou responsabilidades)
• Servidor, cliente, peer

• Distribuição física (recursos e carga de trabalho)

• Regras de particionamento e/ou replicação

• Padrões de interação e comunicação

• Cliente-servidor, ponto-a-ponto
Estilos de arquitetura

• Estilos de arquiteturas
• Camadas

• Baseada em objetos

• Centrada em dados

• Eventos
Estilos de arquitetura

• Arquitetura em camadas
• 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;

Estilos de arquitetura
Estilos de arquitetura

• Arquitetura baseada em objetos

• 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.
Estilos de arquitetura
Estilos de arquitetura

• Arquitetura centrada em dados

• Processos se comunicam por meio de um repositório comum

• Tem grau de importância similar as baseadas em camadas e objetos

• Funcionamento:
• Trabalha com o compartilhamento de arquivos.
Estilos de arquitetura
Estilos de arquitetura

• Arquitetura baseada em eventos

• 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.
Estilos de arquitetura
Estilos de arquitetura

• Espaços compartilhados
• Combinação das arquiteturas baseadas em eventos e centrada em dados
• Processos independem do tempo
Estilos de arquitetura

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
Arquitetura de sistemas

• Arquitetura de sistemas distribuídos

• Divisão de responsabilidade entre os componentes do sistema e a
atribuição destes nos diversos computadores de uma rede.
• Esses modelos são divididos em:

• Arquitetura centralizada
• Arquitetura descentralizada
• Arquitetura híbrida
Arquitetura centralizada

• Cliente-Servidor
• Processos são divididos em 2 grupos
• Servidor: implementa um serviço especifico, gerenciam recursos e
controle de acesso
• Cliente: processo que requisita um serviço do servidor

• Comportamento de requisição-resposta
Arquitetura centralizada

• Cliente-Servidor
• Funcionamento
• Protocolo simples (em rede confiável)
• Cliente envia mensagem para servidor com os dados de entrada
• Servidor processa a mensagem
• Empacota os dados de resposta e envia ao cliente
Arquitetura centralizada
Arquitetura centralizada

• Cliente-Servidor
• Vejamos o seguinte caso:

• O cliente faz a requisição de saque no valor de R$ 10.000,00

• Não obteve resposta do servidor

• O que fazer?
Arquitetura centralizada

• Cliente-Servidor
• Pode-se imaginar as seguintes situações:
• O servidor não recebeu a requisição, por isso não respondeu
• O servidor recebeu a mensagem corrompida, não sabendo o que fazer
• O servidor recebeu a requisição correta, processou, mas não conseguiu enviar a resposta
ao cliente
• Se a resposta foi perdida, reenviar pode resultar em perda de dinheiro
Arquitetura centralizada

• Cliente-Servidor
• Pode-se imaginar outra situação:
• “Informe meu saldo”

• Essa ação pode ser realizada diversas vezes sem prejudicar o cliente
Arquitetura centralizada

• Cliente-Servidor
• Soluções?

• Operações que podem ser repetidas várias vezes sem causar dano são chamadas de
idempotente
• Não existe soluções únicas para tratamento de mensagens perdida
• Alternativa é a utilização de protocolos confiáveis orientados a conexão
• Garantindo que sempre que um cliente requisitou um serviços, antes ele estabeleceu
uma conexão com o servidor e só em seguida enviou a requisição
Arquitetura centralizada

• Cliente-Servidor (Camadas de aplicação)

• Como estabelecer uma distinção clara entre um cliente um servidor?

• Um servidor para um banco de dados distribuídos pode agir continuamente como um

cliente porque está repassando requisições para diferentes servidores de arquivos
responsáveis pela implementação das tabelas do banco de dados
• Processa consultas
Arquitetura centralizada

• Cliente-Servidor (Camadas de aplicação)

• É 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
Arquitetura centralizada

• Cliente-Servidor (Nível de interface de usuário)

• Contem tudo que é necessário para interação do usuário
• Gerenciamento de exibição, por exemplo
• Implementado no cliente
• Distinção de níveis de usuários
• Interfaces modernas trazem diversas funcionalidades

• Caso 1: buscador web

• Caso 2: Sistema de decisão para corretora de valores
Arquitetura centralizada

• Cliente-Servidor (Nível de processamento)

• Contém as aplicações
• Muitas vezes aplicações distintas que se comunicam entre si

• Caso 1: Google Docs

Arquitetura centralizada

• Cliente-Servidor (Nível de dados)

• Gerenciam os dados que estão sofrendo alguma ação
• Persistência – dados não são perdidos
• O nível de dados consiste em um sistema de arquivo, porém é mais comum
utilizar um banco de dados plenamente capacitado
• É implementado no lado do servidor
Arquitetura centralizada

• Cliente-Servidor (Arquiteturas Multidivididas)

• 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
• Em modo geral tem-se:

• Máquina cliente ▪ Contém apenas os programas que implementam o nível (parte do

nível) de interface de usuário
• Máquina do servidor ▪ Contém o resto, ou seja, os programas que implementam o nível
de processamento e de dados.
Arquitetura centralizada
Arquitetura centralizada

• Cliente-Servidor (Arquiteturas Multidivididas)

• Deve-se lembrar que um servidor também pode ser um cliente
Arquitetura descentralizada

• O cliente ou o servidor podem ser subdivididos fisicamente em partes

logicamente equivalentes
• Cada parte opera em sua própria porção do conjunto
• Busca-se o equilíbrio da carga
• Exemplo: peer-to-peer
Arquitetura descentralizada

• Arquitetura peer-to-peer
• De uma perspectiva de alto nível, os processos que constituem um sistemas
peer-to-peer são todos iguais, o que significa que as funções que precisam ser
realizadas são representadas por todo processo que constitui o sistema
distribuído
• Organizam os processos por meio de uma tabela de hash distribuída
• DHT implementa um mapeamento de chave do item para um nó baseando
por distâncias métricas
Arquitetura descentralizada

• Arquitetura peer-to-peer
• De uma perspectiva de alto nível, os processos que constituem um sistemas
peer-to-peer são todos iguais, o que significa que as funções que precisam ser
realizadas são representadas por todo processo que constitui o sistema
distribuído
• Organizam os processos por meio de uma tabela de hash distribuída
• DHT implementa um mapeamento de chave do item para um nó baseando
por distâncias métricas
Arquitetura descentralizada

• Arquitetura peer-to-peer
• Sistema Chord (stoica et. al. 2003)
• Organização em anel
• Um nó K, mapeia nós com identificação menor
• Para consultar um item em um determinado nó, deve-se acessar o nó sucessor primeiro
Arquitetura descentralizada
Arquitetura descentralizada

• Arquitetura peer-to-peer (rede de sobreposição)

• Um nó mantém atalhos para outros nós
• Admite-se que itens de dados sejam colocados aleatoriamente em nós
• A busca de um item de dado na rede é realizada por uma consulta em toda a
rede
• O grande foco desta arquitetura é o gerenciamento de associação ao grupo
• Sua estrutura é similar a um gráfico aleatório
• A lista de vizinhos é denominada visão parcial
Arquitetura descentralizada

• Arquitetura peer-to-peer (superpares)

• 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;
Arquitetura descentralizada

• Arquitetura peer-to-peer (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;
Arquitetura descentralizada
Arquitetura descentralizada

• Arquitetura peer-to-peer (superpares)

• O que acontece caso um superpar caia?

• Espera-se que um superpar tenha vida longa e alta disponibilidade

• Esquema de segurança
• Pares de superpar
• Pares comuns devem ser ligados a 2 superpares

• Problema de eleição de lideres

Arquitetura descentralizada

• Arquitetura híbrida

• São arquitetura que utilizam características tanto da arquitetura centralizada

quanto da arquitetura descentralizada

• Tentam usufruir das vantagens de cada uma delas

Arquitetura descentralizada
Arquitetura vs Middleware

• O middleware forma uma camada entre aplicações e plataformas

distribuídas
• Finalidade: proporcionar um grau de transparência de distribuição
• A especificidade do estilo arquitetônico é para simplificar projetos de
aplicações
• Apesar de sua finalidade, considera-se tê-lo para ser mais adaptável
as requisições de aplicação
• Uma abordagem geral considera melhor é fazer sistemas de
middleware de modo que sejam simples de configurar, adaptar e
personalizar conforme necessário para uma aplicação
Arquitetura vs Middleware

• Interceptadores
• É um constructo de software que interromperá o fluxo de controle usual e
permitirá que seja executado um outro código
• Funciona com alto suporte em sistemas distribuídos orientado à objetos
• Um objeto A pode chamar um método que pertence a um objeto B enquanto
este residir em uma máquina diferente de A
Arquitetura vs Middleware

• Interceptadores
• Esse processo é dividido em 3 etapas

1. É oferecida ao objeto A uma interface local que é exatamente a mesma oferecida pelo
objeto B. A simplesmente chama o método disponível naquela interface

2. A chamada por A é transformada em uma invocação a objeto genérico, possibilitada por

meio de uma interface geral de invocação de objeto oferecida pelo middelware na
máquina em que A reside

3. Por fim, a invocação a objeto genérico é transformada em uma mensagem que é enviada
por meio de uma interface de rede de nível de transporte como oferecida pelo sistema
operacional local de A.
Arquitetura vs Middleware
Discussões

• Situação 1:
• Requisitos extrafuncionais conflitam com a meta 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ão predominante como no caso do middleware”
• Assim, a necessidade se torna uma premissa:
• São necessárias softwares adaptativos no sentido de que permitir mudança à medida
que o ambiente se altera
Discussões

• Por que sistemas distribuídos precisam desse software adaptativo?

• “O argumento mais forte e por certo o mais válido para suporte

software adaptativo é que muitos sistemas distribuídos não podem
ser desligados”
Discussões

• Sistemas distribuídos devem ser capazes de reagir a mudanças em

seu ambiente
• Exemplo: trocar de políticas de alocação de recursos
• O desafio conclusivo é deixar este comportamento reativo e sem a
necessidade de intervenção humana
Atividade

• Em grupos de 3 a 5 alunos, construam um quadro comparativo entre

sistemas cliente-servidor e sistemas P2P. Os alunos devem discutir
entre si quais métricas devem ser levadas em consideração.
Referências

• COULOURIS, George, Sistemas

Distribuídos: Conceitos e Projeto
[recurso eletrônico, Minha
Biblioteca].São Paulo, Bookman, 2013.