A processing method and system for a high-performance gateway system based on Netty

Abstract

The present invention adopts a fully asynchronous multi-task processing model. When time-consuming operations such as IO are encountered during task execution, an asynchronous waiting method is adopted so that the working thread will not be blocked during the waiting process for the time-consuming operation, and the working thread can perform other tasks. The three-level cache lazy loading strategy is adopted to dynamically load the configuration information, and it supports the modification of the configuration at any time and takes effect at any time. The configuration information is loaded when needed, and there is no need to load the configuration when the system starts, which reduces the risk when the system starts and allows the system to focus on executing busy tasks. The Pipeline-Filter task processing mode is adopted, and the linear execution process is more in line with the developer's thinking habits, and the developer only needs to develop different Filters and then use Pipeline to combine the Filters to realize business functions, which reduces the difficulty of development. The three-level exception guarantee mechanism gives the requester a better experience, and the exception guarantee mechanism ensures the stability of the system, and the sending of exceptions by individual tasks will not affect other tasks.

Description

Technical Field

[0001] The present invention relates to the field of computer and network technology, and in particular to a processing method and system for a high-performance gateway system based on Netty. Background Art

[0002] API Gateway is an API-oriented, serial, centralized, and highly controlled service that appears at the system boundary. The system boundary refers to the boundary of the enterprise IT system. Before the concept of microservices became popular, the entity of API Gateway was already born. At that time, the main application scenario was OpenAPI, that is, an open platform, which was aimed at external partners of the enterprise. When the concept of microservices became popular, API Gateway has become a standard component integrated in the upper application layer.

[0003] Api Gateway can be used to solve the following problems:

[0004] 1) The API granularity provided by microservices is usually different from the client's requirements. Microservices generally provide fine-grained APIs, which means that clients generally need to interact with multiple services.

[0005] 2) Different clients require different data, and different types of clients have different network performance.

[0006] 3) The division of services may change over time, so the details need to be hidden from the client.

[0007] The main positioning of the API gateway is:

[0008] 1) For Web Apps, this type of scenario is similar to the separation of front-end and back-end in physical form. At this time, the Web App is no longer a full-featured Web App, but an App customized and scenario-based.

[0009] 2) For Mobile App, in this scenario, the mobile app is the user of the backend service, and the API gateway also needs to assume some of the functions of mobile device management (MDM).

[0010] 3) For Partner OpenAPI, this type of scenario is mainly to meet the external opening of business forms and establish an ecosystem with external partners of the enterprise. In this case, the API gateway needs to add a series of security management and control functions such as quotas, flow control, and tokens.

[0011] 4) Partner External API: As the Internet gradually affects traditional enterprises, many systems rely on the capabilities of external partners to import traffic or content, such as logging in with partner accounts and paying with third-party payment platforms. For enterprises, these are external capabilities. At this time, the API gateway needs to perform unified authentication, authorization, and access control for the external APIs for the unified dispatch of internal enterprise services at the boundary.

[0012] The API gateway system in the existing technology uses Zuul as a technical prototype and is implemented based on the Filter mechanism and the PRPE (PRE-ROUTING-POST-ERROR) model. In terms of system architecture, the plug-in management of business functions is realized through the responsibility chain mechanism (FilterChain) and the Java SPI mechanism, and the management of service / configuration information is realized with the help of the registry module (Registry).

[0013] The data involved in the API gateway in the existing technology mainly includes basic configuration information and business configuration information. Hengfeng Bank stores the basic configuration information in local files, and subscribes to the business configuration information through the Zookeeper registration center.

[0014] The key technologies of the gateway system in the prior art are implemented as follows:

[0015] 1) Platform independence: Filter and other extension points are implemented through the SPI mechanism, as well as some business functions based on third-party tool classes. In addition, it does not rely on other third-party platforms or architectures.

[0016] 2) Filter-PRPE mechanism, improved Zuul implementation, when the gateway starts, it will call the init method of each Filter in turn to obtain the data required for the runtime through the registration center and cache it in the memory to improve the runtime efficiency. The doPre and doPost methods are defined in the interface class to implement the two-way mechanism of the Filter, that is, after the doPre method of each Filter is executed in sequence through the FilterChain, the Filter with the overloaded doPost method is executed in reverse order. It is suitable for scenarios where resources are reserved in doPost and need to be released in doPost.

[0017] 3) Dynamic management of service / configuration data. The gateway does not rely on the persistent data of the database, but manages data through a decentralized registration center. The initial business data is maintained by the management end. The gateway subscribes to these initial business data when it starts. When the registration center data is updated, the gateway can receive notifications in time to update the cache.

[0018] 4) Request filtering mechanism, which performs basic checks or processing on request information, and provides message conversion, message parsing, blacklist and whitelist checking, and request parameter verification functions. Each function supports dynamic start / stop on demand and dynamic expansion.

[0019] 5) Multi-dimensional dynamic routing mechanism, which sends the transaction to the corresponding back-end system according to the parameters in the request message. It provides functions such as rule parsing / checking and service outbound call.

[0020] 6) Service degradation / fuse mechanism, by introducing Netflix's Hystrix mechanism, implements the following functions through resource isolation mechanism: prevent a single dependency from exhausting all user threads in the container; reduce system load, and fail quickly without queuing requests that cannot be processed in time; provide failure fallback, and make failures transparent to users when necessary; use isolation mechanism to reduce the impact of dependent services on the entire system.

[0021] However, the prior art has the following technical problems:

[0022] 1) Hengfeng Bank uses the Zuul gateway framework, which does not have much advantage in overall performance.

[0023] 2) Use the filter preloading mode. When the number of filters increases, the content that needs to be preloaded when the system starts will also increase, and the startup speed will become slower and slower.

[0024] 3) Configuration information is implemented through local files and registration centers. When the gateway starts, it subscribes to all initial business data, and notifies the gateway to update when it is updated. This mode requires subscribing to a large amount of business data at startup, which will slow down the startup speed of the system.

[0025] 4) The service degradation / fuse mechanism used is Netflix's Hystrix mechanism. The current limiting strategy in this mechanism has room for optimization. For the gateway system, the current limiting function is the most basic function. Optimizing the current limiting strategy can better ensure the stability of the gateway system. Summary of the invention

[0026] The present invention provides a processing method and system for a high-performance gateway system based on Netty. In order to achieve platform independence more thoroughly and give full play to the performance of the gateway system, the present invention no longer uses the existing gateway framework, but develops a set of high-performance gateway framework based on Netty. Due to the uneven transaction frequencies of other systems connected to the gateway, many systems may have a transaction only once in a long time. Therefore, in order to allow the system to concentrate on processing busy tasks, the gateway configuration in the present invention adopts a lazy loading mode, that is, loading on demand, rather than all loading when the system starts. In order to improve the operating efficiency of the system, a three-level cache strategy is adopted to save frequently used configuration information in memory, and the principle of locality of the program is utilized. In order to improve the stability of the gateway system and ensure that the gateway will not be abnormal due to a large number of requests, the Ali Sentinel distributed flow control component is used to optimize the flow control, and the three-level abnormal bottoming strategy is adopted to ensure that the request of each external system can be responded to, and the tasks will not affect each other. In order to allow developers to quickly understand and develop different business functions, the present invention uses the Pipeline-Filter mode to process tasks, and the linear processing flow is easier to understand.

[0027] A first aspect of the present invention provides a processing method for a high-performance gateway system based on Netty, comprising:

[0028] Receive the connection request sent by the client, establish a data transmission channel and call the Netty Server processor to process the connection request, obtain the data channel and request data, and package the data channel and request data into a task and put it into the queue to be executed;

[0029] Poll the status of tasks in the queue to be executed, and run tasks whose status is pending.

[0030] Furthermore, the polling of the task status in the waiting-to-be-executed queue, before running the task whose task status is waiting to be executed, includes:

[0031] Determine whether there is an idle thread; if so, put the task to be executed into the idle thread for execution.

[0032] Furthermore, after determining whether there is an idle thread, the method further includes:

[0033] Poll the task status in the waiting queue. If there is a task in the priority processing status, put the task in the priority processing status from the waiting queue to the queue to be executed, and execute the task in the priority processing status first; wherein, the priority processing status includes: waiting for time-consuming operations such as asynchronous IO.

[0034] Furthermore, before determining whether there is an idle thread, the method further includes:

[0035] Receive a network request, package the network request into a task to be executed, and put the task to be executed into a queue to be executed;

[0036] Poll the task status in the pending queue. After running the task whose status is pending, it also includes:

[0037] When calling the task execution thread to run the waiting task, if there is a node that needs to perform an asynchronous operation, the task execution thread first performs the asynchronous operation, and updates the task status of the waiting task to waiting and puts it in the waiting queue; when the asynchronous operation is completed, the task status is synchronously updated to pending execution, and the task is moved from the waiting queue to the pending execution queue, waiting to be executed when there is an idle thread.

[0038] Further, the calling execution task thread to run the task waiting to be run includes:

[0039] When calling the execution task thread to run the waiting task, if there is an exception, the three-level exception protection mechanism is used to handle the exception, including:

[0040] When calling the task execution thread to execute the task waiting to be executed, if there is an abnormal situation, the abnormal situation is handled through the secondary abnormal pipeline in the task execution thread;

[0041] If an abnormal situation occurs during the processing of the abnormal situation by the secondary abnormal pipeline, the currently executed task is marked as an error state;

[0042] Tasks marked as error status are processed through the exception pipeline.

[0043] The second aspect of the present invention also provides a processing system for a high-performance gateway system based on Netty, comprising:

[0044] The task receiving module is used to receive the connection request sent by the client, establish a data transmission channel and call the NettyServer processor to process the connection request, obtain the data channel and request data, and package the data channel and request data into a task and put it into the queue to be executed;

[0045] The task execution module is used to poll the task status in the queue to be executed and run the tasks whose status is to be executed.

[0046] Furthermore, the processing system of the high-performance gateway system based on Netty further includes:

[0047] The thread polling module is used to determine whether there is an idle thread; if so, the task to be executed is put into the idle thread for execution.

[0048] Furthermore, the processing system of the high-performance gateway system based on Netty further includes:

[0049] The priority processing module is used to poll the task status in the waiting queue. If there is a task in the priority processing status, the task in the priority processing status is placed from the waiting queue to the queue to be executed, and the task in the priority processing status is executed first; wherein, the priority processing status includes: waiting for time-consuming operations such as asynchronous IO.

[0050] Furthermore, the processing system of the high-performance gateway system based on Netty further includes:

[0051] A network request module, used for receiving a network request, packaging the network request into a task to be executed, and placing the task to be executed into a queue to be executed;

[0052] The asynchronous operation module is used to call the task execution thread to run the waiting task. If there is a node that needs to perform an asynchronous operation, the task execution thread first performs the asynchronous operation, and updates the task status of the waiting task to waiting and puts it in the waiting queue; when the asynchronous operation is completed, the task status is synchronously updated to pending execution, and the task is moved from the waiting queue to the pending execution queue, waiting to be executed when there is an idle thread.

[0053] Furthermore, the asynchronous operation module is also used for:

[0054] When calling the execution task thread to run the waiting task, if there is an exception, the three-level exception protection mechanism is used to handle the exception, including:

[0055] When calling the task execution thread to execute the task waiting to be executed, if there is an abnormal situation, the abnormal situation is handled through the secondary abnormal pipeline in the task execution thread;

[0056] If an abnormal situation occurs during the processing of the abnormal situation by the secondary abnormal pipeline, the currently executed task is marked as an error state;

[0057] Tasks marked as error status are processed through the exception pipeline.

[0058] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0059] The present invention provides a processing method and system for a high-performance gateway system based on Netty, wherein the method comprises: receiving a connection request sent by a client, establishing a data transmission channel and calling a Netty Server processor to process the connection request, obtaining a data channel and request data, and packaging the data channel and request data into a task and putting it into a queue to be executed; polling the task status in the queue to be executed, and running the task whose task status is to be executed. The present invention adopts a fully asynchronous multi-task processing model. When a time-consuming operation such as IO is encountered during task execution, an asynchronous waiting method is adopted so that the working thread will not be blocked during the waiting process for the time-consuming operation, and the working thread can execute other tasks. The configuration information is dynamically loaded by adopting a three-level cache lazy loading strategy, and the configuration can be modified at any time and take effect at any time. The configuration information is loaded when needed, and the configuration does not need to be loaded when the system is started, which reduces the risk when the system is started, and allows the system to focus on executing busy tasks. The local cache in the three-level cache can well meet the principle of locality of the program and re-use the system performance. The Pipeline-Filter task processing mode is adopted, and the linear execution process is more in line with the developer's thinking habits, and the developer only needs to develop different Filters and then use Pipeline to combine the Filters to realize business functions, which reduces the difficulty of development. The three-level exception protection mechanism provides a better experience for the requester. There will be no timeout or no return due to exceptions. In addition, the exception protection mechanism ensures the stability of the system, and exceptions sent by individual tasks will not affect other tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] In order to more clearly illustrate the technical solution of the present invention, the drawings required for use in the implementation mode will be briefly introduced below. Obviously, the drawings described below are only some implementation modes of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0061] Figure 1 It is a flowchart of a processing method of a high-performance gateway system based on Netty provided by a certain embodiment of the present invention;

[0062] Figure 2 is a flowchart of a processing method of a high-performance gateway system based on Netty provided by another embodiment of the present invention;

[0063] Figure 3 is a flowchart of a processing method of a high-performance gateway system based on Netty provided by another embodiment of the present invention;

[0064] Figure 4 is a flowchart of a processing method of a high-performance gateway system based on Netty provided by another embodiment of the present invention;

[0065] Figure 5 It is a flowchart of a processing method of a high-performance gateway system based on Netty provided by another embodiment of the present invention;

[0066] Figure 6 is a schematic diagram of a fully asynchronous gateway mode provided by an embodiment of the present invention;

[0067] Figure 7 is a schematic diagram of multi-task switching provided by an embodiment of the present invention;

[0068] Figure 8 is a schematic diagram of a gateway working model provided by an embodiment of the present invention;

[0069] Fig. 9 is a schematic diagram of a single task processing provided by an embodiment of the present invention;

[0070] Fig.10 is a schematic diagram of a multi-level cache provided by an embodiment of the present invention;

[0071] Fig.11 is a flowchart of a multi-level cache provided by another embodiment of the present invention;

[0072] Fig.12 is a flowchart of a multi-level cache provided by another embodiment of the present invention;

[0073] Fig.13 It is a device diagram of a processing system of a high-performance gateway system based on Netty provided by a certain embodiment of the present invention;

[0074] Fig.14 is a device diagram of a processing system of a high-performance gateway system based on Netty provided by another embodiment of the present invention;

[0075] Fig.15 is a device diagram of a processing system of a high-performance gateway system based on Netty provided by another embodiment of the present invention;

[0076] Fig.16 is a device diagram of a processing system of a high-performance gateway system based on Netty provided by another embodiment of the present invention;

[0077] Fig.17 It is a structural diagram of an electronic device provided by a certain embodiment of the present invention. DETAILED DESCRIPTION

[0078] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0079] It should be understood that the step numbers used in this document are only for convenience of description and are not intended to limit the order in which the steps are executed.

[0080] It should be understood that the terms used in the present specification are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the present specification and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0081] The terms “include” and “comprising” indicate the presence of described features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0082] The term "and / or" means and includes any and all possible combinations of one or more of the associated listed items.

[0083] The first aspect.

[0084] See also Figure 1 An embodiment of the present invention provides a processing method for a high-performance gateway system based on Netty, comprising:

[0085] S10, receiving a connection request sent by a client, establishing a data transmission channel and calling a Netty Server processor to process the connection request, obtaining a data channel and request data, and packaging the data channel and request data into a task and putting them into a queue to be executed.

[0086] S30, polling the task status in the queue to be executed, and running the tasks whose task status is to be executed.

[0087] See also Figure 2 In a specific implementation manner, before step S30, the step further includes:

[0088] S20, determining whether there is an idle thread; if so, placing the task to be executed into the idle thread for execution.

[0089] See also Figure 3 In another specific embodiment, after step S20, the method further includes:

[0090] S21. Poll the task status in the waiting queue. If there is a task in the priority processing status, put the task in the priority processing status from the waiting queue to the queue to be executed, and give priority to the task in the priority processing status; wherein, the priority processing status includes: waiting for time-consuming operations such as asynchronous IO.

[0091] See also Figure 4 In another specific implementation, before step S20, the method further includes:

[0092] S11 receives a network request, packages the network request into a task to be executed, and puts the task to be executed into a queue to be executed.

[0093] After step S20, the method further includes:

[0094] S40. When calling the task execution thread to run the task waiting to be run, if there is a node that needs to perform an asynchronous operation, the task execution thread first performs the asynchronous operation, and updates the task status of the waiting task to waiting and puts it in the waiting queue; when the asynchronous operation is completed, the task status is synchronously updated to pending execution, and the task is moved from the waiting queue to the pending execution queue, waiting to be executed when there is an idle thread.

[0095] In another specific implementation, after step S40, the method further includes:

[0096] S50: When calling the task execution thread to execute the task waiting to be executed, if an abnormal situation occurs, the abnormal situation is handled through a three-level abnormality protection mechanism.

[0097] Specifically, the step S50 includes:

[0098] S51. When calling the task execution thread to execute the task waiting to be executed, if an abnormal situation occurs, the abnormal situation is processed through the secondary abnormal pipeline in the task execution thread.

[0099] S52: If an abnormal situation occurs during the processing of the abnormal situation by the secondary abnormal pipeline, the currently executed task is marked as an error state.

[0100] S53. Process the task marked as an error state through the exception pipeline.

[0101] An embodiment of the present invention provides a processing method for a high-performance gateway system based on Netty, including:

[0102] 1. Based on Netty technology, a fully asynchronous gateway is implemented.

[0103] See also Figure 6, separate the I / O thread and the business processing thread, so that time-consuming call requests no longer occupy the I / O thread, thereby improving throughput performance. The I / O thread and business processing thread that call the backend business system use asynchronous queue events to put the request directly into the queue. When the event occurs, the callback function is triggered for processing, which supports receiving more requests while reducing the number of threads, thereby reducing the thread context switching overhead, and basically no multi-thread blocking problem.

[0104] In the fully asynchronous gateway mode, the number of threads is no longer a bottleneck for the gateway system, and slow APIs will not cause instability in the gateway system. Combined with thread pool technology, the impact can be effectively isolated.

[0105] in, Figure 6 Explanation of Chinese terms:

[0106]

[0107] Figure 6 Chart analysis:

[0108] First, when the server-side Acceptor receives a connection request from the client, it takes a thread from the reaction thread pool, establishes a data transmission channel and calls the Netty Server processor to process the connection request.

[0109] The Netty Server processor first processes the message sent by the client, and then calls the Netty Client processor through the NettyClient scheduler to send the processed message to other application systems.

[0110] 2. Multi-task switching.

[0111] See also Figure 7 In order to ensure that the gateway's fully asynchronous task processing does not cause thread blocking, the following poller is used in conjunction with the high-performance queue Disruptor to complete the multi-task switching process. When some tasks are blocked due to time-consuming operations such as IO, the thread is immediately released to process other tasks, and the thread resources are continued to be occupied to process tasks after the time-consuming operation is completed.

[0112] Figure 7 Terminology explanation:

[0113]

[0114]

[0115] Figure 7 Process explanation:

[0116] 1) When a network request arrives at the gateway, it is processed by the Netty Server processor to obtain a data channel Channel and request data Message. Then the processor generates a Task task, puts the Channel, Message and the Pipeline name that processes the task into the task, and then puts the task into the TaskQueue.

[0117] 2) EventLooper polls the TaskQueue to see if there is a task in the STANDBY state. If so, it pushes the task to TaskWorker for execution.

[0118] 3) When TaskWorker executes a task, it may be waiting for IO events or being limited. When encountering these situations, set the task status to WAITING, record the current execution location, put the task into TaskQueue, and then release the worker thread.

[0119] 4) Worker threads perform other tasks.

[0120] 5) When the thread executes to the EndPoint node, it needs to forward the network IO message to other application systems as a client. At this time, the Task is placed in the IOWorker for processing by Netty, the task status is set to WAITING, the current execution position is recorded, the task is placed in the TaskQueue to wait for the Netty execution result, and then the worker thread is released.

[0121] 6) Worker threads perform other tasks.

[0122] 7) Loop through the process 2)-6). When the conditions for the task to wait in step 3) and step 5) are met or NettyClient gets a response from the backend system, set the task status to STANDBY and wait for the poller in step 2) to push the task to the worker thread for execution.

[0123] 3. Gateway working model.

[0124] To better understand the above multi-task switching process, please refer to the following gateway working model diagram.

[0125] When the gateway receives network requests of different protocols (Socket, Http, etc.), it packages these requests into tasks and puts them in TaskQueue. TaskWorker obtains tasks from TaskQueue and calls the corresponding Pipeline to process different tasks.

[0126] If a node TaskNode in Pipeline needs to execute an asynchronous process, it will be divided into two Action processes. The first Action executes the asynchronous operation, and the second Action is executed after obtaining the response result of the asynchronous operation. After the first Action is executed, the task status is set to WAITING, the current execution position is recorded, the task is placed in the TaskQueue, and then the worker thread is released (as shown by the Async arrow in the figure). When the asynchronous result is obtained and pushed to the worker thread by the poller for execution, execution starts from the second Action. Figure 8 shown.

[0127] 4. Single-task processing.

[0128] like Fig. 9 The gateway processes a single task through the pipeline, encapsulating single functions such as parameter verification, security authentication, blacklist and whitelist, current limiting control, message conversion, message encryption and decryption, and message conversion into a filter. It can be organized in the configuration order according to different industry standards or partner access requirements, and supports hot plugging of filter functions. When trading, according to different partners connected, the corresponding pipeline is obtained from the pipeline pool, and then the pipeline uses different filters to filter the transaction according to the needs of the function.

[0129] The TaskWorker that executes the task calls the Pipeline to execute different tasks, and executes a single TaskNode function node in the Task task through the Filter. For example, the first Filter performs parameter verification, the second Filter performs security authentication, and the third Filter performs current limiting control, etc.

[0130] Most of the basic functions of the API gateway can be implemented through Filter, such as current limiting control, access control, encryption and decryption, logging, exception handling, traffic interception, field mapping, message parsing, dynamic routing and other functions.

[0131] These Pipelines and Filters are reusable, so for repeated functional requirements, the same Pipeline and Filter can be reused to avoid developing duplicate functional code blocks.

[0132] 5. Pipeline exception handling model.

[0133] The above Pipeline function is the processing flow of normal execution of Task, but abnormal situations are inevitable. In order to maintain the stability of the system, the exception must be handled. The present invention adopts a three-level exception protection mechanism to handle exceptions. Each Pipeline has a corresponding secondary exception pipeline (ExceptionPipeline). Multiple Pipelines can reuse the same ExceptionPipeline. When the expected error is sent in the Filter, the worker thread will set the Task state to the ERROR state and put it into the TaskQueue. When the poller polls the abnormal task, the exception pipeline set during the Pipeline initialization is called to execute the corresponding task. The third-level exception is the DefaultExceptionPipeline. When an exception occurs during the execution of the exception pipeline, it enters the DefaultExceptionPipeline. The DefaultExceptionPipeline performs an exception protection and returns an http message with a status code of 500 to the requester. The three-level exception protection mechanism ensures the stable operation of the server, and the tasks are isolated from each other and do not affect each other. Sending an exception to a task will not affect the execution of other tasks.

[0134] 6. Multi-level caching

[0135] like Fig.10 In order to improve the throughput performance of the gateway, the financial open platform uses a three-level cache mode to avoid the gateway from directly interacting with the database and consuming performance.

[0136] like Fig.10 As shown in the figure, the three-level cache mode is divided into: first-level local cache, second-level Redis cache center cache, and third-level database persistent storage. The local cache mainly stores frequently used configurations or configurations loaded during system initialization; the Redis cache center stores the full database configuration information for use by other application servers; the database stores persistent data, and only the capability center can access the database. Other application servers cannot connect to the database directly, and can only obtain database data by calling the capability center interface or from the Redis cache center.

[0137] When a configuration is added, modified, or deleted, the database record is updated first, then the Redis cache center data is updated, and the gateway reads the data from Redis.

[0138] When the gateway requests configuration information, it first queries the local cache, and then queries the Redis cache center. If the Redis cache center has no data, it asynchronously calls the capability center interface. After the capability center queries the configuration information in the database, it first stores the configuration information in Redis, and then returns the configuration information to the gateway. Fig.11 As shown:

[0139] The local cache uses a high-performance queue Disruptor to manage local cache events and two local Java data structures to manage cache data: a LinkedHashMap object cacheStandby and a HashMap object cache. cacheStandby is mainly used to implement the lru first-in-first-out cache strategy, and cache maintains the current local cache data. The local cache query and update logic is as follows:

[0140] 1) If local cache is not used, query Redis directly;

[0141] 2) If the cache does not exist or has expired (current time - cache update time > cache expiration time), get the data from Redis;

[0142] 3) If condition 2) is not met, get the data from the local cache;

[0143] 4) Regardless of which condition in step 2) or step 3) is met, the local cache needs to be updated;

[0144] 5) If the record does not exist in the local cache, the record is stored in the cacheStandby linked list head and the record is stored in the cache;

[0145] 6) If there is a record in the local cache, but the new and old values ​​are inconsistent, the cache is updated with the new value, the old value in cacheStandby is deleted, and then the new value is inserted at the head of the linked list to update the record in the cache;

[0146] 7) If there is a record in the local cache and the new and old values ​​are consistent, the old node in the cacheStandby linked list is moved to the head of the linked list, and the cache does not process it.

[0147] 8) If the data in cacheStandby exceeds the maximum limit, delete the tail node of the linked list and delete the record in the cache synchronously.

[0148] 9) Every 1024 milliseconds, resynchronize the data in cacheStandby to the cache.

[0149] The beneficial effects of the present invention are:

[0150] 1. Fully asynchronous task processing model for multi-task switching. The prior art adopts a service degradation / fuse mechanism, introduces Netflix's Hystrix mechanism, and implements multi-threaded task processing functions through a resource isolation mechanism. For blocked tasks, a fast failure and no queuing strategy are adopted to provide a failure fallback function. The present invention adopts a fully asynchronous task processing model based on Netty's self-developed model. When a task is blocked, it waits, does not occupy the system thread during the waiting period, and returns an error message after a timeout.

[0151] 2. The three-level cache lazy loading mode gives full play to the system performance. The existing technology uses the registration center and local files to save configuration information, and initializes the configuration information when the system starts. The present invention uses the three-level cache strategy and the configuration center mode to save configuration information. Only when necessary, the configuration is obtained from the Redis cache center and saved to the local cache.

[0152] 3. Local cache strategy, making full use of the principle of program locality to improve system efficiency. The present invention designs the local cache strategy with reference to the CPU three-level cache function in the computer architecture.

[0153] 4. Pipeline-Filter mode task processing. The prior art adopts the Filter-PRPE mechanism to load the configuration at startup. Each Filter has two methods, doPre and doPost. First, doPre is called forward, and then doPost is called reversely to implement the two-way mechanism of Filter. The present invention adopts the Pipeline-Filter mode. Each task corresponds to a Pipeline. The configuration information is loaded from the cache at runtime, and a unidirectional linear execution mode is used.

[0154] 5. Three-level exception protection mechanism. Using the protection mechanism ensures that no abnormal situation will be missed, giving the requester a better experience. There will be no timeout or no return due to an exception. In addition, the protection mechanism ensures the stability of the system, and the exception sent by individual tasks will not affect other tasks.

[0155] The second aspect.

[0156] See also Figure 13-16 An embodiment of the present invention provides a processing system for a high-performance gateway system based on Netty, including:

[0157] The task receiving module 10 is used to receive a connection request sent by a client, establish a data transmission channel and call the Netty Server processor to process the connection request, obtain a data channel and request data, and package the data channel and request data into a task and put it into a queue to be executed.

[0158] The task execution module 30 is used to poll the task status in the to-be-executed queue and run the tasks whose task status is to-be-executed.

[0159] In a specific embodiment, it also includes:

[0160] The thread polling module 20 is used to determine whether there is an idle thread; if so, the task to be executed is put into the idle thread for execution.

[0161] In another specific embodiment, it also includes:

[0162] The priority processing module 40 is used to poll the task status in the waiting queue. If there is a task in the priority processing status, the task in the priority processing status is put from the waiting queue to the queue to be executed, and the task in the priority processing status is executed preferentially; wherein, the priority processing status includes: waiting for time-consuming operations such as asynchronous IO.

[0163] In another specific embodiment, it also includes:

[0164] The network request module 50 is used to receive a network request, package the network request into a task to be executed, and put the task to be executed into a queue to be executed.

[0165] The asynchronous operation module 60 is used to call the task execution thread to run the task waiting to be run. If there is a node that needs to perform an asynchronous operation, the task execution thread first performs the asynchronous operation, and updates the task status of the waiting task to waiting and puts it in the waiting queue; when the asynchronous operation is completed, the task status is synchronously updated to pending execution, and the task is moved from the waiting queue to the pending execution queue, waiting to be executed when there is an idle thread.

[0166] In another specific implementation, the asynchronous operation module 60 is further used to:

[0167] When calling the execution task thread to run the waiting task, if there is an exception, the three-level exception protection mechanism is used to handle the exception, including:

[0168] When calling the task execution thread to execute the task waiting to be executed, if there is an abnormal situation, the abnormal situation is handled through the secondary abnormal pipeline in the task execution thread;

[0169] If an abnormal situation occurs during the processing of the abnormal situation by the secondary abnormal pipeline, the currently executed task is marked as an error state;

[0170] Tasks marked as error status are processed through the exception pipeline.

[0171] The third aspect.

[0172] The present invention provides an electronic device, the electronic device comprising:

[0173] processor, memory, and bus;

[0174] The bus is used to connect the processor and the memory;

[0175] The memory is used to store operation instructions;

[0176] The processor is used to call the operation instruction, and the executable instruction enables the processor to perform an operation corresponding to the processing method of a high-performance gateway system based on Netty as shown in the first aspect of the present application.

[0177] In an alternative embodiment, an electronic device is provided, such as Fig.17 As shown, Fig.17 The electronic device 5000 shown includes: a processor 5001 and a memory 5003. The processor 5001 and the memory 5003 are connected, such as through a bus 5002. Optionally, the electronic device 5000 may also include a transceiver 5004. It should be noted that in actual applications, the transceiver 5004 is not limited to one, and the structure of the electronic device 5000 does not constitute a limitation on the embodiments of the present application.

[0178] Processor 5001 may be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, a transistor logic device, a hardware component or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. Processor 5001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0179] The bus 5002 may include a path to transmit information between the above components. The bus 5002 may be a PCI bus or an EISA bus, etc. The bus 5002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.17 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0180] The memory 5003 may be a ROM or other type of static storage device that can store static information and instructions, a RAM or other type of dynamic storage device that can store information and instructions, or an EEPROM, a CD-ROM or other optical disk storage, an optical disk storage (including a compressed optical disk, a laser disk, an optical disk, a digital versatile disk, a Blu-ray disk, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

[0181] The memory 5003 is used to store application code for executing the solution of the present application, and the execution is controlled by the processor 5001. The processor 5001 is used to execute the application code stored in the memory 5003 to implement the content shown in any of the above method embodiments.

[0182] Among them, electronic devices include but are not limited to: mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc.

[0183] The fourth aspect.

[0184] The present invention provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, a processing method for a high-performance gateway system based on Netty as shown in the first aspect of the present application is implemented.

[0185] Another embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer-readable storage medium is run on a computer, the computer can execute the corresponding content in the aforementioned method embodiment.

Claims

1. A processing method for a high-performance gateway system based on Netty, characterized in that: include: Receive the connection request sent by the client, establish a data transmission channel and call the Netty Server processor to process the connection request, obtain the data channel and request data, and package the data channel and request data into a task and put it into the queue to be executed; Receive a network request, package the network request into a task to be executed, and put the task to be executed into a queue to be executed; Poll the task status in the queue to be executed, and run the tasks whose status is to be executed; When calling the task execution thread to run the waiting task, if there is a node that needs to perform an asynchronous operation, the task execution thread first performs the asynchronous operation, and updates the task status of the waiting task to waiting and puts it in the waiting queue; when the asynchronous operation is completed, the task status is synchronously updated to pending, and the task is moved from the waiting queue to the pending queue, waiting to be executed when there is an idle thread; When calling the task execution thread to execute the task waiting to be executed, if there is an abnormal situation, the abnormal situation is handled through the secondary abnormal pipeline in the task execution thread; If an abnormal situation occurs during the processing of the abnormal situation by the secondary abnormal pipeline, the currently executed task is marked as an error state; Process tasks marked as error status through the exception pipeline; Among them, when performing multi-task switching, the multi-task switching is completed according to the preset poller and Disruptor. When the task is blocked, it waits, and the system thread is not occupied during the waiting period. After the timeout, an error message is returned to ensure that the gateway's fully asynchronous task processing does not cause thread blocking; The cache mode of the high-performance gateway system is divided into: a first-level local cache that stores frequently used configurations or configurations loaded during system initialization, a second-level Redis cache center cache that stores the full database configuration information, and a third-level database persistent storage that stores persistent data; the first-level local cache uses Disruptor to manage local cache events and uses two local Java data structures to manage cache data; When the system configuration is added, modified, or deleted, the database record is updated first, and then the Redis cache center data is updated; When the gateway requests configuration information, it first queries the local cache and then the Redis cache center. If the Redis cache center has no data, the capability center interface is asynchronously called so that the capability center queries the database for configuration information, stores the configuration information in the Redis cache center, and returns the configuration information to the gateway.

2. A processing method for a high-performance gateway system based on Netty as claimed in claim 1, characterized in that: The polling of the task status in the to-be-executed queue, before running the task whose task status is to-be-executed, includes: Determine whether there is an idle thread; if so, put the task to be executed into the idle thread for execution.

3. A processing method for a high-performance gateway system based on Netty as claimed in claim 2, characterized in that: After determining whether there is an idle thread, the method further includes: Poll the task status in the waiting queue. If there is a task in the priority processing status, put the task in the priority processing status from the waiting queue to the queue to be executed, and execute the task in the priority processing status first; wherein the priority processing status includes: waiting for asynchronous IO operation.

4. A processing system for a high-performance gateway system based on Netty, characterized in that: include: The task receiving module is used to receive the connection request sent by the client, establish a data transmission channel and call the NettyServer processor to process the connection request, obtain the data channel and request data, and package the data channel and request data into a task and put it into the queue to be executed; A network request module, used for receiving a network request, packaging the network request into a task to be executed, and placing the task to be executed into a queue to be executed; The task execution module is used to poll the task status in the queue to be executed and run the tasks whose task status is to be executed; The asynchronous operation module is used to call the task execution thread to run the waiting task. If there is a node that needs to execute the asynchronous operation, the task execution thread first executes the asynchronous operation, and updates the task status of the waiting task to waiting and puts it in the waiting queue; when the asynchronous operation is completed, the task status is synchronously updated to pending, and the task is moved from the waiting queue to the pending queue, waiting to be executed when there is an idle thread; When calling the task execution thread to execute the task waiting to be executed, if there is an abnormal situation, the abnormal situation is handled through the secondary abnormal pipeline in the task execution thread; If an abnormal situation occurs during the processing of the abnormal situation by the secondary abnormal pipeline, the currently executed task is marked as an error state; the task marked as an error state is processed through the abnormal pipeline; Among them, when performing multi-task switching, the multi-task switching is completed according to the preset poller and Disruptor. When the task is blocked, it waits, and the system thread is not occupied during the waiting period. After the timeout, an error message is returned to ensure that the gateway's fully asynchronous task processing does not cause thread blocking; The cache mode of the high-performance gateway system is divided into: a first-level local cache that stores frequently used configurations or configurations loaded during system initialization, a second-level Redis cache center cache that stores the full database configuration information, and a third-level database persistent storage that stores persistent data; the first-level local cache uses Disruptor to manage local cache events and uses two local Java data structures to manage cache data; When the system configuration is added, modified, or deleted, the database record is updated first, and then the Redis cache center data is updated; When the gateway requests configuration information, it first queries the local cache and then the Redis cache center. If the Redis cache center has no data, the capability center interface is asynchronously called so that the capability center queries the database for configuration information, stores the configuration information in Redis, and returns the configuration information to the gateway.

5. A processing system for a high-performance gateway system based on Netty as claimed in claim 4, characterized in that: Also includes: Thread polling module, used to determine whether there are idle threads; If so, the task to be executed is put into the idle thread for execution.

6. A processing system for a high-performance gateway system based on Netty as claimed in claim 5, characterized in that: Also includes: The priority processing module is used to poll the task status in the waiting queue. If there is a task in the priority processing status, the task in the priority processing status is put from the waiting queue to the queue to be executed, and the task in the priority processing status is executed preferentially; wherein, the priority processing status includes: waiting for asynchronous IO operation.

Images