How far do you have to go from architect to CTO?

As far as programmers are concerned, there are three possible career paths: focus on technical depth, move to team management, and become an architect.

Being a good architect is what most technical people aspire to be. However, the chance of being a senior architect is only about 0.3%. If you want to stay at the top of the pyramid after 3-5 years, you must have a solid foundation in code and project accumulation, as well as an awareness of technical breadth and architectural thinking ability. You can also gain a lot from learning more experience.

My name is Li Zhihui and I have been engaged in architecture for over 20 years. You in front of the screen, since you have chosen the architecture, you should steadfastly learn every piece of knowledge. Today we will look at distributed message queue MQ. In this article, I will focus on the differences between synchronous and asynchronous architectures.

This article is excerpted from: 36 Exercises for Architects

01 Synchronous Invocation

The so-called
A synchronous invocation, that is to say,
From the time the request is initiated until the final processing is complete.
The caller of the request has been blocking synchronously waiting for the processing of the call to complete.

Let’s take a look at the example in the picture. In this example, the ClientCode needs to perform the operation sendEmail, which calls EmailService to send the message.

EmailService calls a class called SmtpEmailAdapter, which calls a remote service to which requests are sent via SMTP and TCP.

The remote server receives the message, performs a series of operations on it, sends it out, and returns it.

The Adapter receives the return and returns it to the EmailService, which then returns the result to Clientcode.

ClientCode blocks here after sendEmail sends a request, waiting for the result of the final call to return, whether it succeeds or fails. Because this process blocks waiting, this process is also called synchronous invocation.

02
The asynchronous call

The opposite of a synchronous call is an asynchronous call. In the asynchronous call process, we also looked at the example we just sent, when the user’s Clientcode calls EmailService, the EmailService will
The invocation request is sent to the message queue and immediately returned.

Clientcode continues processing after receiving a return and does not continue to block waiting. In fact, once the message is sent to the Queue, it hasn’t been processed yet, so we’ll see that the message is actually consumed a little bit later than the EmailService returns, and then the message is consumed.

There is a QueueConsumer message QueueConsumer that fetches the message from the message queue and sends the message to the SmtpAdapter, which calls the SmtpAdapter.

The SmtpAdapter sends the message to a RemoteServer through SMTP for email sending. After receiving the message, the SmtpAdapter notifies the message Queue of the return result.

We see that in this process, the client call, that is, the application call, is out of sync with the business logic actually sending the mail.

During the process of sending the mail, the client code has been returned and it can
Continue with your subsequent operationsAnd the
No need to waitThe sending of the mail, this is
It’s called asynchronous call.

This article is excerpted from: 36 Exercises for Architects

The primary means of using the asynchronous invocation architecture is through message queue building. This is the architecture of it.

After the producer of the message sends the message to the message queue, the consumer of the message obtains the message from the message queue and then processes the business logic. The producer and consumer of the message are processed asynchronously and do not wait to block each other, so it is called
Asynchronous architecture.

To build an asynchronous invocation architecture with message queues, you need to understand three roles: producer of messages, queue of messages, and consumer of messages.

01 Message producer

The producer of the message is the part of the client application code that initializes the asynchronous invocation processing flow.

In message queue-based processing, the producer has very little responsibility. All it has to do is create a valid message and send it to the message queue. The application developer decides where the producer’s code will execute and when to send the message.

02 Message Queue

Another major component of the message queue asynchronous architecture is the so-called message queue.

Message queues are the destination to which messages are sent and a buffer to consumers. Message queues can be implemented in a variety of ways, using shared folders, relational databases, or NoSQL systems.

Of course, the most important is to use a dedicated distributed message queue server to achieve.

03 Message consumers

The third important role of a business architecture is as a consumer of messages. The message consumer, which receives and processes messages from the message queue, is also implemented by the application developer, but is a component that is processed asynchronously.

The consumer of the message does not need to know that the producer exists, it only depends on the message in the message queue. Consumers of messages are typically deployed on separate servers, completely isolated from message producers, and can scale by adding hardware.

With these three main roles in mind, you need to know two models for building asynchronous invocation architectures using message queues: the point-to-point model and the publish-subscribe model.

Point-to-point model

Let’s start with the point-to-point model. Consumers and producers only need to know the name of the message queue,
Producers send messages to a message queue, and at the other end of the message queue are multiple consumers competing to consume the message.

Each message arriving in the message queue is routed to only one consumer, so the consumer sees a subset of the total message.

If we look at this picture, we have multiple producers of messages, multiple consumers of messages, multiple producers sending messages to the message queue, and multiple consumers competing to consume messages in the message queue.

Each message is consumed by only one consumer, and each consumer consumes only a portion of the messages in the message queue.

Publish and subscribe model

In a publish-subscribe model, messages may be sent to more than one consumer,The producer sends a message to a topic, not to a queue.

Once a message is published to a topic, it is cloned to each consumer that subscribes to it, and each consumer receives a copy of the message copied to its own private queue.

Consumers can use their subscribed messages independently of other consumers and there is no competition for messages among consumers.

Common distributed message queues support a publish-subscribe modelThat is, the publish-subscribe model of messages is a functional feature of distributed message queues.

Combining the two models and comparing them,
The point-to-point model is typically used for businesses that take longer and are logically independentFor example, I mentioned sending an email earlier.

Because sending mail is time consuming, the application doesn’t really care if the mail is sent successfully, and the logic of sending mail is relatively independent, it simply drops the mail message into the message queue and returns it.

And the consumer does not need to care about which producer sends the mail, it only needs to take out the mail message content for consumption, through the remote server to send the mail. and
Each message needs to be sent only once. So the message is consumed by only one consumer.

Corresponding to another case, such as the new user registration, a new user registration, need to give users send an activation email, send a welcome message, also need to write the user registration data into the database, or even new users’ information needs to be sent to the affiliated enterprise systems, such as the new user information sent to the alipay taobao.

This allows users to log in to multiple associated products with one registration.So for new users to register such a message, you need to publish it by topic,
That’s the publish-subscribe model.

When a new user registers, the registration message is sent to a topic that multiple consumers can subscribe to. Consumers who send emails, consumers who send SMS messages, consumers who write registration information to a database, consumers who synchronize messages across systems, and so on.

Thank you for your persistence. In the next lesson, I will explain distributed database in detail and share my practical experience. Come on, we’ll be there!

This article is excerpted from: 36 Exercises for Architects

Copyright notice: The copyright of this article belongs to Pull hook education and the columnist. Any media, website or individual shall not be reproduced, linked, reposted or otherwise copied and published/published without the authorization of this agreement, the offender shall be corrected.