Comunicação entre microsserviços — Orquestração X Coreografia

Valdenir Santana
Livelo
5 min readMay 18, 2023

--

Com o advento de modelos arquiteturais mais modernos como o da arquitetura orientada a microsserviços, surgiram também necessidades específicas no formato de comunicação, para permitir uma melhor interoperabilidade entre os serviços, uma vez que, nesse modelo arquitetural, os serviços estão dispostos de forma mais desacoplada.

Dessa forma, para alcançar os objetivos dos processos de negócio de uma organização, muitas vezes é necessário construir jornadas mais complexas e robustas, o que demanda um nível mais elevado de maturidade no quesito comunicação. Nesse contexto, é fundamental compreender dois paradigmas de comunicação entre serviços: orquestração e coreografia. Ambos apresentam abordagens distintas desempenhando papéis importantes na integração de serviços. Nesse artigo, vamos apresentar esses dois paradigmas de comunicação, realizando um comparativo entre as duas abordagens.

A orquestração e coreografia são abordagens diferentes de como interagir com outros componentes de software. Boa parte dessa comunicação são baseadas em eventos e comandos. Um evento é algo que já aconteceu, ou seja, é um fato, e o produtor desse evento não tem conhecimento de quem irá receber/reagir a ele, portanto não sabe o que irá acontece a seguir. Um exemplo pode ser o evento “Pagamento Confirmado”. Já um comando é algo que tem uma intenção e que ainda irá acontecer no fluxo. Um exemplo de comando pode ser o “Confirmar pagamento”.

Antes de falarmos sobre os benefícios, desvantagens e exemplos, precisamos entender o conceito de cada uma dessas abordagens. Vamos dar uma olhada na definição a seguir.

Coreografia

Na coreografia temos a coordenação e organização de interações entre diferentes componentes de software ou sistemas sem que exista um coordenador/orquestrador do fluxo de forma centralizada. Como o próprio nome já diz, esse paradigma se parece como uma coreografia em uma dança, por exemplo, na qual todas as pessoas que estão compondo a apresentação sabem exatamente o que precisam fazer e como interagir uns com os outros para que a apresentação se complete com sucesso.

Como boa prática, na coreografia, a comunicação entre os serviços é orientada a eventos.

Arquitetura coreografada orientada a eventos para um caso de uso de order management

Vantagens:

  • Performance: latência menor já que a comunicação é mais direta, e também não temos a necessidade de depender da capacidade de processamento de um serviço orquestrador;
  • Acoplamento flexível: os microsserviços ficam acoplados de forma mais livre, podendo operar de forma independente sem a necessidade de ter um ponto central conhecendo o fluxo como um todo;
  • Construção e Manutenibilidade: nesse paradigma os microsserviços são desenvolvidos e mantidos de forma mais independente e, caso a documentação de contrato e fluxo esteja bem documentada, temos menos comandos e eventos no fluxo como um todo, demandando menos esforço e facilitando a construção e manutenibilidade.

Desvantagens:

  • Falta de visibilidade/rastreabilidade: dificuldade de troubleshooting, já que não temos uma centralização do controle. Precisamos sempre de uma boa ferramenta de tracing, além de buscar em mais lugares como, logs ou outras ferramentas os pontos de falha;
  • Resiliência mais manual: dificuldade maior para executar novamente uma etapa ou tratar erros uma vez que não temos um framework em um ponto central que nos auxilia nessa parte. E também conforme comentamos anteriormente, os componentes reagem a eventos, o que dificulta o processo pois gerar novamente eventos de domínio podem causar impactos no fluxo. Dessa forma, os serviços, além de controlar a lógica de negócio do seu domínio, precisam ter um bom controle de erro, idempotência e, muitas vezes, a persistência de eventos com erro em cada etapa do workflow, sendo um controle complexo de ser colocado em cada serviço.

Orquestração

Na orquestração, temos sempre um serviço central que coordena e organiza as interações entre diferentes componentes de software ou sistemas. Como o próprio nome já diz, esse serviço orquestrador é responsável por gerenciar e tomar ações baseadas no conhecimento da regra de negócio. Esse paradigma se parece como uma orquestra, na qual a apresentação como um todo é regida por um maestro (orquestrador) e é ele quem controla todos os outros participantes da apresentação para que a mesma seja finalizada com sucesso.

Como boa prática, na orquestração a comunicação entre os serviços é orientada a comandos.

Arquitetura orquestrada orientada a comandos para um caso de uso de order management

Vantagens:

  • Controle centralizado: com um coordenador central (orquestrador), fica mais fácil monitorar e gerenciar as interações entre os microsserviços em um sistema orquestrado;
  • Visibilidade: mais facilidade para o troubleshooting, já que normalmente os frameworks/plataformas de mercado já possuem ferramentas que auxiliam na visibilidade de tudo que está sendo orquestrado.

Desvantagens:

  • Menor performance: nesse paradigma temos sempre o coordenador central lendo os eventos e tomando as decisões baseado nas regras de negócio. Essa comunicação tem muito mais requests, tendo também a dependência da capacidade de processamento do serviço orquestrador;
  • Acoplamento rígido: a orquestração é normalmente conhecida por ser mais acoplada, o que pode tornar o sistema menos escalável e resiliente. Isso está teoricamente correto, mas a comunicação assíncrona pode diminuir isso, pois um comando em si normalmente é feito de forma assíncrona;
  • Dificuldade em adicionar, remover ou substituir microsserviços: alterar a configuração de um sistema orquestrado pode ser mais difícil, pois, na maioria das vezes, isso requer uma atualização no orquestrador;
  • Overhead: O orquestrador pode vir a ter um overhead, caso a sua construção não seja pensada de forma resiliente e para uma alta disponibilidade, uma vez que ele concentrará todo o esforço do fluxo.

É possível misturar os dois paradigmas?

Sim! Essa combinação de coreografia e orquestração pode oferecer benefícios. Porém precisamos ter em mente que tudo deve que ser muito bem documentado, definido o que deve ser coreografado e orquestrado dentro do sistema como um todo para que a gestão do conhecimento tenha sucesso. A coreografia permite flexibilidade e autonomia nas interações entre microsserviços, já que um serviço pode se comunicar diretamente com outros serviços. Por outro lado, a orquestração pode fornecer uma abordagem centralizada para controlar e coordenar as interações entre os serviços, o que pode simplificar o gerenciamento e troubleshooting do sistema. Ao combinar as duas abordagens, uma arquitetura de microsserviços pode obter os benefícios de flexibilidade e simplicidade.

Conclusão

Decidir entre coreografia e orquestração requer conhecimento prévio e consideração cuidadosa, pois ambas têm vantagens e desvantagens, conforme apresentado. Independentemente de você escolher coreografia, orquestração ou um misto entre os dois paradigmas, é importante entender suas necessidades e o objetivo que você espera obter.

No próximo artigo sobre o tema, vamos abordar um case de migração de coreografia para orquestração em um fluxo transacional, abordando como o uso da orquestração para o nosso caso trouxe benefícios.

Referências

https://medium.com/@crisaltmann/orquestra%C3%A7%C3%A3o-vs-coreografia-em-eda-8c14db455892

https://camunda.com/blog/2023/02/orchestration-vs-choreography

https://microservices.io/book

--

--