This topic describes the domain model of ApsaraMQ for RocketMQ.
Service positioning
ApsaraMQ for RocketMQ is a distributed middleware service that uses the asynchronous communication method and the publish-subscribe (pub/sub) messaging model.
For more information about communication methods and messaging models, see Communication methods and Messaging models.
Asynchronous communication provides benefits such as simple system topology and loose coupling between upstream and downstream systems. Therefore, ApsaraMQ for RocketMQ is mainly used for asynchronous decoupling and peak-load shifting.
If you initiate synchronous calls and require responses to be returned in real time, we recommend that you use Remote Procedure Call (RPC)-based solutions.
You must select a service based on your business scenario and requirements.
Domain model of ApsaraMQ for RocketMQ
The preceding figure shows the lifecycle of messages in ApsaraMQ for RocketMQ. The lifecycle consists of the production, storage, and consumption stages.
Messages are produced by producers and then sent and stored to topics on ApsaraMQ for RocketMQ brokers. Consumers can subscribe to the topics to consume the messages.
Message production
Producers: running entities that produce messages in ApsaraMQ for RocketMQ. Producers are integrated into the upstream systems of business calls and feature light weight and anonymity.
Message storage
Topics: group containers that are used to transmit and store messages in ApsaraMQ for RocketMQ. A topic consists of multiple queues, which are used to store messages and scale out the topic.
Message queues: unit containers that are used to transmit and store messages in ApsaraMQ for RocketMQ. Message queues in ApsaraMQ for RocketMQ are similar to partitions in Kafka. ApsaraMQ for RocketMQ stores messages in a streaming manner based on an infinite queue structure. Messages are stored in order in a queue.
Messages: the minimum units of data transmission in ApsaraMQ for RocketMQ. Messages are immutable after they are sent and stored.
Message consumption
Consumer groups: independent groups of consumption identities that are defined in the pub/sub model of ApsaraMQ for RocketMQ. A consumer group is used to centrally manage consumers that run at the bottom layer. Consumers in the same consumer group must maintain the same consumption logic and configurations and consume messages subscribed by the group together to scale out the consumption capacity.
Consumers: running entities that consume messages in ApsaraMQ for RocketMQ. In most cases, consumers are integrated into the downstream systems of business calls. A consumer must belong to a specific consumer group.
Subscriptions: collections of message filtering, retry, and consumer progress configurations in the pub/sub model of ApsaraMQ for RocketMQ. Subscriptions are managed by consumer group. You can use subscriptions to define how consumers in a consumer group filter messages, retry messages, and restore consumption.
Except for filter expressions, subscriptions in ApsaraMQ for RocketMQ are persistent. If broker restarts or disconnections occur, subscriptions remain unchanged.
Communication methods
In distributed architectures, complex systems are split into multiple independent modules, such as microservices modules. In this case, remote communication between the modules must be ensured. The following communication methods are commonly used: PRC-based synchronous communication and middleware-based asynchronous communication.
RPC-based synchronous communication
In this method, systems directly communicate with each other. Each request is sent from the caller to the callee and then the callee immediately returns the response to the caller.
The word synchronous does not refer to the programming interface mode. RPC also supports the programming mode of asynchronous non-blocking calls. In this case, the caller still expects a direct response from the callee within a specific period of time.
Asynchronous communication
In this method, high coupling is not required for subsystems to be connected. The caller needs only to convert a request into an asynchronous event, or message, and send it to an agent. If the message is sent, the call is considered complete. The agent delivers the message to the called downstream subsystem and ensures that the task is implemented. In most cases, the role of agent is assumed by a message-oriented middleware service.
Asynchronous communication provides the following benefits:
Simple system topology
In asynchronous communication, the caller and callee both communicate only with the agent. The system works in a star structure that is easy to maintain and manage.
Loose coupling between upstream and downstream systems
Loose coupling in asynchronous communication makes the system structure more flexible. Buffering and asynchronous recovery are performed by agents. Applications deployed in the upstream and downstream systems can be upgraded and changed independently without affecting each other.
Peak-load shifting
Message-oriented agents typically provide a large traffic buffer and powerful traffic shaping capability. This prevents traffic peaks from drowning downstream systems.
Messaging models
Message-oriented middleware services uses the point-to-point (P2P) model and the pub/sub model.
P2P model
The P2P model, also known as the queue model, has the following characteristics:
Anonymous consumers: Queues are the only identities used during upstream-downstream communication. Downstream consumers cannot declare identities when they obtain messages from queues.
One-to-one communication: Consumers are anonymous. All consumers in a consumer group consume the subscribed messages together. Each message can be consumed only by one consumer. Therefore, the P2P model supports only one-to-one communication.
Pub/sub model
The pub/sub model has the following characteristics:
Independent consumption: In this model, consumers are identified by consumer groups. Consumer groups are independent of each other.
One-to-many communication: Based on the design of independent identities, this model allows a topic to be subscribed to by multiple consumer groups, each of which can receive all messages from the topic. Therefore, the pub/sub model supports one-to-many communication.
Comparison between messaging models
The P2P model and pub/sub model provide different benefits. The P2P model is simpler in structure, and the pub/sub model offers better scalability. ApsaraMQ for RocketMQ uses the pub/sub model and provides the corresponding benefits.