MW CAP07 2025 VA03 INTEGRACAO DE SERVICOS

A construção de uma aplicação
em microserviços que faz uso de API

passa por diversos pontos,

que terminam deixando a gente
um pouco desnorteado

de por onde começar.

Mas a verdade é que existem
alguns padrões

que são sempre repetitivos
e que terminam gerando ali

uma arquitetura de referência
para a gente poder trabalhar.

Essa arquitetura de referência
vai justamente trazer a gente

para entender
como é que um microsserviço

começa com outro,

como o que eles falam
com serviços externos

e como é que a gente provê ali
segurança, escalabilidade

e debate e vários outros pontos
dentro do nosso ambiente.

Quando eu falo aqui, por exemplo,
dessa arquitetura,

vocês vão ver que a gente começa
logo aqui em cima

tratando dos nossos usuários.

E quando a gente fala de microsserviço,

esse usuário não necessariamente
é uma pessoa.

Aqui eu posso tratar
essa minha arquitetura

como sendo microsserviços
que vão atender outros serviços.

Imagine, por exemplo,
um site de vendas.

A minha estrutura de back-end
para ler e entender os arquivos

é quem vai consumir ali
o carrinho de compras.

Então, um serviço chama o outro.

Esse caso a gente vai ter tratar também
dentro da nossa arquitetura.

Outro cenário pode ser,
por exemplo,

quando uma outra empresa externa
também vai querer consultar

o nosso ambiente.

E aí a gente vai ter que tratar
alguns pontos.

E o primeiro deles é a segurança.

Vejam que quando a gente
começa esse acesso,

a primeira coisa que a gente vai ter
é o nosso firewall.

Aqui a gente vai estar falando de isolar
esses nossos microsserviços do mundo

para que a gente caia em uma DMZ,

zona desmilitarizada.

Isso quer essencialmente dizer
que tudo ali para dentro é seguro

e que os meus microsserviços
não precisam mais se preocupar.

Isso vai ser muito importante,

porque quando eu falo
para o lado de fora,

a minha API estará sempre
com o SSL ativo.

Basicamente, o SSL utilizará
certificados para encriptar meus dados

e, dessa forma,
eu vou estar seguro.

Só que a gente precisa entender
que eu tenho dois tipos de APIs.

Uma API que tem encriptação
na internet, ou seja,

ela só encripta quando eu falo
do transporte em rede pública

e a encriptação fim a fim.

O que quer dizer que mesmo dentro
da DMZ,

o meu dado também vai estar encriptado.

E aí vai do desenvolvedor entender
qual é a melhor solução para ele.

Notem que além dessa estrutura,
essa minha API

que a gente está representando
como API Gateway,

ela ainda vai ter que tratar
toda a parte de autenticação,

identificação de usuário
e registro dos serviços.

E isso vai ser feito de uma forma
muito simples,

utilizando basicamente frameworks
de mercado,

que vai trazer para mim
toda a parte de gestão de autenticação.

Como que eu vou criar um usuário?

Qual token eu vou usar?

E mesmo esse TOC
ele também vai ser padronizado

utilizando por exemplo o JWT,

que é o nosso Java Token para os íntimos.

E aí a gente
consegue utilizar esses padrões de mercado

para aumentar a compatibilidade
da nossa API com outros serviços externos.

E aqui, finalmente, com tudo isso aprovado

é que eu entro nos meus microsserviços.

Aqui a gente vai ter
um ponto muito importante da gente tratar

a entrada e o recebimento desses dados.

Podem ser por uma API que eu desenvolvi

ou podem ser por serviços externos.

Esse gateway,
ele pode simplesmente ser algo que eu

contratei
e diversas empresas prestam esse serviço.

A principal delas é o WS com o IP Gateway.

Ele basicamente vai expor
a minha API principal para o mundo

e uma vez que ela recebe essas chamadas

e que ela já fez todo o tratamento
ali de certificado,

segurança, identificação,
controle de sessão e tudo mais,

é que ela direciona
para dentro dos microsserviços.

E aí eu não preciso ter que desenvolver
toda essa parte,

Uma vez
que a gente tem os nossos microsserviços,

eles vão ter os seus componentes,
vão ter os seus bancos de dados

e vão precisar falar uns com os outros.

Essa fala também
pode ser feita de duas formas.

Eu posso utilizar a primeira forma,

que são APIs de uso interno.

Uma vez que eu estou dentro da DMZ,
eu posso não utilizar criptografia

nesse caso, porque eu considero que aquele
ambiente da DMZ é seguro.

Só que em

alguns casos o meu dado é tão crítico
que ainda assim eu vou encriptar

eles só pra não ter nenhum vacilo ali
no meio do caminho.

Se eu uso uma API para conectar
dois serviços,

basicamente eu estou transformando ali

uma metalinguagem aonde a própria API
vai disponibilizar uma pré IR

para que o Tapi possa chamar
ela e a gente vai entrar nesse loup

que vai perdurar bastante tempo.

Mas eu tenho outra forma de tratar isso.

Essa segunda forma
é utilizando os serviços de mensageria.

Basicamente eu vou criar um canal

aonde a gente vai postar
mensagens de um microserviço para o outro

e ali dentro desse canal
eu vou ter tópicos de conversa,

como por exemplo
um tópico de Observable idade.

É nele que eu vou publicar os meus blogs.

O que que está acontecendo comigo?

As mensagens de erro
e assim sucessivamente.

Não só eu vou fazer isso,
todos os micro-serviços vão fazer isso

e vão publicar os seus logs
no tópico de logs.

É assim que a gente usa
esses canais de conversa.

Esses canais vão estar estruturados
aqui embaixo e vão ser uma estrutura

muito simples que a gente utiliza
há algumas boas décadas

para permitir que vários serviços
se falem de maneira estruturada,

não só entre eles, mas também

com outros serviços externos.

E aqui
a gente vai ter um ponto muito importante

se eu coloco um serviço de mensageria
ali no meio,

eu passo a ter uma estrutura que está
se comunicando de forma assíncrona.

O assíncrono quer dizer que uma vez que eu
publiquei aquela informação,

eu não estou recebendo a confirmação
de recebimento do meu usuário.

Então como é que eu faço
para saber se deu tudo certo?

A resposta que eu confio no processo.

Eu sei que o serviço de mensageria

só vai tirar aquela mensagem de dentro
dele,

uma vez que ele recebeu
o OK de dentro da outra aplicação

ou por parte do processo
que eu esteja utilizando.

E isso para mim é muito importante,

porque eu consigo olhar para
aquele micro serviço que enviou a mensagem

e que muita das vezes é mais custoso do
que o processo de mensageria para operar.

E se ele não tem carga, ele pode parar

e isso vai me reduzir custos.

Ele volta a operar
quando ele recebe novas demandas.

Toda nova demanda
ele publica no serviço de mensageria.

E essa é uma forma simples
da gente arquitetar.

Outra coisa
muito parecida que a gente consegue fazer

é colocar um serviço de fila.

E ele tem um conceito muito parecido
ao serviço de mensageria,

Só que a gente vai utilizar
ela normalmente lá na entrada do dado.

Antes da gente falar do nosso gateway.

E isso vai servir pessoal
justamente para a gente

conseguir não perder mensagem.

Imagina, por exemplo, que o micro serviço
que a gente está construindo

é um processador de pagamento.

Ao invés de eu

mandar ele pagar na hora,
aonde eu teria um erro

caso o serviço do banco
estivesse fora do ar?

Eu agora publico
a solicitação de pagamento em uma lista.

Essa lista vai sendo consumida
ao longo do dia e o serviço de pagamento

vai devolvendo para o banco de dados
o status atualizado.

Sempre que eu realizar um pagamento.

A grande sacada aqui

é que eu não falo mais isso
diretamente para o usuário.

E aí o que vai terminar acontecendo

é que só tem uma falha
no meio do processo.

Eu posso fazer um retry,
eu tento novamente daqui a algum tempo

e eu evito dar dor de cabeça
para esse usuário.

Esse evento é muito comum
quando a gente faz compras.

Se você fez compras em um site,
como por exemplo a Amazon,

o Mercado Livre, você pode ter notado
que algumas ocasiões, ao invés de

a gente receber a confirmação do pagamento
de imediato, a gente recebe um

Estamos processando o seu pagamento e dali
alguns minutos o pagamento sai.

Isso acontece justamente porque a gente
enviou estudado para uma fila

e esperou que o dado fosse finalizado,

que todo o processo concluísse com sucesso

para que eu pudesse determinar
ali, para o usuário o que aconteceu.

E aqui a gente tem um ponto importante
para o processo finalizar com sucesso.

Ele tem que ter uma mensagem esperada.

Essa mensagem pode ser uma negativa.

Vejam que para um carrinho de compras,
um pagamento bem sucedido

ou um pagamento negado,
ainda assim foi um pagamento processado.

Se ele foi processado com sucesso,
eu vou ter uma dessas duas mensagens

e eu consigo retornar
isso para o meu usuário.

Notem que a gente

precisa
tomar conta de vários pequenos processos

para eu conseguir utilizar a API,
como a integração de serviços.

E justamente por isso
a gente vai ter que tratar segurança,

integridade, tomar uma série de decisões
na construção da nossa solução.

A grande sacada é que essa solução
vai ser muito robusta

e que uma vez
que essa arquitetura foi definida,

eu posso mexer nela
com muito mais liberdade,

colocando cada vez mais funções,
mas ao mesmo tempo

sem estar preocupado
que a construção de uma nova Fisher

em um determinado ponto do código
derrube a minha aplicação inteira.