Software system scheduling method, electronic equipment, medium and product

Abstract

The invention discloses a software system scheduling method, electronic equipment, a medium and a product, and relates to the technical field of computers. When a client interacts with a server, a module deployed at the server automatically executes a software scheduling method, and the method comprises the steps of setting a risk level category of the client, and receiving or rejecting a request of the client with a preset risk level category. When the request of the client with the risk is rejected, the security of the software system is ensured; by refusing the request of the preset risk level category, occupied resources are reduced, and stable operation of a software system is ensured; the risk levels of the client are flexibly classified, so that the client can use a software system, and the user experience is improved; the client requests are screened and filtered, stable operation of a software system is guaranteed under the condition that system performance and system resources are not changed, and cost is reduced; the module is an independent module relative to the server, so that the module can be used across software systems, the relevance of products is reduced, and the reusability is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a software system scheduling method, an electronic device, a medium, and a product. Background Art

[0002] The core of a software system is to handle user requirements and business logic. With the development of Internet technology, more and more transactions are processed on software systems. Therefore, the stable operation and security of software systems are becoming increasingly important. To ensure the security of software systems, in related technologies, fixed white and black lists are manually set, and only users in the white list are allowed to access the software system. However, for software with a complex user group, only enabling the white list will cause a large number of blacklist users to be unable to log in, affecting the user experience when using the software system. To ensure the stability of the software system, in related technologies, resource usage thresholds are set. When the threshold is exceeded, the system will send an alarm to the administrator, and the administrator needs to change the system performance and system resources (such as capacity expansion) to ensure the normal operation of the system. However, since the administrator needs to change the system performance and system resources, it will increase the cost of software resource scheduling, and this solution completely depends on the administrator's handling. When the administrator fails to handle it in a timely manner, data loss will occur.

[0003] It can be seen that providing a new software system scheduling method to ensure the security and stability of software systems is a technical problem that needs to be urgently solved by those skilled in the art. Summary of the Invention

[0004] This application provides a software system scheduling method, an electronic device, a medium, and a product, to at least solve the problem in related technologies that fixed white and black lists are manually set, and only users in the white list are allowed to access the software system. However, for software with a complex user group, only enabling the white list will cause a large number of blacklist users to be unable to log in, affecting the user experience when using the software system, and the problem of setting resource usage thresholds. When the threshold is exceeded, since the administrator needs to change the system performance and system resources, it will increase the cost of software resource scheduling, and this solution completely depends on the administrator's handling. When the administrator fails to handle it in a timely manner, data loss will occur.

[0005] This application provides a software system scheduling method, which is applied to a module deployed on the server where the software system is located. The method includes:

[0006] Obtain the request status of the client and the current resource status of the server; wherein, the request status at least includes the request content and the request behavior;

[0007] Determine the risk level category of the client according to the request status;

[0008] Determine whether to accept or reject the request of the client for a preset risk level category according to the current resource status;

[0009] Send the request of the target client received to the server so that the server can respond to the request of the target client by using the resources of the software system;

[0010] Receive the response information sent by the server and send the response information to the target client.

[0011] This application also provides an electronic device, including: a memory for storing a computer program; a processor for implementing the steps of any of the above software system scheduling methods when executing the computer program.

[0012] This application also provides a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by a processor, the steps of any of the above software system scheduling methods are implemented.

[0013] This application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of any of the above software system scheduling methods are implemented.

[0014] The beneficial effects of the present application are as follows: First, the method is applied to a module deployed on the server where the software system is located. During the interaction between the client and the server of the software system, the software scheduling method is executed by this module, including setting the risk level category of the client, receiving or rejecting requests from clients with a preset risk level category. When rejecting requests from clients with risks, the security of the software system is ensured; by rejecting requests from clients with a preset risk level category, the resources occupied for processing requests are reduced, thus ensuring the stable operation of the software system. Compared with the way of manually ensuring the security and stable operation of the software system, in the present application, the security and stability of the software system are automatically ensured by the module deployed on the server where the software system is located, avoiding the occurrence of problems such as data loss caused by the administrator's failure to process in time; Second, when ensuring the security of the software system, the risk level category of the client is determined according to the request status in this method. Therefore, when the request status changes, the risk level category of the client will also change, that is, the risk level classification of the client is more flexible; and when a client that was previously a risky client becomes a non-risky client, the request of this client will also be accepted, improving the experience of the client when using the software system; Third, compared with the previous way of the administrator ensuring the stable operation of the software system by changing the system performance and system resources (such as capacity expansion), in this method, the request of the client with a preset risk level category is received or rejected according to the current resource status, that is, the client requests are screened and filtered, ensuring the stable operation of the software system without changing the system performance and system resources, and reducing costs; In addition, the module deployed on the server where the software system is located is an independent module relative to the server, so it can be used across software systems, reducing the product correlation and improving the reusability. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0016] Figure 1 It is a schematic diagram of an interaction scenario between a client and a server provided by an embodiment of the present application;

[0017] Figure 2 It is a flowchart of a software system scheduling method provided by an embodiment of the present application;

[0018] Figure 3 It is a flowchart of a software system self-scheduling method provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0019] The following will clearly and completely describe the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present application.

[0020] It should be noted that in the description of the present application, the terms "include", "comprise" or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article or device including a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects and not to describe a specific order or sequence.

[0021] In order to enable those skilled in the art of this technology to better understand the solution of the present application, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0022] Combined with the specific application environment architecture or specific hardware architecture on which the execution of the software system scheduling method depends, the specific application environment architecture or specific hardware architecture is described herein. Figure 1 It is a schematic diagram of an interaction scenario between a client and a server provided in an embodiment of the present application. As Figure 1 shown, a software system is deployed on the server, and a module is deployed on the software system. The module is provided with a dynamic list and dynamic rules. The module is used to implement the software system scheduling method. It should be noted that although the deployment method is that the module is embedded in the software system, in actual operation, the requests sent by the client are first received by the module, and then the module processes (filters and screens) the requests. After the module finishes processing, the remaining requests are sent to the server. The server calls the resources of the software system to respond to the requests. The response information is not directly transmitted from the server to the client, but the module receives the response information sent by the server and then transmits the response information to the client.

[0023] An embodiment of the present application provides a software system scheduling method. The method will be described in detail in combination with the execution process of the software system scheduling method. Figure 2 It is a flowchart of a software system scheduling method provided in an embodiment of the present application. As Figure 2 shown, the method includes:

[0024] S10: Obtain the request status of the client and the current resource status of the server;

[0025] S11: Determine the risk level category of the client according to the request status;

[0026] S12: Determine whether to accept or reject the request of a client of a preset risk level category according to the current resource status;

[0027] S13: Send the request of the target client received to the server so that the server can respond to the request of the target client by using the resources of the software system;

[0028] S14: Receive the response information sent by the server and send the response information to the target client.

[0029] There is no limitation on the client, which is determined according to the actual interaction requirements. The request of the client includes at least the request content and the request behavior. The request content is, for example, a request to upload data to the disk of the server; the request behavior is, for example, logging in 5 times in one minute, etc.

[0030] To ensure the security of the software system, the risk levels of the clients are classified. In the classification of the risk levels of the relevant clients, fixed white and black lists are set manually (the clients in the white list can access the software system, while the clients in the black list cannot access the software system). For software with a complex user group, only enabling the white list will cause a large number of blacklist users to be unable to log in, affecting the user experience when using the software system. Therefore, in this application, the risk level category of the client is determined according to the request status. Since the request status will change with the specific request, the risk level category of the client is also dynamically changing. A client that was previously a risky client becomes a non-risky client, and the request of this client will also be accepted, improving the user experience when the client uses the software system.

[0031] When the risk level classification of the client is inaccurate, some clients with a higher risk level will be misidentified as non-risky clients. If the request of this client is received, the security of the software system will be reduced. Therefore, to improve the accuracy of the determined risk level category of the client, in practice, the request status is the request behavior, and determining the risk level category of the client according to the request status includes:

[0032] Since detecting the client logging in to the software system, obtain the number of detected login errors within a preset duration, and / or the application frequency of the verification identifier during the login process;

[0033] Determine the risk level category of the client according to the number of detected login errors within a preset duration, and / or the application frequency of the verification identifier during the login process.

[0034] The preset duration is not limited and is determined according to the actual situation. Since the number of login errors and the application frequency of verification identifiers during the login process are both behaviors of client requests, the classification of the risk level of the client according to the client's request behavior in this method improves the accuracy of the classification of the risk level of the client.

[0035] When classifying the risk level of the client, if it is only divided into clients in the blacklist (i.e., clients with a higher risk level) and clients in the white list (i.e., clients with a lower risk level), for software with a complex user group, only enabling the white list will cause a large number of blacklist users to be unable to log in. Therefore, in this application, in order to reduce the number of clients in the blacklist, when determining the risk level category of the client according to the number of login errors detected within the preset duration and / or the application frequency of verification identifiers during the login process, it includes:

[0036] If the number of login errors detected within the preset duration and / or the application frequency of verification identifiers during the login process is less than the first preset frequency, then determine that the risk level category of the client is the first category;

[0037] If the number of login errors detected within the preset duration and / or the application frequency of verification identifiers during the login process is greater than or equal to the first preset frequency and less than the second preset frequency, then determine that the risk level category of the client is the second category; the first preset number is less than the second preset number;

[0038] If the number of login errors detected within the preset duration and / or the application frequency of verification identifiers during the login process is greater than or equal to the second preset frequency and less than the third preset frequency, then determine that the risk level category of the client is the third category; the second preset number is less than the third preset number.

[0039] The specific values of the first preset number, the second preset number, the third preset number, the first preset frequency, the second preset frequency, and the third preset frequency set are not limited, but the above relationships need to be satisfied. In this method, the risk level of the client is divided into three categories according to the number of login errors detected within the preset duration and / or the application frequency of verification identifiers during the login process. In practice, in order to classify the risk level of the client in more detail, the risk level of the client can be divided into more than three categories. In addition, compared with the previous method of only setting black and white lists, in this method, the risk level of the client is divided into three categories according to the number of login errors detected within the preset duration and / or the application frequency of verification identifiers during the login process, realizing a detailed classification of the risk level of the client; for software with a complex user group, when rejecting clients with a high risk level, the number of clients with a high risk level is reduced, improving the experience of most clients when using the software system.

[0040] The risk level category of the client is determined according to the request behavior as described above. In this embodiment, when the request status is the request content, the method for determining the risk level category of the client according to the request status is further described. Specifically, the method for determining the risk level category of the client according to the request status includes:

[0041] In the case where neither the first type of script nor the second type of script is carried in the request content, it is determined that the risk level category of the client is the first category; wherein, the first type of script is a script different from the target script and detected by the security protection system; the second type of script is a script intercepted by the security protection system;

[0042] In the case where the first type of script is carried in the request content, it is determined that the risk level category of the client is the second category;

[0043] In the case where the second type of script is carried in the request content, it is determined that the risk level category of the client is the third category.

[0044] There is no limitation on the target script. For example, the target script is a script about video. If the script carried in the request content is a script about text and the script about text is not intercepted by the security protection system (such as a firewall), that is, in the case where the first type of script is carried in the request content, it is determined that the risk level category of the client is the second category; if the script carried in the request content is a script intercepted by the security protection system, it is determined that the risk level category of the client is the third category; if the script carried in the request content is a script about video and is not intercepted by the security protection system, it is determined that the risk level category of the client is the first category. In this method, the risk level of the client is divided into three categories according to the request content, realizing a detailed classification of the risk level of the client; in software with a complex user group, when rejecting clients with a high risk level, the number of clients with a high risk level is reduced, improving the experience of most clients when using the software system.

[0045] After classifying the risk level of the client, in order to facilitate viewing the risk level categories of different clients, in practice, before determining the risk level category of the client according to the request status, it further includes:

[0046] Create a list for characterizing the risk level of the client; wherein, the list for characterizing the risk level of the client further includes clients of the fourth category; wherein, the clients of the fourth category are clients in the target list;

[0047] After determining the risk level category of the client according to the request status, it further includes:

[0048] If it is detected that the current client is a client in the target list, then the risk level category of the current client remains unchanged in the list used to represent the risk level of the client;

[0049] If it is detected that the current client is not a client in the target list, then update the list used to represent the risk level of the client according to the determined risk level category of the client.

[0050] The list used to represent the risk level of the client includes, in addition to the above-mentioned clients of the first category, clients of the second category, and clients of the third category, also clients of the fourth category; among them, the clients of the fourth category are clients in the target list. It should be noted that the target list here is determined according to the importance of the clients, and the important clients are used as the clients of the fourth category.

[0051] For example, place the clients of the first category in the white list, place the clients of the second category in the gray list, place the clients of the third category in the black list, and place the clients of the fourth category in the blue list.

[0052] If it is detected that the current client is not a client in the target list, then update the list used to represent the risk level of the client according to the determined risk level category of the client.

[0053] In this method, placing the risk level categories of different clients in different lists facilitates users to view the list and find the corresponding risk level category of the client; and updating the list used to represent the risk level of the client according to the determined risk level category of the client improves the accuracy of the list used to represent the risk level of the client.

[0054] In implementation, updating the list used to represent the risk level of the client according to the determined risk level category of the client includes at least one of the following methods:

[0055] Method 1: Update the list used to represent the risk level of the client according to the determined risk level category of the client in the module;

[0056] Method 2: Send a prompt message for updating the list used to represent the risk level of the client to the management end, so that the management end can update the list used to represent the risk level of the client according to the determined risk level category of the client;

[0057] After updating the list used to represent the risk level of the client according to the determined risk level category of the client, it further includes:

[0058] Send to the management end to represent the correctness of the list for characterizing the risk level of the client; so that the management end can update the list for characterizing the risk level of the client in case of detecting an error in the list for characterizing the risk level of the client.

[0059] When updating the list for characterizing the risk level of the client, the way of updating the list can be made more flexible by means of automatic update or manual update by the management end; and after automatic update, manual error correction by the management end ensures the accuracy of the list.

[0060] To facilitate those skilled in the art to better understand the list creation process of the present application, the process of establishing and dynamically maintaining the white, blue, gray, and black lists will be described again below in combination with specific embodiments.

[0061] Classification is as follows: White list: Safe clients. Blue list: Important clients. Gray list: Clients with minor security risks. Black list: Clients with major security risks.

[0062] Read the white list of the system and add it to the white list; read the important clients of the system and add them to the blue list; dynamically analyze the client requests for dynamic maintenance of the gray and black lists. The rules are as follows:

[0063] 1. For a small number of incorrect logins in a short period of time, or too fast or frequent incorrect identification of the verification code, add the corresponding client to the gray list;

[0064] 2. For a large number of incorrect logins in a short period of time, or too fast or frequent incorrect identification of the verification code, add the corresponding client to the black list;

[0065] 3. If the client uploads an unknown and unclear script, add it to the gray list;

[0066] 4. If the client uploads an attack script, add it to the black list.

[0067] The risk level categories of the client points are determined above. Further, to ensure the security and stability of the software system, determining to receive or reject the requests of clients of a preset risk level category according to the current resource status includes:

[0068] Select a target processing rule from the pre-established processing rules according to the current resource status; where the processing rule is a rule for representing receiving or rejecting the requests of clients of a preset risk level category;

[0069] Receive or reject the requests of clients of a preset risk level category according to the target processing rule.

[0070] In this method, by setting processing rules in advance, after obtaining the current resource status, the target processing rule can be selected from the pre-set processing rules, which improves the processing efficiency of client requests.

[0071] Specifically, the resource status at least includes resource utilization rate, number of ports in use, and / or disk space occupancy rate. Establishing processing rules includes:

[0072] Establishing a first processing rule according to the resource utilization rate;

[0073] Establishing a second processing rule according to the number of ports in use;

[0074] Establishing a third processing rule according to the disk space occupancy rate.

[0075] In this method, different processing rules are set according to different resource status categories, enabling the selection of appropriate processing rules according to the resource status to handle requests.

[0076] Specifically, establishing the first processing rule according to the resource utilization rate includes:

[0077] When it is detected that the resource utilization rate is less than or equal to the first utilization rate, requests from clients of the first category, requests from clients of the second category, and requests from clients of the fourth category are received, and requests from clients of the third category are rejected;

[0078] When it is detected that the resource utilization rate is greater than the first utilization rate and less than or equal to the second utilization rate, requests from clients of the first category and requests from clients of the fourth category are received, and requests from clients of the second category and requests from clients of the third category are rejected; where the first utilization rate is less than the second utilization rate.

[0079] There are no restrictions on the values of the first utilization rate and the second utilization rate, as long as it is ensured that the first utilization rate is less than the second utilization rate. The following is an example to illustrate the process of establishing the first processing rule according to the resource utilization rate in this application. When the monitoring system resource utilization rate (Central Processing Unit (CPU), memory) reaches 50%, requests from clients on the blacklist are rejected. When the monitoring system resource utilization rate (CPU, memory) reaches 80%, only requests from clients on the white and blue lists are received and forwarded to prevent problems such as system crashes or system outages.

[0080] In this method, different request processing rules are set for different resource utilization rates to monitor the running status of the system resources and filter them through dynamic rules to avoid serious problems such as system outages and service crashes.

[0081] Establishing the second processing rule according to the number of ports in use includes:

[0082] When it is detected that the number of ports in use is less than or equal to the first usage quantity, receive requests from clients of the first category, requests from clients of the second category, and requests from clients of the fourth category, and reject requests from clients of the third category;

[0083] When it is detected that the number of ports in use is greater than the first usage quantity and less than or equal to the second usage quantity, receive requests from clients of the first category and requests from clients of the fourth category, and reject requests from clients of the second category and requests from clients of the third category; wherein, the first usage quantity is less than the second usage quantity.

[0084] There are no restrictions on the first usage quantity and the second usage quantity, as long as it is ensured that the first usage quantity is less than the second usage quantity. The following is an example to illustrate the process of establishing the second processing rule according to the port usage quantity in this application. When it is monitored that the system ports are occupied too much, the rules will be updated automatically, and clients that request frequently within a short period will be rejected. For example, when the port occupancy rate reaches 20%, reject the requests of clients that request to establish connections continuously 5 times within 1 minute; when the port occupancy rate reaches 50%, reject the requests of clients that request to establish connections continuously 3 times within 1 minute (the requests of clients that request to establish connections continuously 5 times within 1 minute have been rejected when the port occupancy rate reaches 20%).

[0085] In this method, different request processing rules are set for different port usage quantities, the running status of system resources is monitored, and filtering is performed through dynamic rules to avoid serious problems such as system downtime and service crashes; it solves the load problem brought by malicious requests or risky requests to the software system server.

[0086] In implementation, establishing the third processing rule according to the disk space occupancy rate includes:

[0087] When it is detected that the disk space occupancy rate is less than or equal to the first space occupancy rate, receive requests from clients of the first category, requests from clients of the second category, and requests from clients of the fourth category, and reject requests from clients of the third category;

[0088] When it is detected that the disk space occupancy rate is greater than the first space occupancy rate and less than or equal to the second space occupancy rate, receive requests from clients of the first category and requests from clients of the fourth category, and reject requests from clients of the second category and requests from clients of the third category; wherein, the first space occupancy rate is less than the second space occupancy rate.

[0089] There are no restrictions on the values of the first space occupancy rate and the second space occupancy rate, as long as the first space occupancy rate is less than the second space occupancy rate. The following is an example to illustrate the process of establishing the third processing rule according to the disk space occupancy rate in this application. Read the disk usage of the system, analyze the client requests, and automatically update the rules. When the system disk space reaches 50%, this module refuses to forward the upload data requests from blacklisted customers to the server, so that blacklisted customers cannot upload data to the disk. When the system disk space reaches 60%, this module refuses to forward the upload data requests from graylisted customers to the server, so that blacklisted customers and graylisted customers cannot upload data to the disk.

[0090] In this method, different request processing rules are set for different disk space occupancy rates to monitor the running status of system resources and filter through dynamic rules to avoid serious problems such as system downtime and service crashes. Through system resource analysis, problems such as non-important customers filling up the system storage and important customers being unable to complete file uploads halfway are solved.

[0091] In addition, the establishment of the third processing rule according to the disk space occupancy rate can also be achieved in the following way:

[0092] Obtain the disk space occupied by the upload data of the fourth category of clients within the historical duration;

[0093] In the case where it is detected that the disk space occupancy rate is less than the disk space occupied by the upload data of the fourth category of clients within the historical duration, receive the requests of the first category of clients and the requests of the fourth category of clients, and reject the requests of the second category of clients and the requests of the third category of clients.

[0094] There are no restrictions on the historical duration. For example, the past three months can be used as the historical duration. When the storage of the disk space is less than the space used for the upload data of important customers in the past three months, only the clients in the white and blacklists can upload data, ensuring that important customers can continue their normal business processing for three months in case of emergency system resources.

[0095] In this method, by performing self-upload traffic analysis and system resource analysis, problems such as non-important customers filling up the system storage and important customers being unable to complete file uploads halfway are solved.

[0096] After determining to accept or reject the request of a client for a preset risk level category based on the current resource status, if the request of the client for the preset risk level category is accepted, the module will send the received request of the target client (here, the target client refers to the client whose request is accepted) to the server so that the server can respond to the request of the target client using the resources of the software system. The server sends the response information to the module. In implementation, due to objective requirements, the software system needs to display system information, key information, etc. on the front end. When the client behavior is in doubt, there is a risk of information leakage. To solve this risk, the default display method is usually adopted, that is, key information is hidden. Clients without risks cannot obtain valid information, resulting in a poor user experience. To solve this problem, sending the response information to the target client includes:

[0097] Obtain the risk level category of the target client;

[0098] If the risk level category of the target client is a client of the second category, hide the target information in the response information; send the response information after the hiding process to the target client;

[0099] If the risk level category of the target client is not a client of the second category, keep the response information unchanged and send the response information to the target client.

[0100] This method filters the request response returned by the server to the client. If the client is on the gray list, all system parameters and related information are filtered out to prevent the risk of information leakage.

[0101] To enable those skilled in the art to better understand the overall technical solution of this application, the following will continue to be described in conjunction with the accompanying drawings and specific embodiments. Figure 3 It is a flowchart of a software system self-scheduling method provided by an embodiment of this application. As Figure 3 shown, this method includes:

[0102] S20: Establishment and self-maintenance of a dynamic list;

[0103] S21: Establishment of dynamic rules;

[0104] S22: Receive a request from the client, perform request analysis, update the dynamic list, read system resources, filter through the dynamic rules, and process the client request;

[0105] S23: Filter the request response returned by the server to the client.

[0106] In step S21, read the running status of system resources (resources, port occupancy, disk usage) and analyze the client behavior status to create dynamic rules. This has been described in detail above and will not be elaborated here.

[0107] After receiving a client request, if it is detected that the request is a request to upload resources (using the disk), it is determined whether the client is from the blacklist. If so, the disk usage is detected. When the disk usage is less than the preset value (such as 30%), the request is allowed to be uploaded; otherwise, the request is rejected. In addition, if it is detected that the client is from the blue list, even if the disk usage reaches 50%, the request can still be uploaded to ensure that important customers can use it.

[0108] Through the software system self-scheduling method provided by this application, the following can be achieved:

[0109] 1. Realize dynamic management of clients through white, blue, gray, and blacklists, and solve the problem of inflexible management of a large number of clients.

[0110] 2. Receive requests from clients and decide whether to forward them to the server or reject them after filtering by dynamic rules, so as to solve the problem of load brought to the software system server by malicious requests or risk requests.

[0111] 3. Monitor the running status of system resources and filter them through dynamic rules to avoid serious problems such as system downtime and service crashes.

[0112] 4. Self-conduct upload traffic analysis and system resource analysis to solve the problems of non-important customers filling up the system storage and important customers being unable to upload files halfway.

[0113] 5. Filter the response from the server and forward it to the client, and perform response filtering according to rules (such as if the client is in the gray list, filter out all system parameters and related information) to solve the problem of key (core) information leakage.

[0114] 6. Under the action of dynamic lists and dynamic rules, without changing the system performance and system resources, the system can be made more robust and can provide more stable services for important customers;

[0115] 7. This module is an internal module and can be used across software systems, reducing product correlation and improving reusability, and reducing costs.

[0116] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0117] The embodiment of this application also provides a software system scheduling device, and this software system scheduling device includes:

[0118] A first acquisition module, configured to acquire the request status of a client and the current resource status of a server; wherein, the request status at least includes a request content and a request behavior.

[0119] A first determination module, configured to determine the risk level category of the client according to the request status.

[0120] A second determination module, configured to determine whether to accept or reject the request of a client with a preset risk level category according to the current resource status.

[0121] A first sending module, configured to send the request of a target client received to the server, so that the server uses the resources of the software system to respond to the request of the target client.

[0122] A receiving and sending module, configured to receive the response information sent by the server and send the response information to the target client.

[0123] In some embodiments, when the request status is a request behavior, the first determination module specifically includes:

[0124] A second acquisition module, configured to acquire the number of login errors detected within a preset duration and / or the application frequency of a verification identifier during the login process since it is detected that the client logs in to the software system.

[0125] A third determination module, configured to determine the risk level category of the client according to the number of login errors detected within a preset duration and / or the application frequency of a verification identifier during the login process.

[0126] In some embodiments, the third determination module specifically includes:

[0127] A first determination sub-module, configured to determine that the risk level category of the client is a first category if the number of login errors detected within a preset duration reaches a first preset number and / or the application frequency of a verification identifier during the login process is less than a first preset frequency.

[0128] A second determination sub-module, configured to determine that the risk level category of the client is a second category if the number of login errors detected within a preset duration reaches a second preset number and / or the application frequency of a verification identifier during the login process is greater than or equal to the first preset frequency and less than a second preset frequency; the first preset number is less than the second preset number.

[0129] A third determination sub-module, configured to determine that the risk level category of the client is a third category if the number of login errors detected within a preset duration reaches a third preset number and / or the application frequency of a verification identifier during the login process is greater than or equal to the second preset frequency and less than a third preset frequency; the second preset number is less than the third preset number.

[0130] In some embodiments, the request status is the request content, and the first determination module specifically includes:

[0131] A fourth determination module, configured to determine that the risk level category of the client is the first category when it is detected that the request content does not carry a script of the first type and a script of the second type; wherein, the script of the first type is a script different from the target script and detected by the security protection system; the script of the second type is a script intercepted by the security protection system;

[0132] A fifth determination module, configured to determine that the risk level category of the client is the second category when it is detected that the request content carries a script of the first type;

[0133] A sixth determination module, configured to determine that the risk level category of the client is the third category when it is detected that the request content carries a script of the second type.

[0134] In some embodiments, the software system scheduling device further includes:

[0135] A creation module, configured to create a list for characterizing the risk level of the client; wherein, the list for characterizing the risk level of the client further includes clients of the fourth category; wherein, the clients of the fourth category are clients in the target list;

[0136] A detection and maintenance module, configured to maintain the risk level category of the current client unchanged in the list for characterizing the risk level of the client if it is detected that the current client is a client in the target list;

[0137] A detection and update module, configured to update the list for characterizing the risk level of the client according to the determined risk level category of the client if it is detected that the current client is not a client in the target list.

[0138] In some embodiments, the second determination module specifically includes:

[0139] A selection module, configured to select a target processing rule from the pre-established processing rules according to the current resource status; wherein, the processing rule is a rule for characterizing receiving or rejecting requests from clients of a preset risk level category;

[0140] A processing module, configured to receive or reject requests from clients of a preset risk level category according to the target processing rule.

[0141] In some embodiments, the software system scheduling device further includes a establishment module, configured to establish rules.

[0142] The resource status at least includes resource utilization rate, number of ports in use, and / or disk space occupancy rate; the establishment module specifically includes:

[0143] The first sub - establishment module is used to establish the first processing rule according to the resource utilization rate;

[0144] The second sub - establishment module is used to establish the second processing rule according to the number of port usages;

[0145] The third sub - establishment module is used to establish the third processing rule according to the disk space occupancy rate.

[0146] In some embodiments, the first sub - establishment module specifically includes:

[0147] The first processing module is used to, when detecting that the resource utilization rate is less than or equal to the first utilization rate, receive requests from clients of the first category, clients of the second category, and clients of the fourth category, and reject requests from clients of the third category;

[0148] The second processing module is used to, when detecting that the resource utilization rate is greater than the first utilization rate and less than or equal to the second utilization rate, receive requests from clients of the first category and clients of the fourth category, and reject requests from clients of the second category and clients of the third category; wherein, the first utilization rate is less than the second utilization rate.

[0149] In some embodiments, the second sub - establishment module specifically includes:

[0150] The third processing module is used to, when detecting that the number of port usages is less than or equal to the first usage number, receive requests from clients of the first category, clients of the second category, and clients of the fourth category, and reject requests from clients of the third category;

[0151] The fourth processing module is used to, when detecting that the number of port usages is greater than the first usage number and less than or equal to the second usage number, receive requests from clients of the first category and clients of the fourth category, and reject requests from clients of the second category and clients of the third category; wherein, the first usage number is less than the second usage number.

[0152] In some embodiments, the third sub - establishment module specifically includes:

[0153] The fifth processing module is used to, when detecting that the disk space occupancy rate is less than or equal to the first space occupancy rate, receive requests from clients of the first category, clients of the second category, and clients of the fourth category, and reject requests from clients of the third category;

[0154] A sixth processing module, configured to, when it is detected that the disk space occupancy rate is greater than a first space occupancy rate and less than or equal to a second space occupancy rate, receive requests from clients of a first category and requests from clients of a fourth category, and reject requests from clients of a second category and requests from clients of a third category; wherein, the first space occupancy rate is less than the second space occupancy rate.

[0155] In some embodiments, the third sub - establishment module specifically includes:

[0156] A third acquisition module, configured to acquire the disk space occupied by the data uploaded by clients of a fourth category within a historical duration.

[0157] A seventh processing module, configured to, when it is detected that the disk space occupancy rate is less than the disk space occupied by the data uploaded by clients of a fourth category within a historical duration, receive requests from clients of a first category and requests from clients of a fourth category, and reject requests from clients of a second category and requests from clients of a third category.

[0158] In some embodiments, the sending module in the receiving and sending module specifically includes:

[0159] A fourth acquisition module, configured to acquire the risk - level category of a target client.

[0160] A hiding and sending module, configured to, if the risk - level category of the target client is a client of a second category, perform a hiding process on the target information in the response message; and send the response message after the hiding process to the target client.

[0161] A maintaining and sending module, configured to, if the risk - level category of the target client is not a client of a second category, keep the response message unchanged and send the response message to the target client.

[0162] For the description of the features in the corresponding embodiments of the software system scheduling device, reference can be made to the relevant description in the corresponding embodiments of the software system scheduling method, which will not be elaborated here one by one.

[0163] An embodiment of the present application further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the embodiments of the above - mentioned software system scheduling method.

[0164] An embodiment of the present application further provides a computer - readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any one of the embodiments of the above - mentioned software system scheduling method when running.

[0165] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: various media such as USB flash drives, read-only memory (ROM), random access memory (RAM), mobile hard disks, magnetic disks, or optical discs that can store computer programs.

[0166] The embodiments of the present application also provide a computer program product. The above computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above embodiments of the software system scheduling method.

[0167] The embodiments of the present application also provide another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above embodiments of the software system scheduling method.

[0168] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0169] The above has introduced in detail a software system scheduling method, an electronic device, a medium, and a product provided by the present application. Specific examples are used herein to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the present application.

Claims

1. A software system scheduling method, characterized in that: Applied to a module deployed on a server where a software system is located, the method comprises: Obtain the client's request status and the server's current resource status; wherein the request status at least includes the request content and the request behavior; Determine the risk level category of the client based on the request status; Determine whether to accept or reject requests from clients of preset risk level categories based on current resource status; Sending the received request of the target client to the server, so that the server responds to the request of the target client using the resources of the software system; Receive response information sent by the server and send the response information to the target client.

2. The software system scheduling method according to claim 1, characterized in that: The request status is a request behavior, and the risk level category of the client determined according to the request status includes: Since the detection of the client logging into the software system, the number of login errors detected within a preset time period and / or the frequency of application for verification identification during the login process are obtained; The risk level category of the client is determined based on the number of login errors detected within a preset time period and / or the frequency of application for verification identification during the login process.

3. The software system scheduling method according to claim 2, characterized in that: Determining the risk level category of the client according to the number of login errors detected within a preset time period and / or the frequency of applying for a verification identifier during the login process includes: If a first preset number of login errors are detected within the preset time period, and / or it is detected that the application frequency of the verification identifier during the login process is less than the first preset frequency, then the risk level category of the client is determined to be the first category; If a second preset number of login errors is detected within the preset time period, and / or the application frequency of the verification identifier during the login process is detected to be greater than or equal to the first preset frequency and less than the second preset frequency, it is determined that the risk level category of the client is the second category; and the first preset number of times is less than the second preset number of times; If a third preset number of login errors are detected within the preset time period, and / or the application frequency of the verification identifier during the login process is detected to be greater than or equal to the second preset frequency and less than the third preset frequency, then the risk level category of the client is determined to be the third category; the second preset number of times is less than the third preset number of times.

4. The software system scheduling method according to claim 1, characterized in that: The request status is the request content, and determining the risk level category of the client according to the request status includes: In the case where it is detected that the request content does not carry the first type of script and the second type of script, determining that the risk level category of the client is the first category; wherein the first type of script is a script different from the target script and is detected by the security protection system; and the second type of script is a script intercepted by the security protection system; In the case where it is detected that the request content carries a script of the first type, determining that the risk level category of the client is the second category; When it is detected that the request content carries the script of the second type, it is determined that the risk level category of the client is the third category.

5. The software system scheduling method according to claim 3 or 4, characterized in that: Before determining the risk level category of the client according to the request status, the method further includes: Creating a list for characterizing the risk levels of clients; wherein the list for characterizing the risk levels of clients also includes clients of a fourth category; wherein the clients of the fourth category are clients in the target list; After determining the risk level category of the client based on the request status, it also includes: If it is detected that the current client is a client in the target list, the risk level category of the current client is kept unchanged in the list used to characterize the risk level of the client; If it is detected that the current client is not a client in the target list, the list used to characterize the risk level of the client is updated according to the determined risk level category of the client.

6. The software system scheduling method according to claim 5, characterized in that: The determining of accepting or rejecting a request of a client of a preset risk level category according to the current resource status includes: Selecting a target processing rule from pre-established processing rules according to the current resource state; wherein the processing rule is a rule for characterizing the acceptance or rejection of a request from a client of a preset risk level category; Receive or reject requests from clients of preset risk level categories according to the target processing rules.

7. The software system scheduling method according to claim 6, characterized in that: The resource status at least includes resource usage, port usage quantity and / or disk space usage; the established processing rules include: Establishing a first processing rule according to resource utilization; Establish a second processing rule according to the number of port usage; A third processing rule is established according to the disk space occupancy rate.

8. The software system scheduling method according to claim 7, characterized in that: The establishing of the first processing rule according to the resource usage rate comprises: In the case where it is detected that the resource usage rate is less than or equal to the first usage rate, receiving requests from clients of the first category, requests from clients of the second category, and requests from clients of the fourth category, and rejecting requests from clients of the third category; When it is detected that the resource usage rate is greater than the first usage rate and less than or equal to the second usage rate, requests from clients of the first category and requests from clients of the fourth category are received, and requests from clients of the second category and requests from clients of the third category are rejected; wherein the first usage rate is less than the second usage rate.

9. The software system scheduling method according to claim 7, characterized in that: The second processing rule is established according to the number of ports used, including: In the case where it is detected that the number of used ports is less than or equal to the first number of used ports, receiving requests from clients of the first category, clients of the second category, and clients of the fourth category, and rejecting requests from clients of the third category; When it is detected that the port usage quantity is greater than the first usage quantity and less than or equal to the second usage quantity, requests from clients of the first category and requests from clients of the fourth category are received, and requests from clients of the second category and requests from clients of the third category are rejected; wherein the first usage quantity is less than the second usage quantity.

10. The software system scheduling method according to claim 7, characterized in that: The third processing rule established according to the disk space occupancy rate includes: In the case where it is detected that the disk space occupancy rate is less than or equal to the first space occupancy rate, receiving requests from clients of the first category, requests from clients of the second category, and requests from clients of the fourth category, and rejecting requests from clients of the third category; When it is detected that the disk space occupancy rate is greater than the first space occupancy rate and less than or equal to the second space occupancy rate, requests from clients of the first category and requests from clients of the fourth category are received, and requests from clients of the second category and requests from clients of the third category are rejected; wherein the first space occupancy rate is less than the second space occupancy rate.

11. The software system scheduling method according to claim 7, characterized in that: The third processing rule established according to the disk space occupancy rate includes: Get the disk space occupied by the fourth category of client uploaded data within the historical period; When it is detected that the disk space occupancy rate is less than the disk space occupied by the fourth category of clients uploading data within the historical period, requests from the first category of clients and requests from the fourth category of clients are received, and requests from the second category of clients and requests from the third category of clients are rejected.

12. The software system scheduling method according to claim 7, characterized in that: Sending the response information to the target client includes: Get the risk level category of the target client; If the risk level category of the target client is a client of the second category, hiding the target information in the response information; and sending the hidden response information to the target client; If the risk level category of the target client is not a client of the second category, the response information is kept unchanged and sent to the target client.

13. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, used to implement the steps of the software system scheduling method as claimed in any one of claims 1 to 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the software system scheduling method according to any one of claims 1 to 12.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the software system scheduling method according to any one of claims 1 to 12 are implemented.

Images