Arquitetura coreografada, é um conceito, e não uma regra
Não é difícil hoje em dia encontrar “testemunhas do microsserviço coreografado”, contando todos os seus benefícios e ganhos potenciais de implementação.
Mas vamos lá, a arquitetura coreografada é tudo isso mesmo? Ela resolve todos os problemas?
Bom, a resposta não é tão simples, na verdade não é nem um pouco simples. Para entender qual o melhor modelo ou quando aplicar cada um, aqui vão algumas dicas pelo meu ponto de vista.
O que é coreografia?
Bom, de forma básica, podemos dizer que um ecossistema coreografado é composto pela forma de comunicação entre os microsserviços, e a regra de atuação que estes seguem.
Na arquitetura coreografada, não temos um microsserviço central que orquestra a execução dos demais microsserviços, ou seja, não existe um “chefe” ou um maestro responsável pelo trabalho de todo o grupo, como na arquitetura orquestrada.
Desenho de arquitetura orquestrada:
A arquitetura coreografada se baseia na premissa de que cada microsserviço tenha domínio e responsabilidade sobre a atividade a ser executada.
Vamos a um exemplo:
Imagine um sistema com a responsabilidade de compra de passagens aéreas, que faz os seguintes passos.
1-) Com base no destino e datas escolhidas verifica se existe passagens disponíveis.
2-) Com base nas passagens disponíveis verifica o valor de cada uma.
3-) Apresenta ao usuário as opções.
4-) Após a escolha das opções ele abre as formas de pagamento.
5-) Grava nas bases do sistema a escolha e dados do usuário.
6-) Gera contabilização do valor recebido.
7-) Apresenta ao usuário a confirmação do pedido.
8 -) Envia por e-mail o cartão de embarque.
Com base nesse passo a passo, poderíamos ter um microsserviço que chamasse cada uma das funções até a conclusão do trabalho.
Mas ai teríamos um problema, pois o microsserviço orquestrador teria sempre que estar disponível, para que qualquer função pudesse ser executada. Fora o acoplamento gerado, pois caso um fluxo fosse alterado, você sempre teria que alterar no executor da atividade, e no orquestrador.
Agora imagine um cenário onde o primeiro microsserviço, de análise de passagens disponíveis deixasse uma mensagem avisando que esse passo foi feito. E a partir dessa mensagem o segundo microsserviço faria a leitura e executaria sua função, de verificar os valores. Vamos parar por aqui, e fazer uma simulação, caso amanha seja necessário a criação de um novo calculo do valor, para um parceiro especifico, e que não possa ser feito juntamente com o primeiro microsserviço, nesse cenário você apenas construiria esse microsserviço e consumiria das filas, sem precisar impactar os demais que já estão no ar.
Seguindo nosso fluxo, imagine então que as funções foram sendo executadas até a função de pagamento do usuário, e após essa a mensagem foi postada na fila, e os microsserviços de “gravar nas bases”, “Contabilizar”, “Mostrar na tela ao usuário” e de “envio de e-mail foram iniciados”. Nesse caso caso qualquer um destes microsserviços estaja fora do ar, os demais seguem sua função sem impacto, deixando o trabalho mais próximo de concluído, e possivelmente com uma experiência melhor ao usuário.
Qual problema resolve?
Independência de negócio, um modulo pode seguir sem o outro, conforme explicado nos exemplos acima.
Facilidade para testes mockados, com a independência dos microsserviços, e com a comunicação feita por fila, você abre uma gama de testes mockados com mais variedades de ferramentas e abordagens.
Aumenta as possibilidades de trabalho com cache, podendo deixar mensagens para processamento posterior, ou até mesmo trabalhar com dados com latência.
O que tem de ruim?
Necessidade de documentação com mapeamento de dependências, pois como podemos verificar, temos maior complexidade.
Dificuldade de gestão da informação, ou seja, fica mais complicado garantir que todos os microsserviços fizeram sua parte, e que os dados inseridos estão íntegros.
Caso um erro ocorra, e você precise retornar as alterações para o status anterior, você terá mais dificuldade.
Problemas acontecem, e quando acontecerem, troubleshooting não é tão fácil, precisa de muito mais cuidado e dados.
Em caso de inclusão de muitas filas, você pode sofrer com maior latência.
Regras mínimas para implementar
Não é possível fazer a gestão de microsserviços sem a documentação rica de como seu ecossistema trabalha.
Observability é essencial, você precisa conseguir saber como está a saúde da sua aplicação.
Log, Log e mais um pouquinho de log. Nesse caso, nunca é demais, pois facilitam muito a analise em caso de problemas.
Conclusão
A arquitetura coreografada traz sim muitos benefícios, mas traz também algumas complexidades. É necessário entender o ambiente no qual você está inserido, e por esse motivo é sempre importante analisar todo o seu fluxo, e quais problemas você quer resolver. Se o fluxo que você atua, é necessariamente interdependente, você não tem concorrência de alterações nos códigos, problemas para testar, e não tem um business que costuma sofrer alterações, me parece não fazer sentido seguir essa estratégia. Portanto pare, pense e analise, todas as decisões de arquitetura têm seus lados positivos e negativos, não se apaixone por nenhuma delas.
Deixe uma resposta