Service request access control method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a service request access control method and device, electronic equipment and a storage medium, belongs to the technical field of computers, and can be applied to financial and medical service systems. The method comprises the following steps: classifying original service requests according to a request timestamp, a request response state, a request response duration, a control rule category and a control parameter to obtain normal and abnormal service requests, and obtaining a normal request number of the normal service requests and an abnormal request number of the abnormal service requests; performing index evaluation according to the control parameters, the normal request quantity and the abnormal request quantity to obtain a request access index; and screening the control rule category according to the request access index to obtain a target rule category, generating a fusing operation or an alarm operation according to the target rule category and the target control parameter of the target rule category, and sending the fusing operation or the alarm operation to the second micro-service for access control, so that access control can be performed on the request of the micro-service. And the availability of the micro-service is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology and is applied to the fields of financial technology and digital medicine, and in particular to a method, device, electronic device and storage medium for access control of service requests. Background Art

[0002] To handle highly concurrent business requests, business systems typically employ distributed systems. Distributed systems are designed based on a microservices architecture, which divides the distributed system into multiple independent microservices, each responsible for a specific business function. To decouple the relationships between microservices and improve system scalability, multiple microservices often call each other. For example, in a fintech scenario, a banking system can be divided into an account management microservice and a transaction management microservice. The account management microservice is responsible for account creation, querying, updating, and deleting, while the transaction management microservice processes various transactions. During transactions such as transfers and payments, the transaction management microservice calls the account management microservice to obtain account information and verify account status. For example, in a digital healthcare scenario, a digital healthcare system can be divided into a physician management microservice and a medical record microservice. The physician management microservice manages and stores physician information, while the medical record microservice stores patient electronic medical records. During consultations, physicians access patients' electronic medical records, and the physician management microservice calls the medical record microservice to obtain these records. To ensure high availability of each microservice, access control is required for business requests to these microservices. Without an effective access control mechanism, business systems can easily become unavailable due to resource exhaustion, fault propagation, or performance bottlenecks. Summary of the Invention

[0003] The main purpose of the embodiments of the present application is to propose a method, device, electronic device and storage medium for access control of service requests, aiming to control access to microservice requests and improve the availability of business systems.

[0004] To achieve the above objectives, a first aspect of an embodiment of the present application proposes a method for controlling access to a service request, which is applied to a first microservice. The method for controlling access to a service request includes:

[0005] In response to the original business request sent by the second microservice, a service log is generated; wherein the service log includes the request timestamp, request response status, and request response duration of the original business request;

[0006] Acquire a request control rule from a pre-acquired control configuration file; wherein the request control rule includes a control rule category and a control parameter of the control rule category;

[0007] Classify the original service request according to the request timestamp, the request response status, the request response duration, the control rule category, and the control parameter to obtain normal service requests and abnormal service requests, and obtain the normal request quantity of the normal service requests and the abnormal request quantity of the abnormal service requests;

[0008] Performing an index evaluation based on the control parameter, the number of normal requests, and the number of abnormal requests to obtain a request access index;

[0009] Filtering the control rule category according to the requested access indicator to obtain a target rule category, and generating an access control policy according to the target rule category and a target control parameter of the target rule category; wherein the access control policy includes a fuse operation or an alarm operation;

[0010] The fuse operation or alarm operation is sent to the second microservice for access control.

[0011] In some embodiments, the control parameter includes a time window length, and the classifying the original service request according to the request timestamp, the request response status, the request response duration, the control rule category, and the control parameter to obtain normal service requests and abnormal service requests includes:

[0012] Filter the original service request according to the request timestamp and the time window length to obtain a candidate service request;

[0013] Filtering the request response status and the request response duration according to the control rule category to obtain a request classification parameter;

[0014] The candidate service requests are classified according to the request classification parameters to obtain the normal service requests and the abnormal service requests.

[0015] In some embodiments, the control rule category includes a circuit breaker rule, a current limiting rule, or an alarm rule, and filtering the request response status and the request response duration according to the control rule category to obtain the request classification parameter includes:

[0016] If the control rule category is the fuse rule or the alarm rule, the request response status is used as the request classification parameter;

[0017] If the control rule category is the current limiting rule, the request response time is used as the request classification parameter.

[0018] In some embodiments, the control parameter includes an index parameter, and performing an index evaluation based on the control parameter, the number of normal requests, and the number of abnormal requests to obtain a request access index includes:

[0019] Calculating the ratio between the number of abnormal requests and the preset number of requests to obtain a request abnormality rate; wherein the preset number of requests is the sum of the number of normal requests and the number of abnormal requests;

[0020] Calculate the ratio between the number of abnormal requests and the number of normal requests to obtain a request error rate;

[0021] The preset request number, the normal request number, the abnormal request number, the request abnormality rate and the request error rate are screened according to the indicator parameters to obtain the request access indicator.

[0022] In some embodiments, the control rule category includes a fuse rule or an alarm rule, and generating an access control policy according to the target rule category and a target control parameter of the target rule category includes:

[0023] If the target rule category is the fuse rule, extracting the silence duration from the target control parameter, and generating the fuse operation according to the silence duration;

[0024] If the target rule category is the alarm rule, extracting alarm parameters from the target control parameters, and generating the alarm operation according to the alarm parameters;

[0025] Generate the access control policy according to the fuse operation or the alarm operation.

[0026] In some embodiments, the original service request has the request timestamp, the request response status, and the request response duration, and generating a service log in response to the original service request sent by the second microservice includes:

[0027] In response to the original business request sent by the second microservice, convert the request timestamp, request response status, and request response duration of the original business request into a log format to obtain an original log;

[0028] Sampling the original logs according to a preset sampling rate to obtain candidate logs;

[0029] Storing the candidate logs in a message queue to obtain a target queue;

[0030] The candidate log is obtained from the target queue through a preset asynchronous thread to obtain the service log.

[0031] In some embodiments, sampling the original log according to a preset sampling rate to obtain a candidate log includes:

[0032] Storing the original log in a log queue and obtaining the queue length of the log queue;

[0033] Obtaining a log generation speed of the original log according to the queue length;

[0034] Adjusting the preset sampling rate according to the log generation speed to obtain a target sampling rate;

[0035] Log sampling is performed on the original log according to the target sampling rate to obtain the candidate log.

[0036] To achieve the above objectives, a second aspect of an embodiment of the present application provides an access control device for a service request, which is applied to a first microservice. The access control device for a service request includes:

[0037] A request acquisition module, configured to generate a service log in response to the original service request sent by the second microservice; wherein the service log includes the request timestamp, request response status, and request response duration of the original service request;

[0038] A rule acquisition module is used to acquire a request control rule from a pre-acquired control configuration file; wherein the request control rule includes a control rule category and control parameters of the control rule category;

[0039] a request classification module, configured to classify the original service request according to the request timestamp, the request response status, the request response duration, the control rule category, and the control parameter, to obtain normal service requests and abnormal service requests, and to obtain the number of normal requests for the normal service requests and the number of abnormal requests for the abnormal service requests;

[0040] a calculation module, configured to perform an index evaluation based on the control parameter, the number of normal requests, and the number of abnormal requests to obtain a request access index;

[0041] a screening module, configured to screen the control rule category according to the requested access indicator to obtain a target rule category, and generate an access control policy according to the target rule category and a target control parameter of the target rule category; wherein the access control policy includes a fuse operation or an alarm operation;

[0042] A sending module is used to send the fuse operation or the alarm operation to the second microservice for access control.

[0043] To achieve the above-mentioned purpose, the third aspect of an embodiment of the present application proposes an electronic device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor implements the method described in the first aspect when executing the computer program.

[0044] To achieve the above-mentioned purpose, the fourth aspect of the embodiments of the present application proposes a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the method described in the first aspect.

[0045] The access control method, access control device, electronic device, and computer-readable storage medium for service requests proposed in the embodiments of the present application generate a service log in response to an original service request sent by a second microservice, and perform log analysis on the service log to perform request access control on the service request. The service log includes the request timestamp, request response status, and request response duration of the original service request. The request timestamp, request response status, and request response duration can be used to identify whether the service request is abnormal, thereby implementing access control on the service request. Microservices receive various types of service requests at the same time. In order to implement access control for large-scale service requests, it is necessary to determine a unified request rule. Therefore, the request control rule is obtained from a pre-acquired control configuration file. The request control rule includes a control rule category and control parameters for the control rule category. When performing access control on the service request, it is necessary to determine whether the first microservice can respond to the service request accurately and promptly. In order to quantitatively evaluate the service performance of the first microservice, the original service request is classified according to the request timestamp, request response status, request response duration, control rule category, and control parameters to obtain normal service requests and abnormal service requests, and the number of normal requests for normal service requests and the number of abnormal requests for abnormal service requests are obtained. An indicator evaluation is performed based on control parameters, the number of normal requests, and the number of abnormal requests to obtain a request access indicator. This indicator is then used to quantify the first microservice's response performance to business requests. Different request access indicators trigger different control rules. To obtain the control rules for the first microservice, the control rule categories are filtered based on the request access indicators to obtain the target rule categories. An access control policy is then generated based on the target rule categories and their target control parameters. The access control policy includes either a circuit breaker or an alarm operation, which is sent to the second microservice for access control. This allows access control of business requests sent from the second microservice to the first microservice, ensuring the availability of the business system. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 This is a flowchart of a method for controlling access to service requests provided by an embodiment of the present application;

[0047] Figure 2 yes Figure 1 Flowchart of step S110 in FIG.

[0048] Figure 3 yes Figure 2 Flowchart of step S220 in FIG.

[0049] Figure 4 yes Figure 1 Flowchart of step S130 in FIG.

[0050] Figure 5 yes Figure 4 Flowchart of step S420 in FIG.

[0051] Figure 6 yes Figure 1 Flowchart of step S140 in FIG.

[0052] Figure 7 yes Figure 1 Flowchart of step S150 in FIG.

[0053] Figure 8 Schematic diagram of the structure of the access control device for service requests provided in an embodiment of the present application;

[0054] Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0056] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0057] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0058] To handle highly concurrent business requests, business systems typically employ distributed systems. Distributed systems are designed based on a microservices architecture, which divides the distributed system into multiple independent microservices, each responsible for a specific business function. To decouple the relationships between microservices and improve system scalability, multiple microservices often call each other. For example, in a fintech scenario, a banking system can be divided into an account management microservice and a transaction management microservice. The account management microservice is responsible for account creation, querying, updating, and deleting, while the transaction management microservice processes various transactions. During transactions such as transfers and payments, the transaction management microservice calls the account management microservice to obtain account information and verify account status. For example, in a digital healthcare scenario, a digital healthcare system can be divided into a physician management microservice and a medical record microservice. The physician management microservice manages and stores physician information, while the medical record microservice stores patient electronic medical records. During consultations, physicians access patients' electronic medical records, and the physician management microservice calls the medical record microservice to obtain these records. To ensure high availability of each microservice, access control is required for business requests to these microservices. Without an effective access control mechanism, business systems can easily become unavailable due to resource exhaustion, fault propagation, or performance bottlenecks.

[0059] Based on this, the embodiments of the present application provide a method for access control of service requests, an apparatus for access control of service requests, an electronic device, and a computer-readable storage medium, which aim to perform access control on microservice requests and improve the availability of the business system.

[0060] The access control method for service requests, the access control device for service requests, the electronic device and the computer-readable storage medium provided in the embodiments of the present application are specifically illustrated through the following embodiments. First, the access control method for service requests in the embodiments of the present application is described.

[0061] The access control method for service requests provided in the embodiment of the present application relates to the field of computer technology. The access control method for service requests provided in the embodiment of the present application can be applied to a terminal, can be applied to a server side, or can be software running in a terminal or a server side. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, etc.; the server side can be configured as an independent physical server, or as a server cluster or distributed system composed of multiple physical servers, or as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application that implements the access control method for service requests, etc., but is not limited to the above forms.

[0062] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.

[0063] Figure 1 This is an optional flowchart of the access control method for service requests provided in an embodiment of the present application, which is applied to the first microservice. Figure 1 The method may include but is not limited to steps S110 to S160.

[0064] Step S110: Generate a service log in response to the original service request sent by the second microservice; wherein the service log includes the request timestamp, request response status, and request response duration of the original service request;

[0065] Step S120: obtaining a requested control rule from a pre-acquired control configuration file; wherein the requested control rule includes a control rule category and control parameters of the control rule category;

[0066] Step S130: classify the original service request according to the request timestamp, request response status, request response time, control rule category, and control parameter to obtain normal service requests and abnormal service requests, and obtain the number of normal service requests and the number of abnormal service requests.

[0067] Step S140, performing an index evaluation based on the control parameters, the number of normal requests, and the number of abnormal requests to obtain a request access index;

[0068] Step S150: Filter the control rule categories based on the requested access indicator to obtain a target rule category, and generate an access control policy based on the target rule category and the target control parameter of the target rule category; wherein the access control policy includes a fuse operation or an alarm operation;

[0069] Step S160: Send the fuse operation or alarm operation to the second microservice for access control.

[0070] In steps S110 to S160, as shown in the embodiment of the present application, the request access index is calculated to quantitatively evaluate the first microservice's request response performance for business requests. Different access control policies are generated based on the request response performance, and access control is performed on business requests sent from the second microservice to the first microservice according to the access control policies. This embodiment can be applied to financial and medical service systems. By performing access control on business requests from these systems, system resources can be effectively protected, ensuring high availability and stable operation of these systems.

[0071] See also Figure 2 In some embodiments, step S110 may include but is not limited to steps S210 to S240:

[0072] Step S210: In response to the original business request sent by the second microservice, convert the request timestamp, request response status, and request response duration of the original business request into a log format to obtain an original log;

[0073] Step S220: sampling the original logs according to a preset sampling rate to obtain candidate logs;

[0074] Step S230, storing the candidate logs into the message queue to obtain the target queue;

[0075] Step S240: Obtain candidate logs from the target queue through a preset asynchronous thread to obtain a service log.

[0076] In step S210 of some embodiments, when the second microservice calls the first microservice, it sends an original business request to the first microservice. The original business request is the request sent by the second microservice to the first microservice to perform a business task. Taking the fintech scenario as an example, the account management microservice is used as the first microservice and the transaction management microservice is used as the second microservice. When making an online payment, the transaction management microservice will call the account management microservice to verify the account balance to improve transaction security and transaction success rate. The original business request can be an account balance query request. Taking the digital healthcare scenario as an example, the medical record microservice is used as the first microservice and the doctor management microservice is used as the second microservice. When a doctor sees a patient, the doctor management microservice will call the medical record microservice to obtain the electronic medical record. The original business request can be a patient medical record query request.

[0077] When the first microservice receives the original service request, it responds to it and records the metadata of the original service request and the first microservice's response to it, generating the original log of the first microservice. This log reflects the first microservice's service performance in responding to the service request. The metadata of the original service request includes the request timestamp, which indicates when the original service request was created. The first microservice's response to the original service request includes the request response status and request response duration. The request response status provides feedback on the first microservice's processing of the original service request and can be represented by a status code, indicating a successful or failed response. For example, a status code of 2xx indicates a successful response, while a status code of 4xx indicates an unsuccessful response. The request response duration is the time from when the second microservice sends the original service request to when the first microservice responds to it. The request response duration can be used to measure the service performance and response speed of the first microservice. In order to better record and analyze various information of the first microservice during operation, the log format is determined. The log format can be JSON format or other custom text format. The request timestamp, request response status and request response duration of the original business request are mapped to the log format to obtain the original log.

[0078] In step S220 of some embodiments, as the business develops, the first microservice will receive a large number of business requests at the same time. For example, during stock trading, the first microservice will receive a large number of transaction verification requests. In order to improve the access control efficiency of business requests and reduce the storage space requirements of business requests, the original logs are sampled according to a preset sampling rate to reduce the number of logs in the original logs and obtain candidate logs. The preset sampling rate can be a log sampling ratio or a time sampling ratio. The log sampling ratio is used to indicate the event frequency of log sampling, such as sampling 1 for every 100 original logs, sampling 10 for every 1000 original logs, etc. The time sampling ratio is used to indicate the time frequency of log sampling, such as sampling 1 per hour.

[0079] A random number generator can be used to generate random numbers, which are then used as the log sampling ratio or time sampling ratio. Original logs are sampled based on these ratios to generate candidate logs. Random sampling can cover logs from different business requests, enabling comprehensive analysis and ensuring the accuracy of access control.

[0080] In step S230 of some embodiments, the first microservice is a high-concurrency service that receives a large number of business requests at the same time, so that the speed of log generation is much faster than the speed of log processing. In order to avoid the log generation process being blocked by the log processing process, the candidate logs are stored in the message queue to obtain the target queue, thereby separating the log generation process from the log processing process, so that the log generation thread can return immediately after writing the log to the queue, and log generation will not be affected by the delay of log processing.

[0081] In step S240 of some embodiments, a preset asynchronous thread is started, which allows multiple log processing tasks to be executed simultaneously. The preset asynchronous thread obtains candidate logs from the target queue in parallel to obtain service logs, thereby improving the efficiency of service log generation.

[0082] Through the above steps S210 to S240, the service log can be quickly obtained according to the business request, and the storage space requirement of the service log is reduced.

[0083] See also Figure 3 In some embodiments, step S220 may include but is not limited to steps S310 to S340:

[0084] Step S310: storing the original log into a log queue and obtaining the queue length of the log queue;

[0085] Step S320, obtaining the log generation speed of the original log according to the queue length;

[0086] Step S330, adjusting the preset sampling rate according to the log generation speed to obtain a target sampling rate;

[0087] Step S340 : sampling the original logs according to the target sampling rate to obtain candidate logs.

[0088] In step S310 of some embodiments, to improve the service performance of the first microservice, the original log is stored in a log queue to separate the log generation process and the log processing process. The queue length of the log queue is obtained. The queue length is the number of original log entries stored in the log queue.

[0089] In step S320 of some embodiments, the difference between the queue length at the current time and the queue length at the previous time is calculated at intervals of a preset duration, with the current time being the sum of the previous time and the preset duration. The ratio between the length difference and the preset duration is calculated to obtain the log generation rate. The log generation rate indicates the number of original log entries generated per unit time.

[0090] In step S330 of some embodiments, if the log generation speed is greater than the preset generation speed, it means that the speed of log generation is large and the number of logs in the original log is large. In order to reduce the occupation of the log queue storage space by the original log, the preset sampling rate is reduced to obtain the target sampling rate. If the log generation speed is less than the preset generation speed, it means that the speed of log generation is small and the number of logs in the original log is small. In order to improve the coverage of the log to different types of business requests and the control accuracy of access control, the preset sampling rate is increased to obtain the target sampling rate. If the log generation speed is equal to the preset generation speed, the preset sampling rate is used as the target sampling rate. It should be noted that in order to ensure the accuracy and rationality of the sampling rate, avoid the sampling rate being too large or too small, after completing a sampling of the original log, the target sampling rate can be restored to the preset sampling rate.

[0091] In step S340 of some embodiments, the target sampling rate includes a log sampling ratio or a time sampling ratio, and log sampling is performed on the original log according to the log sampling ratio or the time sampling ratio to obtain a candidate log.

[0092] Through the above steps S310 to S340, the log sampling rate can be dynamically adjusted, so that when request access control is performed on business requests based on logs, the control accuracy of the access control can be dynamically adjusted.

[0093] In step S120 of some embodiments, the control configuration file defines various configuration items required for access control. In order to perform access control on massive business requests, a unified request control rule is obtained from the pre-acquired control configuration file. The request control rule includes a control rule category and control parameters of the control rule category. The control rule category includes a circuit breaker rule, an alarm rule, or a current limiting rule. The control parameters are parameters related to request access control involved in the control rule category. It should be noted that the circuit breaker rule is used to prevent the second microservice from continuing to attempt failed operations when the request is abnormal, thereby avoiding excessive consumption of system resources and further failures. For example, when the transaction management microservice calls the account management microservice to verify the account balance, if the account management microservice is unavailable, the transaction management microservice will enter a circuit breaker state instead of continuing to attempt to call the account management microservice. The alarm rule is used to issue an alarm to the first microservice or the second microservice. The current limiting rule is used to limit the number of requests to the first microservice to avoid system overload.

[0094] See also Figure 4 In some embodiments, step S130 may include but is not limited to steps S410 to S430:

[0095] Step S410, screening the original service request according to the request timestamp and the time window length to obtain candidate service requests;

[0096] Step S420, filtering the request response status and request response duration according to the control rule category to obtain a request classification parameter;

[0097] Step S430 , classifying the candidate service requests according to the request classification parameters to obtain normal service requests and abnormal service requests.

[0098] In step S410 of some embodiments, the control parameters include a time window length, which is the length of a preset time window, such as 5 seconds. Different time window lengths can be set for different control rule categories, such as a time window length of 5 seconds for a circuit breaker rule, a time window length of 1 minute for an alarm rule, and a time window length of 1 second for a current limiting rule. To achieve real-time access control for microservices, original business requests are screened based on the request timestamp and time window length, and original business requests with request timestamps within the preset time window, such as original business requests within the last 5 seconds, are obtained to obtain candidate business requests.

[0099] In step S420 of some embodiments, different control rule categories have different standards for distinguishing normal business requests from abnormal business requests. In order to obtain the distinguishing index corresponding to the control rule category, the request response status and the request response duration are screened according to the control rule category to obtain the request classification parameter. The request response status is used to reflect whether the business request is processed normally by the microservice. If the business request is processed normally by the microservice, the request response status is a success status, otherwise it is a failure status. In the embodiment of the present application, business requests with status codes of 4xx or 5xx are regarded as abnormal business requests, and the rest are normal business requests. The request response duration is the duration for the microservice to respond to the business request, which can reflect the processing speed of the microservice to the business request. The request response duration is inversely proportional to the processing speed. The request classification parameter is used to distinguish whether the business request is a normal business request or an abnormal business request. The request classification parameter is the request response status or the request response duration.

[0100] In step S430 of some embodiments, if the request classification parameter is the request response status, candidate service requests with a successful request response status are considered normal service requests, and candidate service requests with a failed request response status are considered abnormal service requests. If the request classification parameter is the request response duration, candidate service requests with a request response duration less than or equal to a preset duration threshold are considered normal service requests, and candidate service requests with a request response duration greater than the preset duration threshold are considered abnormal service requests. The number of normal service requests is obtained, and the number of abnormal service requests is obtained, and the number of abnormal requests is obtained.

[0101] Through the above steps S410 to S430, it is possible to distinguish whether a service request is a normal request or an abnormal request, so as to perform access control on the service request.

[0102] See also Figure 5 In some embodiments, step S420 may include but is not limited to steps S510 to S520:

[0103] Step S510: If the control rule category is a fuse rule or an alarm rule, the request response status is used as a request classification parameter;

[0104] Step S520: If the control rule type is a current limiting rule, the request response time is used as a request classification parameter.

[0105] In step S510 of some embodiments, the control rule category includes a circuit breaker rule, a current limiting rule, or an alarm rule. If the control rule category is a circuit breaker rule or an alarm rule, the request response status is used as a request classification parameter.

[0106] In step S520 of some embodiments, if the control rule category is a current limiting rule, the request response time is used as a request classification parameter.

[0107] Through the above steps S510 to S520, the request classification parameters can be obtained to distinguish normal business requests from abnormal business requests according to the request classification parameters, thereby performing access control on microservices based on abnormal business requests and improving the availability of microservices.

[0108] See also Figure 6 In some embodiments, step S140 may include but is not limited to steps S610 to S630:

[0109] Step S610: Calculate the ratio between the number of abnormal requests and the preset number of requests to obtain a request abnormality rate; wherein the preset number of requests is the sum of the number of normal requests and the number of abnormal requests;

[0110] Step S620, calculating the ratio between the number of abnormal requests and the number of normal requests to obtain a request error rate;

[0111] Step S630 , screening the preset request quantity, normal request quantity, abnormal request quantity, request abnormality rate, and request error rate according to the indicator parameters to obtain a request access indicator.

[0112] In step S610 of some embodiments, the number of normal requests and the number of abnormal requests are added to obtain a preset number of requests, and the number of abnormal requests is divided by the preset number of requests to determine a ratio between the number of abnormal requests and the preset number of requests to obtain a request abnormality rate.

[0113] In step S620 of some embodiments, the number of abnormal requests is divided by the number of normal requests, and the ratio between the number of abnormal requests and the number of normal requests is calculated to obtain the request error rate.

[0114] In step S630 of some embodiments, the control parameters include at least one indicator parameter and an indicator threshold of the indicator parameter. The indicator parameter is used to indicate the calculation indicator under the control rule category. The indicator threshold is the upper limit value of the indicator parameter, which can be set according to business needs and the resource conditions of the server where the microservice is located. For example, the indicator parameter is an abnormal request number parameter, and the indicator threshold is an abnormal number threshold such as 10. The indicator threshold is used to trigger a specific control rule category. According to the indicator parameter, the preset request number, normal request number, abnormal request number, request abnormality rate and request error rate are screened to obtain a request access indicator. For example, if the indicator parameter of the fuse rule is an abnormal request number parameter, the request access indicator is a specific value of the abnormal request number. If the indicator parameter of the alarm rule is a request abnormality rate parameter and an abnormal request number parameter, the request access indicator is a specific value of the request abnormality rate and a specific value of the abnormal request number.

[0115] Through the above steps S610 to S630, the request access index can be obtained to evaluate the service performance of the first microservice according to the request access index.

[0116] If the requested access metric is greater than or equal to the metric threshold, the control rule category is selected as the target rule category. Specifically, the target rule category includes circuit breaker rules, alarm rules, or rate limiting rules. The control parameters of the target rule category are obtained to obtain the target control parameters. Based on the target rule category and the target control parameters of the target rule category, an access control policy is generated. The access control policy includes circuit breaker actions, alarm actions, or rate limiting actions.

[0117] See also Figure 7 In some embodiments, step S150 may include but is not limited to steps S710 to S730:

[0118] Step S710: If the target rule type is a blow rule, extract the silence duration from the target control parameter and generate a blow operation according to the silence duration;

[0119] Step S720: If the target rule type is an alarm rule, extract the alarm parameter from the target control parameter and generate an alarm operation according to the alarm parameter;

[0120] Step S730: Generate an access control policy based on the fuse operation or the alarm operation.

[0121] In step S710 of some embodiments, if the target rule category is a circuit breaker rule, the silence duration is extracted from the target control parameter, and a circuit breaker operation is generated based on the silence duration. The silence duration is the time interval between the second microservice going from the circuit breaker state to the next service request being initiated, such as 2 seconds.

[0122] Taking the fuse rule as an example, the fuse operation is usually for the caller, and in the embodiment of the present application, the caller is the second microservice. For example, service A calls service B, and the time window length and the fuse threshold are configured in the rule module. The time window length is 1 minute, and the fuse threshold is the upper limit of the request exception rate, such as 20%. If the request exception rate is greater than or equal to 20% per minute, the real-time analysis and decision module will send the fuse information to service A, and the thread of service A itself can also pull or detect the fuse information. Service A will automatically fuse the request to service B according to the fuse information and return the default failure information. After waiting for the silent period, service A will synchronously allow the request to service B. At this time, service A can continue to try to request service B. If service B recovers, the entire call link will heal itself, thereby protecting the downstream service B. At the same time, the number of call links from service A to service B is reduced through the fuse operation, which also protects service A.

[0123] In step S720 of some embodiments, if the target rule category is an alarm rule, alarm parameters are extracted from the target control parameters. The alarm parameters can be alarm templates, and an alarm action is generated based on the alarm parameters. Taking alarm rules as an example, the configuration module defines various alarm rules. When the analysis and decision module calculates the request access indicators that require alarms, it pushes them to the alarm module, which then pushes the alarm information to the second microservice, facilitating timely troubleshooting of microservice issues.

[0124] If the target rule type is a rate limiting rule, a rate limiting parameter is extracted from the target control parameter, and a rate limiting operation is generated based on the rate limiting parameter. The rate limiting parameter is the upper limit of the number of business requests allowed to be received by the first microservice. The rate limiting operation is used to limit the number of business requests received by the first microservice. The rate limiting parameter can be a dynamic rate limiting configuration. The average request response time is calculated by averaging the request response time for each request based on a preset number of requests, and the rate limiting parameter is obtained based on the average request response time.

[0125] Taking the current limiting rule as an example, the current limiting operation is usually for the callee, and in the embodiment of the present application, the callee is the first microservice. For example, service A calls service B, and the current limiting rule is configured in the rule configuration module. For example, when the average request response time within one minute exceeds 1s, and the business request with a request response time of 100ms is a normal business request, the current limiting parameter is configured to be 80% of the current total request amount, i.e., the preset number of requests; if the average request response time exceeds 2s, the current limiting parameter is configured to be 60% of the current total request amount, and so on. When the average request response time is less than or equal to 100ms, it means that service B is currently able to undertake more traffic, and the current limiting parameter can be gradually increased. Service B can dynamically adjust the current limiting value according to the response of its own system to give full play to the performance of service B and realize the self-protection of service B.

[0126] Through current limiting, fusing and alarming, the high availability problem of distributed systems can be effectively solved, and through alarm operations, problems in the system can be quickly discovered or foreseen so that problems can be dealt with in a timely manner to prevent further spread of the problem. By independently deploying and running the method of the embodiment of the present application, the intrusion, coupling and impact on the business system can be reduced, which is conducive to the maintenance and upgrade of the later system. And access control based on the standard access log format can be used not only for each microservice of the distributed system, but also for dependent components, such as DB, message queue, external third-party call, etc., as long as the log format is standardized.

[0127] In step S730 of some embodiments, a fuse operation or an alarm operation is used as an access control policy.

[0128] The above steps S710 to S730 can generate an access control policy to perform access control on the business requests of the microservice based on the access control policy.

[0129] In step S160 of some embodiments, a circuit breaker operation or an alarm operation is sent to the second microservice, so that the second microservice performs access control according to the circuit breaker operation or the alarm operation. Access control is performed on the first microservice through a current limiting operation. The access control method of the embodiment of the present application does not have complex calculation logic. After the access control policy is generated, it can be synchronized to the microservice. The microservice executes the circuit breaker operation, the alarm operation, or the current limiting operation according to the access control policy, thereby realizing real-time access control of the microservice, reducing the maintenance cost of the microservice, and ensuring the high availability of the microservice.

[0130] See also Figure 8 The embodiment of the present application further provides an access control device for a service request, which is applied to the first microservice and can implement the access control method for the service request. The access control device for the service request includes:

[0131] The request acquisition module 810 is configured to generate a service log in response to the original service request sent by the second microservice; wherein the service log includes the request timestamp, request response status, and request response duration of the original service request;

[0132] A rule acquisition module 820 is configured to acquire a requested control rule from a pre-acquired control configuration file; wherein the requested control rule includes a control rule category and control parameters of the control rule category;

[0133] The request classification module 830 is used to classify the original service request according to the request timestamp, request response status, request response time, control rule category and control parameters, obtain normal service requests and abnormal service requests, and obtain the normal request quantity of the normal service requests and the abnormal request quantity of the abnormal service requests;

[0134] A calculation module 840 is configured to perform an index evaluation based on the control parameters, the number of normal requests, and the number of abnormal requests to obtain a request access index;

[0135] A screening module 850 is configured to screen the control rule categories based on the requested access indicator to obtain a target rule category, and generate an access control policy based on the target rule category and the target control parameters of the target rule category; wherein the access control policy includes a circuit breaker operation or an alarm operation;

[0136] The sending module 860 is used to send the fuse operation or the alarm operation to the second microservice for access control.

[0137] The specific implementation of the access control device for service requests is substantially the same as the specific embodiment of the access control method for service requests described above, and will not be described in detail herein.

[0138] The present application also provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the aforementioned access control method for service requests. The electronic device can be any smart terminal, such as a tablet computer or an in-vehicle computer.

[0139] See also Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is shown. The electronic device includes:

[0140] The processor 910 may be implemented as a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is configured to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0141] The memory 920 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 920 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 920, and the processor 910 calls and executes the access control method for the service request of the embodiments of this application;

[0142] Input / output interface 930, used to implement information input and output;

[0143] Communication interface 940, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0144] bus 950 , which transmits information between various components of the device (e.g., processor 910 , memory 920 , input / output interface 930 , and communication interface 940 );

[0145] The processor 910 , the memory 920 , the input / output interface 930 , and the communication interface 940 are connected to each other in communication within the device via a bus 950 .

[0146] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the access control method for the above-mentioned service request is implemented.

[0147] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0148] The service request access control method, service request access control device, electronic device, and computer storage medium provided in the embodiments of the present application can quantitatively evaluate the request response performance of a first microservice to a business request by calculating a request access index, thereby generating different access control policies based on the request response performance, and performing access control on the business request sent from a second microservice to the first microservice based on the access control policy.

[0149] The embodiments described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0150] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0151] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0152] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0153] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0154] It should be understood that in this application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0155] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the above-mentioned units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0156] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0157] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0158] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes multiple instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: various media that can store programs, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0159] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention should be within the scope of the present invention.

Claims

1. A method for controlling access to a service request, characterized in that: Applied to the first microservice, the method includes: In response to the original business request sent by the second microservice, a service log is generated; wherein the service log includes the request timestamp, request response status, and request response duration of the original business request; Acquire a request control rule from a pre-acquired control configuration file; wherein the request control rule includes a control rule category and a control parameter of the control rule category; Classify the original service request according to the request timestamp, the request response status, the request response duration, the control rule category, and the control parameter to obtain normal service requests and abnormal service requests, and obtain the normal request quantity of the normal service requests and the abnormal request quantity of the abnormal service requests; Performing an index evaluation based on the control parameter, the number of normal requests, and the number of abnormal requests to obtain a request access index; Filtering the control rule category according to the requested access indicator to obtain a target rule category, and generating an access control policy according to the target rule category and a target control parameter of the target rule category; wherein the access control policy includes a fuse operation or an alarm operation; The fuse operation or alarm operation is sent to the second microservice for access control.

2. The method according to claim 1, characterized in that The control parameter includes a time window length, and the original service request is classified according to the request timestamp, the request response status, the request response duration, the control rule category, and the control parameter to obtain a normal service request and an abnormal service request, including: Filter the original service request according to the request timestamp and the time window length to obtain a candidate service request; Filtering the request response status and the request response duration according to the control rule category to obtain a request classification parameter; The candidate service requests are classified according to the request classification parameters to obtain the normal service requests and the abnormal service requests.

3. The method according to claim 2, characterized in that The control rule category includes a circuit breaker rule, a current limiting rule, or an alarm rule. The request response status and the request response duration are filtered according to the control rule category to obtain a request classification parameter, including: If the control rule category is the fuse rule or the alarm rule, the request response status is used as the request classification parameter; If the control rule category is the current limiting rule, the request response time is used as the request classification parameter.

4. The method according to claim 1, wherein The control parameter includes an index parameter, and the index evaluation is performed according to the control parameter, the number of normal requests, and the number of abnormal requests to obtain the request access index, including: Calculating the ratio between the number of abnormal requests and the preset number of requests to obtain a request abnormality rate; wherein the preset number of requests is the sum of the number of normal requests and the number of abnormal requests; Calculate the ratio between the number of abnormal requests and the number of normal requests to obtain a request error rate; The preset request number, the normal request number, the abnormal request number, the request abnormality rate and the request error rate are screened according to the indicator parameters to obtain the request access indicator.

5. The method according to any one of claims 1 to 4, characterized in that The control rule category includes a fuse rule or an alarm rule, and generating an access control policy according to the target rule category and a target control parameter of the target rule category includes: If the target rule category is the fuse rule, extracting the silence duration from the target control parameter, and generating the fuse operation according to the silence duration; If the target rule category is the alarm rule, extracting alarm parameters from the target control parameters, and generating the alarm operation according to the alarm parameters; Generate the access control policy according to the fuse operation or the alarm operation.

6. The method according to any one of claims 1 to 4, characterized in that The original business request has the request timestamp, the request response status, and the request response duration. The response to the original business request sent by the second microservice generates a service log, including: In response to the original business request sent by the second microservice, convert the request timestamp, request response status, and request response duration of the original business request into a log format to obtain an original log; Sampling the original logs according to a preset sampling rate to obtain candidate logs; Storing the candidate logs in a message queue to obtain a target queue; The candidate log is obtained from the target queue through a preset asynchronous thread to obtain the service log.

7. The method according to claim 6, characterized in that The sampling of the original log according to the preset sampling rate to obtain the candidate log includes: Storing the original log in a log queue and obtaining the queue length of the log queue; Obtaining a log generation speed of the original log according to the queue length; Adjusting the preset sampling rate according to the log generation speed to obtain a target sampling rate; Log sampling is performed on the original log according to the target sampling rate to obtain the candidate log.

8. An access control device for service requests, characterized in that: Applied to the first microservice, the apparatus includes: A request acquisition module, configured to generate a service log in response to the original service request sent by the second microservice; wherein the service log includes the request timestamp, request response status, and request response duration of the original service request; A rule acquisition module is used to acquire a request control rule from a pre-acquired control configuration file; wherein the request control rule includes a control rule category and control parameters of the control rule category; a request classification module, configured to classify the original service request according to the request timestamp, the request response status, the request response duration, the control rule category, and the control parameter, to obtain normal service requests and abnormal service requests, and to obtain the number of normal requests for the normal service requests and the number of abnormal requests for the abnormal service requests; a calculation module, configured to perform an index evaluation based on the control parameter, the number of normal requests, and the number of abnormal requests to obtain a request access index; a screening module, configured to screen the control rule category according to the requested access indicator to obtain a target rule category, and generate an access control policy according to the target rule category and a target control parameter of the target rule category; wherein the access control policy includes a fuse operation or an alarm operation; A sending module is used to send the fuse operation or the alarm operation to the second microservice for access control.

9. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images