As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Comunicação assíncrona
Por outro lado, na comunicação assíncrona, o cliente emite uma solicitação para um serviço, mas não recebe uma resposta imediata. Nesse caso, ele geralmente recebe apenas uma confirmação de que a solicitação foi aceita.
Os benefícios da comunicação assíncrona incluem:
-
Suporte de arquitetura orientado por eventos: adequação natural para padrões de terceirização de eventos e segregação de responsabilidade por consultas de comando (CQRS).
-
Melhor gerenciamento de recursos: capacidade dos serviços de processar solicitações com base em suas capacidades.
-
Melhor isolamento de falhas: desacoplamento de serviços, o que evita falhas em cascata.
-
Manipulação de picos de carga: melhor gerenciamento de picos de tráfego por meio do enfileiramento de mensagens.
As desvantagens incluem a complexidade. Por exemplo:
-
Se o cliente exigir o resultado da operação assíncrona, a implementação de um mecanismo para obter ou receber esse resultado exigirá mais esforços.
-
Pode ser mais difícil solucionar problemas em operações assíncronas, porque a solução de problemas exige análises de logs em vários sistemas.
-
Pode ser mais difícil testar operações assíncronas, pois os testes exigem coordenação entre vários sistemas e serviços.
As abordagens de comunicação assíncrona incluem acionar e esquecer, verificar declarações, retorno de chamada e comunicação bidirecional.
Acionar e esquecer
No padrão “acionar e esquecer”, um cliente emite uma solicitação ao servidor e recebe de forma síncrona uma confirmação indicando que o servidor recebeu a mensagem e a processará. No entanto, o processamento real ainda não ocorreu, e o cliente não tem visibilidade de quando ou como ele será feito. O diagrama a seguir ilustra esse padrão.
Nesse caso, o serviço não deve enviar a confirmação até que o objeto seja mantido de forma duradoura. Essa persistência pode ser implementada como uma operação de gravação no banco de dados ou colocando um item em uma fila.
Considerações adicionais:
-
Implemente idempotência para lidar com mensagens duplicadas. Ou seja, cada mensagem deve ser processada apenas uma vez.
-
Considere filas de mensagens não entregues
em caso de falha no processamento. -
Monitore taxas de sucesso de processamento de mensagens.
Verificação de declaração
Se um cliente precisar do resultado de uma chamada de serviço, você poderá criar o serviço para emitir uma verificação de declaração ao receber uma solicitação. O diagrama a seguir ilustra esse padrão. A verificação da declaração é implementada como um identificador que o serviço retorna em sua confirmação. O cliente pode usar esse identificador posteriormente para verificar o status da solicitação e recuperar o resultado quando a solicitação estiver concluída.
Os clientes devem implementar um mecanismo para pesquisar os resultados. Isso pode ser automatizado (por exemplo, uma verificação pode ser realizada a cada n minutos) ou implementado manualmente, em que a verificação é realizada em resposta a outro evento ou ação do usuário. Os serviços que implementam o padrão de verificação de declaração devem ser explícitos sobre o período de validade de um verificação de declaração.
Práticas recomendadas:
-
Implemente um recuo exponencial para sondagem.
-
Defina um tempo de vida útil (TTL) para verificações de declarações.
-
Forneça endpoints de status para acompanhamento do progresso.
Retorno de chamada
No padrão de retorno de chamada, um cliente emite uma solicitação para um serviço e fornece um local para o serviço entrar em contato quando o processamento estiver concluído. O cliente não espera um resultado, e o processamento continua. O serviço é responsável por entrar em contato com o local quando o processamento estiver concluído e fornecer o resultado. Os tipos comuns de locais para respostas são REST APIs ou filas. O diagrama a seguir ilustra o padrão de retorno de chamada.
Implementação:
-
Implemente mecanismos de repetição para retornos de chamada com falha.
-
Proteja o local de retorno da chamada como faria com outros serviços.
-
Gerencie os tempos limite de retorno de chamada.
Comunicação bidirecional
Para implementar a comunicação bidirecional, você deve criar uma conexão estável entre um cliente e um serviço, que permita que o cliente e o serviço enviem e processem mensagens. Isso é ilustrado no diagrama a seguir. Embora a comunicação seja assíncrona, o serviço deve ser capaz de sustentar uma conexão aberta para cada cliente.
Considerações de implementação:
-
Ordenação de mensagens
-
Números de sequência
-
Estratégias de partição
-
Ordenação de mensagens
-
-
Gerenciamento de estados
-
Padrões de fornecimento de eventos
-
Conciliação de estado
-
Modelos de consistência
-
-
Tratamento de erros
-
Política de novas tentativas
-
Estratégias de fallback
-
Monitoramento e observabilidade
-
Correlação IDs
-
Rastrear mensagens
-
Métricas de performance
-
Indicadores de integridade do sistema
-
