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,

como é o caso do OAF,

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

como eu vou criar um usuário,

qual token eu vou usar.

E mesmo esse token,
ele também 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 pode simplesmente
ser algo que eu contratei

e diversas empresas prestam
esse serviço.

A principal delas é a AWS
com o API 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 encriptá-los

só para 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 API
para que outra API

possa chamá-la,
e a gente vai entrar nesse looping

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

onde a gente vai postar mensagens
de um microsserviço para o outro

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

como, por exemplo,
um tópico de observabilidade.

É nele que eu vou publicar
os meus logs,

o que que está acontecendo comigo,

as mensagens de erro,
e assim sucessivamente.

Não só eu vou fazer isso,

todos os microsserviç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 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
microsserviç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 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 API Gateway.

E isso vai servir, pessoal,
justamente para a gente

conseguir não perder mensagem.

Imagine, por exemplo,

que o microsserviç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 se eu tenho 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 ou o Mercado Livre,

você pode ter notado
que algumas ocasiões,

ao invés da gente receber

a confirmação
do pagamento de imediato,

a gente recebe um:

"estamos processando
o seu pagamento".

E dali a alguns minutos
o pagamento sai.

Isso acontece justamente
porque a gente enviou esse dado

para uma fila
e esperou que o dado fosse finalizado,

que todo o processo
concluísse com sucesso,

para que eu pudesse determinar
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.