Method for realizing interface asynchronous calling based on message queue

Abstract

The invention provides a method for realizing interface asynchronous calling based on a message queue, and relates to the technical field of cloud computing, and the method comprises the following steps: S1, selecting a message queue product, and carrying out installation configuration; s2, packaging the functions of the message queue, and providing a unified event publishing and subscribing mechanism; s3, defining and generating a synchronous interface through the front-end interface, wherein the synchronous interface is used for receiving the request parameters and executing the corresponding service logic; s4, registering the synchronous interface as an asynchronous interface, and generating a publishing end and a subscribing end of the corresponding message queue; wherein the calling process of the asynchronous interface comprises the steps that a client requests to trigger the publishing end of the message queue, the publishing end packages request parameters into a message body and sends the message body to the message queue, and the subscription end monitors the message queue, obtains the message body and calls the synchronous interface to execute service logic.

Description

Technical Field

[0001] The present application belongs to the field of cloud computing technology, and specifically relates to a method for implementing asynchronous interface calls based on a message queue. Background Art

[0002] With the rapid development of cloud computing and distributed systems, modern software has an increasing demand for high-concurrency, low-latency interface calls. Especially in the fields of e-commerce, financial payments, and real-time data processing, the system needs to respond quickly to massive requests to avoid blocking problems caused by synchronous calls. Asynchronous interface call technology significantly improves system throughput and user experience by decoupling time-consuming operations from the main process, and has become an important direction for current technological evolution.

[0003] At present, the mainstream asynchronous interface implementation methods mainly include the following three: Create independent threads to handle time-consuming operations to avoid blocking the main thread. However, thread management is complex, resource consumption is large, and it is difficult to deal with stability issues in high-concurrency scenarios. Deliver the request message to the queue and process it asynchronously by the background program. Common products such as RabbitMQ and Kafka can achieve decoupling and peak shaving, but developers need to manually write queue publishing, subscription and exception handling logic, which has low development efficiency. For example, the @Async annotation of the Spring framework simplifies asynchronous method calls through declarative methods, but it relies on a specific technology stack, lacks flexibility, and lacks unified interface configuration capabilities.

[0004] The existing solution requires developers to deeply code to implement message queue integration, interface binding and exception handling, which has high technical requirements for developers. From interface definition to asynchronous logic implementation, multiple links need to be manually developed, and the testing and verification cycle is long, making it difficult to quickly respond to business needs. The existing technology lacks an automated compensation mechanism for abnormal scenarios such as message loss and processing timeout, and additional retry or rollback logic needs to be developed. The switching between synchronous and asynchronous modes depends on code modification and cannot be dynamically adjusted through configuration, making it difficult to adapt to changing business scenarios. Summary of the invention

[0005] The present application provides a method for implementing asynchronous interface calls based on message queues to solve the technical problems of system blocking, response delays and insufficient exception handling caused by traditional synchronous interface calls due to low development efficiency, weak fault tolerance, high technical barriers and lack of flexible configuration.

[0006] The technical solution adopted in this application is:

[0007] The present application embodiment provides a method for implementing an asynchronous interface call based on a message queue, comprising the following steps:

[0008] S1. Select a message queue product and install and configure it.

[0009] S2. Encapsulate the functions of the message queue and provide a unified event publishing and subscription mechanism;

[0010] S3. Define and generate a synchronous interface through the front-end interface, where the synchronous interface is used to receive request parameters and execute corresponding business logic;

[0011] S4, registering the synchronous interface as an asynchronous interface, and generating a corresponding publisher and subscriber of the message queue;

[0012] Among them, the calling process of the asynchronous interface includes: the client request triggers the publishing end of the message queue, the publishing end encapsulates the request parameters as a message body and sends it to the message queue, the subscriber listens to the message queue and obtains the message body, and calls the synchronous interface to execute business logic.

[0013] According to one embodiment of the present application, the message queue product is selected from at least one of the following: RabbitMQ, Kafka, RocketMQ, ActiveMQ or a message queue implemented based on Redis.

[0014] According to an embodiment of the present application, in step S2, the function encapsulation is implemented using the JMS specification or the Spring AMQP framework.

[0015] According to an embodiment of the present application, in step S3, the front-end interface configuration includes:

[0016] Register the existing method or RPC service in the system as a synchronous interface, and serialize or deserialize the request parameters of the interface.

[0017] According to an embodiment of the present application, in step S4, when registering the asynchronous interface, the publishing end and the subscribing end of the message queue are automatically generated, and the publishing end and the subscribing end are both deployed in the same application instance.

[0018] According to an embodiment of the present application, after the asynchronous interface call is completed, the execution result is returned to the client through a preset callback interface.

[0019] According to an embodiment of the present application, the subscriber of the message queue supports compensation or retry operations for requests with execution exceptions when calling a synchronous interface.

[0020] According to an embodiment of the present application, it also includes configuring the calling mode of the switching interface through the interface to achieve dynamic switching between asynchronous calling and synchronous calling.

[0021] According to an embodiment of the present application, when sending a message body, the publisher of the message queue converts the format of the request parameters to adapt them to the synchronous interface parameter requirements of the subscriber.

[0022] According to one embodiment of the present application, the triggering conditions of the compensation or retry operation include: message processing timeout, interface return error code or the persistence mechanism of the message queue detects an unfinished message.

[0023] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows:

[0024] This application supports the flexible selection of multiple mainstream message queues (such as RabbitMQ, Kafka, etc.), adapts to the performance requirements of different business scenarios (such as high throughput, low latency), and improves the universality and scalability of the solution. Through standardized interfaces (such as JMS, Spring AMQP), the underlying MQ differences are shielded, the development complexity is reduced, and the system compatibility and maintainability are enhanced. Interface configuration replaces manual coding, allowing non-technical personnel to quickly register existing methods or RPC services as synchronous interfaces, greatly reducing the technical threshold and shortening the development cycle. Automatically generate the queue components required for asynchronous calls, and realize "one-click switching" from synchronous interface to asynchronous mode, avoiding invasive code modifications and improving deployment efficiency. The decoupling of requests and processing is achieved through message queues to ensure that the main process responds quickly to the client. At the same time, the persistence, retry and other mechanisms of the queue are used to enhance the system's fault tolerance and avoid request loss or repeated execution.

[0025] This application significantly reduces the development and maintenance costs of asynchronous interfaces through interface configuration, standardized packaging and automated generation mechanisms. At the same time, relying on the mature features of message queues (such as peak shaving and valley filling, exception retry), it improves the reliability and scalability of the system in high-concurrency scenarios, and provides efficient technical support for rapid response to business needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0027] Figure 1 A flowchart of a method for implementing asynchronous interface calls based on a message queue is provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to more clearly illustrate the overall concept of the present application, a detailed description is given below in an illustrative manner in conjunction with the accompanying drawings.

[0029] In the following description, many specific details are set forth to facilitate a full understanding of the present application. However, the present application may also be implemented in other ways different from those described herein. Therefore, the protection scope of the present application is not limited by the specific embodiments disclosed below. It should be noted that the embodiments of the present application and the features in each embodiment may be combined with each other without conflict.

[0030] In the present application, unless otherwise clearly specified and limited, a first feature "above" or "below" a second feature may be that the first and second features are in direct contact, or the first and second features are in indirect contact through an intermediate medium. In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in an appropriate manner in any one or more embodiments or examples.

[0031] Example 1

[0032] like Figure 1 As shown, a method for implementing interface asynchronous calling based on a message queue includes the following steps:

[0033] S1. Select a message queue product and install and configure it.

[0034] Specifically, choose a message queue product: First, you need to choose from a variety of message queue products, including RabbitMQ, Kafka, RocketMQ, ActiveMQ, or message queues based on Redis. Choosing a suitable message queue product requires considering multiple factors, such as performance requirements, reliability, scalability, community support, etc.

[0035] Installation and configuration: After selecting a message queue product, the next step is to install and configure it. This process usually involves the following steps: Environment preparation: Make sure that the server environment meets the operating requirements of the selected message queue product, such as operating system version, Java runtime environment (if applicable), network configuration, etc. Installation: Perform the installation process according to the official documentation or guide. Different message queue products have different installation methods, which may include downloading binary files, installing using a package manager, or deploying through containerization technology (such as Docker). Configuration: After the installation is complete, the message queue needs to be configured to adapt to the specific application scenario. Configuration items may include but are not limited to network listening ports, persistent storage settings, cluster mode configuration (if used for distributed systems), security settings (such as user authentication and permission control), etc. Testing and verification: After completing the installation and configuration, a series of tests are generally required to verify whether the message queue is installed correctly and whether the configuration is effective, such as sending and receiving test messages, checking log output, etc.

[0036] For example, first, we need to select the most suitable message queue (MQ) product based on project requirements and application scenarios. Suppose our project is an application that processes a large number of real-time transaction requests, requiring high throughput, low latency, and good scalability and active community support. Based on these requirements, we can compare several common MQ products:

[0037] RabbitMQ: Written in Erlang, supports multiple protocols (such as AMQP, XMPP, etc.), has strong concurrency capabilities, excellent performance, an active community, and a rich management interface.

[0038] RocketMQ: Developed by Alibaba, it is suitable for the big data field, has good scalability, and high single-machine throughput (hundreds of thousands), but its C++ client support is not yet mature.

[0039] Kafka: Designed for big data, although it only supports the main MQ functions, it performs well in high-throughput scenarios with low latency.

[0040] ActiveMQ: As an old product, it is highly mature and has more documentation, but its single-machine throughput is relatively the lowest.

[0041] In this example, considering the need for high throughput and low latency, as well as an active community for better technical support, you might be inclined to choose RabbitMQ or RocketMQ. Since RocketMQ's lack of C++ client support may be an obstacle, the final decision was to choose RabbitMQ.

[0042] Install and configure RabbitMQ

[0043] Environment preparation: Make sure the server operating system meets the requirements of RabbitMQ. For example, if you are using a Linux system, confirm that the necessary dependencies, such as the Erlang language runtime environment, have been installed.

[0044] Install RabbitMQ:

[0045] You can download the latest version of RabbitMQ installation package from the official website, or use the system package manager (such as yum or apt-get) to install it. If it is a production environment deployment, it is recommended to consult the official documentation for more detailed installation guides, including how to set up cluster mode to improve availability and fault tolerance.

[0046] Configure RabbitMQ:

[0047] Modify the configuration file (usually located in the / etc / rabbitmq / directory) to adjust the network listening port, user authentication, and permission control according to actual needs. Configure persistent storage to ensure that important data is not lost in the event of a failure. Set the parameters of the message queue according to the needs of the application, such as message expiration time, maximum queue length, etc. Test and verify: After starting the RabbitMQ service, you can verify whether the installation is successful by sending a simple test message to the queue and trying to receive the message from another terminal. Check the log output to ensure that no error messages appear, indicating that RabbitMQ has been correctly configured and started working.

[0048] Furthermore, you can also consider whether the performance indicators of the message queue, such as throughput and latency, meet the application requirements. For example, if you need to process a large number of real-time transaction requests, you should choose a message queue product with high throughput and low latency, such as RabbitMQ or RocketMQ. Evaluate the data protection capabilities of the message queue under system failures. For application scenarios where message loss is not allowed, you need to choose a message queue that supports persistent storage and understand its persistence mechanism. Consider the needs of future business growth and choose a message queue product that is easy to expand. For example, some products may be better at horizontal expansion (such as Kafka), while other products provide a rich feature set to adapt to different usage scenarios. Choose a product with an active community and technical support, which can help solve problems and obtain best practice recommendations. At the same time, sufficient official documentation and third-party tutorials are also important factors. Check whether the selected message queue product supports the programming language and framework used in the project, and how difficult it is to integrate with other systems.

[0049] S2. Encapsulate the functions of the message queue and provide a unified event publishing and subscription mechanism.

[0050] Specifically, in actual applications, different message queue products (such as RabbitMQ, RocketMQ, etc.) have their own unique APIs and usage methods. In order to simplify the development process and improve the maintainability and scalability of the system, it is necessary to abstract and encapsulate these underlying message queue functions and provide a unified interface to the upper-level business logic. This allows developers to publish and subscribe to events through the same programming model regardless of the message queue product, without having to worry about the specific implementation details of the underlying layer.

[0051] Event publishing: refers to sending an operation or state change in the form of a message to a message queue for other system components or services to subscribe and process. In this process, it is necessary to define the format of good messages (such as JSON or XML) and how to serialize / deserialize these messages. The encapsulated function should allow developers to easily specify the topic (Topic), exchange (Exchange) and other information of the message without having to have an in-depth understanding of the relevant concepts of specific message queue products. Event subscription: refers to listening to messages in a specific topic or queue, and triggering the corresponding processing logic when the message is received. The encapsulated subscription mechanism should be able to automatically handle the reception, parsing and distribution of messages to appropriate processors, while supporting error handling and retry strategies. For developers, they only need to focus on the implementation of business logic.

[0052] There are two main technical means to achieve this mechanism:

[0053] JMS (Java Message Service) specification: This is a standard API that provides message services for Java applications. It defines a set of common message transmission interfaces, allowing applications to communicate without relying on specific message queue implementations. Many messaging middlewares implement the JMS specification, so JMS can be used to create cross-platform messaging solutions.

[0054] Spring AMQP framework: If you choose an AMQP-compatible message queue (such as RabbitMQ), you can use the Spring AMQP framework to simplify the interaction with the message queue. Spring AMQP provides a high-level abstraction, including template classes (AmqpTemplate), message listener containers (MessageListenerContainer) and other components, which greatly simplifies the process of sending and receiving messages.

[0055] For example, suppose you have selected RabbitMQ as the message queue product and completed the installation and configuration. Now, you need to encapsulate its functions to provide a unified event publishing and subscription interface for the business layer.

[0056] Encapsulation Target

[0057] Abstraction: The features and operation methods of different message queue products are abstracted, so that the business logic code can be independent of the specific message queue product. Ease of use: Messages can be sent and received through simple API calls, reducing development complexity. Maintainability: When expanding or replacing message queue products in the future, only the encapsulation layer code needs to be modified without affecting the upper-layer application.

[0058] Encapsulation using the JMS specification or Spring AMQP framework

[0059] Example: Encapsulation using the Spring AMQP framework

[0060] a. Configuration class

[0061] First, create a configuration class to set up basic components such as connection factories and templates. This step hides the specific RabbitMQ connection information (such as host address, port number, etc.).

[0062] -Create a Java configuration class to define RabbitMQ connection parameters, such as host, port, username, password.

[0063] -Define the ConnectionFactory, which is the entry point to connect to the RabbitMQ server.

[0064] -Defines AmqpTemplate, which is the core interface for sending and receiving messages.

[0065] b. Message sender

[0066] Next, define a message sender service that uses the previously configured AmqpTemplate to send messages. Here we simplify the operation of sending messages to a method call, hiding the specific interaction details of RabbitMQ.

[0067] -Define a MessageSender class, including a sendMessage method.

[0068] -In the sendMessage method, use the convertAndSend method of AmqpTemplate to send the message to the specified exchange and routing key.

[0069] c.Message Listener

[0070] Then, define a message listener to subscribe to messages of a specific topic. This listener is responsible for receiving messages and executing corresponding business logic processing.

[0071] -Define a MessageListener class that implements the MessageListener interface.

[0072] -Write the logic for handling received messages in the onMessage method.

[0073] -Configure the MessageListenerContainer, associate it with the MessageListener, and specify the name of the queue to be listened.

[0074] Unified event publishing and subscription mechanism

[0075] After the above encapsulation, the business layer can use the message queue in the following ways:

[0076] Event publishing: Just call the MessageSender.sendMessage(String exchange,String routingKey,Object message) method and pass in the appropriate exchange name, routing key and message content. This method will automatically handle the message format conversion and sending process. Event subscription: By implementing the onMessage(Message message) method in MessageListener, when a message arrives at the listening queue, the system will automatically call this method and pass the message object to it. Developers only need to focus on how to process these messages. This encapsulation method not only simplifies the use of message queues, but also provides a good abstraction layer, so that if you need to replace the message queue product or adjust the message processing logic in the future, you can easily complete it without changing a lot of business code. For example, if we decide to switch from RabbitMQ to Kafka, we only need to adjust the implementation of the encapsulation layer without modifying any service code that uses the message queue.

[0077] Furthermore, the differences between different message queue products can be hidden by defining a set of high-level APIs. These APIs should cover basic message sending (publishing), receiving (subscribing), and related management operations (such as creating / deleting queues). For example, methods such as sendMessage and subscribeMessage can be defined so that developers only need to call these methods to complete message interactions without having to worry about the specific message queue implementation. In addition to the abstraction at the API level, configuration parameters also need to be abstracted. This means that developers can specify various settings for message queues through a unified configuration method (such as property files or environment variables) instead of directly dealing with configuration items specific to each message queue. The advantage of this is that it is easier to switch between different message queues by simply changing the configuration without having to modify the code.

[0078] Since different message queues may have different exception types, a unified exception handling mechanism should be provided in the encapsulation layer. This includes capturing exceptions thrown by the underlying message queue and converting them into a common exception type for easy processing by upper-layer applications. When publishing messages, you need to consider how to convert business data into a message format suitable for transmission. Typically, JSON or XML are common choices. The encapsulation layer should support flexible message formatting strategies, allowing developers to choose the appropriate serialization method as needed. To enhance flexibility, the encapsulation layer should support a message distribution mechanism based on topics or routing keys. This means that when a message is published, it can be determined which subscribers should receive the message based on its topic or routing key.

[0079] Subscribers should be able to process received messages asynchronously to avoid blocking the main thread. The wrapper layer needs to ensure this and preferably provide a callback mechanism so that developers can perform certain actions after the message processing is completed. Many message queues support message confirmation mechanisms, that is, a message will not be removed from the queue until the consumer successfully processes it. The wrapper layer should simplify this process and allow developers to easily enable or disable message confirmation. For messages that fail to be processed, the wrapper layer should provide a retry mechanism. This can include strategies such as a fixed number of retries and exponential backoff algorithms to ensure that messages are processed successfully as much as possible even in the face of temporary failures. Regardless of the type of message queue, the interface provided should be consistent. For example, all message sending operations follow the same pattern, and so do all message receiving operations. This helps reduce the learning cost and improves the portability of the code. The design of the wrapper layer should also take into account integration with other frameworks or libraries. For example, if the project uses the Spring framework, the wrapper layer should be as compatible with the Spring ecosystem as possible to facilitate the integration of features such as dependency injection.

[0080] S3. Define and generate a synchronous interface through the front-end interface, where the synchronous interface is used to receive request parameters and execute corresponding business logic.

[0081] Specifically, visual configuration: This step involves developing a user-friendly front-end interface that allows users to define interfaces through wizard-style configuration. This interface usually contains a series of forms, options, and input boxes, through which users can specify various attributes of the interface, such as name, path, request method (GET / POST, etc.), request parameter type, etc. Method selection and registration: Users can select existing methods or RPC services in the system on the interface and register them as an accessible interface. This step may include selecting a specific method name, specifying the class or module where the method is located, and determining the input and output parameter formats of the method. Request parameter processing: For the selected method or service, it is necessary to define how to handle request parameters from the client. This includes serialization (when the client sends a request) and deserialization (when the server receives the request) of parameters. For example, if the client sends data in JSON format, it is necessary to ensure that the data can be correctly parsed and mapped to the corresponding parameters of the method. Automatic code generation: Based on the user's configuration, the system automatically generates the corresponding interface code. This part of the work is usually completed by the backend, which generates one or more files based on the information provided by the frontend. These files implement the functions of the interface, including receiving request parameters, calling corresponding business logic methods, and returning results to the client. Interface deployment: The generated interface will be deployed to the application and become a service endpoint that can be called externally. This means that once the configuration is completed and deployed successfully, any HTTP request that meets the preset rules can trigger this interface and execute the business logic behind it. Synchronous execution: As mentioned in the description, "the synchronous interface is used to receive request parameters and execute the corresponding business logic", which means that when the client initiates a request, the interface will immediately start processing the request and will not respond to other requests until it is processed. Only when all business logic is executed will the result be returned to the client. This mechanism greatly simplifies the interface creation process, lowers the technical threshold, and enables non-professional programmers to participate in the design and implementation of the interface. At the same time, it also improves development efficiency and shortens the time cycle from requirement submission to function launch.

[0082] For example, suppose you are developing an e-commerce platform that needs to provide an interface for external systems to query product inventory information. In this example, we will show you how to define and generate such a synchronous interface through the front-end interface.

[0083] Select an existing method or service: In the e-commerce platform, there is already a method called getProductStock, which accepts a product ID as an input parameter and returns the stock quantity of the product. Now you need to register this method as an HTTP interface.

[0084] Configure interface properties:

[0085] Interface name: can be named / api / v1 / getProductStock

[0086] HTTP Method: Select GET method because this is a query operation.

[0087] Request parameter: Specify the product ID parameter (e.g., productId) that needs to be received from the client, and set its type to string. Response format: Determine the data format of the interface response, such as JSON format, including fields such as productId and stockQuantity.

[0088] Serialization and deserialization processing: Since JSON is selected as the data exchange format, you may also need to configure on the front-end interface how to convert the JSON object sent by the client into a Java object (for productId), and how to convert the Java object on the server back to JSON format and return it to the client.

[0089] Automatically generate code: Based on the configuration made on the front-end interface, the backend will automatically generate the corresponding controller code. This code will achieve the following functions:

[0090] Listen for GET requests from the / api / v1 / getProductStock path.

[0091] Extract the productId parameter from the request.

[0092] Call the getProductStock method and pass in the extracted productId.

[0093] The result of the getProductStock method is packaged into JSON format and returned to the client.

[0094] Example automatically generated pseudo code:

[0095]

[0096]

[0097] Front-end verification: After completing the configuration, you can directly call the newly created interface through the preview or test function provided by the front-end to check whether the expected results can be obtained correctly. For example, enter a known product ID to check whether the returned inventory quantity is accurate.

[0098] Integration testing: Ensure that the interface can work properly with other parts of the system, such as the part that interacts with the database, to ensure data consistency and accuracy.

[0099] Furthermore, an intuitive, guided user interface can be provided to allow users to easily complete the definition of the interface. This includes selecting the method or service to be exposed, specifying the interface path, HTTP method (GET, POST, etc.), request parameter format and type, etc. The necessary input items are automatically filled in based on the signature of the selected method, such as parameter name, type (string, integer, Boolean, etc.), and whether it is a required parameter. For parameters of complex object types, the definition of nested structures is supported.

[0100] Allow users to preview the expected response format, such as JSON structure, during the configuration process to help them better understand the behavior of the interface. Provide built-in support for converting request data sent by the client to the parameter type required by the server-side method, and vice versa. For example, convert JSON formatted data to Java objects, or convert Java objects back to JSON format and return them to the client. Allow users to set validation rules for each parameter, such as length limit, value range, regular expression matching, etc., to ensure that the incoming data meets the expected requirements.

[0101] Template-driven code generation: Based on the user's configuration, standardized controller code templates are automatically generated. These templates follow the RESTful principle and are easy to understand and maintain. A default error handling mechanism is provided for the generated interface, while allowing users to customize specific exception handling logic, such as returning custom error messages or status codes.

[0102] Provide a simple tool or environment that allows developers to quickly test newly created interfaces without leaving the current interface. This may include simulating different types of requests (successful cases, failed cases) and viewing detailed response information. The integrated logging function makes it easy for developers to track the history of interface calls, analyze performance bottlenecks or troubleshoot problems.

[0103] Supports interface version management. When an interface needs to be updated, a new version can be created without affecting existing applications that rely on the interface. API documentation is automatically generated based on the interface definition, including request examples, parameter descriptions, response details, etc., for other developers to consult.

[0104] S4. Register the synchronous interface as an asynchronous interface, and generate a corresponding publishing end and a subscription end of the message queue.

[0105] Specifically, select the synchronous interface: First, select the interface that needs to be converted to asynchronous processing from the existing synchronous interfaces. For example, in the example mentioned above, we have a synchronous interface / api / v1 / getProductStock for querying product inventory.

[0106] Configure asynchronous properties: On the front-end interface, add the relevant configuration of asynchronous processing for the selected synchronous interface. This may include but is not limited to specifying the type of message queue to be used (such as RabbitMQ, Kafka, etc.), setting the message body format, defining the callback mechanism, etc.

[0107] Create a publisher: When a synchronous interface is registered as an asynchronous interface, the system will automatically generate a message queue publisher associated with the interface. This publisher is responsible for receiving requests from clients and encapsulating request parameters into a message body and sending it to the message queue.

[0108] Message formatting: According to the configuration, perform appropriate serialization operations on the request parameters (such as converting them to JSON format) to ensure that the message can be correctly processed by the message queue.

[0109] Create a subscriber: At the same time, a message queue subscriber is also generated. The task of the subscriber is to listen to and obtain published messages from the message queue, then decode these messages and call the corresponding business logic method to perform actual processing.

[0110] Execute business logic: Once the subscriber receives the message and completes the deserialization process, it will call the actual business logic behind the original synchronous interface (for example, call the getProductStock method to query stock information). It should be noted here that due to asynchronous processing, the subscriber will not directly return the result to the client after processing the request, but may notify the client of the processing result through a preset callback interface.

[0111] Compensation or retry mechanism: To ensure the reliability of the service, if an error (such as network failure, data format mismatch, etc.) is encountered during the processing of the subscriber, a certain compensation or retry strategy can be set. For example, if the message processing times out or the interface returns an error code, the retry mechanism is triggered to retry processing the message.

[0112] Persistent storage: For critical business scenarios, you can also use the persistence feature of the message queue to ensure that unfinished messages are not lost even in the event of a system crash.

[0113] In this way, "registering the synchronous interface as an asynchronous interface and generating the corresponding message queue publisher and subscriber" not only realizes the transformation of the interface processing mode, but also enhances the concurrency and response speed of the system, which is particularly suitable for those time-consuming operations or application scenarios that require high availability. In addition, this design is also convenient for later maintenance and expansion, and the asynchronous processing process can be flexibly adjusted according to needs.

[0114] For example, select the previously defined synchronous interface / api / v1 / getProductStock in the front-end interface and configure it to become an asynchronous interface. This step may include:

[0115] Select a message queue product: Select a suitable message queue product (such as RabbitMQ, Kafka, etc.) from the options provided. In this example, we choose RabbitMQ as the message queue.

[0116] Set callback mechanism: Define how to notify the client when the asynchronous processing is completed. It can be an HTTP callback URL or another notification method.

[0117] Determine the message format: For example, decide to use JSON as the data format for messaging.

[0118] Once the synchronous interface is successfully registered as an asynchronous interface, the system will automatically generate a publisher to receive requests from clients and convert these requests into messages and send them to the message queue.

[0119] When the client initiates a GET request to the / api / v1 / getProductStock interface, instead of calling the business logic directly, the request parameters (such as productId) are encapsulated into the message body.

[0120] Use the RabbitMQ API or a corresponding framework (such as Spring AMQP) to send the message to the specified message queue. At this point, the client will immediately receive a response informing it that the request has been accepted (but not yet processed).

[0121] At the same time, the system will also generate a subscriber, which will continuously monitor the specified message queue and trigger the corresponding processing logic when a new message is detected.

[0122] The subscriber listens to a specific queue and waits for the message containing the product ID to arrive.

[0123] When the message arrives, the subscriber decodes the message body, extracts the product ID, and calls the original business logic method getProductStock(productId) to obtain the inventory information.

[0124] After the processing is completed, if a callback mechanism is configured, the client is notified of the processing result through a preset method (such as HTTP POST to the callback URL).

[0125] The following is an example to illustrate the above process:

[0126]

[0127]

[0128] Furthermore, through the wizard-style configuration tool provided by the front-end interface, users can specify which synchronous interfaces need to be converted to asynchronous interfaces. This includes but is not limited to the interface name, request method type (GET, POST, etc.), input parameter definition, and output result format. The system automatically adjusts the behavior mode of the interface based on the user's configuration, from direct processing and immediate response to immediately forwarding it to the message queue for processing after receiving the request, and immediately returning a confirmation response to the client.

[0129] On the publishing side, the request data from the client needs to be properly encapsulated. This means serializing the request parameters in a preset data format (such as JSON) to form the message body. At the same time, additional metadata may need to be added, such as timestamps or unique identifiers, for subsequent tracking and management. Determine how the message is sent to the message queue. Different switch types (direct, topic, headers, fanout) can be selected to accommodate different message routing requirements. In addition, the persistence properties of the message can be set to ensure that the message is not lost even if the server is restarted.

[0130] The subscriber is responsible for listening to messages in a specific queue. Once a new message arrives, the subscriber will take it out and deserialize it into the original request parameter format, and then call the corresponding business logic method to perform the actual operation. During the message processing, if an abnormal situation (such as network failure, database unreachable, etc.) is encountered, the subscriber should have a certain error handling capability. This usually involves implementing a retry strategy (such as an exponential backoff algorithm), recording logs for subsequent analysis, and even triggering compensating transactions in extreme cases to ensure data consistency.

[0131] Provides a unified management interface that allows administrators to view all registered asynchronous interfaces and their related configurations (such as the message queues used, message processing status, etc.). This helps simplify maintenance and improves the manageability of the system. Integrated monitoring functions track the status of message queues in real time (such as queue length, message processing speed, etc.) and issue alarms when abnormal situations occur (such as message backlog exceeds the threshold, processing failure rate is too high, etc.).

[0132] Among them, the calling process of the asynchronous interface includes: the client request triggers the publishing end of the message queue, the publishing end encapsulates the request parameters as a message body and sends it to the message queue, the subscriber listens to the message queue and obtains the message body, and calls the synchronous interface to execute business logic.

[0133] Specifically, the client initiates a request: When a client (for example, a mobile application or a web front end) needs to query some information or submit data, it sends an HTTP request to the server to a specific API endpoint (such as / api / v1 / getProductStock).

[0134] Triggering the publishing end: Unlike the traditional synchronous interface, the API endpoint here is configured in asynchronous mode. Therefore, when the server receives the client's request, it does not immediately start processing the business logic, but first encapsulates the request parameters into a message body and then sends it out through the publishing end of the message queue.

[0135] Encapsulate request parameters: At this stage, the system will serialize all necessary information (such as product ID, user ID, etc.) sent by the client, usually converted into JSON or other data formats that are easy to transmit. This information constitutes the main content of the message body.

[0136] Send message to queue: Next, the publisher uses the API provided by the message queue or related framework (such as SpringAMQP for RabbitMQ) to send the encapsulated message to the specified message queue. At this point, the client may immediately receive a confirmation response, indicating that the request has been received and is being processed, but the specific business logic has not yet been executed.

[0137] Subscriber continues to listen: At the same time, the pre-configured subscriber (consumer) will continue to listen to the specified message queue, waiting for the arrival of new messages. Once a new message is found in the queue, the subscriber will take it out.

[0138] Deserialize the message body: After retrieving the message, the subscriber will deserialize the message body and restore the original request parameters. This step ensures that the corresponding business logic method can be called correctly later.

[0139] Calling the synchronous interface: Based on the deserialized request parameters, the subscriber calls the business logic behind the originally defined synchronous interface (for example, calling getProductStock(productId) to query inventory information). This step is actually executed asynchronously in the background, and the interaction with the client has been completed.

[0140] Processing result: After the business logic processing is completed, if the callback mechanism is configured before, the client can be notified of the processing result through the preset method (such as HTTP POST to the callback URL provided by the client). If no callback is set, other methods (such as polling) may be relied on to let the client know the final result.

[0141] For example, suppose there is an e-commerce platform that provides an API / api / v1 / getProductStock to query product inventory information. Initially, this was a synchronous interface, but in high concurrency situations, directly processing each request may cause performance bottlenecks. Therefore, it was decided to convert it to an asynchronous interface based on RabbitMQ.

[0142] Client initiates request: The user sends an HTTP GET request to the server through the mobile application or web front-end to / api / v1 / getProductStock?productId=12345 to query the inventory of the product with product ID 12345.

[0143] Triggering the publisher: After receiving the request, the system does not process the business logic immediately, but encapsulates the request parameters (here productId = 12345) into a message body through the configured publisher and sends it to the RabbitMQ message queue. The client will immediately receive a response informing it that the request has been accepted and is being processed.

[0144] Encapsulate request parameters: On the publishing end, the system converts productId=12345 into a message body in JSON format, for example, {"productId":"12345"}.

[0145] Send the message to the queue: Then use the API provided by RabbitMQ or the Spring AMQP framework to send this message to the specified message queue, such as the queue named productStockQueue.

[0146] {

[0147] "productId":"12345"

[0148] }

[0149] Subscriber continues to listen: The pre-configured subscriber (consumer) will continuously listen to the productStockQueue queue. Once a new message arrives, it will take the message out of the queue.

[0150] Deserialize the message body: After retrieving the message, the subscriber will deserialize the message body and restore the original request parameter productId = 12345.

[0151] Calling the synchronous interface: Based on the deserialized request parameters, the subscriber calls the business logic method getProductStock(productId) behind the originally defined synchronous interface to query the inventory information. This step is executed asynchronously in the background, and the interaction with the client has been completed.

[0152] Processing result: Assume that the query result shows that the current inventory of the product is 30 pieces. If the callback mechanism is configured before, the client can be notified of the final processing result through a preset method (such as HTTP POST to the callback URL provided by the client).

[0153] {

[0154] "productId":"12345",

[0155] "stockQuantity":30

[0156] }

[0157] If no callback mechanism is set, the client may need to obtain the final processing result through polling or other methods.

[0158] Furthermore, when the client initiates a request (for example, via HTTP GET or POST), the server first receives the request. At this point, the system recognizes that this is a request that needs to be processed asynchronously. The system extracts necessary parameters (such as product ID, user information, etc.) from the request. These parameters are the basis for subsequent business logic processing. After receiving the request, the server immediately returns a confirmation response to the client, informing it that the request has been accepted and is being processed. This instant feedback improves the user experience and avoids long waits.

[0159] According to the configuration, the request parameters are converted into a suitable message format (usually JSON). This step may involve serialization operations to ensure that data can be efficiently transmitted between different components. In addition to the request parameters, additional information such as timestamp, message ID, priority, etc. can be added to the message for subsequent tracking and management. Choose an appropriate message sending strategy (direct, topic, fan-out, etc.) to adapt to different routing requirements. In addition, the persistence settings of the message must also be considered to ensure that important information is not lost even if the system fails.

[0160] The subscriber (consumer) continuously monitors the specified message queue, waiting for the arrival of new messages. This monitoring mechanism is usually event-driven and can respond to new tasks in real time. Once a new message arrives, the subscriber will take it out and deserialize it to restore the original request parameters. This step is a prerequisite for the accurate execution of business logic. If problems are encountered during the acquisition or deserialization process (such as incorrect message format), the subscriber should have basic error handling capabilities, record logs or take appropriate remedial measures to prevent system crashes.

[0161] Use the restored request parameters to call the business logic method behind the original synchronous interface. This step is actually executed asynchronously in the background, independent of the client's interaction process. After the business logic is executed, the processing results can be further operated according to the preset rules. For example, if it is a query operation, the result can be stored directly or notified to the client through callback; if it is an update operation, the consistency and integrity of the data must be ensured. Considering the complexity of the business logic, it may involve multiple steps or interactions between services, so an effective transaction management mechanism is needed to ensure the atomicity, consistency, isolation and persistence (ACID characteristics) of the entire process.

[0162] In some embodiments of the present application, the message queue product is selected from at least one of the following: RabbitMQ, Kafka, RocketMQ, ActiveMQ, or a message queue implemented based on Redis.

[0163] Specifically, RabbitMQ

[0164] Background: Written in Erlang language, it supports multiple protocols (AMQP, MQTT, etc.) and is a widely used open source message broker software.

[0165] Advantages: High concurrency: Due to the use of Erlang's concurrency model, it can efficiently handle a large number of concurrent connections. Easy to deploy and manage: Provides a rich plug-in system and a user-friendly management interface. Flexibility: Supports multiple message routing mechanisms (such as direct, topic, fan-out, etc.). Applicable scenarios: Suitable for application scenarios that require flexible message routing.

[0166] Kafka

[0167] Background: Originally developed by LinkedIn, it is now an open source stream processing platform under the Apache project.

[0168] Advantages: High throughput: Especially suitable for processing large-scale data streams, such as log aggregation, real-time analysis, etc. Persistence and reliability: The reliability and persistent storage of messages are guaranteed by means of distributed submission logs. Strong scalability: Supports horizontal expansion, which is very suitable for big data environments. Applicable scenarios: Most suitable for scenarios that need to process massive data streams, such as real-time data analysis, monitoring systems, etc.

[0169] RocketMQ

[0170] Background: Developed by Alibaba and contributed to the Apache Foundation, it is a low-latency, high-reliability distributed messaging middleware.

[0171] Advantages: High throughput: The design is optimized for financial transaction systems and supports high-concurrency message processing. Strong scalability: Good horizontal scalability to facilitate business growth. Transaction support: Provides complete distributed transaction support to ensure message consistency and integrity. Applicable scenarios: Suitable for application scenarios with extremely high performance requirements and strong consistency, such as e-commerce transaction systems.

[0172] ActiveMQ

[0173] Background: A long-established message middleware maintained by the Apache Foundation, supporting multiple message protocols.

[0174] Advantages: Mature and stable: It has a long development history, complete documentation, and an active community. Multi-protocol support: In addition to standard JMS, it also supports multiple protocols such as STOMP and AMQP. Easy to integrate: It can be easily integrated with frameworks such as Spring. Applicable scenarios: It is suitable for traditional enterprise-level applications that need to be compatible with multiple protocols.

[0175] Message queue based on Redis

[0176] Background: Although Redis is mainly used as an in-memory database, it also provides simple message queue functions (such as publish / subscribe mode).

[0177] Advantages: High performance: As an in-memory database, it has extremely high read and write speeds. Easy to use: Very convenient for small applications that do not require complex message routing logic. Lightweight: No need to install a dedicated message queue service. Applicable scenarios: Suitable for scenarios that do not require high messaging requirements and pursue fast deployment and simple use.

[0178] In some embodiments of the present application, in step S2, the function encapsulation is implemented using the JMS specification or the Spring AMQP framework.

[0179] Specifically, Java Message Service (JMS) is a standard API that provides message services for Java applications. It defines a set of common messaging interfaces that allow applications to communicate without relying on specific message queue implementations. Event publishing: Through the JMS API, developers can easily send business data as messages to a specified topic or queue. For example, TopicPublisher or QueueSender can be used to publish messages. Event subscription: Similarly, TopicSubscriber or QueueReceiver is used to subscribe and receive messages. JMS supports both point-to-point (Queue) and publish / subscribe (Topic) modes. Transaction management: JMS provides support for messaging transactions, allowing developers to send or receive multiple messages in a transaction context to ensure message consistency and reliability. Standardization: Since JMS is a standard, different message queue products (such as ActiveMQ, RabbitMQ, etc.) can be seamlessly switched without modifying business code as long as they implement the JMS API. Mature and stable: JMS has been around for many years and has mature community support and rich documentation resources.

[0180] Spring AMQP is a part of the Spring project, a high-level abstract framework designed specifically for the AMQP protocol (Advanced Message Queuing Protocol). It simplifies the use of message queues based on the AMQP protocol (such as RabbitMQ).

[0181] AmqpTemplate: This is one of the core classes provided by Spring AMQP, which is used to simplify the sending and receiving of messages. Developers can send messages through the convertAndSend() method of AmqpTemplate and receive messages using the receiveAndConvert() method.

[0182] Message listening container: Spring AMQP provides MessageListenerContainer, which can automatically listen to messages in the specified queue and call the corresponding processor (MessageListener) to process the message when the message arrives.

[0183] Integration with Spring Ecosystem: Spring AMQP is deeply integrated with the Spring framework and can work well with other Spring components (such as Spring Boot, Spring Data, etc.) to provide more powerful functions and services. Ease of use: Spring AMQP greatly simplifies the operation of the AMQP protocol and reduces the workload of developers to directly operate low-level APIs. Flexibility: Supports a variety of configuration options, and can adjust the behavior of messaging according to actual needs, such as message confirmation mechanism, retry strategy, etc. Powerful ecosystem: Thanks to Spring's powerful ecosystem, Spring AMQP can be easily integrated with other Spring technology stacks to build complex distributed applications.

[0184] Whether you choose the JMS specification or the Spring AMQP framework, the purpose is to provide a unified interface layer to hide the specific implementation details of the underlying message queue. The benefits of doing so include but are not limited to: Reduced coupling: Business logic no longer directly depends on a specific message queue product, which improves the portability and maintainability of the system. Improved development efficiency: Developers only need to focus on how to use high-level APIs to send and receive messages, without having to deeply understand the unique characteristics of each message queue. Enhanced system stability: Through reasonable exception handling and retry mechanisms, the robustness and fault tolerance of the system can be effectively improved.

[0185] In some embodiments of the present application, in step S3, the front-end interface configuration includes:

[0186] Register the existing method or RPC service in the system as a synchronous interface, and serialize or deserialize the request parameters of the interface.

[0187] Specifically, visual configuration: provides a user-friendly front-end interface that allows developers or system administrators to define and register new interfaces through a graphical wizard process. This interface usually contains components such as input boxes and drop-down menus to specify the basic properties of the interface (such as name, path, HTTP method type, etc.). Select existing methods or RPC services: users can select services or methods that need to be exposed as interfaces from the list of existing methods in the system. These methods may be existing business logic functions or remote procedure call (RPC) services. Define interface properties: In addition to selecting specific methods, you also need to define some basic properties of the interface, such as:

[0188] API path: for example, / api / v1 / getProductStock.

[0189] HTTP method: GET, POST, etc.

[0190] Request parameters: Define which parameters are required, what their data types are (string, integer, boolean, etc.), and whether nested object type parameters are supported.

[0191] Serialize or deserialize the request parameters of the interface

[0192] When the client initiates a request, the data format it sends may not be directly suitable for the method call on the server. Therefore, the client's data (usually in JSON or XML format) needs to be converted into a format suitable for the server-side method (such as a Java object). This step is called serialization. Deserialization: Conversely, after the operation is performed on the server, the result returned to the client also needs to be converted from the server-side data structure (such as a Java object) back to a format that the client can understand (such as JSON). This step is called deserialization. Automated tool support: Modern frameworks and libraries usually provide automated serialization / deserialization tools. For example, the Jackson library in Spring Boot can automatically handle the conversion from JSON to Java objects. Custom serializers and deserializers: For some special cases, you may need to write custom serializers and deserializers to meet specific needs. For example, if there is a complex nested object structure, or some fields require special encoding methods, you can customize the conversion logic by implementing the corresponding interface. Error handling: Various problems may be encountered during serialization and deserialization, such as data format mismatch, missing required fields, etc. Good design should include appropriate error handling mechanisms to ensure that these problems are caught promptly and notified to the user or system administrator in a friendly manner.

[0193] In some embodiments of the present application, in step S4, when registering the asynchronous interface, the publishing end and the subscribing end of the message queue are automatically generated, and the publishing end and the subscribing end are deployed in the same application instance.

[0194] Specifically, automatically generate the publisher and subscriber

[0195] The publisher is responsible for receiving requests from clients and encapsulating these requests into messages and sending them to the message queue. When a synchronous interface is registered as an asynchronous interface, the system will automatically generate the publisher logic based on the configuration information (such as the selected message queue product, request parameter format, etc.). The tasks that the publisher needs to handle include but are not limited to: serializing request parameters (for example, converting Java objects to JSON or XML format), constructing the message body, selecting the appropriate message queue switch type, and finally sending the message to the specified message queue.

[0196] The subscriber is responsible for listening to a specific message queue. Once a new message arrives, it will take the message out of the queue and process it. Similarly, the subscriber is automatically generated based on pre-set rules. Its main responsibility is to deserialize the received message (that is, convert the message body back to the original request parameter format), and then call the corresponding business logic method to perform the actual operation. In addition, the subscriber also needs to manage the retry mechanism, logging and other functions in abnormal situations to ensure that the message can be processed reliably.

[0197] High integration: By deploying the publisher and subscriber in the same application instance, the complexity and potential delays caused by cross-service calls can be reduced. This approach is particularly suitable for application scenarios that want to maintain a high degree of internal integration. Simplified management and maintenance: Since the publisher and subscriber are in the same application instance, it makes it easier for them to share resources (such as database connection pools, caches, etc.), and also simplifies monitoring and troubleshooting. Developers only need to focus on the status of a single application. Easy to expand: Although both the publisher and subscriber run in the same application instance, the design should consider supporting horizontal expansion. This means that if the subsequent traffic increases, the load can be dispersed by adding more identical application instances without making major changes to the existing architecture.

[0198] Suppose there is a product inventory query interface / api / v1 / getProductStock in an e-commerce platform. Now we want to convert it into an asynchronous interface:

[0199] Register an asynchronous interface: Select the interface through the front-end interface tool, set it to asynchronous mode, and select RabbitMQ as the message queue product.

[0200] Generate the publisher: The system automatically generates the publisher logic, which is responsible for receiving client requests and encapsulating parameters such as productId into JSON format messages and sending them to a queue named productStockQueue. Generate the subscriber: Generate the subscriber logic at the same time and continuously monitor the productStockQueue. Whenever a new stock query request arrives, the subscriber will read the message content, deserialize it to obtain the productId, and then call the original business logic method to query the inventory information. Deploy in the same instance: Both the publisher and the subscriber are deployed in the same application instance, which makes it easy to share configurations, dependent libraries and other resources, and also facilitates unified management and performance optimization.

[0201] In some embodiments of the present application, after the asynchronous interface call is completed, the execution result is returned to the client through a preset callback interface.

[0202] Specifically, the callback mechanism after the asynchronous interface call is completed

[0203] First, let's review the basic workflow of the asynchronous interface:

[0204] The client initiates a request: The client sends a request to the server, which is converted into a message and sent to the message queue. The publisher processes: The publisher of the server encapsulates the request parameters into a message body and sends it to the specified message queue. The subscriber processes: The subscriber listens to the message queue, deserializes the message after receiving it, and calls the corresponding business logic method to perform the actual operation. In this process, the client will not get the processing result immediately, but will receive a confirmation message indicating that the request has been accepted and is being processed.

[0205] Because it is an asynchronous process, the client cannot directly obtain the response result like the synchronous interface. In order to enable the client to know the final result, a callback mechanism is usually used. The "preset callback interface" mentioned here refers to a URL or other form of notification method provided by the client to the server during the initial request. When the asynchronous process is completed, the server will use this callback interface to notify the client of the processing result.

[0206] Specific implementation of the callback interface

[0207] The client provides a callback address: When initiating an asynchronous request, in addition to passing the necessary business parameters, the client also needs to provide a callback address (such as an HTTP URL) for receiving the processing results.

[0208] Execution result preparation: Once the subscriber completes the business logic processing and obtains the results (such as the inventory of the queried product), these results need to be organized into an appropriate data format (usually JSON or XML). Call the callback interface: Next, the server will use the callback address provided previously to send the processing results back to the client through methods such as HTTP POST. This step may involve serialization of the result data.

[0209]

[0210]

[0211] Error handling: If you encounter problems when calling the callback interface (such as network failure, unreachable target, etc.), you can set a certain retry strategy. For example, use an exponential backoff algorithm to try to resend the result until it succeeds or reaches the maximum number of retries. Logging: For each callback attempt and its result (success or failure), detailed logging should be done to facilitate subsequent analysis and troubleshooting.

[0212] Receiving results: The client needs a service to listen to the callback request from the server and parse and process the received data. Updating the UI or triggering subsequent operations: Based on the callback result, the client can update the user interface to display the latest information or trigger other related business logic operations.

[0213] In some embodiments of the present application, the subscriber of the message queue supports compensation or retry operations for requests with execution exceptions when calling a synchronous interface.

[0214] Specifically, in a distributed system, some requests may not be completed normally due to network fluctuations, temporary unavailability of services, and other reasons. Through compensation or retry mechanisms, the reliability and robustness of the system can be significantly improved, ensuring that important business data will not be lost even if temporary problems occur. For some application scenarios that require strong consistency (such as financial transactions, order processing, etc.), it is crucial to ensure that all requests are processed correctly. Compensation and retry mechanisms help maintain data consistency and prevent data inconsistency problems caused by partial failures. Error capture: When calling the synchronous interface, the subscriber should have a complete exception capture mechanism that can identify various types of exceptions. This includes but is not limited to network timeouts, HTTP error codes (such as 500 internal server error), database connection failures, etc. Logging: For each failed attempt, detailed error information should be recorded, including timestamps, request IDs, specific error descriptions, etc. These log information is very useful for subsequent troubleshooting and analysis.

[0215] Compensation transaction: In some cases, a simple retry may not be enough to solve the problem, especially when it involves multiple steps (such as a transfer operation involving two steps, deduction and crediting). In this case, a compensation transaction can be designed to undo some of the previous operations, and then decide whether to retry the entire process based on the specific situation. Manual intervention: For some complex abnormal situations, manual intervention may be required for compensation. For example, after checking the system status and fixing potential problems, manually trigger a retry or manually correct the data. Fixed number of retries: Set a fixed number of retries, such as a maximum of 3 retries. If it still fails after exceeding this number, it is considered that the request cannot be processed further, and it is usually marked as failed, and the relevant personnel are notified for further processing. Exponential backoff algorithm: In order to avoid frequently sending requests to an already overloaded service, an exponential backoff algorithm can be used to control the retry interval. For example, the first retry interval is 1 second, the second retry interval is 2 seconds, the third retry interval is 4 seconds, and so on. Condition-based retry: Different retry strategies can be selected according to different error types. For example, for errors such as network timeouts, you can set a shorter retry interval; for errors such as service unavailability, you can wait longer before retrying. Persistence of unfinished tasks: In order to prevent the loss of ongoing retry tasks due to system crashes, unfinished tasks can be persisted in a database or other persistent storage medium. This way, even after the system restarts, processing can be continued from the interruption point. Idempotent design: Considering that the same request may be retried multiple times, it is necessary to ensure that the business logic is idempotent, that is, no matter how many times it is repeated, the result is the same. This is very important to avoid data inconsistency caused by repeated processing of the same request.

[0216] In some embodiments of the present application, the calling mode of the switching interface is also configured through the interface to achieve dynamic switching between asynchronous calling and synchronous calling.

[0217] Specifically, graphical interface: By providing an intuitive, graphical interface, users can easily view the call mode (synchronous or asynchronous) of all interfaces in the current system and can modify it directly on this interface. Simplified operation process: The interface call mode can be switched without going deep into the code level, which reduces the difficulty of operation and technical threshold.

[0218] Immediate effect: Ideally, this switch takes effect in real time, that is, once the calling mode of an interface is changed on the interface, the change will immediately affect all subsequent requests to the interface. No need to restart the service: Most modern frameworks and platforms support hot loading or hot update mechanisms, which means that the calling mode of the interface can be changed dynamically without restarting the entire application.

[0219] Implement switching between asynchronous and synchronous calls

[0220] Direct processing logic: When the interface is set to synchronous call, the server will immediately execute the corresponding business logic after receiving the request and return the result directly to the client. The whole process is blocking until the processing is completed or an error occurs.

[0221] Applicable scenarios: Suitable for operations with high response time requirements and short processing time, such as simple data query and status check.

[0222] Message queue intervention: When the interface is configured for asynchronous call, the server no longer processes the request directly, but encapsulates the request parameters into a message and sends it to the message queue. Then, the client will immediately receive a confirmation response, indicating that the request has been accepted and is being processed. Background processing: The subscriber takes the message from the message queue, deserializes it, and calls the corresponding business logic method to perform the actual operation. After the processing is completed, if the callback mechanism is configured, the client can be notified of the processing result in a preset way.

[0223] Configuration options: Provide a switch or drop-down menu for each interface on the front-end interface to select the call mode (synchronous / asynchronous) of the interface. In addition, some additional configuration items can be included, such as: Message queue selection: If the asynchronous call mode is selected, you may also need to specify which message queue product to use (such as RabbitMQ, Kafka, etc.). Callback address: For the asynchronous call mode, you need to provide a callback URL to receive the processing results. Persistent storage: In order to ensure that the configuration information is not lost due to system restart, these configurations should be stored persistently (for example, saved to a database). In this way, even if the application is restarted, the previously set call mode will still be valid.

[0224] In some embodiments of the present application, when sending a message body, the publisher of the message queue converts the format of the request parameters to adapt them to the synchronous interface parameter requirements of the subscriber.

[0225] Specifically, the functions and roles of the publishing end

[0226] Receiving the original request: First, the publisher receives the original HTTP request from the client, which contains all necessary business parameters (such as product ID, user information, etc.).

[0227] Serialization: In order to efficiently transmit data between different components, the publisher needs to convert these request parameters into a format suitable for transmission, usually JSON or XML. This process is called serialization. For example, if the original request parameter is a Java object, it will be converted into a JSON string.

[0228] {

[0229] "productId":"12345",

[0230] "userId":"user123"

[0231] }

[0232] Format adjustment: In addition to simple serialization operations, sometimes the data format needs to be further adjusted according to the specific needs of the subscriber. For example, if the subscriber expects data with a specific structure (such as containing additional metadata), the publisher needs to reorganize the data according to this structure before sending.

[0233] Send a message to a message queue

[0234] Choose the appropriate message format: Based on the requirements of the subscriber, the publisher will select the appropriate fields and data types to construct the message body. This may involve adding some additional information (such as timestamps, message IDs, etc.) for subsequent tracking and management.

[0235] Send to the message queue: Finally, the publisher uses the API or framework (such as Spring AMQP) provided by the selected message queue product (such as RabbitMQ, Kafka, etc.) to send the formatted message body to the specified message queue.

[0236] Ensure that the synchronization interface parameter requirements of the subscriber are met

[0237] Keep data consistent: During the conversion process, it is necessary to ensure that all necessary information is accurately passed to the subscriber. This means not only serializing the data correctly, but also ensuring the integrity and accuracy of the data. For example, if the subscriber relies on certain specific field names or data types, the publisher needs to strictly follow these requirements for conversion.

[0238] Input validation: Before converting request parameters into message bodies, you can add input validation steps to ensure that all inputs are valid and conform to the expected format. This can prevent subscriber processing failures due to invalid input. Exception handling: For any errors that may occur (such as serialization failure, field missing, etc.), the publisher should have an appropriate exception handling mechanism, record detailed error logs, and give friendly error prompts as much as possible.

[0239] In some embodiments of the present application, the triggering conditions of the compensation or retry operation include: message processing timeout, interface return error code or the persistence mechanism of the message queue detects an unfinished message.

[0240] Specifically, the triggering conditions for compensation or retry operations

[0241] Message processing timeout

[0242] Definition: When the subscriber takes a message from the message queue and tries to call the corresponding synchronous interface to execute the business logic, if the preset time limit (i.e. timeout) is exceeded, the processing is considered to have failed. Implementation details: Time monitoring: Set a timer when starting the processing task. Once the set time threshold (such as 5 seconds, 30 seconds, etc.) is exceeded, it is marked as timeout. Automatic retry: The system can be configured to automatically retry processing the message when a timeout is detected. The retry strategy can be customized according to the actual situation, such as a fixed number of retries, exponential backoff algorithm, etc.

[0243] The interface returns an error code

[0244] Definition: After the subscriber calls the synchronous interface to execute business logic, if the interface returns an error code indicating failure (such as HTTP status code 4xx or 5xx), compensation or retry is required. Implementation details: Error code identification: The subscriber needs to have the ability to identify specific error codes and take appropriate measures based on different error types. For example, for temporary errors (such as connection failures caused by network fluctuations), you can choose to retry; for permanent errors (such as invalid request parameters), you may need to log and notify the administrator. Error handling strategy: Different handling strategies can be defined for different types of error codes. For example, some error codes may indicate that a retry is required immediately, while other error codes suggest trying again later or giving up directly.

[0245] The message queue persistence mechanism detects an unfinished message

[0246] Definition: Many message queue products support persistent storage, which means that even if the server restarts, unfinished messages will not be lost. When the system restarts, the message queue will check whether there are messages that have not been processed and trigger corresponding compensation or retry operations. Implementation details: Persistent storage: The message queue saves all unconfirmed received messages to disk or other persistent storage media to ensure that these messages can be recovered even if a failure occurs. Recovery mechanism: When the system resumes normal operation, the message queue will automatically redistribute previously unfinished messages to subscribers for processing. This usually involves cooperation with the subscriber to ensure that each message is processed appropriately. Idempotent design: In order to avoid data inconsistency caused by repeatedly processing the same message, the subscriber should be designed to be idempotent, that is, no matter how many times it is repeated, the result is the same.

[0247] Anything not described in this application can be achieved by adopting or drawing on existing technologies.

[0248] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from other embodiments.

[0249] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for implementing asynchronous interface calls based on a message queue, characterized in that: The following steps are involved: S1. Select a message queue product and install and configure it. S2. Encapsulate the functions of the message queue and provide a unified event publishing and subscription mechanism; S3. Define and generate a synchronous interface through the front-end interface, where the synchronous interface is used to receive request parameters and execute corresponding business logic; S4, registering the synchronous interface as an asynchronous interface, and generating a corresponding publisher and subscriber of the message queue; Among them, the calling process of the asynchronous interface includes: the client request triggers the publishing end of the message queue, the publishing end encapsulates the request parameters as a message body and sends it to the message queue, the subscriber listens to the message queue and obtains the message body, and calls the synchronous interface to execute business logic.

2. The method according to claim 1, characterized in that The message queue product is selected from at least one of the following: RabbitMQ, Kafka, RocketMQ, ActiveMQ or a message queue based on Redis.

3. The method according to claim 1, characterized in that: In step S2, the function encapsulation is implemented using the JMS specification or the Spring AMQP framework.

4. The method according to claim 1, characterized in that In step S3, the front-end interface configuration includes: Register the existing method or RPC service in the system as a synchronous interface, and serialize or deserialize the request parameters of the interface.

5. The method according to claim 1, characterized in that In the step S4, when registering the asynchronous interface, the publishing end and the subscribing end of the message queue are automatically generated, and the publishing end and the subscribing end are deployed in the same application instance.

6. The method according to claim 1, characterized in that After the asynchronous interface call is completed, the execution result is returned to the client through the preset callback interface.

7. The method according to claim 1, characterized in that The subscriber of the message queue supports compensation or retry operations for requests with abnormal execution when calling the synchronous interface.

8. The method according to claim 1, characterized in that: It also includes switching the calling mode of the interface through interface configuration to achieve dynamic switching between asynchronous calling and synchronous calling.

9. The method according to claim 1, characterized in that: When sending the message body, the publisher of the message queue converts the format of the request parameters to adapt them to the synchronous interface parameter requirements of the subscriber.

10. The method according to claim 7, characterized in that The triggering conditions of the compensation or retry operation include: message processing timeout, interface return error code or the persistence mechanism of the message queue detects an unfinished message.

Images