What is a synchronous call What is an asynchronous call
Once microservices are split, they will inevitably involve mutual calls between services. After the caller initiates a request, he needs to wait for the service provider to return the result after executing the business, and then continue to execute the subsequent business. The caller is blocked during the calling process, so we call this calling method synchronous calling, which can also be called synchronous communication. But in many scenarios, we may need to use asynchronous communication. Let's take a look at what synchronous communication and asynchronous communication are.
Synchronous communication: Just like making a video call, the interaction between both parties is real-time. Therefore you can only make a video call with one person at a time.
Asynchronous communication: Just like chatting on WeChat, the interaction between the two parties is not real-time, and you do not need to respond to the other party immediately. So you can operate in multiple lines and chat with multiple people at the same time.
Both methods have their own pros and cons. You can get an immediate response when you call, but you can't talk to multiple people at the same time. You can send and receive WeChat messages to multiple people at the same time, but the response is often delayed.
Therefore, if our business requires real-time response from the service provider, we should choose synchronous communication (synchronous call). And if we pursue higher efficiency and do not need real-time response, we should choose asynchronous communication (asynchronous call).
There are three problems with synchronous calls:
First, poor scalability. Our current business is relatively simple, but as the business scale expands, the functions of the products are also constantly improved. In most e-commerce businesses, after the user successfully pays, the user will be notified via text message or other means to inform them that the payment was successful. What should you do if the product manager puts forward such new requirements later? Do you want to add the business of notifying users to the above business? In some e-commerce projects, there will also be the concept of points or gold coins. If the product manager makes a request and the user pays successfully, the user will be rewarded with points or gold coins will be returned. What should you do? Should you add points business and gold coin return business to the above business? . . Eventually your payment business will become more and more bloated:
In other words, every time there is a new demand, the existing payment logic must change accordingly. The code changes frequently, which does not comply with the opening and closing principle and has poor scalability.
Second, the performance decreases because we use synchronous calls. The caller needs to wait for the service provider to complete the execution and return the result before continuing to execute. That is to say, for every remote call, the caller is in a blocking waiting state. In the end, the response time of the entire business is the sum of the execution time of each remote call. If the execution time of each microservice is 50ms, the entire business may ultimately take up to 300ms, and the performance is too poor.
Third, the cascade failed because we called the transaction service and notification service based on OpenFeign. When the transaction service and notification service fail, the entire transaction will be rolled back and the transaction will fail. This is actually the cascading failure problem of synchronous calls.
To solve these problems, we must use asynchronous calls instead of synchronous calls.
Advantages and features of asynchronous calls
The asynchronous calling method is actually based on message notification, and generally includes three roles:
Message sender: The person who delivers the message is the original caller
Message Broker: manages, temporarily stores, and forwards messages. You can think of it as a WeChat server.
Message receiver: The person who receives and processes the message is the original service provider
In an asynchronous call, the sender no longer directly calls the receiver's business interface synchronously, but sends a message to the message broker. The receiver then subscribes to the message from the message broker according to its own needs. Whenever the sender sends a message, the recipient can get the message and process it. In this way, the person sending the message and the person receiving the message are completely decoupled.
Let’s take the balance payment business as an example:
Except for deducting the balance and updating the status of the payment slip, all other calling logic is cancelled. Instead, a message is sent to the Broker. Relevant microservices can subscribe to message notifications. Once the message reaches the Broker, it will be distributed to each subscribed microservice to process their respective businesses.
Suppose the product manager puts forward new requirements, such as updating user points after successful payment. The payment code does not need to be changed at all, just let the points service also subscribe to the message:
No matter how many message subscribers are added later, as a payment service, just send the message after deducting the balance and updating the payment flow status. The business time consumption is only for these three parts of the business, only 100ms, which greatly improves business performance.
In addition, whether it is transaction services, notification services, or points services, their business has low correlation with payment. Nowadays, asynchronous calls are used to decouple the coupling. Even if they fail during execution, the payment service will not be affected.
In summary, the advantages of asynchronous calls include:
Less coupling
Better performance
Strong business expansion
Fault isolation to avoid cascading failures
Of course, asynchronous communication is not perfect. It has the following shortcomings:
Completely dependent on Broker's reliability, security and performance
Complex architecture, troublesome later maintenance and debugging