MBA Full Stack Developer –

Microservices, Cloud e IoT

Aula 2
Estilos de Comunicação
Síncrono e Assíncrono
Microsserviços Síncronos
Síncrono

Um microsserviço é síncrono se fizer uma solicitação para outros

microsserviços e durante o processamento da solicitação
aguarda o resultado.
Síncrono
Síncrono

A comunicação síncrona e assíncrona de acordo com esta

definição é independente do protocolo de comunicação
Síncrono

Em geral, o estilo síncrono melhora a consistência dos dados,

porque os serviços armazenam cada parte dos dados usando o
contexto vinculado e outros serviços consomem esses dados.
Síncrono
Benefícios
Síncrono

Todos os serviços podem acessar o mesmo conjunto de dados,

portanto, há menos problemas de consistência.
Síncrono

A comunicação síncrona é uma abordagem natural se o sistema

oferecer uma API. Qualquer microsserviço pode implementar
parte da API. A API pode ser o produto. É esse o caso, por
exemplo, como um provedor de soluções de pagamento. Ou a API
pode ser usada por aplicativos móveis.
Síncrono

Pode ser mais fácil migrar para essa arquitetura. Por exemplo, a
atual arquitetura já pode ter essa divisão em
diferentes endpoints de comunicações síncronas ou equipes
podem existir para cada uma das funcionalidades
Síncrono

Chamar métodos, procedimentos ou funções em um programa

geralmente é síncrono. Os desenvolvedores são familiarizados
com este modelo, para que possam entendê-lo mais facilmente.
Síncrono

Existem várias ferramentas que permitem o troubleshooting o

tracing, como Jaeger e Opentracing Standard
Desafios
Síncrono

A comunicação com outros microsserviços durante

o processamento da solicitação causa as latências respostas de
outros microsserviços e os tempos de comunicação via rede para
adicionar acima. Portanto, a comunicação síncrona pode levar a
um problema de desempenho. Como quanto o microsserviço
reage lentamente, isso pode ter consequências para outros
microsserviços.
Síncrono

Quando um microsserviço síncrono chama um microsserviço com

falha, o microsserviço de chamada também pode travar e, assim,
propagar a falha. Isso torna o sistema muito vulnerável. A
vulnerabilidade dos microsserviços e a adição de tempos de
espera podem impedir a operação confiável de sistemas de
microsserviços com comunicação síncrona
Síncrono

A comunicação síncrona pode criar um nível mais alto de

dependência no domínio lógico. Além disso, a comunicação
síncrona geralmente define o que um microsserviço deve fazer.
Dicas
Síncrono

Os microsserviços precisam saber como eles podem se comunicar

com outros microsserviços. Usualmente, isso requer um endereço
IP e uma porta. Service discovery serve para encontrar a porta e o
endereço IP de um serviço. Além disso, um microsserviço pode
falhar, tornando-o indisponível no endereço IP conhecido.
Síncrono

Quando a comunicação é síncrona, os microsserviços precisam

estar preparados para a falha de outros microsserviços.
O microsserviço de chamada também deve ser impedido de
falhar. Caso contrário, uma cascata de falhas ocorre quando o
primeiro microsserviço falha. No final, todo o sistema estará
inoperante
Síncrono

Cada microsserviço deve ser escalável independentemente dos

outros microsserviços. A carga deve ser distribuído entre
microsserviços. Isso não só diz respeito ao acesso de fora, mas
também para comunicação interna. Portanto, deve haver um load
balancing para cada microsserviço.
Síncrono

Finalmente, todo acesso externo deve ser encaminhado aos

microsserviços responsáveis. Isso requer roteamento. Um usuário
pode querer usar o catálogo e o processo de pedido. Apesar deles
serem microsserviços separados, devem aparecer como partes do
mesmo sistema para o exterior.
Síncrono

Obrigado API Gateway Pattern

Microsserviços Assíncronos
Assíncrono

Um microsserviço é assíncrono (a) se não fizer uma solicitação a

outros microsserviços enquanto fizer o processamento de
solicitações ou (b) solicita a outros microsserviços ao processar
solicitações e não esperar pelo resultado.
Assíncrono

A. O microsserviço não se comunica com outros sistemas durante

o processamento de uma solicitação. Nesse caso, o microsserviço
normalmente se comunica com os outros
sistemas em um momento diferente. Por exemplo, o
microsserviço pode replicar dados usados ao processar uma
solicitação. Dessa forma, os dados do cliente podem ser
replicados para que, ao processar um pedido, o microsserviço
possa acessar os dados do cliente disponíveis localmente.
Assíncrono
Assíncrono

B. O microsserviço envia uma solicitação para outro microsserviço,

mas não espera por uma resposta. Um microsserviço responsável
pelo processamento de um pedido pode enviar uma solicitação
para outro microsserviço que gera a fatura. Uma resposta a esta
solicitação não é necessária para processar o pedido, não sendo
necessário aguardá-lo.
Assíncrono
Replicação de Dados &
Bounded Context
Assíncrono

Isso se torna mais complicado se forem necessários dados para

executar uma solicitação. Por exemplo, no catálogo, no processo
do pedido e para a fatura, os dados sobre produtos e clientes
devem estar disponíveis. Assim cada um dos sistemas armazena
uma parte das informações sobre esses objetos de negócios.
Assíncrono

O catálogo deve exibir os produtos, para que ele tenha fotos e

descrições dos produtos. Para faturas, preços e taxas de imposto
são importantes. Isso corresponde aos bounded contexts,
cada um dos quais tem seu próprio modelo de domínio
Assíncrono

Cada bounded contexts tem seu próprio modelo de domínio. Isso

significa que todos os dados para o bounded
contexts são representados em seu modelo de domínio. Portanto,
os dados específicos para o bounded contexts devem ser
armazenados no bounded contexts em seu próprio esquema de
banco de dados. Outros bounded contexts não devem acessar
esses dados diretamente, o que comprometeria o
encapsulamento. Em vez disso, os dados devem ser acessados
apenas pela lógica no contexto limitado e sua interface.
Assíncrono

Embora seja possível ter um sistema que contenha todas as

informações sobre, por exemplo, um produto, isso não faria muito
sentido. O modelo do sistema seria muito complicado.
Também significa que o modelo de domínio seria dividido em,
digamos, um sistema para um processo de pedido e um sistema
para os dados do produto. Isso levaria a um acoplamento muito
apertado.
Assíncrono

Um terceiro sistema, como o registro de dados do cliente ou a

listagem de dados do produto, deve aceitar todos os dados e
transferir as partes necessárias dos dados para os respectivos
sistemas. Isso também pode ser feito de forma assíncrona. Os
outros contextos limitados armazenam as informações sobre
produtos e clientes em seus bancos de dados locais, tornando a
replicação apenas o resultado do processamento de eventos.
Assíncrono

Um evento como "novo produto adicionado" faz com que cada

contexto limitado adicione alguns dados ao seu modelo de
domínio. O registro ou a listagem não precisam armazenar os
dados. Depois de enviar os dados para os outros microsserviços, o
trabalho deles é concluído.
Desafios
Assíncrono

Devido à comunicação assíncrona, o sistema é não consistente.

Alguns microsserviços já possuem certas informações, outras não.
Por exemplo, o processo de pedido já pode ter informações sobre
um pedido, mas o faturamento ou a ordem ainda não
o conhecem. Este problema não pode ser resolvido. Leva tempo
para a comunicação assíncrona alcançar todos os sistemas
Introdução Teorema CAP
Assíncrono

Essas inconsistências não são apenas problemas práticos, mas

nem sequer podem ser resolvidas em teoria. De acordo com o
teorema da PAC, existem três características em um sistema
distribuído
Assíncrono

Consistência (C) significa que todos os componentes do sistema

têm as mesmas informações.
Assíncrono

Tolerância de partição (P) significa que um sistema continuará

funcionando em caso de perda de pacote arbitrário na rede.
Assíncrono

Disponibilidade (A) significa que nenhum sistema para de

funcionar porque outro sistema falhou.
Assíncrono

O teorema CAP afirma que um sistema pode ter no máximo dois

recursos dentre esses três. A tolerância de partição é um caso
especial. Um sistema deve reagir se a rede falhar. De fato, nem
mesmo um falha completa é necessária; a perda de pacotes só
precisa ser alta ou o tempo de resposta muito longo. Um sistema
que responde muito lentamente é indistinguível de um sistema
que falhou completamente.
Algumas palavras sobre
inconsistências
Assíncrono

Portanto, a inconsistência de um sistema assíncrono é inevitável, a

menos que você queira abrir mão da disponibilidade. Portanto, é
importante conhecer os requisitos de consistência, o que requer
alguma habilidade. Os clientes querem um sistema confiável. A
inconsistência dos dados parece contradizer isso. É por isso que é
É importante saber o que acontece quando os dados estão
temporariamente inconsistentes e se isso realmente causa
problemas.
 Assíncrono

Afinal, as inconsistências geralmente desaparecem após frações

de segundo ou poucos segundos.
Além disso, certas inconsistências podem até ser toleráveis de
uma perspectiva de domínio.
Por exemplo, se as mercadorias são listadas dias antes da primeira
venda, as inconsistências são inicialmente aceitáveis e devem ser
corrigidas apenas quando as mercadorias estiverem finalmente
sendo vendidas.
Assíncrono

Se inconsistências não forem aceitáveis, a comunicação

assíncrona não é uma opção. Isso significa que a comunicação
síncrona deve ser usada com todas as suas desvantagens. Se a
tolerância para dados temporariamente inconsistentes não for
conhecida, isso pode levar a uma decisão errada em relação à
variante de comunicação.
Assíncrono

Entrega garantida
Em um sistema assíncrono, a entrega de mensagens pode ser
garantida se o sistema for implementado adequadamente. O
remetente faz com que o sistema de mensagens confirme que
recebeu a mensagem. Posteriormente, o sistema de mensagens
faz com que o destinatário da mensagem reconheça
o recebimento (acknowledge). No entanto, se o destinatário
nunca coleta os dados e, portanto, impede a entrega, o remetente
tem uma confirmação, mas a mensagem ainda não chega ao
destinatário.
Assíncrono

Idempotência
Se as mensagens não forem confirmadas (ack) pelo destinatário,
elas serão enviadas novamente. Quando o microsserviço receptor
processa a mensagem, mas não consegue reconhecê-la devido a
um problema ou falha, o destinatário recebe a mensagem uma
segunda vez, embora já tenha processado a mensagem.
Assíncrono

Portanto, normalmente, tenta-se projetar sistemas distribuídos de

maneira que os microsserviços sejam idempotentes. Isso significa
que uma mensagem pode ser processada mais de uma vez, mas o
estado do serviço não é mais alterado. Por exemplo, ao criar uma
fatura, o microsserviço de fatura pode primeiro verificar em seu
próprio banco de dados se uma fatura já foi criada. Dessa
maneira, uma fatura é criada apenas na primeira vez que a
mensagem é recebida. Se a mensagem for transferida novamente,
ela será ignorada.
Vamos falar sobre Patterns
de Comunicação
AMQP
AMQP

AMQP significa Asynchronous Message Queuing Protocol e é um

padrão aberto para sistemas de mensagens. Foi projetado
inicialmente para sistemas financeiros (comércio e bancos) e,
como tal, sobre índices de confiabilidade, escalabilidade e
capacidade de gerenciamento.
AMQP

A seguir, são apresentadas algumas das construções definidas

pela especificação AMQP: Possui um protocolo no nível do fio que
descreve os pacotes (quadros, na linguagem AMQP) trocados
entre brokers, produtores e consumidores.
AMQP

No AMQP, as mensagens são publicadas para os exchanges. As

mensagens são roteadas para diferentes queues usando regras
chamadas como bindings. Os consumidores buscam mensagens
das queues
AMQP
AMQP

A rede é considerada não confiável e os consumidores podem não

conseguir processar as mensagens. Portanto, o modelo AMQP
tem o conceito de confirmações de mensagens: quando uma
mensagem é entregue a um consumidor, o consumidor envia uma
confirmação (ack) ao broker depois de consumir a mensagem.
AMQP

Este será o gatilho para o broker remover a mensagem da queue.

Os acks geralmente são acompanhados de timeouts; se uma
mensagem não for confirmada dentro de um tempo limite, será
reenviada ao consumidor.
Conceitos
AMQP

Direct Exchange
Uma troca direta entrega mensagens para filas com base na
routing key de mensagens. Uma troca direta é ideal para o
roteamento unicast de mensagens (embora elas também possam
ser usadas para o roteamento multicast).
AMQP

Uma queue se liga ao exchange com uma chave de roteamento K

Quando uma nova mensagem com a chave de roteamento R

chega na troca direta, a central a encaminha para a fila se K = R
AMQP
AMQP

Direct exchanges costumam ser usadas para distribuir tarefas

entre vários workers (instâncias do mesmo aplicativo) de maneira
alternada.
Ao fazer isso, é importante entender que, no AMQP 0-9-1, as
mensagens são balanceadas por carga entre consumidores e não
entre queues.
AMQP

Fanout Exchange
Fanout Exchange roteia mensagens para todas as filas que estão
vinculadas a ela e a chave de roteamento é ignorada. Se N filas
estiverem vinculadas a uma troca de fanout, quando uma nova
mensagem for publicada nessa troca, uma cópia da mensagem
será entregue a todas as N filas. As trocas de fanout são ideais
para o broadcast de mensagens.
AMQP
AMQP

Os jogos massivamente multiplayer online (MMO) podem usá-lo

para atualizações do placar ou outros eventos globais

Os sites de notícias esportivas podem usar trocas de fanout para

distribuir atualizações de pontuação para clientes móveis quase
em tempo real

Os sistemas distribuídos podem transmitir várias atualizações de

estado e configuração
AMQP

* (asterisco) pode substituir exatamente uma palavra.

# (hash) pode substituir zero ou mais palavras.
AMQP

Topic exchange faz o roteamento de mensagens para uma ou

várias filas com base na correspondência entre uma routing key
de mensagens e o padrão usado para ligar uma queue ao
exchange. O tipo de troca de tópicos é frequentemente usado
para implementar várias variações de padrão de publicação /
assinatura. Trocas de tópicos são comumente usadas para o
roteamento multicast de mensagens.
AMQP

Topic exchange têm um conjunto muito amplo de casos de uso.

Sempre que um problema envolve vários consumidores /
aplicativos que escolhem seletivamente quais tipos de mensagens
eles desejam receber, o uso de trocas de tópicos deve ser
considerado.
AMQP

Distribuir dados relevantes para uma localização geográfica

específica, por exemplo, pontos de venda
Processamento de tarefas em segundo plano feito por vários
workers, cada um capaz de lidar com um conjunto específico de
tarefas
Atualizações de notícias que envolvem categorização ou marcação
(por exemplo, apenas para um esporte ou equipe específico)
AMQP

Headers exchange foi projetada para roteamento em vários

atributos que são mais facilmente expressos como message
headers do que uma routing key. Headers exchange ignoram o
atributo de chave de roteamento. Em vez disso, os atributos
usados para roteamento são obtidos do atributo headers. Uma
mensagem é considerada correspondente se o valor do cabeçalho
for igual ao valor especificado no binding.
AMQP

Headers exchange podem ser encaradas como "trocas diretas com

esteróides". Como eles são roteados com base nos valores do
cabeçalho, eles podem ser usados como trocas diretas, onde a
routing key não precisa ser uma sequência; poderia ser um
número inteiro ou um hash (dicionário), por exemplo.
AMQP

Queues
Queues no modelo AMQP 0-9-1 são muito semelhantes às filas
em outros sistemas de enfileiramento de mensagens e tarefas:
elas armazenam mensagens consumidas pelos aplicativos.
AMQP

Name
Durable (a fila sobreviverá a uma reinicialização do broker)
Exclusive (usado por apenas uma conexão e a fila será excluída
quando a conexão for fechada)
Auto-delete (a fila que teve pelo menos um consumidor é excluída
quando o último consumidor cancela a inscrição)
Arguments (opcional; usado por plug-ins e recursos específicos do
broker, como TTL da mensagem, limite de comprimento da fila,
etc.)
AMQP

Bindings
Bindings são regras que as exchanges usam (entre outras coisas)
para rotear mensagens para queues. Para instruir uma exchange E
a rotear mensagens para uma queue Q, Q deve estar vinculado a
E. As ligações podem ter um atributo de routing key opcional
usado por alguns tipos de exchange. O objetivo da routing key é
selecionar determinadas mensagens publicadas em uma
exchange serem roteadas para a queue vinculada. Em outras
palavras, a routing key atua como um filtro.
AMQP

Para desenhar uma analogia:

Queue é como seu destino na cidade de São Paulo

Exchange é como o aeroporto CGH
Bindings são rotas de CGH para o seu destino. Pode haver zero ou
muitas maneiras de alcançá-lo
Vantagens
AMQP

Princípio Fire & Forget

Mensagens duráveis (evitar Circuit Breakers e Retries)
Melhores estratégias de escala e desacoplamento de aplicativos
Adequado para integrações de parceiros
Desafios
AMQP

Acompanhe os eventos, caso contrário você terá problemas

Usamos novas tentativas para colocar a mensagem na queue
Cuide dos dados na mensagem (preocupações de segurança)
Ferramentas
RabbitMQ
Gerenciamento de Filas
Outras opçōes
 RabbitMQ
Instalando Erlang

1 – Importar Erlang GPG Key

wget -O- https://packages.erlang-solutions.com/ubuntu/erlang_solutions.asc |
sudo apt-key add -
2 – Adicionar Repositório
echo "deb https://packages.erlang-solutions.com/ubuntu bionic contrib" | sudo
tee /etc/apt/sources.list.d/rabbitmq.list
3 – Atualizar
sudo apt update
sudo apt -y install erlang
4 - Iniciar

erl
 RabbitMQ
Instalando RabbitMQ

5 – Importar Erlang GPG Key

wget –O - "https://dl.bintray.com/rabbitmq/Keys/rabbitmq-release-signing-
key.asc" | sudo apt-key add -
6 – Adicionar Repositório
wget –O - "https://www.rabbitmq.com/rabbitmq-release-signing-key.asc" | sudo
apt-key add -
7 – Adicionar repositório RabbitMQ
echo "deb https://dl.bintray.com/rabbitmq/debian $(lsb_release -sc) main" |
sudo tee /etc/apt/sources.list.d/rabbitmq.list
8– Instalar RabbitMQ Server

sudo apt update

sudo apt -y install rabbitmq-server
 RabbitMQ
Instalando RabbitMQ

9 – Verificar status

sudo systemctl status rabbitmq-server.service

10 – Verificar configuração do serviço ao iniciar

systemctl is-enabled rabbitmq-server.service

11 – Habilitar serviço ao iniciar

sudo systemctl enable rabbitmq-server

12 – Habilitar Dashboard

sudo rabbitmq-plugins enable rabbitmq_management

 RabbitMQ
Instalando RabbitMQ

13 – Habilitar portas - Firewall

sudo ufw allow proto tcp from any to any port 5672,15672

14 – Abrir console Web RabbitMQ

firefox http://localhost:15672
Username: guest
Password: guest
RabbitMQ
Criando Queues
RabbitMQ
Criando Exchange
RabbitMQ
Configurar Bindings
 Ferramentas
Spring Boot + RabbitMQ
 RabbitMQ
Criando uma Aplicação - Producer

1 – Crie um projeto Spring Started Project

 RabbitMQ
Criando uma Aplicação - Producer

2 – Adicione a dependência Spring RabbitMQ

 RabbitMQ
Criando uma Aplicação - Producer

3 - Confirme
 RabbitMQ
Criando uma Aplicação - Producer

4– Crie a classe Produtor

 RabbitMQ
Criando uma Aplicação - Producer

5 - Run As > Spring Boot Application

 RabbitMQ
Criando uma Aplicação - Consumer

1 – Crie um projeto Spring Started Project

 RabbitMQ
Criando uma Aplicação - Consumer

2 – Adicione a dependência Spring RabbitMQ

 RabbitMQ
Criando uma Aplicação - Consumer

3 - Confirme
 RabbitMQ
Criando uma Aplicação - Consumer

4– Crie a classe Consumidor

 RabbitMQ
Criando uma Aplicação - Consumer

5 - Run As > Spring Boot Application

Ferramentas
Apache Camel
Apache Camel
Framework open source

O que é?

O Apache Camel é uma estrutura de software livre

para middleware orientado a mensagens com um
mecanismo de mediação e roteamento baseado em
regras que fornece uma implementação baseada em
objeto.

https://www.enterpriseintegrationpatterns.com/
Apache Camel
Configurando
Apache Camel
Adicione as dependências ao .pom

<camel.version>2.24.2</camel.version>

<!-- APACHE CAMEL -->

<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring-boot-starter</artifactId>
<version>${camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-rabbitmq-starter</artifactId>
<version>${camel.version}</version>
</dependency>
 Apache Camel
Configure properties

Botão Direito mouse no arquivo application.properties > Converter to .properties

to .yaml

camel:
component:
rabbitmq:
addresses: localhost:5672
username: guest
password: guest
route:
fiap:
input:
endpoint: rabbitmq:fiap.scp.input.exchange?queue=fiap.scp.input.fila
output:
endpoint: rabbitmq:fiap.scp.output.exchange?queue=fiap.scp.output.fila
Apache Camel
Implementação
Apache Camel
Implementação Rota
Apache Camel
Execução
Ferramentas
Kettle
Kettle
Ferramenta de Integração de Dados
O Pentaho Data Integration é o componente
da suíte Pentaho usado para criar processos
de extração, transformação e carga
(Extraction, Transformation and Loading)
que alimentam o banco de dados.
Com o Pentaho Data Integration é possível
fazer inúmeras operações de Integração de
Dados:
• Tratamento de dados.
• Movimentação de grande massa de
dados.
• Input de diversas fontes de dados e
output para diversos componentes como
Base de dados Relacional, NoSQL,
Message Broke, etc...
 Kettle
Instalando

1 – Acesse a URL

https://sourceforge.net/projects/pentaho/files/Pentaho%209.0/client-tools/
 Kettle
Instalando

1 – Crie o repositorio do Kettle

mkdir -p ~/pentaho

2 – Descompacte o .zip em ~/pentaho/client-tools

unzip pdi-ce-9.0.0.0-423.zip -d ~/AulaDev02/pentaho/

3– Executar Spoon

./spoon.sh
Kettle
Primeiro Contato
 Kettle
Criar uma Transformação

1 – Abra uma nova janela

<CTRL> + <N>
 Kettle
Criar uma Transformação
2 – Adicione um step CSV File Input
 Kettle
Criar uma Transformação
3 – Adicione um Step Sort rows
 Kettle
Criar uma Transformação
4 – Adicione um Step Group by
 Kettle
Criar uma Transformação
4 – Adicione um Step Text file output
 Kettle
Criar uma Transformação
5 – Adicione um Step Text file output (configure Fields)
 Kettle
Execute a Transformação
1 – Acione o botão play ou F9
 Kettle
Execute a Transformação
2 – Valide o arquivo gerado
Copyright © 2020 Prof. Carlos Hesketh

Todos direitos reservados. Reprodução ou divulgação total ou

parcial deste documento é expressamente proíbido sem o
consentimento formal, por escrito, do Professor Carlos
Hesketh. Material baseado na apostila do Professor Carlos
Hesketh.