Comunicação entre microserviços — Orquestração X Coreografia — Parte 2
Conforme mencionado no artigo anterior, falamos sobre dois paradigmas de comunicação para uma arquitetura orientada a eventos (EDA): orquestração e coreografia, explorando também os pontos positivos e negativos de cada uma dessas abordagens na comunicação entre serviços distribuídos.
Também comentamos que o intuito da tecnologia é usar de ferramentas para alcançar os objetivos dos processos de negócio de uma organização, e com o passar do tempo esses objetivos podem ter alterações devido a necessidade de evolução natural desses processos, e cabe a nós estarmos preparados para lidar com esses desafios.
Nosso intuito nessa segunda parte é dar continuidade no assunto, apresentando o caso de um fluxo transacional no qual optamos pela migração da coreografia para a orquestração, trazendo benefícios como melhor visibilidade e facilidade para realização de troubleshootings.
A arquitetura
Para fins de exemplificação, usaremos o case do artigo anterior, um exemplo simples mas que servirá para ilustrar o cenário.
Na imagem abaixo, podemos ter a visão da arquitetura com os devidos microserviços envolvidos:
O Fluxo
No cenário proposto, temos um fluxo que consiste no recebimento de uma ordem de compra e suas respectivas validações, persistências nos microsserviços envolvidos e na sequencia outras ações, tais como: verificação de estoque, avaliação de fraude, pagamento e finalizando com a entrega.
Coreografia
Anteriormente, usávamos a coreografia como formato de comunicação entre os microserviços apresentados acima. Nesse cenário, o microserviço Receive valida a consistência dos dados recebidos, persiste e dispara um evento de order.received no qual todos os outros serviços reagem e persistem os dados que lhe cabem em cada uma das suas bases de dados, conforme ilustrado abaixo.
Na sequência, se dá início a uma série de passos do fluxo transacional. Sendo o responsável pela verificação de estoque o microserviço Stock, a avaliação de fraude o Fraud, o pagamento pelo Payment, e a parte da entrega o Shipping.
Abaixo temos um exemplo da sequência de eventos que ocorriam logo após o recebimento dos dados do pedido.
Nesse cenário da coreografia, não tínhamos um serviço centralizado (orquestrador) fazendo comandos, e sim vários microserviços dispostos reagindo a eventos disparados por outros microserviços.
E nesse formato, identificamos alguns problemas à medida que o sistema foi evoluindo:
- Visibilidade e rastreabilidade — Caso um problema ocorresse no fluxo, o microserviço em questão armazenava informações do problema internamente em seu banco de dados e em ferramenta de logs para uma avaliação futura, o que deixava a visibilidade decentralizada, necessitando um esforço de buscas em vários lugares, como logs e api’s de vários serviços. Existia também um outro microsserviço que servia como um repositório de problemas, porém nem sempre tínhamos todas as informações nele, ocasionando o mesmo problema citado anteriormente, e com o passar do tempo esse serviço acabou sendo apenas um cemitério de erros em desuso.
- Sincronia de eventos — Um dos exemplos de problemas com sincronia de eventos que podemos citar no cenário proposto deste artigo é que o evento de order.received era disparado pelo microservico Receive e o microserviço de Stock lia esse evento, persistia os dados, verificava o estoque e disparava o próximo evento de stock.checked para que o fluxo continuasse. Porém, o próximo microsserviço que recebia esse evento, o Fraud, muitas vezes ainda estava fazendo a persistência dos dados do evento anterior e dava erro ao tentar localizar o pedido no seu banco de dados, uma vez que a transação do evento anterior ainda estava em outra thread do microsserviço sendo processada.
- Dificuldade de evolução e documentação — Em uma arquitetura orientada a eventos, sempre temos o desafio de documentar muito bem o fluxo para que todos tenham o entendimento de tudo que ocorre. No modelo da coreografia, tínhamos uma documentação mais manual sobre os eventos e seus conteúdos, e desafiava o entendimento e alinhamento entre todos os níveis da organização, uma vez que essa documentação precisa ser consumida por vários times, como times técnicos, negócio, SRE e etc. A cada nova feature, plugávamos um novo serviço em um evento, mas com muitas features surgindo em paralelo ficava cada vez mais difícil ter o entendimento do todo.
- Resiliência/operação muito manual — A cada problema que encontrávamos dentro do fluxo, era custoso recuperar os pedidos, ou atuar em possíveis troubleshootings, já que gerar novamente eventos de domínio podem causar impactos negativos.
Orquestração
Dado o cenário, revisitamos nossa arquitetura e optamos por migrar do paradigma de coreografia para o de orquestração. Para isso, analisamos algumas ferramentas de mercado que pudéssemos utilizar para orquestrar o fluxo, e por consequência, nos auxiliasse a resolver os problemas mencionados anteriormente.
Nosso objetivo era ter mais visibilidade de tudo que ocorre no fluxo de fulfillment de ordens, resolvendo problemas de sincronismo de eventos, documentação centralizada e ferramentas de resiliência e operação.
Buscamos algo que encaixasse na nossa necessidade e não fosse preciso o desenvolvimento manual ou de um framework próprio de orquestração. Testamos ferramentas como o Conductor da NetFlix, o Camunda e também o Zeebe (que agora foi incorporado a suite Camunda). Das ferramentas que avaliamos a que mais se encaixou nessas necessidades foi o Camunda.
O Camunda fornece uma plataforma completa para automação de processos de negócio. Com ele, é possível modelar processos através de notação BPMN, que é um formato de fluxograma que modela etapas de um processo de ponta a ponta. Esse fluxograma representa de forma visual uma sequência detalhada das atividades que compõem os fluxos de negócio e as informações necessárias para concluir um processo.
Abaixo, temos uma modelagem BPMN com os passos necessários para executar e as necessidades de negócio do nosso cenário (apresentado anteriormente), agora no formato de coreografia.
Como nosso cenário é composto por 4 principais passos em diferentes microsserviços dispostos de forma isolada, nosso fluxo foi orquestrado de forma assíncrona utilizando comandos para executar determinadas ações e eventos, para que seja possível avaliar a resposta e tomar a decisão de prosseguirmos para o próximo passo, ou prosseguirmos por um cenário alternativo.
Soluções dos problemas
Conforme mencionado anteriormente, haviam 4 principais problemas, falaremos agora um pouco de como resolvemos cada um deles com a adoção da orquestração com o Camunda:
1 — Visibilidade e rastreabilidade — Todo e qualquer processo que entra dentro do fluxo é atrelado a um process instance, no formato UUID, e através dele é possível efetuar um rastreamento de todo o caminho percorrido por ele. Quando desenhamos o nosso BPMN, precisamos pensar em todos os possíveis condicionais e caminhos alternativos, para que caso um problema ocorra, o mesmo seja tratado e as respectivas tratativas de resiliências(retry, move) sejam aplicadas(quando possível), ou as tratativas manuais(Manual Task) sejam efetuadas.
Abaixo temos um exemplo da visão geral do fluxo com os contadores dos process instances em andamento na ferramenta Camunda Cockpit:
A visibilidade de tudo que ocorre fica centralizada e caso precisemos de um detalhe maior, é possível navegar por cada etapa do BPMN, ou efetuar buscas pelos process instances ou também variáveis customizadas, como por exemplo, o identificador de uma ordem de compra, código do cliente, data da compra, etc.
Abaixo, temos um exemplo da visão geral do fluxo com o histórico de um process instance que teve sucesso percorrendo todo o caminho feliz do fluxo.
Dessa forma, temos informações de forma centralizada aqui.
É possível criar variáveis customizadas e ir adicionando informações ao longo do fluxo.
2 — Sincronismo de eventos — Como agora passamos a utilizar comandos e aguardamos a resposta através de um evento do domínio, não temos mais vários eventos sendo executados em paralelo, que era o causador desse problema.
3 — Dificuldade de evolução e documentação — Utilizamos sempre o próprio BPMN criado como documentação, uma vez que essa modelagem é compreendida pelo time de negócios, pelo time técnico para desenvolver o fluxo em questão e também pelos times de apoio e suporte a operação.
Abaixo, temos um exemplo da utilização da modelagem com a nomenclatura dos comandos e eventos feitos em cada passo.
4 — Resiliência/operação manual — A plataforma do Camunda tem recursos que auxiliam o uso de resiliências básicas e o desenvolvedor deve tomar conta disso no momento da implementação, que pode ser feita em Java ou NodeJS. Caso um problema ocorra, podemos atrelar um Incident, que gera uma tarefa e fica disponível no dashboard pra que seja possível que uma pessoa possa avaliar e tomar a melhor decisão para aquele process instance. É possível inclusive mover um process instance ou fazer essa operação em lote para muitos deles.
Uso do Camunda
Utilizamos a licença Enterprise que nos permite utilizar o Camunda Cockpit e Camunda Optimize de forma completa.
O uso do Cockpit reduziu o tempo de análise em uma ordem de compra que antes ficava entre 15 e 20 minutos para alguns segundos. Já o Camunda Optimize nos habilitou a alertas de negócio segmentado por produto baseado nas process variables.
A seguir, vamos ver algumas ferramentas que auxiliam nas avaliações do dia a dia.
Camunda Cockpit: apresenta uma visão geral do que está ocorrendo dentro dos fluxos implantados.
Selecionando uma versão implantada, teremos a visão do BPMN completo, conforme mostrado anteriormente com os contadores e detalhamento de variáveis e caminhos percorridos por cada process instance.
Camunda Optimize: apresenta ferramentas para criação de dashboards e relatórios, analisar gargalos e examinar áreas em processos de negócios para uma possível melhoria. Dentro dele, também temos uma visão macro em formato de um “mapa de calor” sobrepondo o BPMN, mostrando a frequência relativa com que as atividades e caminhos em um processo são executados. Podem também ser extraídas informações de quantidade ou de tempo médio de execução de um process instance, e ter uma rápida informação caso algumas demorem mais que a média.
Conclusão
Abordamos, nesse artigo, um case de migração de coreografia para orquestração em um fluxo transacional, mostrando como o uso da orquestração para o nosso cenário trouxe muitos benefícios, conforme explicado anteriormente.
Em conjunto com o uso de uma plataforma de mercado, conseguimos sair de um cenário que não estávamos confortáveis com a observabilidade e operação, para um cenário onde temos um controle efetivo sobre todo o processo transacional em uma perspectiva técnica e de negócio.
