Propósito
O objetivo desse Grooming foi o de verificar os principais pontos e opiniões sobre a melhor forma de implementar o AMQP como um novo canal de comunicação.
Ata
Inicialmente, foi explicado que a necessidade dessa implementação foi levantada por uma equipe de arquitetos do Datasul, que está partindo para uma estratégia de microserviços baseados nos seus módulos.
A intenção era a de que cada um desses módulos poderia se subscrever para receber as mensagens necessárias.
Os principais pontos discutidos foram:
- Qual arquitetura de mensageria melhor nos atende?
- Pub/Sub
- RPC/point-to-point (syncronous request-response)
- Uma mescla entre os dois acima?
- Queues privadas ou compartilhadas?
- Quantos exchanges?
- Persistência de mensagens?
- Tópicos?
- Forma de distribução de QUEUEs
- Aplicativo externo?
- Mensagem?
- Fila intermediária?
- Onde é o local mais adequado para configurar essa comunicação?
- Novo "DeliveryType"?
- Nova configuração de aplicativo?
- Precisamos definir um novo protocolo?
- ERP envia BusinessMessage
- ERP recebe "Ack" do brocker
- ERP recebe uma ou mais mensagens de resposta
Algumas considerações relevantes:
- A intenção é que o fluxo entre o EAI e o negócio seja assíncrono, e assim a camada de negócio precisaria fazer a gestão da incerteza.
- AMQP também faz balanceamento de carga.
- O monitor/diagnóstico teria que verificar se existem canais não subscritos, ou com algum tipo de falha na configuração.
Principais preocupações:
- Dificuldade do cliente em lidar com a mudança de protocolo.
- Congestionamento de mensagens, no caso de uma única fila estar sendo consumida por vários microserviços.
- Cenários em que, em uma mesma fila, exista mais de uma resposta.
Conclusões
Nesse momento, ainda não foi possível concluir o assunto. Ficou pendente de um levantamento mais detalhado.
Ações
- Realizar o levantamento técnico, evoluindo o desenho da necessidade para um desenho de arquitetura.
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas