Request processing method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a request processing method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of software architecture under Java ecology, and the method comprises the following steps: receiving a request, packaging the request into a Fiber task, and carrying out asynchronous processing; in the Fiber task asynchronous processing process, the dependency service is accessed in an asynchronous non-blocking mode, and a user response is formed according to dependency data and task logic; and writing back the user response to the user side in an asynchronous non-blocking mode. Through the technical scheme in the embodiment of the invention, the system resource utilization rate and the disaster recovery capability in a high-concurrency scene can be improved, and the service deployment cost is reduced.

Description

Technical Field

[0001] This application relates to the field of software architecture technology in the Java ecosystem, and in particular to a request processing method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] Among related technologies, backend online software application services implemented based on the Java ecosystem currently occupy a large application scenario. However, these backend online application architectures mainly use traditional threads as units for blocking data computation and storage. However, while ensuring resource utilization efficiency, a single process has a very low upper limit on the number of threads it can support, resulting in high resource coupling and low efficiency, which is not conducive to building high-concurrency systems. Although lightweight thread Fiber components or reactive programming based on Spring WebFlux are provided as solutions to address the problems of low thread capacity and severe resource coupling in a single process, however:

[0003] 1. Using traditional IO components directly within Fiber will degenerate into blocking mode; accessing IO within Fiber will consume a large amount of memory; custom thread pools cannot inherit the context of Fiber; and the ecosystem of Fiber components is incomplete and cannot be implemented independently.

[0004] 2. The learning and adaptation costs for Spring WebFlux streaming programming are too high.

[0005] 3. The virtual threads in Java's software development kit (JDK) 21 and later are still under experimental development. It will take a very long time to truly form a complete and reliable ecosystem and be implemented at the enterprise level.

[0006] Due to the factors mentioned above, the Java ecosystem currently lacks a low-cost, readily deployable, lightweight thread-based architecture that offers greater flexibility. When facing high concurrency requests, using threads for blocking processing leads to issues such as low system resource utilization, poor fault tolerance, and high service deployment costs. Summary of the Invention

[0007] The present application provides a request processing method, apparatus, electronic device, storage medium, and program product that can improve system resource utilization and disaster recovery capabilities in high-concurrency scenarios, and reduce service deployment costs.

[0008] The technical solution of this application is implemented as follows:

[0009] This application provides a request processing method, including:

[0010] Receive the request, encapsulate the request into a Fiber task, and process it asynchronously;

[0011] During the asynchronous processing of the Fiber task, dependent services are accessed in an asynchronous, non-blocking manner, and user responses are generated based on the dependent data and task logic.

[0012] The user response is written back to the user terminal in an asynchronous, non-blocking manner.

[0013] In the above scheme, receiving the request and encapsulating the request into a Fiber task includes:

[0014] Based on the asynchronous non-blocking service provider, the request is encapsulated into the Fiber task in the request receiving thread pool and handed over to the Fiber pool for asynchronous processing.

[0015] In the above scheme, the step of accessing dependent services in an asynchronous, non-blocking manner during the asynchronous processing of the Fiber task, and forming a user response based on the dependent data and task logic, includes:

[0016] Based on asynchronous non-blocking I / O components and an asynchronous subscription thread pool, the dependent services are accessed, and the Fiber task is suspended.

[0017] Based on the subscription callback thread pool, the dependency data returned by the dependent service is set, and the suspended Fiber task is resumed; wherein, the asynchronous subscription thread pool and the subscription callback thread pool are used to isolate network I / O request operations during the processing of the Fiber task;

[0018] The user response is obtained based on the Fiber task logic and the dependency data.

[0019] In the above scheme, writing the user response back to the user terminal in an asynchronous, non-blocking manner includes:

[0020] The user response is encapsulated into a user response task and handed over to the response write-back thread pool to write the response back to the user client; wherein, the response write-back thread pool is used to isolate network I / O request operations during the processing of the Fiber task.

[0021] In the above scheme, the asynchronous non-blocking service provider includes: an Rpc asynchronous callback service provider and a SpringWebFlux HTTP service provider;

[0022] The Fiber task includes: the request input parameters of the request, a callback object that is an asynchronous context of a publisher or RPC in the WebFlux ecosystem, a business logic processing object, and request receiving thread context information.

[0023] The method in the above scheme further includes:

[0024] Obtain and clone the Java thread context mapping table of the thread in the request receiving thread pool that processes the request;

[0025] Extract the request receiving thread context information from the Java thread context mapping table and copy it to the Fiber fiber in the Fiber pool that processes the Fiber task.

[0026] In the above scheme, the asynchronous non-blocking IO components include: an Rpc asynchronous callback service consumer component, a reactive component of SpringWebFlux dependent downstream services, and a database / caching / MQ reactive or asynchronous non-blocking access component.

[0027] In the above scheme, accessing the dependent service and suspending the Fiber task based on asynchronous non-blocking I / O components and an asynchronous subscription thread pool includes:

[0028] Get and clone the Java thread context mapping table in the Fiber;

[0029] An asynchronous subscription task is constructed based on the context information in the Java thread context mapping table in the Fiber and the asynchronous non-blocking I / O component; wherein, the asynchronous subscription task includes: the context information, the asynchronous non-blocking I / O component, the request input parameters of the request, and a listener object, wherein the listener object contains a completionStage object that can be completed and the context information.

[0030] The asynchronous subscription task is handed over to the asynchronous subscription thread pool, and the context information corresponding to the Java thread context mapping table of the Fiber is copied into the asynchronous subscription thread in the asynchronous subscription thread pool that processes the asynchronous subscription task.

[0031] Access to the dependent service is based on the asynchronous subscription thread;

[0032] Remove context information from the subscription thread, except for Netty's underlying memory allocation cache;

[0033] Use the Fiber framework to suspend the Fiber task.

[0034] In the above scheme, resuming the suspended Fiber task includes:

[0035] After the dependency service returns the dependency data, the completion method of the completeable CompletionStage object is called to resume the suspended Fiber task.

[0036] The method in the above scheme further includes:

[0037] During the asynchronous processing of the Fiber task, the dependent data is obtained by extracting and copying based on the Spring transaction context or by using the same reactive database connection object to access the database, thereby achieving transactional access to the database.

[0038] In the above scheme, the step of extracting and copying data based on the Spring transaction context or using the same reactive database connection object to access the database during the asynchronous processing of the Fiber task, thereby achieving transactional database access to obtain the dependent data, includes:

[0039] During the asynchronous processing of the Fiber task, a small number of threads are used in a thread pool for isolation, and the database transaction context object in Spring is used for context passing and cleanup to achieve database transactional access to obtain the dependent data.

[0040] In the above scheme, the step of extracting and copying data based on the Spring transaction context or using the same reactive database connection object to access the database during the asynchronous processing of the Fiber task, thereby achieving transactional database access to obtain the dependent data, includes:

[0041] During the asynchronous processing of the Fiber task, an asynchronous subscription thread pool is used for isolation, and the same reactive database connection object is used for database access operations to achieve transactional database access and obtain the dependent data.

[0042] In the above scheme, the user response task includes: the request input parameters, response object, callback object, and context information of the request; wherein, the context information is copied in the Java thread context mapping table corresponding to the Fiber.

[0043] In the above scheme, the step of encapsulating the user response into a user response task and handing it over to the response write-back thread pool to write back the response to the user client includes:

[0044] The user response is encapsulated into a user response task and handed over to the response write-back thread in the response write-back thread pool.

[0045] Get and clone the Java thread context mapping table in the Fiber;

[0046] The context information corresponding to the Java thread context mapping table of the Fiber is copied to the response write-back thread in the response write-back thread pool that processes the user response task;

[0047] Remove the Java thread context from the Fiber.

[0048] Based on the response write-back thread, an asynchronous non-blocking write-back is performed to the user terminal;

[0049] Remove context information from the response write-back thread, excluding Netty's underlying memory allocation cache.

[0050] This application also provides a reactive software architecture based on blocking programming, which encapsulates the above-mentioned request processing methods into a basic framework.

[0051] This application embodiment also provides a request processing apparatus, including:

[0052] A request receiving unit is used to receive requests, encapsulate the requests into Fiber tasks, and process them asynchronously.

[0053] The processing unit is used to access dependent services in an asynchronous non-blocking manner during the asynchronous processing of the Fiber task, and to generate a user response based on the dependent data and task logic.

[0054] The write-back unit is used to write back the user response to the user terminal in an asynchronous, non-blocking manner.

[0055] This application also provides an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the steps in the above-described method.

[0056] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps in the above-described method.

[0057] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps in the above-described method.

[0058] In this embodiment, a request is received, encapsulated into a Fiber task, and processed asynchronously. During Fiber task processing, dependent services are accessed asynchronously and non-blockingly, and a user response is generated based on the dependent data and task logic. The user response is then written back to the client asynchronously and non-blockingly. Because this application utilizes an asynchronous non-blocking I / O component for the Fiber pool, implementing the underlying environment for asynchronous non-blocking service calls, the Fiber pool does not degenerate into a blocking processing mode when processing requests, thus solving the problem of the Fiber pool requiring significant computational resources to degenerate into a blocking processing mode when facing requests. Furthermore, since the resource utilization of threads in the Fiber pool is extremely low when processing request tasks, compared to threads in related technologies facing high concurrency requests, this method can handle more requests with lower resources. Therefore, the technical solution in this embodiment can improve system resource utilization and disaster recovery capabilities in high-concurrency scenarios, and reduce service deployment costs. Attached Figure Description

[0059] Figure 1 A schematic diagram illustrating the effect of the related technology provided in the embodiments of this application;

[0060] Figure 2 A schematic diagram illustrating the effect of the related technology provided in the embodiments of this application;

[0061] Figure 3 A schematic diagram illustrating the effect of the related technology provided in the embodiments of this application;

[0062] Figure 4 A flowchart illustrating the request processing method provided in this application embodiment;

[0063] Figure 5 A flowchart illustrating the request processing method provided in this application embodiment;

[0064] Figure 6 A flowchart illustrating the request processing method provided in this application embodiment;

[0065] Figure 7 A flowchart illustrating the request processing method provided in this application embodiment;

[0066] Figure 8 A flowchart illustrating the request processing method provided in this application embodiment;

[0067] Figure 9 A flowchart illustrating the request processing method provided in this application embodiment;

[0068] Figure 10 A flowchart illustrating the request processing method provided in this application embodiment;

[0069] Figure 11 A flowchart illustrating the request processing method provided in this application embodiment;

[0070] Figure 12 A schematic diagram of the structure of the request processing apparatus provided in the embodiments of this application;

[0071] Figure 13 This is a schematic diagram of a hardware entity of an electronic device provided in an embodiment of this application. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0073] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0074] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0075] Among related technologies, backend online software application services currently implemented based on the Java ecosystem occupy the majority of application scenarios. Combined with... Figure 1 These backend online application architectures primarily use traditional threads for blocking data computation and storage. However, while ensuring resource utilization efficiency, a single process can only support a very limited number of threads (generally a few thousand at most), resulting in high resource coupling, low efficiency, and making it unsuitable for building high-concurrency systems.

[0076] While related technologies offer two solutions—lightweight threaded Fiber components (fibers, similar to coroutines in Go, are low-resource-utilization, suspendable, and interruptible tasks; a single process can handle tens or hundreds of thousands of them, one or several orders of magnitude higher than threads; hereinafter referred to as Fiber) or reactive programming based on Spring WebFlux—that can solve the problems of low single-threaded capacity and severe resource coupling, however:

[0077] 1. The Fiber component has an incomplete ecosystem and cannot be implemented independently.

[0078] 2. The learning and adaptation costs for Spring WebFrame's UX streaming programming are too high.

[0079] 3. The Java Development Kit (JDK) version 21 and later versions of virtual threads are still under experimental development. It will take a very long time for them to truly form a complete and reliable ecosystem and be implemented.

[0080] Due to the factors mentioned above, there is currently no more flexible application architecture in the Java ecosystem that can be implemented quickly and cost-effectively with lightweight threads.

[0081] Disadvantages of related technologies:

[0082] The high cost of traditional thread-based blocking in-memory computing architectures can be understood as: combining Figure 1 The maximum number of threads a single process can support (thread 1 to thread n) is low (taking cloud virtual hosts as an example, once the number of threads reaches several thousand, thread switching will occupy most of the central processing unit (CPU) time), which will cause the following problems:

[0083] 1. Relatively high application deployment costs: In the current thread-based blocking architecture, many Java-based architectures typically deploy a large number of redundant machines to handle high concurrency, traffic spikes, and instability issues in upstream and downstream dependent services. This usually consumes more computing resources than actually needed.

[0084] 2. Relatively high online operation and maintenance costs: Because the maximum number of threads a single process can support is low, threads consume significant memory / CPU resources. Competition for these resources among interfaces within a single process becomes extremely fierce. A sudden surge in request traffic or I / O timeouts at one interface can block and consume a large amount of thread resources, rendering other interfaces unusable. This low resource limit severely increases resource contention and coupling within a single process; often, an error in one interface can cause numerous other interfaces to become unavailable, creating a cascading failure. Therefore, under the same hardware resource conditions, thread-based blocking architectures have a relatively higher probability of encountering Service Level Agreement (SLA) issues, leading to higher daily operation and maintenance costs.

[0085] The existing Fiber ecosystem is incomplete and lacks the ability to be implemented independently.

[0086] 1. Directly using traditional IO components within Fiber will degenerate into blocking mode: such as Figure 2As shown, Fiber components primarily support in-memory computing. Mature components for I / O access are implemented based on threads, not Fiber. Therefore, directly performing I / O access within a Fiber task will block the underlying threads that the Fiber task depends on (the number of underlying Fiber threads is equal to the number of CPU cores), thus degrading the service to a blocking mode supported by only a few threads. Even if the I / O task is offloaded to other threads (thread 1 to thread n) for asynchronous processing, these asynchronous threads are still blocking, requiring a large number of threads to handle the load, making the difference from the blocking mode negligible.

[0087] 2. Fiber I / O operations consume a significant amount of memory: for example... Figure 2 As shown, many current I / O components are implemented based on Netty. Netty's underlying memory allocation and management cache is based on ThreadLocal, and this cache is quite large. If these I / O components are used directly within Fiber tasks, then Netty's memory allocation and management cache will be directly attached to each Fiber task. Since a process can create tens or hundreds of thousands of Fibers, the total amount of Netty's memory allocation and management cache attached to all Fibers will be several gigabytes, causing frequent Full GC (Full Garbage Collection).

[0088] 3. Custom thread pools cannot inherit the context of Fiber: such as Figure 3 As shown, when a custom thread pool takes over a portion of the tasks of a Fiber, the asynchronous thread cannot inherit the context of the Fiber itself, resulting in context loss. For example, the transaction context of a database, once enabled in a Fiber, is stored in the Fiber. If creation, update, read, delete, or CRUD operations are performed in an asynchronous thread, the transaction will be lost.

[0089] 4. The implementation cost of Spring WebFlux reactive architecture is high. Although the Spring WebFlux ecosystem is relatively complete and mature, its fluent programming mode is fundamentally disruptive compared to traditional blocking programming, resulting in excessively high learning and migration costs.

[0090] Spring WebFlux Flow Programming Example:

[0091] Flux <user>userFlux;

[0092] userFlux.filter(user->user.isActive())

[0093] .map(activeUser->new SimpleUser(activeUser.getName()))

[0094] .concatWith(Mono.error(new RuntimeException("Unexpected error")))

[0095] .onErrorResume(e->Mono.just(new SimpleUser("default user")))

[0096] .then(Mono.just("Operation Completed"));

[0097] Traditional blocking programming example:

[0098]

[0099] In summary, within the current Java ecosystem, for high-concurrency applications, the options are either to use a traditional thread-based blocking architecture, incurring higher costs to deploy more redundant machines to achieve the same effect as a highly elastic architecture, or to incur even higher learning and migration costs by disruptively migrating existing applications to a Spring WebFlux reactive architecture to achieve high architectural elasticity. There is currently no low-cost solution within the Java ecosystem to achieve a highly elastic architecture similar to the coroutine-based architecture in the Go ecosystem.

[0100] This application provides a request processing method. Please refer to [link / reference]. Figure 4 This is a flowchart illustrating a request processing method provided in an embodiment of this application, which will be combined with... Figure 4 The steps shown are explained below:

[0101] S101. Receive the request, encapsulate the request into a Fiber task, and process it asynchronously.

[0102] In this embodiment, a highly resilient and responsive software architecture based on blocking programming receives requests sent by the user, encapsulates the requests into Fiber tasks, and hands them over to Fiber fibers for asynchronous processing.

[0103] The request processing device may include a server, cloud server, or terminal with corresponding functions.

[0104] Fiber, or "fiber process," is a lightweight thread component in the Java ecosystem, similar to coroutines in Go. Essentially, it's a task that can be suspended at any time, executed by threads (the number of threads is typically equal to the number of CPU cores). Compared to threads, it's extremely lightweight, has higher CPU switching efficiency, consumes less memory, and a single process can support tens or hundreds of thousands of Fibers (far exceeding the number of threads by one or several orders of magnitude), greatly improving single-process elasticity and making it more suitable for building high-concurrency applications at low cost. Currently, it lacks an IO component and is not suitable for independent deployment.

[0105] S102. During the asynchronous processing of the Fiber task, the dependent services are accessed in an asynchronous non-blocking manner, and a user response is generated based on the dependent data and task logic.

[0106] In this embodiment, the software architecture delegates Fiber tasks to the Fiber thread pool. When a Fiber task needs to access a dependent service, the Fiber thread pool hands over the subscription task to a thread in the asynchronous subscription thread pool for processing, while suspending the Fiber tasks in the Fiber thread pool. Then, based on the dependency data returned by the external dependent service, the suspended Fiber task is resumed, and finally, a user response is generated based on the dependency data and task logic.

[0107] S103. Write the user response back to the user terminal in an asynchronous, non-blocking manner.

[0108] In this embodiment of the application, the user response is encapsulated into a user response task and handed over to the user terminal by the response write-back thread pool in an asynchronous non-blocking manner to write back the response.

[0109] In this architecture, the asynchronous subscription thread pool and the response write-back thread pool use a small number of threads (typically the number of CPU cores) to prevent Netty's underlying memory allocation cache (CachedThreadLocal) from being attached to every Fiber task. Tens of thousands or hundreds of thousands of such contexts would consume a large amount of memory, causing frequent Full GC. In fact, because the input / output (I / O) components used are asynchronous and non-blocking, these two thread pools only require a few threads to meet the requirements.

[0110] Please see Figure 5 This is a flowchart illustrating a request processing method provided in an embodiment of this application. Figure 4 S101 to S103 can also be implemented through S201 to S205, which will be explained in conjunction with the steps:

[0111] S201. Based on the asynchronous non-blocking service provider, the request is encapsulated into the Fiber task in the request receiving thread pool and handed over to the Fiber pool for asynchronous processing.

[0112] In this embodiment, the asynchronous non-blocking service provider's request receiving thread pool receives requests, extracts and clones the request context object, constructs business logic processing objects and callback objects, encapsulates them into Fiber tasks, and hands over the Fiber tasks to the Fiber pool for asynchronous processing. After handing over the Fiber tasks, the request receiving thread immediately takes on other requests. When a Fiber task is executed, it first sets the passed-in context into the current fiber, and then begins executing the business processing logic.

[0113] The asynchronous non-blocking service providers include: Remote Procedure Call (RPC) asynchronous callback service providers, Spring WebFlux HTTP service providers, and other service providers with asynchronous callback capabilities. The context object is a developer-defined in-memory object that is passed throughout the request processing, facilitating information sharing across different stages of the processing logic. The constructed business logic processing object is the object containing the business logic written by the developer. The callback object is used to write back the response after the user response is generated. The Fiber task includes: the request parameters, the callback object (using the asynchronous context of the publisher or RPC in the WebFlux ecosystem), the business logic processing object, and the request receiving thread context information.

[0114] S202. Based on the asynchronous non-blocking IO component and the asynchronous subscription thread pool, access the dependent service and suspend the Fiber task.

[0115] In this embodiment, when access to a dependent service is required, the software architecture forms an asynchronous subscription task based on information such as asynchronous non-blocking I / O components and dependent services. This asynchronous subscription task is then handed over to an asynchronous subscription thread pool to access the dependent service. Finally, the Fiber task is manually suspended using the built-in capabilities of the Fiber framework. When the asynchronous subscription task executes, the Fiber context is first set in the subscription thread. After the dependent service access is triggered, the set context is cleared.

[0116] The asynchronous non-blocking I / O components include: RPC asynchronous callback service consumer components, Spring WebFlux reactive components, and database / caching / MQ (Message Queue) reactive or asynchronous non-blocking access components, etc. The dependency subscription thread pool is used to encapsulate the execution of subscription access to dependent services to prevent memory leaks. The context is the context object extracted from Fiber and passed down as described in S201.

[0117] S203. Based on the subscription callback thread pool, set the dependency data returned by the dependency service and resume the suspended Fiber task.

[0118] In this embodiment, the software architecture retrieves dependency data from the dependent service based on an asynchronous subscription thread pool. The software architecture can then use the subscription callback thread pool to set the dependency data returned by the dependent service into a completementStage object, thereby resuming the suspended Fiber task.

[0119] S204. Obtain the user response based on the Fiber task logic and the dependency data.

[0120] In this embodiment of the application, the software architecture can obtain user responses based on the Fiber task logic and dependency data.

[0121] S205. The user response is encapsulated into a user response task and handed over to the response write-back thread pool to write back the response to the user.

[0122] In this embodiment, the software architecture encapsulates the user response into a user response task, hands the user response task over to a response write-back thread pool, and clears the context set in the Fiber. When the user response task is executed, the context information is first set in the write-back thread, then a callback object is used to write the response back to the user in an asynchronous, non-blocking manner, and finally the set context is cleared. The response write-back thread pool is used to isolate network I / O request operations during the processing of the Fiber task.

[0123] The context is the context object extracted from Fiber and passed down as described in S201; the callback object is the object that writes back the user response as described in S201.

[0124] Please see Figure 6 This is a flowchart illustrating a request processing method provided in an embodiment of this application. Figure 5 S201 can be implemented through S301 to S302, which will be explained in conjunction with the steps:

[0125] S301. Obtain and clone the Java thread context mapping table of the thread in the request receiving thread pool that processes the request.

[0126] In this embodiment of the application, the software architecture obtains and clones the Java thread context mapping table of the thread that processes the request in the request receiving thread pool.

[0127] S302. Extract the request receiving thread context information from the Java thread context mapping table and copy it to the Fiber fiber in the Fiber pool that processes the Fiber task.

[0128] In this embodiment, the software architecture extracts the request receiving thread context information from the Java thread context mapping table and copies it to the Fiber fiber in the Fiber pool that processes the Fiber task.

[0129] In the Java ecosystem, context information is stored in the thread context (ThreadLocal or InheritableThreadLocal). You can use the JDK's Unsafe to extract the private ThreadLocalMap (object attribute) from the Thread object, and then convert it into a Map structure (where the key is the ThreadLocal object and the value is the actual stored context object). This allows you to clone the corresponding context information into the threads corresponding to FiberTask, asynchronous subscription tasks, and asynchronous write-back tasks, respectively.

[0130] In this embodiment, the Java thread context mapping table of the thread handling the request in the request receiving thread pool is obtained and cloned; the request receiving thread context information is extracted from the Java thread context mapping table and copied to the Fiber fiber handling the Fiber task in the Fiber pool. In this way, after a fiber task is transferred to the Fiber pool, the request receiving thread context information corresponding to the request receiving thread can be copied to the Fiber fiber, solving the problem of inconsistent context passing during the continuous transfer of a task between the Fiber and the thread.

[0131] The specific execution flow of S301 to S302 includes: when a request enters the software architecture, the following flow is executed in the traditional request receiving thread;

[0132] First, obtain and clone the ThreadLocalMap object representing the request receiving thread context from the request receiving thread pool (in the Java ecosystem, context is generally stored in ThreadLocal and InheritableThreadLocal, and underlyingly stored in the ThreadLocalMap attribute of each thread variable). Context information is information that persists throughout the program's execution; essentially, it's a memory object that stores various necessary information and can be read and written at any time during runtime.

[0133] Then, construct a Fiber Task that can run in the Fiber pool. A Fiber Task includes: the request parameters, a callback object of the asynchronous context of the publisher or RPC in the WebFlux ecosystem, a business logic processing object, and the request receiving thread context information.

[0134] The callback object required by FiberTask can be a publisher within the Spring WebFlux ecosystem:

[0135] If using Spring WebFlux, it's almost identical to traditional Spring MVC (Model-View-Controller) blocking HTTP, with extremely low migration costs. Implement a custom `Publiser` class that extends Mono or Flux, and override the `subscribe` method. When a `Publiser` subclass is subscribed to, it saves the `Subscriber` object, and the custom `Publiser` uses the saved `Subscriber`'s `complete` method to write back the response.

[0136] If you are using a common RPC framework (such as Dubbo), the provider side provides an AsyncContext, which can be used as a callback object. The example code structure is shown below:

[0137] 1. HTTP application port based on WebFlux:

[0138]

[0139] 2. Applications based on RPC:

[0140]

[0141] 3. Publishers in the Spring WebFlux ecosystem:

[0142]

[0143]

[0144] 4. The overall structure of FiberTask is as follows:

[0145]

[0146]

[0147] After a FiberTask is handed over to Fiber, the execution flow is as follows:

[0148] First, extract the context from the passed-in cloned ThreadLocalMap and set it in the current thread.

[0149] Then, the internal business logic is executed, and if it is an in-memory computation, it is exactly the same as the traditional coding style.

[0150] Please see Figure 7 This is a flowchart illustrating a request processing method provided in an embodiment of this application. Figure 5 S202 to S203 can be implemented through S401 to S407, which will be explained in conjunction with the steps:

[0151] S401. Obtain and clone the Java thread context mapping table in the Fiber.

[0152] In this embodiment, the software architecture obtains and clones the Java thread context mapping table in the Fiber.

[0153] S402. Construct an asynchronous subscription task based on the context information in the Java thread context mapping table in the Fiber and the asynchronous non-blocking IO component.

[0154] The asynchronous subscription task includes: the context information, the asynchronous non-blocking I / O component, the request parameters of the request, and a listener object. The listener object contains a CompletionStage object that can be completed and the context information.

[0155] For example, the software architecture obtains the ThreadLocalMap of the Fiber where the current Fiber task is located, constructs an asynchronous subscription task, and implements the JDK's Runnable interface. This asynchronous subscription task includes request parameters, a reactive IO component based on Spring WebFlux or a traditional asynchronous non-blocking IO component based on the listener pattern (such as 2DBC / ReactiveRedis / ReactiveEs / ReactiveMQ / ReactiveGRPC in the WebFlux ecosystem, asynchronous callback Consumer supported by mainstream RPC, asynchronous callback HttpClient, MQ, etc.), a Listener object, and context information. The Listener object contains a CompleteableFuture and context information.

[0156] The asynchronous subscription task structure is as follows:

[0157]

[0158]

[0159] Spring WebFlux is a reactive application framework that uses a publish-subscribe principle. It relies on Netty's underlying NIO, and its execution process is thread-free, allowing it to handle high concurrency workloads with a very small number of threads. Its ecosystem is currently quite mature and complete, offering a comprehensive suite of components such as R2DBC, ReactiveRedis, ReactiveES, ReactiveMQ, and ReactiveGRPC. However, WebFlux employs a streaming programming model, which incurs significant learning and adaptation costs.

[0160] S403. Transfer the asynchronous subscription task to the asynchronous subscription thread pool, and copy the context information corresponding to the Java thread context mapping table of the Fiber to the asynchronous subscription thread in the asynchronous subscription thread pool that processes the asynchronous subscription task.

[0161] S404. Access the dependent service based on the asynchronous subscription thread.

[0162] In this embodiment, after the software architecture delegates the asynchronous subscription task to the asynchronous subscription thread in the asynchronous subscription thread pool, it can access the dependent service and obtain the dependent data based on the asynchronous subscription thread. The software architecture can copy the context information corresponding to the Java thread context mapping table of the Fiber to the asynchronous subscription thread in the asynchronous subscription thread pool that processes the asynchronous subscription task.

[0163] For example:

[0164] The software architecture submits asynchronous subscription tasks to a small pool of asynchronous subscription threads.

[0165] An asynchronous subscription thread pool executes SubscriptionTasks in parallel, with the following process:

[0166] First, extract the context from the passed ThreadLocalMap and set it in the asynchronous subscription thread.

[0167] Secondly, initiate asynchronous non-blocking call subscriptions to external dependent services, as shown in the following structure:

[0168] / / WebFlux initiates a subscription call

[0169] Mono <user>user=repository.findByld(id);

[0170] user.doOnError(e->listener.onResult(null,e)).subscribe(user->listener.onResult(user,null);

[0171] / / RPC initiates call subscription

[0172] rpcApi.invoke(r,listener);

[0173] / / Asynchronous non-blocking HTTP initiation, call, and subscription

[0174] httpAsyncClient.execute(r,listener);

[0175] Finally, clean up the context except for Netty's underlying memory allocation cache (CachedThreadLocal).

[0176] S405. Delete the context information in the subscription thread except for the underlying Netty memory allocation cache.

[0177] In this embodiment, after the dependent service is accessed, the software architecture removes context information other than Netty's underlying memory allocation cache. That is, it cleans up the context in the subscription thread except for Netty's underlying memory allocation cache (CachedThreadLocal).

[0178] S406. Suspend the Fiber task using the Fiber framework's AsyncCompletionStage.get(CompletionStage object).

[0179] S407. After the dependency service returns the dependency data, call the completion method of the CompletionStage object to resume the suspended Fiber task.

[0180] In this embodiment, after the external dependent service returns the dependent data, it calls the Listener's callback interface. Within the callback interface, it calls the `complete()` or `completeExceptionally()` method of `CompletableFuture`. Once the Fiber detects that `CompletableFuture` has completed, it will automatically resume execution from its suspension and continue execution once CPU resources are available.

[0181] In this embodiment, the Java thread context mapping table in the Fiber is obtained and cloned; based on the context information in the Java thread context mapping table in the Fiber, an asynchronous subscription task is constructed using an asynchronous non-blocking I / O component; the asynchronous subscription task is then transferred to an asynchronous subscription thread pool to access dependent services. In this way, by transferring the asynchronous subscription task to asynchronous subscription threads in the asynchronous subscription thread pool, the cache related to asynchronous non-blocking requests can be locked in the asynchronous subscription thread pool with a small number of threads, solving the problem of excessive memory consumption caused by attaching the cache to the Fiber task (Fiber fiber pool). Furthermore, the context information in the object attributes of the request receiving thread executing the Fiber is passed and exchanged between the Fiber and the asynchronous subscription thread pool, resolving the problem of inconsistency between the Fiber task and thread contexts.

[0182] Please see Figure 8 The following is a flowchart illustrating a request processing method provided in an embodiment of this application, and the steps will be described in conjunction with the flowchart:

[0183] S501. During the asynchronous processing of the Fiber task, the database access is achieved by extracting and copying based on the Spring transaction context or by using the same reactive database connection object to obtain the dependent data.

[0184] In this embodiment, during the asynchronous processing of the Fiber task, the software architecture uses a thread pool with a small number of threads for isolated operations, and uses Spring's database transaction context object for context passing and cleanup, achieving transactional database access to obtain the dependent data. This method is generally used for asynchronous blocking database access.

[0185] Asynchronous blocking access: In typical complex business scenarios, a single process with a few dozen threads can support blocking database access of around 1000 QPS. Therefore, a thread pool of a few dozen threads can be established (other I / O accesses are asynchronous and non-blocking, requiring fewer threads in the pool, yet still maintaining a small number of threads per process). Blocking database access tasks are submitted to this thread pool for asynchronous execution. After submission, the Fiber task is suspended using the same `AsyncCompletionStage.get(f)` method, waiting for the result to return before resuming execution. The Spring framework's manual transaction method is used for transaction initiation / commit / rollback. It's important to note that transaction operations require network I / O and should be placed in a Structured Query Language (SQL) thread pool. The Spring transaction context is stored in `NamedInheritableThreadLocal`. This type of context is copied and continuously exchanged between the Fiber and the thread pool, allowing for transactions to be performed as if they were done manually within a single thread.

[0186] In this embodiment, during the asynchronous processing of the Fiber task, the software architecture uses an asynchronous subscription thread pool for isolation and the same reactive database connection object for database access operations, achieving transactional database access to obtain the dependent data. This method is generally used for asynchronous non-blocking database access.

[0187] Asynchronous non-blocking access: Reactive relational database connectivity (R2DBC) provides a reactive Connection that can be used to manually manipulate transactions. All tasks are asynchronous and non-blocking, but they all need to be placed in a thread pool with a small number of threads to avoid exposing the Netty underlying cache as mentioned earlier. After submitting the task to the thread pool, AsyncCompletionStage.get(f) is used to switch the Fiber.

[0188] Please see Figure 9 This is a flowchart illustrating a request processing method provided in an embodiment of this application. Figure 5 S205 in the above can also be implemented through S601 to S605, which will be explained in conjunction with the steps:

[0189] S601. The user response is encapsulated into a user response task and handed over to the response write-back thread in the response write-back thread pool.

[0190] The user response task includes: the request input parameters, response object, callback object, and context information of the request; wherein the context information is copied from the Java thread context mapping table corresponding to the Fiber.

[0191] After several rounds of in-memory computation -> external dependency call subscription and Fiber switching, the process after receiving the user response is as follows:

[0192] First, obtain and clone the ThreadLocalMap of the thread in which the current Fiber resides, and assemble the user response task, which includes the response object, callback object, and context information. The structure of the user response task is as follows:

[0193]

[0194] Then, the user response task is submitted to a small pool of response write-back threads.

[0195] S602. Obtain and clone the Java thread context mapping table in the Fiber.

[0196] S603. Copy the context information corresponding to the Java thread context mapping table of the Fiber to the response write-back thread in the response write-back thread pool that processes the user response task.

[0197] In this embodiment of the application, the write-back process executed by the response write-back thread pool is as follows: extract the context from the cloned ThreadLocalMap passed in and set it into the response write-back thread.

[0198] S604. Delete the Java thread context in the Fiber.

[0199] S605. Based on the response write-back thread, perform asynchronous non-blocking write-back to the user terminal.

[0200] In this embodiment of the application, the callback method of the callback object is used to perform asynchronous non-blocking writeback (the underlying implementation generally relies on Netty's WriteAndFlush).

[0201] S606. Delete context information in the response write-back thread, except for the underlying Netty memory allocation cache.

[0202] Finally, clean up the context except for Netty's underlying memory allocation cache (CachedThreadLocal).

[0203] In this embodiment, the above request processing method can also be combined with the component ecosystem to form a shared underlying framework. On this framework, simply keep pushing the SuspendException from the Fiber framework upwards (so that the Fiber framework can identify and instrument the response function) to develop business logic using traditional blocking programming methods.

[0204] Please see Figure 10 This is a flowchart illustrating a request processing method provided in an embodiment of this application. Figure 10 The process described in the document is a supplementary description of the context from a holistic perspective. It will be explained in conjunction with the steps:

[0205] S11. Extract and clone the context object properties.

[0206] In this embodiment of the application, during the software architecture construction process, the software architecture utilizes Unsafe to extract and clone the ThreadLocalMap of the thread that processes requests in the request receiving thread pool. A Map structure can be constructed based on the extracted and cloned ThreadLocalMap (the key of the Map is the ThreadLocal object, and the value is the actual stored context object).

[0207] S12, Passing context object properties.

[0208] In this embodiment of the application, during the context object passing process, the software architecture extracts and clones the ThreadLocalMap object and passes it to the Fiber.

[0209] S13. Extract and set the context.

[0210] In this embodiment of the application, when copying the context to the corresponding Fiber, the software architecture copies the context from the passed ThreadLocalMap object to the Fiber.

[0211] S14. Extract the context object properties.

[0212] In this embodiment of the application, the ThreadLocalMap of the thread corresponding to the Fiber is extracted from the software architecture before accessing the dependent service.

[0213] S15. When setting up an asynchronous subscription thread, use Unsafe to extract and set the context.

[0214] In this embodiment of the application, when setting up an asynchronous subscription thread, the software architecture copies the context in the passed ThreadLocalMap object into the asynchronous subscription thread that processes the task in the asynchronous subscription thread pool.

[0215] S16. Execution of IO actions when retrieving dependent data.

[0216] In this embodiment of the application, the software architecture performs I / O access to external dependent services when obtaining dependent data.

[0217] S17. When using database transactions, replace all identical objects in the passed-in ThreadLocalMap with all currently namedInheritableThreadLocal objects in the subscribing thread.

[0218] S18. After the IO action is executed, clear all contexts set in the thread (except for the Netty underlying cache).

[0219] In this embodiment, after the IO action is executed when obtaining dependent data, the software architecture clears the context information set in the corresponding thread in the asynchronous subscription thread pool, except for the underlying Netty memory allocation cache (CachedThreadLocal).

[0220] S19, IO response returned.

[0221] In this embodiment of the application, the software architecture receives the dependency data returned from the response of the external dependency service when the dependency data is returned.

[0222] S20. Extract and clone the context object properties.

[0223] In this embodiment, after the dependency data is returned, the software architecture extracts and clones the context object of the ThreadLocalMap object passed from the Fiber.

[0224] S21. After the dependency data is returned, clear all contexts set in the Fiber.

[0225] In this embodiment of the application, after the dependent data is returned, the software architecture can clear the context information set in S13 for the Fiber thread that processes the task in the Fiber.

[0226] S22. Use Unsafe to extract and set the context.

[0227] In this embodiment of the application, when performing response write-back, the software architecture can use the Unsafe tool to extract the corresponding context information from the Map structure determined in S20 and set it to the corresponding thread in the response write-back thread pool.

[0228] S23. Execution of IO actions during response write-back.

[0229] In this embodiment of the application, when writing back the response, the software architecture can perform corresponding IO actions based on the corresponding thread in the response write-back thread pool, that is, perform write-back processing on the returned data.

[0230] S24. Clear all contexts set in the thread (excluding Netty's underlying cache).

[0231] In this embodiment of the application, after the response write-back is completed, the software architecture clears the context information in the corresponding thread of the response write-back thread pool, except for the underlying Netty memory allocation cache (CachedThreadLocal).

[0232] Please see Figure 11 This is a flowchart illustrating a request processing method provided in an embodiment of this application. Figure 11 This is a general description from a holistic perspective of the entire process of the embodiments. The steps will be explained in conjunction with the following:

[0233] W11. After receiving a request, encapsulate the fiber task through the preset request receiving thread pool.

[0234] In this embodiment of the application, after receiving a request, the software architecture receives and processes the request through a thread in the request receiving thread pool, and encapsulates the thread into a Fiber task.

[0235] W12, Handing over fiber transfer tasks.

[0236] In this embodiment of the application, when handing over fiber tasks, the software architecture transfers the Fiber task to the Fiber fiber in the Fiber fiber pool.

[0237] W13, Transfer subscription task.

[0238] In this embodiment of the application, when access to a dependent service is required, the software architecture forms a subscription task based on Fiber-1 fibers to hand over the processing task to the asynchronous subscription thread pool, and then hands over the subscription task to the thread in the asynchronous subscription thread pool.

[0239] W14. After the subscription task is handed over, suspend the Fiber and yield the thread.

[0240] In this embodiment of the application, after the subscription task is handed over, the software architecture transfers the subscription task to the asynchronous subscription thread pool and then suspends the Fiber task in the Fiber pool.

[0241] W15, IO action execution.

[0242] In this embodiment of the application, when accessing a dependent service, the software architecture performs IO actions based on threads in the asynchronous subscription thread pool in conjunction with the external dependent service to determine the returned data.

[0243] W16, Returns data.

[0244] In this embodiment of the application, after the dependency data is returned, the software architecture passes the dependency data to the Fiber through an asynchronous subscription callback thread pool and resumes the suspended Fiber.

[0245] W17, Restore Fiber.

[0246] W18, Assemble asynchronous response tasks.

[0247] In this embodiment of the application, when a response writeback is required, the software architecture is based on the restored Fiber and the return task to assemble a user response task.

[0248] W19, Handing over user response tasks.

[0249] In this embodiment of the application, when handing over the user response task, the software architecture hands over the user response task to the corresponding thread in the response write-back thread pool for write-back processing.

[0250] W20, the response write-back thread pool executes user response tasks.

[0251] In this embodiment of the application, when executing a user response task, the thread in the response write-back thread pool performs write-back processing on the user response task based on the callback object and returns it to the user.

[0252] In summary, the overall process combines a Fiber pool, Spring WebFlux IO components (or Remote Procedure Call (RPC) components), and an asynchronous thread pool with a small number of threads, providing a highly elastic and responsive architecture construction method that can be quickly deployed with the Fiber pool as the basic execution unit.

[0253] This architecture combines a Fiber pool with Spring WebFlux (or asynchronous callback) IO components to address the lack of an IO ecosystem and independent deployment capabilities of Fiber. Specifically, within a Fiber task, IO access is delegated to an asynchronous thread pool with a small number of threads. These threads use Spring WebFlux (or asynchronous listener mode) for subscription-based asynchronous non-blocking IO access. Once the IO returns, the suspended Fiber task resumes execution.

[0254] In this architecture, only the IO layer (receiving requests / accessing dependent services / writing back user responses) incorporates Spring WebFlux reactive IO components or traditional listener-based asynchronous non-blocking IO components to supplement Fiber's IO access. Typically, the IO layer is very lightweight, with minimal learning and modification costs and workload. The core domain logic remains unaffected and can be developed using traditional blocking programming, significantly reducing the cost of implementing and migrating this architecture.

[0255] In this architecture, Fiber receives requests, encapsulates them into Fiber tasks, and processes them asynchronously. During Fiber task processing, dependent services are accessed asynchronously and non-blockingly, and a user response is generated based on the dependency data and task logic. The user response is then written back to the client asynchronously and non-blockingly. Since the asynchronous non-blocking I / O component in this application provides the underlying environment for the Fiber pool to implement dependent asynchronous non-blocking service calls, the Fiber pool will not degenerate into a blocking processing mode when processing requests, thus solving the problem of the Fiber pool requiring significant computing resources to degenerate into a blocking processing mode when facing requests. Furthermore, because the threads in the Fiber pool have extremely low resource utilization when processing request tasks, compared to threads in related technologies that can handle more requests with lower resources when facing high concurrency, the technical solution in this embodiment can improve system resource utilization and disaster recovery capabilities in high-concurrency scenarios, and reduce service deployment and maintenance costs.

[0256] Please see Figure 12 This is a schematic diagram of the structure of the request processing device provided in the embodiments of this application.

[0257] This application also provides a request processing apparatus 800, including: a request receiving unit 801, a processing unit 802, and a write-back unit 803.

[0258] The request receiving unit 801 is used to receive a request, encapsulate the request into a Fiber task, and process it asynchronously.

[0259] The processing unit 802 is used to access dependent services in an asynchronous non-blocking manner during the asynchronous processing of the Fiber task, and to generate a user response based on the dependent data and task logic.

[0260] The write-back unit 803 is used to write back the user response to the user terminal in an asynchronous, non-blocking manner.

[0261] In this embodiment of the application, the request receiving unit 801 in the request processing device 800 is used to encapsulate the request into the Fiber task in the request receiving thread pool based on the asynchronous non-blocking service provider, and hand it over to the Fiber thread pool for asynchronous processing.

[0262] In this embodiment of the application, the processing unit 802 in the request processing device 800 is used to access the dependent service based on the asynchronous non-blocking IO component and the asynchronous subscription thread pool, and suspend the Fiber task;

[0263] Based on the subscription callback thread pool, the dependency data returned by the dependent service is set, and the suspended Fiber task is resumed; wherein, the asynchronous subscription thread pool and the subscription callback thread pool are used to isolate network I / O request operations during the processing of the Fiber task;

[0264] The user response is obtained based on the Fiber task logic and the dependency data.

[0265] In this embodiment of the application, the write-back unit 803 in the request processing device 800 is used to encapsulate the user response into a user response task and hand it over to the response write-back thread pool for writing back the response to the user terminal; wherein, the response write-back thread pool is used to isolate network I / O request operations during the processing of the Fiber task.

[0266] In this embodiment of the application, the asynchronous non-blocking service provider includes: an Rpc asynchronous callback service provider and a SpringWebFlux HTTP service provider;

[0267] The Fiber task includes: the request input parameters of the request, a callback object that is an asynchronous context of a publisher or RPC in the WebFlux ecosystem, a business logic processing object, and request receiving thread context information.

[0268] In this embodiment of the application, the request receiving unit 801 in the request processing device 800 is used to obtain and clone the Java thread context mapping table of the thread that processes the request in the request receiving thread pool; extract the request receiving thread context information in the Java thread context mapping table, and copy it into the Fiber fiber that processes the Fiber task in the Fiber fiber pool.

[0269] In this embodiment of the application, the asynchronous non-blocking IO component includes: an Rpc asynchronous callback service consumer component, a reactive component of SpringWebFlux dependent downstream services, and a database / caching / MQ reactive or asynchronous non-blocking access component.

[0270] In this embodiment of the application, the processing unit 802 in the request processing device 800 is used to obtain and clone the Java thread context mapping table in the Fiber.

[0271] An asynchronous subscription task is constructed based on the context information in the Java thread context mapping table in the Fiber and the asynchronous non-blocking I / O component; wherein, the asynchronous subscription task includes: the context information, the asynchronous non-blocking I / O component, the request input parameters of the request, and a listener object, wherein the listener object contains a completionStage object that can be completed and the context information.

[0272] The asynchronous subscription task is handed over to the asynchronous subscription thread pool, and the context information corresponding to the Java thread context mapping table of the Fiber is copied into the asynchronous subscription thread in the asynchronous subscription thread pool that processes the asynchronous subscription task.

[0273] Access to the dependent service is based on the asynchronous subscription thread;

[0274] Remove context information outside of Netty's underlying memory allocation cache;

[0275] The Fiber task is suspended using the Fiber framework's AsyncCompletionStage.get (CompletionStage object).

[0276] In this embodiment of the application, the processing unit 802 in the request processing device 800 is used to call the completion method of the completeable CompletionStage object to resume the suspended Fiber task after the dependent service returns the dependent data.

[0277] In this embodiment of the application, the processing unit 802 in the request processing device 800 is used to extract and copy based on the Spring transaction context or use the same reactive database connection object to access the database during the asynchronous processing of the Fiber task, so as to obtain the dependent data through transactional database access.

[0278] In this embodiment of the application, the processing unit 802 in the request processing device 800 is used to perform operations in isolation using a thread pool with a small number of threads during the asynchronous processing of the Fiber task, and to use the database transaction context object in Spring for context passing and clearing, so as to obtain the dependent data through database transactional access.

[0279] In this embodiment of the application, the processing unit 802 in the request processing device 800 is used to perform operations in isolation using an asynchronous subscription thread pool during the asynchronous processing of the Fiber task, and to perform database access operations using the same reactive database connection object, so as to obtain the dependent data through database transactional access.

[0280] In this embodiment of the application, the user response task includes: the request input parameters, response object, callback object, and context information of the request; wherein, the context information is copied in the Java thread context mapping table corresponding to the Fiber.

[0281] In this embodiment of the application, the write-back unit 803 in the request processing device 800 is used to encapsulate the user response into a user response task and transfer it to the response write-back thread in the response write-back thread pool.

[0282] Get and clone the Java thread context mapping table in the Fiber;

[0283] The context information corresponding to the Java thread context mapping table of the Fiber is copied to the response write-back thread in the response write-back thread pool that processes the user response task;

[0284] Remove the Java thread context from the Fiber.

[0285] The response write-back thread performs an asynchronous, non-blocking write-back to the user terminal.

[0286] Remove context information from the response write-back thread, excluding Netty's underlying memory allocation cache.

[0287] It should be noted that, in the embodiments of this application, if the above-described request processing method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a request processing device (which may be a personal computer, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0288] Correspondingly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a method on one side of the request processing device 800.

[0289] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0290] It should be noted that, Figure 13 A schematic diagram of a hardware entity of an electronic device provided in an embodiment of this application, such as... Figure 13 As shown, this application embodiment provides an electronic device 900, including a memory 902 and a processor 901. The memory 902 stores a computer program that can run on the processor 901. When the processor 901 executes the program, it implements the steps in the above-described method, wherein;

[0291] Processor 901 typically controls the overall operation of electronic device 900.

[0292] The memory 902 is configured to store instructions and applications executable by the processor 901, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data and video communication data) in the processor 901 and various modules in the electronic device 900. It can be implemented by flash memory or random access memory (RAM).

[0293] Correspondingly, this application embodiment also provides a computer program product, including a computer program that can be executed by the processor 901 of the electronic device 900 to complete the steps in the method on one side of the request processing device 800.

[0294] Correspondingly, this application embodiment also provides a software architecture, which encapsulates the functions corresponding to the request processing device into a basic framework.

[0295] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0296] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0297] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the apparatus or units can be electrical, mechanical, or other forms.

[0298] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0299] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0300] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0301] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0302] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / user> < / user>

Claims

1. A request processing method, characterized in that, include: Receive the request, encapsulate the request into a Fiber task, and process it asynchronously; During the asynchronous processing of the Fiber task, dependent services are accessed in an asynchronous, non-blocking manner, and user responses are generated based on the dependent data and task logic. The user response is written back to the user terminal in an asynchronous, non-blocking manner.

2. The request processing method according to claim 1, characterized in that, The receiving request is encapsulated into a Fiber task for asynchronous processing, including: Based on the asynchronous non-blocking service provider, the request is encapsulated into the Fiber task in the request receiving thread pool and handed over to the Fiber pool for asynchronous processing.

3. The request processing method according to claim 1, characterized in that, The asynchronous processing of the Fiber task, including accessing dependent services in an asynchronous, non-blocking manner and generating a user response based on the dependent data and task logic, includes: Based on asynchronous non-blocking I / O components and an asynchronous subscription thread pool, the dependent services are accessed, and the Fiber task is suspended. Based on the subscription callback thread pool, the dependency data returned by the dependent service is set, and the suspended Fiber task is resumed; wherein, the asynchronous subscription thread pool and the subscription callback thread pool are used to isolate network I / O request operations during the processing of the Fiber task; The user response is obtained based on the Fiber task logic and the dependency data.

4. The request processing method according to claim 1, characterized in that, The asynchronous, non-blocking method of writing the user response back to the user terminal includes: The user response is encapsulated into a user response task and handed over to the response write-back thread pool to write the response back to the user client; wherein, the response write-back thread pool is used to isolate network I / O request operations during the processing of the Fiber task.

5. The request processing method according to claim 2, characterized in that, The asynchronous non-blocking service providers include: Rpc asynchronous callback service providers and SpringWebFlux HTTP service providers; The Fiber task includes: the request input parameters of the request, a callback object that is an asynchronous context of a publisher or RPC in the WebFlux ecosystem, a business logic processing object, and request receiving thread context information.

6. The request processing method according to claim 2, characterized in that, The method further includes: Obtain and clone the Java thread context mapping table of the thread in the request receiving thread pool that processes the request; Extract the request receiving thread context information from the Java thread context mapping table and copy it to the Fiber fiber in the Fiber pool that processes the Fiber task.

7. The request processing method according to claim 3, characterized in that, The asynchronous non-blocking I / O components include: Rpc asynchronous callback service consumer components, reactive components of SpringWebFlux dependent downstream services, and database / caching / MQ reactive or asynchronous non-blocking access components.

8. The request processing method according to claim 3, characterized in that, The method of accessing the dependent service and suspending the Fiber task based on asynchronous non-blocking I / O components and an asynchronous subscription thread pool includes: Get and clone the Java thread context mapping table in the Fiber; An asynchronous subscription task is constructed based on the context information in the Java thread context mapping table in the Fiber and the asynchronous non-blocking I / O component; wherein, the asynchronous subscription task includes: the context information, the asynchronous non-blocking I / O component, the request input parameters of the request, and a listener object, wherein the listener object contains a completionStage object that can be completed and the context information. The asynchronous subscription task is handed over to the asynchronous subscription thread pool, and the context information corresponding to the Java thread context mapping table of the Fiber is copied into the asynchronous subscription thread in the asynchronous subscription thread pool that processes the asynchronous subscription task. Access to the dependent service is based on the asynchronous subscription thread; Remove context information from the subscription thread, except for Netty's underlying memory allocation cache; Use the Fiber framework to suspend the Fiber task.

9. The request processing method according to claim 3, characterized in that, The resumption of the suspended Fiber task includes: After the dependency service returns the dependency data, the completion method of the completeable CompletionStage object is called to resume the suspended Fiber task.

10. The request processing method according to claim 3, characterized in that, The method further includes: During the asynchronous processing of the Fiber task, the dependent data is obtained by extracting and copying based on the Spring transaction context or by using the same reactive database connection object to access the database, thereby achieving transactional access to the database.

11. The request processing method according to claim 10, characterized in that, During the asynchronous processing of the Fiber task, the extraction and copying based on the Spring transaction context or the use of the same reactive database connection object for database access, to achieve transactional database access and obtain the dependent data, includes: During the asynchronous processing of the Fiber task, a small number of threads are used in a thread pool for isolation, and the database transaction context object in Spring is used for context passing and cleanup to achieve database transactional access to obtain the dependent data.

12. The request processing method according to claim 10, characterized in that, During the asynchronous processing of the Fiber task, the extraction and copying based on the Spring transaction context or the use of the same reactive database connection object for database access, to achieve transactional database access and obtain the dependent data, includes: During the asynchronous processing of the Fiber task, an asynchronous subscription thread pool is used for isolation, and the same reactive database connection object is used for database access operations to achieve transactional database access and obtain the dependent data.

13. The request processing method according to claim 4, characterized in that, The user response task includes: the request input parameters, response object, callback object, and context information of the request; wherein, the context information is copied from the Java thread context mapping table corresponding to the Fiber.

14. The request processing method according to claim 4, characterized in that, The step of encapsulating the user response into a user response task and handing it over to the response write-back thread pool for writing back the response to the user client includes: The user response is encapsulated into a user response task and handed over to the response write-back thread in the response write-back thread pool. Get and clone the Java thread context mapping table in the Fiber; The context information corresponding to the Java thread context mapping table of the Fiber is copied to the response write-back thread in the response write-back thread pool that processes the user response task; Remove the Java thread context from the Fiber. Based on the response write-back thread, an asynchronous non-blocking write-back is performed to the user terminal; Remove context information from the response write-back thread, excluding Netty's underlying memory allocation cache.

15. A reactive software architecture based on blocking programming, characterized in that, The software architecture is implemented by encapsulating the request processing method described in any one of claims 1 to 14 into a basic framework.

16. A request processing apparatus, characterized in that, include: A request receiving unit is used to receive requests, encapsulate the requests into Fiber tasks, and process them asynchronously. The processing unit is used to access dependent services in an asynchronous non-blocking manner during the asynchronous processing of the Fiber task, and to generate a user response based on the dependent data and task logic. The write-back unit is used to write back the user response to the user terminal in an asynchronous, non-blocking manner.

17. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program that can run on the processor, the processor executing the computer program to implement the steps of the method according to any one of claims 1 to 14.

18. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 14.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 14.

Images