# data[].attributes.headline
Caracterização deSistemas Distribuídos PDF afundo 

# data[].attributes.subject
Caracterização deSistemas Distribuídos PDF afundo 

# data[].attributes.attachment_link.readable_text
Uma vez que a sociedade aderiu à mobilidade constante, aplicações devem disponibilizar dados em tempo real - não apenas o resultado final em uma tabela armazenada em um banco de dados, mas também todas as ações executadas por um usuário da solução. Qualquer informação compartilhada, como cliques, log data ou sensor data, é utilizada para aprimorar a experiência, gerar relatórios, alimentar sistemas de machine learning e por aí vai. Hoje, desenvolvedores devem voltar suas atenções a sistemas baseados no fluxo de eventos em tempo real.

A imagem a seguir mostra um exemplo de uma arquitetura baseada no processamento do fluxo de eventos:

IBM Event Streams é uma instância gerenciada Kafka para sua empresa.

Apache Kafka é uma solução indicada para a criação de sistemas escaláveis de eventos complexos. A ferramenta proporciona recursos constantemente aprimorados para plataformas de streaming de eventos que desenvolvedores podem usar em soluções avançadas de negócios. Contudo, eles frequentemente precisam integrar soluções Java empresariais baseadas em tecnologias como IBM MQ ou IBM WebSphere Application Platform às novas arquiteturas.

Considere o seguinte exemplo. Uma loja virtual possui um aplicativo que utiliza Kafka para enviar dados de pagamento a um sistema de pagamento distribuído implementado em Java empresarial. A solução deve fornecer garantia absoluta de processar uma solicitação de pagamento uma única vez (para evitar cobranças múltiplas do comprador). Contudo, falhas são inevitáveis em um sistema distribuído, então a solução precisa lidar com os problemas da melhor maneira possível.

Implementando messaging com Apache Kafka

Apache Kafka é um sistema distribuído utilizado para processamento de fluxo de eventos amplamente utilizado em arquiteturas de microsserviços e ambientes baseados em nuvem. Ele fornece mensagens, armazenamento e processamento de eventos - tudo na mesma plataforma.

A imagem abaixo mostra uma topologia básica dos componentes do Apache Kafka, formados por produtores e consumidores que trocam mensagens por meio da infraestrutura do cluster Kafka:

Mesmo que traga muitas vantagens, Kafka enfrenta problemas como:

Lógica de compensação manual nos casos de falhas de processamento de mensagens, o que pode resultar no não processamento dos dados.

Falta de suporte de processamento para transações XA.

Garantia de somente um processamento de entrega nas aplicações do consumidor.

Esforço extra de desenvolvimento e manutenção para a integração da ferramenta a soluções empresariais.

Para resolver essas questões, é possível aplicar os conceitos topológicos tradicionais de messaging, como logs de transação, logs de recuperação e transações XA, assim como implementar um adaptador de recursos baseado no Java EE Connector Architecture (JCA). Com essa alternativa, você pode fornecer recursos ACID ao servidor, visando implementar o processamento de mensagens Kafka. O JCA então fornece uma integração adequada de suas aplicações com soluções JAVA EE.

Implementando o adaptador de recursos JCA

O Java EE Connector Architecture define uma série de mecanismos transacionais escaláveis e seguros. É possível instalar o adaptador JCA em qualquer aplicação compatível com Java EE, como IBM Websphere Application Server, IBM Business Process Manager, JBoss, WebSphere Liberty, Glassfish ou Weblogic.

Suas especificações também trazem uma série de contratos padronizados que possibilitam a comunicação entre aplicações empresariais e sistemas de informação, como o Kafka. Além disso, o JCA pode funcionar como um plugin no servidor, habilitando a integração com Kafka e gerenciando todos os níveis dos mecanismos do sistema (transações, gerenciamento de conexão, recuperação de falhas, detecção de erros e logging). Além disso, o adaptador esconde qualquer lógica de comunicação pertencente ao Kafka necessária à integração de aplicações empresariais. Ao implementar o adaptador de recursos JCA, o provedor pode se voltar à estruturação de estratégias e lógicas de apresentação relacionadas ao Kafka - mesmo as mais avançadas. Portanto, o adaptador é desenvolvido uma única vez e pode ser reutilizado em diferentes aplicações.

Vamos relacionar a solução ao nosso cenário de pagamentos observando o seguinte diagrama, que mostra o contexto do sistema da estratégia planejada:

A aplicação mobile envia os dados da solicitação de pagamento para o Kafka, que está integrado à aplicação da empresa por meio do adaptador. Além disso, notificações de pagamento são enviadas por meio da solução. O adaptador, então, inicia uma transação XA, enviada ao sistema empresarial e também ao sistema de notificações. Portanto, todas as tarefas relacionadas ao processamento da solicitação do pagamento vão ser executadas na mesma transação global e poderão ser concluídas com sucesso ou falhar todas juntas. A estrutura exige configurações de tópicos de novas tentativas, dead letters e log de transações no Kafka, bem como aqueles já criados para leitura ou escrita.

Vamos explorar, agora, mais detalhadamente o processamento de mensagens enviadas da e para a aplicação mobile.

Fluxo de entrada

Em nosso cenário de pagamento, o fluxo de entrada diz respeito à comunicação iniciada pela aplicação mobile da loja online, que envia os dados de pagamento solicitados para o Kafka. O adaptador fornece conectividade e entrega mensagens assincronamente para os endpoints existentes no servidor da aplicação. Isso pode ser feito por meio de um contrato inflow determinado pela especificação JCA.

O adaptador de recursos Kafka JCA implementa uma especificação de ativação JavaBean com uma série de propriedades utilizadas para a configuração de ativação do endpoint. Os detalhes dessas configurações são definidos como parte de uma configuração do servidor da aplicação.

O adaptador de recursos consulta periodicamente um lote de solicitações de pagamento no tópico inbound do Kafka. Depois disso, ele itera pelo lote de dados e entrega mensagens assincronamente às instâncias endpoint. Múltiplas instâncias endpoint podem existir para cada endpoint de mensagem, o que possibilita consumo concorrente de mensagens e proporciona alta taxa de transferência.

O offset consumidor do Kafka é confirmado logo após o agendamento de entrega de mensagem, para evitar problemas com lotes bloqueados. Essa estrutura é viável porque o adaptador implementa procedimentos de tolerância a falhas por meio de novas tentativas, dead letters e tópicos log de transações que precisam ser configurados no Kafka. Em nosso caso, o endpoint precisa suportar transações XA, e o contexto de transação tem de ser criado antes do envio de dados para o endpoint, proporcionando assim um alto consumo de mensagens.

Caso a transação fosse recusada pelo servidor da aplicação, todo o trabalho realizado pela instância endpoint teria de ser revertido e a mensagem precisaria ser encaminhada ao tópico de nova tentativa do Kafka.

O adaptador consome mensagens do tópico de novas tentativas do Kafka e as processa novamente. Depois que o número de definido de novas tentativas é excedido, o adaptador transfere a mensagem ao tópico de dead letters do Kafka. Pelo fato de essas mensagens possuírem dados valiosos, é importante monitorar o tópico.

Fluxo de saída

Esse fluxo diz respeito à comunicação iniciada pela aplicação da empresa. Em nosso caso, esse sistema é utilizado para enviar confirmações de pagamento para a aplicação mobile. A especificação JCA define o contrato de gerenciamento de conexão, que ativa um servidor de aplicativos para agrupar conexões Kafka. Dessa maneira, proporciona um ambiente escalável que suporta um grande número de clientes.

Os detalhes da configuração de uma conexão outbound Kafka são definidos por meio de Managed Connection Factory JavaBean . Se valendo desses detalhes, o adaptador permite a administradores e desenvolvedores configurar o produtor Kafka e aproveitar recursos como confiabilidade, disponibilidade, taxa de transferência, latência e suporte de transação. Tais especificações são definidas como parte da configuração do servidor da aplicação.

O adaptador de recursos Kafka JCA expõe o Kafka Connection Factory e o Kafka Connection que implementam o CCI (Common Client Interface), assim como as interfaces do JMS (Java Message Service). Um componente do aplicativo procura uma connection factory utilizando o nome JNDI (Java Naming and Directory Interface). Depois de obtê-la, a aplicação a usa para conseguir uma conexão e acessar o Kafka. Dessa maneira, é possível adicionar uma integração Kafka ao aplicativo do sistema de notificação, que atualmente envia dados para provedores de sistemas de mensagens JMS, como IBM MQ ou Active MQ.

O fluxo de saída do adaptador de recursos encapsula lógica de comunicação low-level Kafka e faz o seguinte:

Pool de conexão.

Usa mecanismos transacionais Kafka para garantir entrega única.

Cuida da identificação, do registro e do manuseio de falhas do Kafka normalmente.

Implementa transações XA e, portanto, fornece processamento confiável de mensagens com Kafka em sistemas distribuídos.

Para gerenciar transações dentro do fluxo de saída, o adaptador de recursos utiliza o contrato de gerenciamento de transações definido pela JCA Specification.

No nosso exemplo, a connection factory precisa ser ajustada para suportar transações XA, e o adaptador precisa iniciar a transação Kafka quando o cliente obtém a conexão. A transação Kafka deve ser cancelada se o servidor reverter a conexão. No caso de uma confirmação de transação XA, o gerenciador de transações executa um protocolo de confirmação de duas etapas em todos os recursos que participam da transação em execução. Isso garante que todo acesso de leitura/escrita aos recursos gerenciados seja confirmado ou revertido.

Por fim, o adaptador de recursos mantém o rastreamento de transações em andamento registrando dados no tópico de log de transação Kafka. Os dados registrados são utilizados em processos de reembolso, pois fornecem processamento confiável de mensagens em um sistema distribuído.

A estratégia de configurar um adaptador JCA Kafka garante uma integração "plug and play" entre JMS e processamento de eventos complexos para soluções com padrões empresariais Java. Esse design permite integrar perfeitamente o Kafka aos aplicativos corporativos existentes, sem a necessidade de implementar a lógica de compensação. Além disso, o adaptador possibilita que um servidor forneça a infraestrutura, o ambiente de tempo de execução para conectividade Kafka e o gerenciamento de transações necessário à estabilidade do sistema da empresa.
...
Quer ler mais conteúdo especializado de programação? Conheça a IBM Blue Profile e tenha acesso a matérias exclusivas, novas jornadas de conhecimento e testes personalizados. Confira agora mesmo, consiga as badges e dê um upgrade na sua carreira!

# data[].attributes.attachment_link.title
Estruturando uma infraestrutura de mensagens de alta performance com Kafka

# data[].attributes.attachment_link.description
Uma vez que a sociedade aderiu à mobilidade constante, aplicações devem disponibilizar dados em tempo real - não apenas o resultado final em uma tabela armazenada em um banco de dados, mas também todas as ações executadas por um usuário da solução.

# data[].attributes.attachment_link.readable_text
Um sistema de processamento distribuído ou paralelo é um sistema que interliga vários nós de processamento (computadores individuais, não necessariamente homogéneos) de maneira que um processo de grande consumo seja executado no nó "mais disponível", ou mesmo subdividido por vários nós. Conseguindo-se, portanto, ganhos óbvios nestas soluções: uma tarefa qualquer, se divisível em várias subtarefas pode ser realizada em paralelo.

A nomenclatura geralmente utilizada neste contexto é HPC ( High Performance Computing) e/ou DPC ( Distributed/Parallel Computing).

Este é um assunto muito vasto e, embora com alguma idade, só em 2001 se começou a falar em padrões para estas soluções, que são utilizadas (em larga escala) geralmente nos meios científicos e outros de cálculo intensivo pela sua extensibilidade. São bastante flexíveis, já que permitem a coexistência de sistemas desenhados especificamente para isso (por exemplo, a arquitectura NUMA), de sistemas desktop, e mesmo de sistemas considerados obsoletos, mas não o suficiente para permitir a coexistência de soluções semelhantes.

Antes de avançar, será necessário distinguir um sistema de multiprocessamento paralelo (SMP) de um sistema distribuído. Para um sistema ser de processamento distribuído, uma ou várias unidades de processamento ( CPU) estará separada fisicamente da(s) outra(s), enquanto que num sistema SMP todas as unidades de processamento se encontram na mesma máquina. Ambos sistemas são capazes de processamento paralelo, e qualquer um deles pode ser visto como elemento de um sistema distribuído!

Com os desenvolvimentos nesta área, surgiram soluções por software que fazem, geralmente (mas não necessariamente), alterações no núcleo do sistema operativo e que, na maioria dos casos, não são compatíveis entre elas, e dificilmente entre versões diferentes da mesma solução. Assentam, no entanto, em arquitecturas de comunicação padrão, como é o caso da Parallel Virtual Machine e Message Passing Interface. Resumidamente, estas arquitecturas conseguem transportar um processo (tarefa) e o seu contexto (ficheiros abertos, etc.) pela rede até outro nó. O nó que originou o processo passa, assim, a ser apenas um receptor dos resultados desse processo.

Actualmente, a principal barreira destes sistemas é implementar mecanismos de Inter-Process Communication (IPC), os Distributed IPC, dada a sua extrema complexidade.

A Figura 1 ilustra as várias camadas de interoperabilidade de um sistema distribuído. Através do a rede pública tem acesso a um supercomputador, sem ter conhecimento disso, dado que só conhece o gateway. Qualquer aplicação executada no gateway (preparada para ser paralelizada) pode ser distribuída por vários nós, entregando os resultados mais rápido do que se fosse processada por apenas um nó.

De acordo com TANENBAUM, "Um sistema distribuído é um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente"

Já para COULORIS, "Definimos um sistema distribuído como sendo aquele no qual os componentes de hardware ou software, localizados em computadores interligados em rede, se comunicam e coordenam ações apenas enviando mensagens entre si."

Assim, a computação distribuída consiste em adicionar o poder computacional de diversos computadores interligados por uma rede de computadores. A união desses diversos computadores com o objetivo de compartilhar a execução de tarefas, é conhecida como sistema distribuído.

Abaixo características de um sistema distribuído. Conforme definição de COULORIS :

Segurança: A criptografia pode ser usada para proporcionar proteção adequada para os recursos compartilhados e para manter informações sigilosas em segredo, quando transmitidas em mensagens de uma rede. Os ataques de negação de serviço ainda são um problema.

Escalabilidade: um sistema distribuído é considerado escalável se o custo de adição de um usuário for um valor constante, em termos dos recursos que devem ser adicionados. Os algoritmos usados para acessar os dados compartilhados devem evitar gargalos de desempenho, e os dados devem ser estruturados hierarquicamente para se obter os melhores tempos de acesso. Os dados acessados frequentemente podem ser replicados.

Tratamento de falhas: qualquer processo, computador ou rede pode falhar, independentemente dos outros. Portanto, cada componente precisa conhecer as maneiras possíveis pela quais os componentes de que depende podem falhar e ser projetado de forma a tratar cada uma dessas falhas apropriadamente.

Concorrência: a presença de múltiplos usuários em um sistema destruído é uma fonte de pedidos concorrentes para seus recursos. Em ambiente concorrente, cada recurso deve ser projetado para manter a consistência nos estados de seus dados.

Transparência: o objetivo é tornar certos aspectos da distribuição invisíveis para o programador de aplicativos, param que este se preocupe apenas com o projeto de seu aplicativo em particular. Por exemplo, ele não precisa estar preocupado com sua localização ou com os detalhes sobre como suas operações serão acessadas por outros componentes, nem se será replicado ou migrado. As falhas de rede e processos podem ser apresentadas aos programadores de aplicativos na forma de exceções - mas elas devem ser tratadas.

Organizar a interação entre cada computador é essencial. Visando poder usar o maior número possível de máquinas e tipos de computadores, o protocolo ou canal de comunicação não pode conter ou usar nenhuma informação que possa não ser entendida por certas máquinas. Cuidados especiais também devem ser tomados para que as mensagens sejam entregues corretamente e que as mensagens inválidas sejam rejeitadas, caso contrário, levaria o sistema a cair ou até o resto da rede.

Outro fator de importância, é a habilidade de mandar softwares para outros computadores de uma maneira portável de tal forma que ele possa executar e interagir com a rede existente. Isso pode não ser possível ou prático quando usando hardware e recursos diferentes, onde cada caso deve ser tratado separadamente com cross-compiling ou reescrevendo software.

Peer-to-peer (P2P)

É uma arquitetura de sistemas distribuídos caracterizada pela descentralização das funções na rede, onde cada nó realiza tanto funções de servidor quanto de cliente.

Objetos distribuídos

Semelhante ao peer-to-peer (do inglês peer-to-peer, que significa ponto-a-ponto) é um formato de rede de computadores em que a principal característica é descentralização das funções convencionais de rede, onde o computador de cada usuário conectado acaba por realizar funções de servidor e de cliente ao mesmo tempo.

Seu principal objetivo é a transmissão de arquivos e seu surgimento possibilitou o compartilhamento em massa de músicas e filmes. Com a crescente utilização da rede P2P para este fim, cada vez mais surgem programas para este fim, porém nem sempre eles atendem às expectativas do usuário.

Diversas redes operam hoje em dia nestes moldes de compartilhamento, entre elas Kademlia, Gnutela, Kad Network e SoulSeek. Alguns programas valem a pena ser citados quando o assunto é compartilhamento P2P: μTorrent, BitTorrent, SoulSeek, Ares Galaxy, Shareaza, DreaMule, iMesh e Morpheus. Caso prefira, acesse a categoria de Compartilhadores P2P do Baixaki e conheça mais programas que operam deste modo.

Mas com um Middleware intermediando o processo de comunicação.

A organização do hardware em sistemas com várias UCPs se dá por:

Sistemas paralelos

É constituído de vários processadores tipicamente homogêneos e localizados em um mesmo computador.

Multicomputadores - Cada processador possui sua própria memória local.

Multiprocessadores - Os processadores compartilham memória.

Arquiteturas

Multiprocessadores em barramento.

Multiprocessador.

Multiprocessador homogêneo.

Multiprocessador heterogêneo.

Fracamente acoplados - um software que serve de interface entre o computador (hardware) e os humanos (peopleware) , que permite a execução de diversos outros softwares (aplicativos)....

Fortemente acoplados - permitem que máquinas e usuários de um sistema distribuído sejam fundamentalmente independentes e ainda interagir de forma limitada quando isto for necessário, compartilhando discos, impressoras e outros recursos.

Sistema operacional (SO) é um software que serve de interface entre o computador (hardware) e os humanos (peopleware) , que permite a execução de diversos outros softwares (aplicativos).

SO de máquinas monoprocessadas.

SO Multiprocessadores é uma extensão de SOs de máquinas monoprocessadas, a principal diferença sendo que os dados da memória são acessados por vários processadores e, portanto, necessitam de proteção com relação aos acessos concorrentes.

SOs Multicomputadores são uma alternativas para o buffering de mensagens e pontos de bloqueio, alguns SOs disponibilizam uma abstração de memória compartilhada.

SOs de rede: existe uma independência entre os computadores.

Sistemas fortemente acoplados Neste sistema existe vários processadores compartilhando uma memória, e gerenciado por apenas um S.O.

Múltiplos processadores permitem que vários programas sejam executados ao mesmo tempo e em tempo real.Com isso será possível aumentar a capacidade de computação adicionando apenas processadores.

# data[].attributes.attachment_link.title
Sistema de processamento distribuído - Wikipédia, a enciclopédia livre

# data[].attributes.attachment_link.description
Um sistema de processamento distribuído ou paralelo é um sistema que interliga vários nós de processamento (computadores individuais, não necessariamente homogéneos) de maneira que um processo de grande consumo seja executado no nó "mais disponível", ou mesmo subdividido por vários nós.