I. Background messaging middleware
1. Introduction: Consider the use of messaging middleware scene?
- It requires the use of messaging middleware scenario in which
- Why should the introduction of messaging middleware in the system
2, according to the above mentioned problems: from life to actual production Case Case
Service-based micro-architecture Background: chained calls to our general process of writing program time, in order to complete a whole function will split it into multiple functions (or sub-modules), such as module A calls Module B, Module B calls module C, C module calls module D. But in large-scale distributed applications, RPC interaction between complex systems, a function to be called back hundreds of interfaces is not impossible, the transition from stand-alone micro-architecture to the general rule distributed services architecture.
Note meaning: these architectures will be considered at this point what the problem?
Direct calls between landing system actually works and problems:
- Interface is coupled between the system more serious
- The face of large concurrent flow, easy to be washed away
- Waiting for sync performance issues
Coupling the interface between (1) the system is more serious
For example: if the data to be transmitted to the system A and system B System C, there may be transmitted to the difference data for each system, so the system A the data to be transmitted to each system have been assembled, and then transmitted one by one;
when the code is on-line and then added a demand:
the data is also sent to D, a D on new system also accepts data a system, then you need to modify a system that allows him to perceive the presence of D system, while data deal to give D. In this process, you will see that each access a downstream system, the system must be A code reform, inefficient development of the FBI. Its overall structure below
(2) the face of large concurrent flow, easy to be washed away
For example spike business:
upstream operating system to initiate purchase orders, I was operating under a single
downstream spike system complete business logic
(read orders, check inventory, inventory freeze, balance check, balance freezing order, the balance of deductions, inventory reduction, generating water balance thaw, stock thaw)
(3) wait for the synchronization performance issues
For example, A calls B / C / D is 50ms, but this time B calls the B1, take 2000ms, then directly drag on overall service performance.
3. Solution:
In designing the system can clear targets to be achieved:
Second, an overview of the messaging middleware
1. Definitions
Message-oriented middleware (message-oriented middleware) MOM can solve the above problems, it refers to the exchange of data with efficient and reliable messaging platform-independent mechanism, and distributed to the integrated communication system based on the data.
By providing a transfer message and message queuing model provides decoupling applications in a distributed environment, elastically stretchable, redundant storage, flow clipping, asynchronous communication, data synchronization.
Process messaging: the sender to send the message to the message server, message server messages stored in a number of queue / topic in the topic, at the right time, back to the message server forwards the message to the recipient. In this process, sending and receiving is asynchronous, that is, send no waiting, and the sender and receiver of the life cycle is not necessarily related; in particular, publish pub / subscribe under sub mode, you can also complete many of communication, that allows a message has multiple recipients.
2. Features
(1) asynchronous processing mode
Message sender can send a message without waiting for the response. Message sender to send a message to a virtual channel (topic or queue) on;
the message recipient is subscribed or love listening to the channel. A message may eventually forwarded to one or more of the message recipient, the recipient of these messages are synchronized without having to make a response to the message sender. The entire process is asynchronous.
Case: In other words, when communication between a system with another system, if the system A wants to send a message to System B, let him to deal with. A system but the system does not care about how to handle or B in the end there is no deal, so the system A to send a message to MQ, then regardless of "life and death of" this message, then the system B MQ consumption from the inside out process can be. As for how to deal with, whether processed, when processing, system B thing is, regardless of the system A.
Decoupling between (2) applications
- The sender and receiver do not have to understand each other, just make sure the message
- The sender and receiver need not be online at the same time
3, the overall architecture:
4, the message middleware function:
5, download and use the related functions
(1) download:
ActiveMQ official website: http://activemq.apache.org/
(2) main functions:
(3) use:
- Consumption and handling asynchronous messages
- Consumer sequence control message
- Spring can be integrated to simplify the code or SpringBoot
- MQ cluster configuration fault-tolerant cluster
Three, Activemq download and install
1, the official website to download
2, linux installation
Upload: Use rz and sz commands upload and download
- / Opt directory
- Unzip apache-activemq-5.15.9-bin
- In the root directory mkdir / myactiveMQ
- cp -r apache-activemq-5.15.9 /myactiveMQ/
- Normal start mq: ./activemq start
- actvemq the default process port is 61616
- View background processes methods:
3, start:
(1) Normal startup default port is 61616
(2) with a running log of the start-up mode
Let's not start the console log information print, and put a special file:
4, Apache ActiveMQ Console
5, notes:
- 61616 using ActiveMQ JMS port to provide services
- ActiveMQ using port 8161 to provide management console service