Padrão de coreografia

O padrão de Coreografia descentraliza a lógica do fluxo de trabalho e distribui responsabilidades para outros componentes dentro de um sistema. Em vez de dependerem de um orquestrador central, os serviços decidem quando e como processar uma operação empresarial.

Contexto e problema

Normalmente, divide-se uma aplicação baseada na cloud em vários pequenos serviços que trabalham em conjunto para processar uma transação de negócio de ponta a ponta. Uma única operação dentro de uma transação pode resultar em múltiplas chamadas ponto a ponto entre todos os serviços. Idealmente, esses serviços são pouco acoplados. É desafiante desenhar um fluxo de trabalho distribuído, eficiente e escalável porque envolve comunicação interserviços complexa.

Um padrão comum de comunicação é usar um serviço centralizado ou um orquestrador. As solicitações recebidas fluem através do orquestrador à medida que ele delega operações aos respetivos serviços. Cada serviço cumpre a sua responsabilidade e não está ciente do fluxo de trabalho global.

Normalmente implementa-se o padrão de orquestrador como software personalizado que possui conhecimento do domínio sobre as responsabilidades dos serviços dentro do sistema. Um benefício desta abordagem é que o orquestrador pode consolidar o estado de uma transação com base nos resultados das operações individuais que os serviços a jusante realizam.

Esta abordagem também cria alguns obstáculos. Adicionar ou remover serviços pode quebrar a lógica existente porque você precisa reconectar partes do caminho de comunicação. Essa dependência torna a implementação do orchestrator complexa e difícil de manter. O orquestrador pode afetar negativamente a fiabilidade da carga de trabalho. Sob carga, pode introduzir gargalos de desempenho e ser o único ponto de falha (SPoF). Também pode causar falhas em cascata nos serviços a jusante.

Solução

Delegue a lógica de gestão de transações entre os serviços. Deixe que cada serviço participe no fluxo de trabalho de comunicação de uma operação empresarial e decida quando e como processá-lo.

O padrão Coreografia minimiza a dependência de software personalizado que centraliza o fluxo de trabalho de comunicação. Os componentes implementam lógica comum enquanto coreografam o fluxo de trabalho entre si, sem comunicar diretamente entre si.

Uma maneira comum de implementar coreografias é usar um agente de mensagens que armazena solicitações em buffer até que os componentes downstream as reivindiquem e processem. A imagem seguinte mostra o tratamento de pedidos através de um modelo editor-assinante.

1. Os pedidos do cliente são enfileirados como mensagens num broker de mensagens.

2. Os serviços ou o assinante interpelam o corretor para determinar se pode processar essa mensagem com base na lógica de negócio implementada. O corretor também pode enviar mensagens aos subscritores interessados nessa mensagem.

3. Cada serviço subscrito realiza a sua operação conforme a mensagem indica e responde ao corretor com uma mensagem de sucesso ou falha da operação.

4. Se a operação for bem-sucedida, o serviço pode enviar uma mensagem de volta para a mesma fila ou para outra fila de mensagens diferente, para que outro serviço possa continuar o fluxo de trabalho, se necessário. Se a operação falhar, o agente de mensagens trabalha com outros serviços para compensar essa operação ou toda a transação.

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar este padrão:

• Lidar com falhas pode ser desafiante. Os componentes numa aplicação podem gerir tarefas atómicas e depender de outras partes do sistema. A falha num componente pode afetar outros componentes, o que pode causar atrasos na conclusão do pedido global.

  Para lidar com falhas com elegância, implementa-se lógica de gestão de falhas, que introduz complexidade. A lógica de gestão de falhas, como transações compensatórias, também é propensa a falhas.

  

  O fluxograma mostra a lógica de tratamento de erros e compensação num padrão de coreografia que tem dependências sequenciais de serviços. No topo, um nó de início aponta para o serviço A. O serviço A conecta-se a um losango que aponta para o serviço B à esquerda e para o serviço C à direita. Setas apontam de cada um destes serviços para um diamante de decisão que pergunta se a solicitação falhou. O caminho rotulado como sim ramifica-se para cima, num ciclo que retorna ao losango que liga os três serviços. O caminho rotulado "não" continua até uma caixa que diz que ambos os serviços foram bem-sucedidos. A partir deste estado de sucesso, o fluxo continua para baixo até ao serviço D, que se liga a um diamante de decisão final que pergunta se o pedido falha. O caminho do 'sim' deste losango volta a subir para reentrar no fluxo antes do serviço D, e o caminho do 'não' continua a descer até um nó final.

• Este padrão adequa-se a um fluxo de trabalho que processa operações empresariais independentes em paralelo. O fluxo de trabalho pode se tornar complicado quando a coreografia precisa ocorrer em uma sequência. Por exemplo, o Serviço D só pode iniciar a sua operação depois de o Serviço B e o Serviço C completarem as suas operações com sucesso.

  

  O diagrama mostra o fluxo de mensagens num padrão coreográfico em que os serviços processam operações em paralelo e sequencialmente. No topo encontram-se cinco componentes dispostos horizontalmente: serviço A, um corretor de mensagens, serviço B, serviço C e serviço D. No extremo esquerdo, um utilizador envia um pedido ao serviço A. O serviço A converte o pedido em m1_a de mensagens e publica-o para o corretor de mensagens. Por baixo do corretor de mensagens, uma linha temporal vertical mostra como cada serviço gere as mensagens. Dentro de uma região sombreada rotulada par para processamento paralelo, o broker de mensagens entrega m1_a simultaneamente ao serviço B e ao serviço C através de setas tracejadas. O Serviço B processa a mensagem e devolve m1_b ao corretor de mensagens. O serviço C processa a mensagem e devolve m1_c ao broker de mensagens. No lado direito do diagrama, duas pequenas caixas representam as condições de espera para o serviço D. A primeira condição diz Esperar até m1_b e m1_c, o que indica que o serviço D não pode prosseguir até receber ambas as mensagens. A segunda condição diz: Espere até m1_b. Após o processamento paralelo concluir e tanto o serviço B como o serviço C responderem, o intermediário de mensagens envia m1_c para o serviço D, seguido de m1_b. O Serviço D processa estas mensagens e devolve m1_d ao broker de mensagens. Por baixo do diagrama, uma legenda explica cada notação. Request refere-se ao pedido HTTP original enviado para um endpoint público. M1_a é o pedido HTTP convertido numa mensagem. M1_b é a mensagem processada e enviada de volta ao corretor de mensagens a partir do serviço B. M1_c é a mensagem processada e enviada de volta ao corretor de mensagens a partir do serviço C, e m1_d indica que m1_b e m1_c são processadas e enviadas de volta como confirmação final ao corretor de mensagens. Setas sólidas indicam publicar mensagens e setas tracejadas indicam mensagens de subscrição.

• Este padrão apresenta desafios se o número de serviços crescer rapidamente. Muitas partes móveis independentes complicam o fluxo de trabalho entre serviços. Deve usar consistentemente rastreamento distribuído e identificadores de correlação para aumentar a capacidade de observação.

• Num design liderado pelo orquestrador, o componente central pode delegar responsabilidades de resiliência, como a gestão de repetições para falhas transitórias, não transitórios e de timeout, a um gestor de resiliência dedicado.

  Quando removes o orquestrador num design baseado em coreografia, os componentes posteriores não assumem responsabilidades de resiliência. Mantêm-se centralizados no gestor de resiliência. Mas os componentes a jusante devem comunicar diretamente com esse gestor, o que aumenta a comunicação ponto a ponto.

• A evolução do esquema de eventos pode causar alterações disruptivas nos consumidores ao longo do tempo. Neste padrão, múltiplos serviços independentes consomem os mesmos eventos. Se um produtor alterar a estrutura de dados de um evento, pode quebrar os consumidores a jusante que dependem do esquema antigo. Use um registo de esquemas para gerir contratos de eventos e utilize evoluções retrocompatíveis à medida que os serviços evoluem de forma independente.

• A ordenação de eventos não é garantida em tentativas ou no aumento de escalabilidade. Projete para idempotência e reemita mensagens em sequência para lidar com eventos duplicados ou fora de ordem.

• Topologias de eventos descentralizadas podem criar comportamentos emergentes em grande escala. Quando muitos serviços reagem aos eventos uns dos outros, o sistema pode, sem querer, produzir ciclos de retroalimentação ou tempestades de eventos. Um evento menor pode desencadear uma cascata de reações a jusante. Para evitar cadeias circulares de eventos, utilize mecanismos de proteção como filtragem de eventos, limites de concorrência do consumidor, limitação e regras explícitas.

Quando utilizar este padrão

Utilize este padrão quando:

• Os componentes a jusante lidam com operações atómicas de forma independente. Pense neste padrão como um mecanismo de disparar e esquecer , em que um componente realiza uma tarefa que não precisa de gestão ativa. Quando a tarefa está concluída, o componente envia uma notificação aos outros componentes.

• Esperas atualizar e substituir os componentes com frequência. Este padrão permite-lhe modificar a aplicação com menos esforço e com mínima interrupção dos serviços existentes.

• Usas arquiteturas serverless para fluxos de trabalho simples. Os componentes podem ser de curta duração e orientados por eventos. Quando ocorre um evento, o serviço cria componentes que realizam uma tarefa, e o serviço remove componentes após a conclusão dessa tarefa.

• A comunicação entre contextos limitados requer acoplamento frouxo através das fronteiras do domínio. Para comunicação dentro de um único contexto limitado, aplique um padrão orquestrador.

• O orquestrador central introduz um gargalo de desempenho.

Este padrão pode não ser adequado quando:

• O aplicativo é complexo e requer um componente central para lidar com a lógica compartilhada para manter os componentes a jusante leves.

• A comunicação ponto a ponto entre os componentes é inevitável.

• É preciso usar a lógica de negócio para consolidar todas as operações que os componentes posteriores tratam.

Design da carga de trabalho

Avalie como usar o padrão de Coreografia no design de uma carga de trabalho para tratar dos objetivos e princípios mencionados nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece orientação sobre como esse padrão suporta as metas de cada pilar.

Se este padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.

Exemplo

Este exemplo mostra o padrão de Coreografia ao criar uma carga de trabalho nativa da cloud orientada por eventos, que executa funções juntamente com microsserviços. Quando um cliente pede para enviar um pacote, a carga de trabalho atribui um drone. Depois de a encomenda estar pronta para recolha pelo drone agendado, inicia-se o processo de entrega. Enquanto a encomenda está em trânsito, a carga de trabalho trata da entrega até receber o estado de envio.

O serviço de ingestão recebe pedidos dos clientes e converte-os em mensagens que incluem os detalhes da entrega. As transações comerciais começam depois de os serviços consumirem essas novas mensagens.

Uma transação comercial de um único cliente requer três operações comerciais distintas:

• Crie ou atualize um pacote.

• Atribui um drone para entregar o pacote.

• Efetue a entrega, incluindo verificar o envio e enviar uma notificação quando a encomenda for despachada.

Microserviços de pacotagem, programador de drones e entrega realizam o processamento empresarial. Os serviços utilizam mensagens em vez de um orquestrador central para comunicar entre si. Cada serviço deve implementar previamente um protocolo que coordene o fluxo de trabalho empresarial de forma descentralizada.

Design

Os serviços processam transações empresariais numa sequência através de múltiplos saltos. Cada salto partilha um único barramento de mensagens entre todos os serviços empresariais.

Quando um cliente envia um pedido de entrega através de um endpoint HTTP, o serviço de ingestão recebe-o, converte-o numa mensagem e depois publica a mensagem para o barramento de mensagens partilhado. Os serviços empresariais subscritos consomem novas mensagens adicionadas ao autocarro. Quando um serviço empresarial recebe a mensagem, a operação é concluída com sucesso, ou o pedido falha ou expira. Se o pedido for bem-sucedido, o serviço responde ao barramento de mensagens com o código de estado Ok, cria uma nova mensagem de operação e envia-a para o barramento de mensagens. Se o pedido falhar ou expirar, o serviço reporta a falha enviando o código de razão para o barramento de mensagens e depois adiciona a mensagem a uma fila de letras mortas (DLQ). O serviço também transfere mensagens que não consegue receber ou processar num determinado período de tempo para o DLQ.

Este design utiliza vários barramentos de mensagens para processar a totalidade da transação empresarial. O Azure Service Bus e o Azure Event Grid fornecem a plataforma de serviços de mensagens para este design. A carga de trabalho corre no Azure Container Apps, que aloja Azure Functions para ingestão. As Aplicações Container tratam do processamento orientado a eventos que executa a lógica de negócio.

Este design também garante que a coreografia ocorre em sequência. Um único espaço de nomes de Service Bus contém um tópico que tem duas subscrições e uma fila consciente da sessão. O serviço de ingestão publica mensagens sobre o tema. O serviço de gestão de pacotes e o serviço de agendamento de drones subscrevem o tópico e publicam mensagens que notificam a fila sobre pedidos bem-sucedidos. Incluir um identificador de sessão comum que associe um GUID ao identificador de entrega, para que os serviços possam processar sequências ilimitadas de mensagens relacionadas de forma sequencial. O serviço de entrega espera por duas mensagens relacionadas para cada transação. A primeira mensagem indica que o pacote está pronto para ser enviado, e a segunda mensagem sinaliza que um drone está agendado.

Neste design, o Service Bus trata mensagens de alto valor que não devem ser perdidas ou duplicadas durante todo o processo de entrega. Quando o pacote é enviado, uma alteração de estado é publicada para Event Grid. O remetente do evento não tem expectativas sobre como a mudança de estado é tratada. Os serviços de organização a jusante que este design não inclui podem escutar este tipo de evento e executar lógica empresarial específica, como enviar um email de atualização de estado da encomenda para o utilizador.

Se implementares este padrão noutro serviço de computação, como o AKS, podes implementar o boilerplate de aplicação do padrão Publisher-Subscriber com dois contentores no mesmo pod. Um contentor executa o embaixador que interage com o barramento de mensagens que escolhes, enquanto o outro contentor executa a lógica de negócio. Esta abordagem melhora o desempenho e a escalabilidade. O embaixador e o serviço de negócios partilham a mesma rede, o que reduz a latência e aumenta o débito.

Para evitar operações de retentativa sucessivas que possam levar a múltiplas tentativas, os serviços empresariais devem sinalizar imediatamente mensagens inaceitáveis. Enriqueça estas mensagens usando códigos de razão comuns ou um código de aplicação definido para que os serviços possam movê-las para um DLQ. Considere implementar o padrão Saga para gerir problemas de consistência provenientes de serviços subsequentes. Por exemplo, outro serviço trata mensagens de dead-letter apenas para fins de remediação, executando uma transação de compensação, repetição ou pivot.

Os serviços empresariais são idempotentes para garantir que as operações de nova tentativa não criem recursos duplicados. Por exemplo, o serviço de pacotes utiliza operações upsert para adicionar dados à base de dados.

Passos seguintes

• Centralize a gestão de esquemas de eventos utilizando o registo de esquemas nos Azure Event Hubs para manter a compatibilidade à medida que os seus serviços evoluem.

• Consulte as opções de mensagens assíncronas no Azure para conhecer as diferentes opções de infraestrutura disponíveis para implementar um fluxo de trabalho descentralizado.

• Avalie as capacidades técnicas das diferentes plataformas para escolher o serviço de mensagens Azure adequado às suas necessidades específicas de coreografia.

Recursos relacionados

Considere estes padrões no seu design para coreografia:

• Modularize o serviço empresarial utilizando o padrão Ambassador.

• Implemente o padrão Queue-Based Load Leveling para lidar com picos na carga de trabalho.

• Use mensagens distribuídas assíncronas através do padrãoPublisher-Subscriber.

• Use transações compensatórias para desfazer uma série de operações bem-sucedidas caso uma ou mais operações relacionadas falhem.