What is distributed messaging middleware?
For distributed message middleware, we must first understand two basic concepts, namely what is a distributed system and what is middleware.
Distributed Systems
“A distributed system is one in which components located at networked computers communicate and coordinate their actions only by passing messasges.”——《Distributed Systems Concepts and Design》
From the above explanation, two characteristics of distributed systems can be obtained:
Components are distributed across network computers
Coordinate actions between components through messages
middleware
Middleware is computer software that provides services to software applications beyond those available from the operating system. It can be described as "software glue". Middleware makes it easier for software developers to implement communication and input/output, so they can focus on the specific purpose of their application.——维基百科
Middleware is described as providing applications with services other than those provided by the operating system, simplifying application communication, input and output development, and allowing them to focus on their own business logic.
The explanation of middleware from Wikipedia feels a bit confusing. In fact, middleware can be understood from the perspective of "space", that is, middleware is a component in the "middle layer", which is between the upper-level application and the underlying service. Bridges (for example, the upper layer of DB middleware is the application program, and the bottom layer is the DB service), and it is also a bridge between applications (such as distributed service components).
Distributed message middleware
“Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems.”——维基百科
The definition of message middleware given by Wikipedia is the hardware or software infrastructure that supports sending and receiving messages in a distributed system (for the scope of our discussion here, it must be software).
So distributed message middleware actually means that message middleware itself is also a distributed system.
What can message middleware do?
Any middleware must solve a certain problem in a specific field, and message middleware solves the problem of message transmission between distributed systems. Message passing is a problem that distributed systems must face.
Assuming an e-commerce transaction scenario, after the user places an order, the inventory system is called to reduce the inventory, and then the logistics system needs to be called to deliver the goods. If the transaction, inventory, and logistics belong to the same system, then it is an interface call. However, with the development of the system, each module is getting bigger and bigger, and the business logic is getting more and more complex, so it is necessary to do servitization and business splitting. At this time, it is necessary to consider how these systems interact. The first reaction is RPC (Remote Procedure Call). As the system continues to develop, it may be necessary to call dozens of interfaces to execute the business after a transaction, such as risk control systems, SMS services, and so on. At this time, message middleware needs to appear to solve the problem.
The author believes that the difference between RPC and message middleware scenarios largely lies in "dependence" and "quantity". For example, the SMS notification service is not necessary for the transaction process, does not affect the order process, and is not strongly dependent, so the transaction system should not rely on the SMS service. For example, some data analysis programs may need to obtain the total sales volume of a day, which only requires the sales center to provide an interface to call when needed.
After the emergence of message middleware, for transaction scenarios, it may call the inventory center and other strongly dependent systems to perform business, and then publish a message (this message is stored in the message middleware). Such as SMS notification service, data statistics service, etc., all rely on message middleware to consume this message to complete their own business logic.
From the above scenarios, we can see that message middleware actually decouples the system and brings benefits such as asynchronization.
A brief summary of the application scenarios of message middleware is roughly as follows:
Business decoupling: the transaction system does not need to know the existence of the SMS notification service, but only needs to publish the message
Peak shaving and valley filling: For example, the throughput capacity of the upstream system is higher than that of the downstream system, which may overwhelm the downstream system during the traffic peak. The message middleware can accumulate messages during the peak time, and the downstream system slowly consumes messages to solve the traffic peak after the peak value passes. The problem
Event-driven: The business can be driven in the form of message passing between systems and processed in a streaming model
What does distributed message middleware look like?
An abstract understanding of distributed message middleware is roughly like this:
There is an SDK that provides an interface for business systems to send and consume messages
A batch of Server nodes are used to receive and store messages, and send them to downstream systems for consumption when appropriate