Translation
Messaging is a fundamental part of any distributed system. It allows a producer to send a message to any number of consumers, and it is not necessary to know any information about the consumer. This is a great help for truly asynchronous and decoupling communication.
When you use RabbitMQ, the diagram above shows a very basic but typical structure. A producer sends a message to the switch. According to the routing logic, the switch puts the message into the queue bound to the switch. More specifically, if it is a broadcast type switch, the copy of this message will be sent to each queue repeatedly. A consumer can then receive and process the message.
An important assumption for the above structure to work successfully for producers and consumers is that all RabbitMQ components (i.e. queues, switches, and bindings) must be created in advance. A consumer cannot send a message to a switch If the switch does not exist, a consumer cannot process messages from a queue that does not exist.
Therefore, it is not difficult to understand that before the producer/consumer sends/receives the message, let a producer/consumer value create a queue, switch and binding relationship. Let's take a look at the advantages and disadvantages of each way.
1. Distinguish responsibilities
Image translation (1. Producer creates a switch 2. Consumer creates a queue and binds the queue to the switch)
In order for producers and consumers to fully decouple, ideally, producers only know information about the switch (not the queue), and consumers only know about the queue (not the switch). The binding relationship indicates the relationship between the switch and the queue
One possible way is to have the producer handle the creation of the switch, and the consumer creates the queue and binds the queue to the switch. The advantage of this decouplement method is that if the consumer needs a queue, it is simply necessary to create a queue and bind them according to the demand, and the producer does not need to know any information about the queue. But this is not a sufficient decoupling: because the consumer must know the switch in order to bind it.
2. Producers create everything
When the producer is running, it can be configured to create all the required components (switches, queues, and bindings). The advantage of this approach is that no messages are lost (because the queue is already created and bound to the switch, and no consumer needs to start it first).
However, this means that the producer must know all the queues that need to be tied to the switch. This is a highly coupled way. The reason is that every time a new queue needs to be added, the producer must reconfigure and deploy to create and bind queues
3. Consumers create everything
The opposite is to let the consumer create the switches, queues, and bindings it needs when it is running. As in the previous approach, this method produces coupling because the consumer must know the information about the switch they are bound to the queue. Any changes to the switch (such as renaming) mean that all consumers must be reconfigured and deployed. When there are large queues and consumers, this complexity can be prohibitive.
4. Neither creates anything
A completely different approach is to neither the producer nor the consumer to create any required components. Instead, it is created using the user interface of the admin plugin or the admin CLI beforehand. This method is based on the following advantages:
- Producers and consumers can be completely decoupled. Producers only know the exchange, and consumers only know the queue.
- This can be easily scripted and automated as part of the deployment pipeline
- Any changes, such as new queues, can be added without touching any existing, deployed publishers and consumers
summary
In distributed systems, asynchronous messages are a useful way to decouple, but in order to keep them decoupled, it is necessary to maintain an effective strategy for maintaining the underlying messaging structure (in RabbitMQ, these are queues, switches, and bindings).
While publisher and consumer services may be responsible for creating what they need themselves, they can be costly in terms of initial message loss, coupling, and operational maintenance (in terms of configuration and deployment).
Probably the best way to handle messaging system configuration where it belongs: write scripts outside of the application. This ensures that services remain decoupled and that the queue system can change dynamically as needed without affecting a large number of existing services.
Original:The hyperlink login is visible.
Original English:The hyperlink login is visible.
|
Posted on 5/3/2023 10:31:59 PM
|
|
|
|
