Introduction to message middleware series - functions and protocols

Author: Ge Xianliang, unit: China Mobile Smart Home Operation Center

Labs Guide

In recent years, Internet technology has developed rapidly, and the amount of information in all walks of life has expanded dramatically. With the advent of the era of cloud computing and computing power networks, message middleware has received increasing attention in key applications in many industries in China. In high-concurrency distributed scenarios, the rational use of message middleware can often break through performance bottlenecks and simplify complexity.

1 Message-Oriented Middleware

In the field of modern architecture design, middleware can be divided into two categories based on purpose and implementation mechanism:

• Remote Procedure Call (RPC)-based middleware allows procedures in one application to call procedures in a remote application as if they were local calls.
• Message-Oriented Middleware (MOM) enables distributed applications to communicate and exchange data by sending and receiving messages.

Both models allow a local component to access (affect) another remote component through a network protocol. The difference is that when the RPC middleware calls a remote component, it is a synchronous operation and must wait for the call process to return before it can proceed. MOM middleware, on the other hand, uses an efficient and reliable message passing mechanism for asynchronous data transmission.

The difference between synchronization and asynchrony means that in the RPC model, the local component (caller) and the remote component (callee) must be running at the same time. If the remote component is currently in an upgrade or faulty state, the RPC call will fail. At this time, the local component needs to implement data caching and retry mechanisms to ensure that the final call is successful (it can also directly return a failure prompt to the user based on product requirements). In the MOM model, almost all message middleware implements the message persistence function. When the local component sends a message to the remote component, the message will first be packaged and sent to the communication server (Broker). After receiving the message, the communication server will persist the message and then send the message to the remote component through the underlying network. The remote component reads the message from the message queue interface.

Figure 1 RPC call

Figure 2 MOM call

As mentioned above, the MOM-based system implements a persistent asynchronous communication mode, allowing components to be more loosely coupled, extending communication between services (processes) in distributed scenarios, and supporting heterogeneous systems to complement multiple development and the currently popular microservice architecture, so that the business system has good dynamic load scaling capabilities.

2. The role of message middleware

In actual application scenarios, message middleware, as an implementation of the event-driven architecture model, can also provide application decoupling, asynchronous communication, traffic peak shaving, elastic scaling, redundant storage, data synchronization, and eventual consistency in a distributed environment by providing a message queue model and message passing mechanism.

2.1 Application Decoupling/Event-Driven

Event Driven Architecture is a distributed asynchronous architecture model that focuses on production and consumption. In applications based on the event-driven architecture model, systems can drive business through message transmission and process in a streaming model. It has the characteristics of high concurrency, easy scalability, and loose coupling.

Compared with direct calls (synchronous/asynchronous) through RPC, message transmission enables producers and consumers to establish logical connections through messages, and producers and consumers can belong to different systems. For non-core processes, they can be split into different consumers, and support subsequent dynamic expansion. Whether consumers consume messages or not will not affect the core processes in producers.

❖ Example: For example, in the user registration process, when the registration is successful, the system needs to send email notifications and SMS notifications. The call logic for sending SMS and emails is written in the registration method. The user registration module is strongly coupled with the SMS module and the email module. If there is a need to send WeChat public account notifications later, the user registration process can only be modified to create dependencies with more modules.

Figure 3 Application decoupling - user registration - message queue

But in fact, in the user registration process, the core process is user information writing, and operations such as sending SMS and sending emails are all triggered after the user successfully registers. If the event-driven style (message/event notification) is adopted, the user module as a producer generates a "registration success" event message after the user successfully registers, and other modules as consumers subscribe to the event message, then the user module can be decoupled from other modules (SMS, email). Since the producer does not care about the subsequent processing results of the event, the consumer module can choose different scheduling strategies according to the actual situation, such as concurrent processing, asynchronous processing, or processing according to idle time, busy time, etc.

2.2 Asynchronous Communication

Making non-core processes asynchronous can reduce system response time, increase throughput, and thus improve user experience. For example: SMS notifications, APP push, etc.

In the message middleware scenario, the user clicks the registration button on the front-end page. After the platform receives the request, it executes the user registration process in the user module. After successful registration, it sends a "registration successful" event message to the message server (Broker). After receiving the event message, the SMS module sends a text message to the user's mobile phone.

In the above process, we ignore some details and make the following assumptions based on the main steps. It takes 100 milliseconds for the front-end page to reach the user module, a total of 200 milliseconds. It takes 50 milliseconds for the user module to execute the registration process, and 100 milliseconds for the SMS module to execute. At this time, the SMS sending process is triggered by the event message and will not block the main user registration process. For the user, the user registration process only takes 250 milliseconds. If the traditional calling method is used, it will take 350 milliseconds.

Figure 4 Asynchronous communication

Of course, the RPC method can also implement asynchronous mode. For example, when local component A calls remote component B synchronously, after receiving the request, remote component B places the processing in the asynchronous thread pool, and the current thread quickly returns the result. In this way, first, remote component B must be online (otherwise the call will fail due to timeout), and second, the task may be lost due to process restart when the asynchronous thread pool in remote component B is executed (the task is only in the memory queue and is not persisted). The asynchronous characteristics and message persistence mechanism of the message middleware do not have these two problems (here it means that they do not exist in a broad sense. If the message middleware server fails, the producer will also fail to send the message).

2.3 Traffic Peak Shaving

In some Internet e-commerce scenarios such as flash sales, when the throughput of the upstream system is higher than that of the downstream system, the downstream system may be overwhelmed during traffic peaks. When the thread pool solution is adopted, although users can be quickly returned, the tasks are piled up in the thread pool queue, resulting in excessive memory usage and task loss due to process restart. The message middleware can accumulate messages during peak times, and the downstream system slowly consumes the messages after the peak passes to solve the problem of traffic peaks.

❖ Example: After the user successfully checks out in the payment system, the order system will push a deduction notification to the user through the SMS system. The SMS system may be stuck at the gateway (hundreds of requests per second) due to the short board effect, which is not on the same order of magnitude as the concurrency of the front end. As a result, the processing capabilities of the payment system and the SMS system are differentiated. At this time, the message queue can be used as a reliable temporary storage for messages, and a certain degree of message accumulation can be performed. The downstream system can obtain and process messages according to its own rhythm.

2.4 Eventual Consistency

The concept of consistency comes from the ACID characteristics of local transactions and the CAP theory in distributed transactions. It means that data meets expectations and there will be no contradictions between related data.

The consistency discussed in CAP and ACID is called "strong consistency", sometimes also called "linearizability" (usually in the context of discussing consensus algorithms), and the behavior of sacrificing C in the AP system to obtain the correct results as much as possible is called the pursuit of "weak consistency". In weak consistency, people have summarized a slightly stronger special case, called "eventual consistency", which means: if the data is not changed by other operations within a period of time, it will eventually reach the same result as the strong consistency process.

Eventual consistency is not a necessary feature of message queues, but you can rely on message queues to achieve eventual consistency. On the contrary, if strong consistency is required and you focus on the processing results of business logic, it is more appropriate to use RPC.

There are two ways to achieve eventual consistency using message middleware:

Solution 1: Local message table + compensation mechanism. The local message table is used to ensure that tasks are not lost, and the compensation mechanism ensures that failed messages are eventually consumed successfully through continuous retries. This solution requires attention to message duplication and idempotence design.

Solution 2: Use RocketMQ's message middleware with built-in message transactions (message transactions are not a silver bullet and have the same flaws as other distributed transactions).

Figure 5 Eventual consistency - MQ message transaction (RocketMQ)

3. Side Effects of Message Middleware

While message middleware brings many benefits, it also introduces many disadvantages:

• Reduced system availability: System availability is reduced to some extent, for example, issues such as message loss and message middleware downtime need to be considered.
• Increased system complexity: After the introduction of message middleware, businesses need to consider issues such as duplicate message consumption, message loss, and message delivery order.
• Consistency issues: The asynchronous mechanism of the message queue can indeed improve the system response speed, but consumers may introduce consistency issues if they do not consume correctly.

4 Message Middleware Composition

Although the implementation mechanisms of various message middleware are different, they basically include the following roles:

• Broker: a message server that provides core message services and is responsible for storing and forwarding messages (the forwarding modes are divided into push and pull);
• Producer: message producer, business initiator, responsible for producing messages and transmitting them to broker;
• Consumer: Message consumer, business processor, responsible for obtaining messages from brokers and performing business logic processing;
• Topic: A topic is a centralized place for messages in the publish-subscribe mode. Different producers send messages to a topic, which are distributed to different subscribers by the MQ server to broadcast the messages.
• Queue: message queue. In PTP (point-to-point) mode, a specific producer sends a message to a specific queue, and a consumer subscribes to a specific queue to receive the specified message.
• Message: The message body is a data packet encoded according to the fixed format defined by different communication protocols to encapsulate business data and realize message transmission.

5 Message Middleware Protocol

5.1 JMS

JMS, or Java Message Service (Java Message Service) application program interface, is a message-oriented middleware (MOM) API in the Java platform, used to send messages between two applications or in a distributed system for asynchronous communication. It is similar to JDBC (Java Database Connectivity).

⇊ JMS consists of the following elements:

• JMS provider: connects to the message-oriented middleware and implements the JMS interface. The provider can be a JMS implementation on the Java platform or an adapter for the message-oriented middleware on a non-Java platform;
• JMS client: a Java application or object that produces or consumes messages;
• JMS producer: a JMS client that creates and sends messages;
• JMS consumer: a JMS client that receives messages;
• JMS message: An object that contains data that can be passed between JMS clients;
• JMS queue: An area that holds sent messages waiting to be read. Contrary to what the name of the queue implies, the order in which the messages are received is not necessarily the same as the order in which they were sent. Once a message is read, it is removed from the queue;
• JMS topic: A mechanism that supports sending messages to multiple subscribers.

Strictly speaking, JMS in the messaging field is more of a specification than a protocol. ActiveMQ is a typical implementation of this protocol.

5.2 AMQP

AMQP (Advanced Message Queuing Protocol), an application layer standard advanced message queue protocol that provides unified messaging services, is an open standard for application layer protocols and is designed for message-oriented middleware. Based on this protocol, clients and message middleware can transmit messages without being restricted by different client/middleware products, different development languages, etc.

AMQP has currently launched version 1.0 of the protocol. Well-known products that implement this protocol include StormMQ, RabbitMQ, Apache Qpid, etc. The AMQP version implemented by RabbitMQ is 0.9.1, and it can support version 1.0 through plugins.

⇊ The following content is excerpted from the official website:

RabbitMQ implements version 0-9-1 of the AMQP specification in the core, with a number of extensions to the specification.

RabbitMQ implements AMQP 1.0 via a plugin. However, AMQP 1.0 is a completely different protocol than AMQP 0-9-1 and hence not a suitable replacement for the latter. RabbitMQ will therefore continue to support AMQP 0-9-1 indefinitely.

--Source: https://www.rabbitmq.com/specification.html

5.3 MQTT

MQTT (Message Queuing Telemetry Transport) is a "lightweight" communication protocol based on the publish/subscribe model. The protocol is built on the TCP/IP protocol and was released by IBM in 1999.

The biggest advantage of MQTT is that it can provide real-time and reliable message services for connecting remote devices with very little code and limited bandwidth. As an instant messaging protocol with low overhead and low bandwidth usage, it is widely used in the Internet of Things, small devices, mobile applications, etc.

✓ RabbitMQ can support this protocol through a plug-in.

Figure 6 MQTT application scenario

5.4 STOMP Protocol

STOMP (Streaming Text Orientated Message Protocol) is a streaming text oriented message protocol, a simple text protocol designed for MOM (Message Oriented Middleware). STOMP provides an interoperable connection format that allows clients to interact with any STOMP message broker.

The predecessor of the STOMP protocol was the TTMP protocol (a simple text-based protocol) designed specifically for messaging middleware.

STOMP is a very simple and easy-to-implement protocol, and its design is inspired by the simplicity of HTTP. Although the implementation of the STOMP protocol on the server side may be somewhat difficult, the implementation of the client side is very easy. For example, you can use Telnet to log in to any STOMP broker and interact with the STOMP broker.

5.5 XMPP

XMPP (Extensible Messaging and Presence Protocol) is a protocol based on Extensible Markup Language (XML), mostly used for instant messaging (IM) and online site detection. It is suitable for quasi-instant operations between servers. The core is based on XML streaming, and this protocol may eventually allow Internet users to send instant messages to anyone else on the Internet, even if their operating systems and browsers are different. Features: universal openness, strong compatibility, scalability, high security, but the XML encoding format occupies a large bandwidth and is a long-standing protocol.

5.6 Custom Protocol

Some special frameworks (such as Redis, Kafka, ZeroMq, etc.) do not strictly follow the MQ specification according to their own needs. Instead, they encapsulate a set of protocols based on TCP/IP and transmit them through the network socket interface to realize the functions of MQ.

5.7 Simple comparison of protocols

Figure 7

6 Conclusion

Currently, message middleware technology has become the infrastructure for building distributed Internet applications. More and more systems use message middleware to solve problems such as asynchrony, decoupling, and peak load shaving. Message middleware is not a new technology, but new implementation solutions emerge in an endless stream. When introducing message middleware, you also need to choose a suitable solution based on your own business characteristics and needs.

References

[1] Message-Oriented Middleware (MOM): https://docs.oracle.com/cd/E19148-01/820-0533/6nc927vst/index.html.

[2] Phoenix Architecture: http://icyfenix.cn/.​