Shulou(Shulou.com)05/31 Report--

This article mainly shows you "how to standardize the use of RabbitMQ in micro services", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "how to standardize the use of RabbitMQ in micro services" this article.

Typical application scenarios RabbitMQ typical application scenarios

This figure shows a typical application scenario of RabbitMQ. Producers send messages to Exchange, consumers read messages from Queue, and messages can be routed to Queue by Exchange through topic, header, direct and fanout.

In the development process of micro services, if developers are allowed to define Exchange, Queue and routing, even if good programmers correctly define these elements, service dependency will generate a very complex mesh structure, which must be a disaster to manage. Therefore, it is necessary to standardize the use, which is the proper meaning of technical management.

Through the document definition specification, this constraint is weak and needs to constantly verify the implementation of the specification. Through the code, architecture definition specification, the implementation of the specification without the intervention of developers, shielding the complexity of the program is a problem that architects need to consider. Excellent architecture simplifies and standardizes the development process, enables programmers to focus on business development, and improves the efficiency of business development.

According to this guiding ideology, the use of RabbitMQ is regulated and restricted.

Application scenarios in standardizing Micro-Services

The constraints are as follows:

If the service has Producer enabled, create the same Exchange as the service name and send a message to this Exchange.

If the service has Consumer enabled, create the same Queue as the service name, and subscribe to messages from this Queue.

Read the Receiver defined in the program, parse the defined service (which is actually the Exchange name) and tag, and create a binding relationship between Queue to Exchange.

The above process is performed when the service is started without programmer intervention.

Advantages: programmers do not need to pay attention to who the message is sent to, just call the service to send the message; programmers do not need to care about how the message is routed, just define the receiver processing class for the tag they care about. In addition, because of the use of unified api sending and receiving, it is convenient for future expansion.

Cons: each service has only one Exchange, only one Queue, and only Topic routing is used; therefore, performance is not optimal and can only be used in moderate or mild processing scenarios. If you have personalized processing scenarios, you still need to customize these components.

Summary: in AntSentry's micro-service architecture, Kinesis queues (like kafka) are used for large traffic, and peer-to-peer SQS queues are used for large concurrency. RabbitMQ is only used to solve the problem of calling between services, and the traffic is not too large. Its flexibility makes up for the shortcomings of Kinesis and SQS. In this unique scenario, it meets the business needs. In most microservice scenarios, this application model can meet most of the needs, and I hope it will be helpful to you.

Usage

1) modify pom and upgrade api version (this project is not open source and is used internally)

Xx

Cloud-api-tools

1.3.3-SNAPSHOT

2) Custom AutoConfig is adopted. After configuration, rabbitmq is enabled according to the specification.

Com:

Xx:

Rabbitmq:

Host: 10.30.60.41

Password: XX

UserName: xx

Port: 5672

Vhost: dev

3) create a message entity

@ Data

Public class XXDemoInfo extends MQMessage {

@ Override

Public String getTag () {

Return "work"; / / Identification of the message

}

Private String name

Private Long timestamp

}

4) create the recipient, configure the source of the message and tag; can be configured with multiple annotations to implement a single receiver to handle multiple tag

@ RabbitMQReceiver (service = "cloud-xx-service", tag = "work")

Public class XXTagReceiver implements RabbitMQBaseReceiver {

@ Override

Public void receive (XXDemoInfo xxDemoInfo) {

}

}

5) send a message example

@ Autowired

RabbitMQSender sender

Public void send () {

XXDemoInfo info = new XXDemoInfo ()

Info.setName ("Test Message")

Info.setTimestamp (System.currentTimeMillis ())

Sender.send (info)

}

Configure ReceiverScan@RabbitMQReceiverScan (basePackages = {"com.xx.receiver"})

/ / fill in the package where the receiver class is located

Public class SomeApplication implements CommandLineRunner {

}

Implementation of key technologies

There's nothing to talk about here, so you can't post a lot of code. Just draw a brief picture of the startup process.

The above is all the contents of the article "how to standardize the use of RabbitMQ in Micro Services". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.