Tradução
A mensagem é uma parte fundamental de qualquer sistema distribuído. Ele permite que um produtor envie uma mensagem para qualquer número de consumidores, e não é necessário saber informações sobre o consumidor. Isso é uma grande ajuda para comunicação verdadeiramente assíncrona e de desacoplamento.
Quando você usa o RabbitMQ, o diagrama acima mostra uma estrutura muito básica, mas típica. Um produtor envia uma mensagem para o switch. De acordo com a lógica de roteamento, o switch coloca a mensagem na fila vinculada ao switch. Mais especificamente, se for um switch do tipo broadcast, a cópia dessa mensagem será enviada repetidamente para cada fila. O consumidor pode então receber e processar a mensagem.
Uma suposição importante para que a estrutura acima funcione com sucesso para produtores e consumidores é que todos os componentes do RabbitMQ (ou seja, filas, switches e bindings) devem ser criados antecipadamente. Um consumidor não pode enviar uma mensagem para um comutador. Se o comutador não existir, um consumidor não pode processar mensagens de uma fila que não existe.
Portanto, não é difícil entender que, antes do produtor/consumidor enviar/receber a mensagem, deixe um valor produtor/consumidor criar uma fila, troca e relação de vinculação. Vamos analisar as vantagens e desvantagens de cada jeito.
1. Distinguir responsabilidades
Tradução de imagem (1. O produtor cria um switch 2. O consumidor cria uma fila e vincula a fila ao switch)
Para que produtores e consumidores possam se desacoplar totalmente, idealmente, os produtores só conhecem informações sobre a mudança (não a fila), e os consumidores só sabem da fila (não da troca). A relação de vinculação indica a relação entre o switch e a fila
Uma possível maneira é que o produtor cuide da criação do switch, e o consumidor crie a fila e vincule a fila ao switch. A vantagem desse método de desacoplamento é que, se o consumidor precisa de uma fila, é simplesmente necessário criar uma fila e vinculá-los conforme a demanda, e o produtor não precisa saber nenhuma informação sobre a fila. Mas isso não é um desacoplamento suficiente: porque o consumidor precisa conhecer o switch para poder vinculá-lo.
2. Os produtores criam tudo
Quando o produtor está em execução, ele pode ser configurado para criar todos os componentes necessários (switches, filas e bindings). A vantagem dessa abordagem é que nenhuma mensagem é perdida (porque a fila já está criada e vinculada ao switch, e nenhum consumidor precisa iniciá-la primeiro).
No entanto, isso significa que o produtor deve conhecer todas as filas que precisam ser vinculadas ao switch. Esse é um método altamente acoplado. A razão é que toda vez que uma nova fila precisa ser adicionada, o produtor precisa reconfigurar e implantar para criar e vincular filas
3. Os consumidores criam tudo
O oposto é deixar o consumidor criar os switches, filas e bindings que precisa quando está em execução. Como na abordagem anterior, esse método produz acoplamento porque o consumidor deve conhecer as informações sobre o switch ao qual está vinculado à fila. Qualquer alteração na switch (como renomeação) significa que todos os consumidores devem ser reconfigurados e implantados. Quando há filas grandes e consumidores, essa complexidade pode ser proibitiva.
4. Nenhum dos dois cria nada
Uma abordagem completamente diferente é que nem o produtor nem o consumidor criem quaisquer componentes necessários. Em vez disso, ele é criado usando a interface do plugin de administrador ou a CLI de administrador anteriormente. Esse método baseia-se nas seguintes vantagens:
- Produtores e consumidores podem ser completamente desacoplados. Os produtores só conhecem a troca, e os consumidores só conhecem a fila.
- Isso pode ser facilmente scriptado e automatizado como parte do pipeline de implantação
- Quaisquer mudanças, como novas filas, podem ser adicionadas sem afetar nenhum editor ou consumidor existente e implantado
resumo
Em sistemas distribuídos, mensagens assíncronas são uma forma útil de desacoplar, mas para mantê-las desacopladas, é necessário manter uma estratégia eficaz para manter a estrutura de mensagens subjacente (no RabbitMQ, são filas, switches e bindings).
Embora os serviços para publicadores e consumidores possam ser responsáveis por criar o que precisam por conta própria, eles podem ser caros em termos de perda inicial de mensagens, acoplamento e manutenção operacional (em termos de configuração e implantação).
Provavelmente a melhor forma de lidar com a configuração do sistema de mensagens onde ele pertence: escrever scripts fora da aplicação. Isso garante que os serviços permaneçam desacoplados e que o sistema de filas possa mudar dinamicamente conforme necessário, sem afetar um grande número de serviços existentes.
Original:O login do hiperlink está visível.
Inglês original:O login do hiperlink está visível.
|
Publicado em 03/05/2023 22:31:59
|
|
|
|
