“Orquestrador” para encapsular a chamada de microsserviços, sim ou não?
Você já se deparou com a situação em que sua equipe possui um conjunto de microsserviços, e eles se comunicam com um ou mais serviços internos ou externos?
Situação atual
O Serasa eCred é um marketplace de crédito em um ecossistema de serviços financeiros na Serasa, e temos o propósito de crédito para todos (momento jabá, rs), com isso, precisamos integrar com algumas empresas parceiras para expor seus produtos da melhor forma para o consumidor, pois como marketplace de crédito quem disponibiliza crédito é o nosso parceiro.
Nosso papel, como integração, é basicamente “traduzir” os dados da plataforma eCred e enviá-los aos parceiros. Então quando a plataforma eCred solicita “quero o parceiro X, Y e Z”, nosso objetivo como integração é em uma única chamada da plataforma retornar o maior número de ofertas em uma estrutura de dados padronizada para que a plataforma consiga entender e realizar a exibição de ofertas com aquela magia que só UX e UI sabem fazer.
Para gerenciar todas as chamadas de API dos parceiros, criamos um microsserviço para cada parceiro e chamamos ele de integrador. Logo após, foi criado um orquestrador de chamadas para os integradores (Que carinhosamente chamamos de GO, por estar na linguagem GOlang rsrs). Com ele, a plataforma eCred consegue solicitar de forma simples os recursos dos integradores.
Segue uma imagem da arquitetura informada:
Prós arquitetura de microsserviços utilizando o Orquestrator
1. Fácil para adicionar novos parceiros:
Utilizamos configurações no backend da plataforma para validar se o parceiro está ativo. Para adicionar um novo parceiro o backend da plataforma não precisa rebuildar, ele somente adiciona uma nova configuração de um novo parceiro e as requisições vão pelo orquestrador, ou seja, configura o parceiro e adiciona as urls no orquestrador;
2. Centralizar a regra de chamadas das apis:
Temos um fluxo em que necessitamos chamar os integradores simultaneamente e aguardar a resposta de todos para devolver a chamada para a plataforma eCred;
Contras arquitetura de microsserviços utilizando o Orquestrator
1. Responsabilidade compartilhada:
De quem é a responsabilidade de chamar os integradores? Esta responsabilidade seria de quem consome o recurso e não de quem provê, ou seja, esta responsabilidade seria do backend da plataforma e não da integração.
2. Única porta de entrada e saída:
Este é o ponto mais crítico na minha opinião, olhando a imagem da arquitetura acima, se a aplicação Orchestrator “quebrar”, o que aconteceria? Ficaríamos sem nenhuma integração funcionando, ou seja, nosso core principal estaria fora. E aquele conceito de resiliência em microsserviços? O que aconteceu com ele?
Cuidado: Sua arquitetura de microsserviço pode não ser quem vc pensa.
Atualmente criamos algumas camadas para tentar facilitar o uso de microsserviços e com isso podemos acabar quebrando o conceito da própria arquitetura, como é o caso do nosso orquestrador que reunia todas as chamadas aos microsserviços de integração, assim, tornando-o quase um monolito e um ponto extremamente crítico para o funcionamento da aplicação, fazendo com que o produto fique fora caso o serviço fique indisponível. O problema não é só o produto ficar indisponível, mas quando fazemos uma arquitetura de microsserviços o nosso olhar para desenhar ela deve ser totalmente voltado para fracionar as partes do sistema a ponto de manter o funcionamento do produto estável mesmo havendo algum tipo de indisponibilidade em algum serviço periférico e não crítico.
E agora? O que faremos?
A nossa ideia é que a integração mantenha, em um banco NoSQL, as informações dos seus parceiros (Informações essas, que antes estavam no Orchestrator) e agora o backend da plataforma poderá consultar a informação e realizar as chamadas nas APIs dos integradores, utilizando melhor o conceito de microserviços. Ou seja, como integração disponibilizamos como chegar até nós.
Nossas aplicações ficam na cloud da AWS. Então, utilizaremos um serviço de banco de dados NoSQL performático e escalável que é o DynamoDB. Mas cuidado porque o DynamoDB também pode ser um carrasco, leia muito antes de usá-lo.
A imagem abaixo mostra como será o fluxo
Prós da arquitetura de microsserviços utilizando o AWS DynamoDB
1. Resiliência:
O ponto mais importante na minha visão é a retirada de um serviço único que controlava todas as chamadas aos integradores, então o problema que tínhamos na queda do Orchestrator foi resolvido, e caso um microsserviço de parceiro ficar down, apenas ele é penalizado por isso e não todo ecossistema;
2. Performance do DynamoDB:
Segundo documentação da AWS, consultas por chave em um DynamoDB bem configurado, retornam em menos de 10ms, é uma performance muito boa para o momento de retornar as configurações das APIs dos integradores ao client que estiver consumindo a integração;
Contras da arquitetura de microsserviços utilizando o AWS DynamoDB
1. Muita alteração no backend da plataforma:
Como o backend da plataforma já existe, precisa fazer uma alteração no mesmo para que ele crie toda a regra para recuperar a url no DynamoDB e faça uma ou múltiplas chamadas nos integradores.
2. Gerenciamento de memória no backend da plataforma:
O backend da plataforma precisa gerenciar as suas chamadas assíncronas para não estourar memória e ficar reiniciando o pod do K8s.
Conclusão
Esta publicação tem o intuito de fazer com que você reflita se realmente é necessário criar uma camada para encapsular a chamada de microsserviços ou se não seria mais interessante um monólito.
Ela tem o intuito de mostrar um pouco de como estamos organizando a nossa arquitetura, não queremos dizer o que é certo nem errado. Queremos mostrar que existem formas diferente de desenhar uma arquitetura.
Quero muito agradecer a Matheus Losi pela ajuda na revisão e escrita do artigo.
