Service request distribution method and system, storage medium and electronic device

Abstract

The invention discloses a service request distribution method and system, a storage medium and an electronic device, and relates to the technical field of smart home / smart home, and the service request distribution method comprises the steps: obtaining the monitoring data of a service node and a service request, the monitoring data being used for reflecting the performance and operation state of the service node; determining a distribution strategy based on the monitoring data by using a preset distribution rule and a node prediction model; and distributing the service request to the target service node according to the distribution strategy. According to the application, the monitoring data of the service node is acquired, and the distribution strategy is determined by using the preset distribution rule and the node prediction model based on the monitoring data, so that the purpose of fully considering the performance and the running state change trend of the service node during service request distribution is achieved; the effect of timely and automatically adjusting the request distribution according to the change trend is achieved, the balance of node resource utilization is ensured, and the node resource utilization rate is improved.

Description

Technical Field

[0001] The present application relates to the field of smart home / intelligent family technology, and more specifically, to a service request distribution method, system, storage medium and electronic device. Background Art

[0002] In distributed systems, the distribution and processing of service requests are key links. The service request distribution mechanism usually relies on static configuration or fixed rules. When the system traffic or service nodes change, it cannot be adjusted in time, which easily leads to uneven node resource utilization. In addition, the maintenance cost of manually adjusting the configuration is high.

[0003] Accordingly, the art needs a new service request distribution solution to solve the above problems. Summary of the invention

[0004] In order to overcome the above-mentioned defects, the present application is proposed to solve or at least partially solve the problem that service request distribution based on static configuration or fixed rules easily leads to uneven utilization of node resources.

[0005] In a first aspect, a service request distribution method is provided, comprising: obtaining monitoring data and service requests of a service node, wherein the monitoring data is used to reflect the performance and operating status of the service node; determining a distribution strategy based on the monitoring data using preset distribution rules and a node prediction model, wherein the node prediction model is used to predict the changing trend of the performance and operating status of the service node, and the distribution strategy includes a target service node; and distributing the service request to the target service node according to the distribution strategy.

[0006] In a technical solution of the above-mentioned service request distribution method, the method also includes: obtaining historical monitoring data and business logs; training a machine learning model based on the historical monitoring data and business logs to obtain the node prediction model.

[0007] In a technical solution of the above-mentioned service request distribution method, the distribution strategy is determined based on the monitoring data using preset distribution rules and a node prediction model, including: obtaining prediction data of the service node based on the monitoring data using the node prediction model; determining the distribution strategy based on preset distribution rules, the prediction data and the monitoring data.

[0008] In a technical solution of the above service request distribution method, when there is a conflict between determining a distribution strategy based on the preset distribution rule and the monitoring data and determining a distribution strategy based on the prediction data, the distribution strategy is determined based on the preset distribution rule first.

[0009] In a technical solution of the above-mentioned service request distribution method, the method further includes: in response to an abnormality in the prediction data or the monitoring data, triggering an alarm.

[0010] In a technical solution of the above-mentioned service request distribution method, the distribution strategy also includes: additional resources and service priority, and the method also includes: obtaining the distribution path and processing results of the service request; optimizing the target service node, additional resources and service priority of the service request according to the distribution path and processing results.

[0011] In a technical solution of the above service request distribution method, the monitoring data includes real-time monitoring data or monitoring data acquired based on a preset time interval.

[0012] In a second aspect, a service request distribution system is provided, comprising: a data monitoring module, used to obtain monitoring data and service requests of service nodes, the monitoring data being used to reflect the performance and operating status of the service nodes; a policy engine module, used to determine a distribution strategy based on the monitoring data using preset distribution rules and a node prediction model, the node prediction model being used to predict changing trends in the performance and operating status of the service nodes, the distribution strategy including a target service node; and a service distribution module, used to distribute the service request to the target service node according to the distribution strategy.

[0013] In a technical solution of the above-mentioned service request distribution system, the system also includes: a data and log acquisition module, used to obtain historical monitoring data and business logs; a model training module, used to train a machine learning model based on the historical monitoring data and business logs to obtain the node prediction model.

[0014] In a technical solution of the above-mentioned service request distribution system, the policy engine module includes: a data prediction unit, used to obtain the prediction data of the service node based on the monitoring data using the node prediction model; a policy determination unit, used to determine the distribution strategy based on preset distribution rules, the prediction data and the monitoring data.

[0015] In a technical solution of the above-mentioned service request distribution system, the strategy determination unit includes: a priority determination subunit, which is used to determine the distribution strategy based on the preset distribution rule when there is a conflict between the distribution strategy determined based on the preset distribution rule and the monitoring data and the distribution strategy determined based on the prediction data.

[0016] In a technical solution of the above service request distribution system, the system further includes: an alarm module, which is used to trigger an alarm in response to an abnormality in the prediction data or the monitoring data.

[0017] In a technical solution of the above-mentioned service request distribution system, the distribution strategy also includes: additional resources and service priorities. The system also includes: a path and result acquisition module, which is used to obtain the distribution path and processing results of the service request; a strategy optimization module, which is used to optimize the target service node, additional resources and service priority of the service request according to the distribution path and processing results.

[0018] In a technical solution of the above service request distribution system, the monitoring data includes real-time monitoring data or monitoring data acquired based on preset time intervals.

[0019] In a third aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored program, wherein when the program is run, the service request distribution method in the above-mentioned first aspect or any corresponding technical solution thereof is executed.

[0020] In a fourth aspect, an electronic device is provided, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the service request distribution method in the above-mentioned first aspect or any corresponding technical solution thereof through the computer program.

[0021] The above one or more technical solutions of the present application have at least one or more of the following beneficial effects:

[0022] In the technical solution for implementing the present application, by obtaining monitoring data and service requests of service nodes, and determining the distribution strategy based on the monitoring data using preset distribution rules and node prediction models, the purpose of fully considering the performance and operating status change trends of service nodes when distributing service requests is achieved, and the effect of timely and automatic adjustment of request distribution according to the change trend is achieved, which is conducive to ensuring the balance of node resource utilization, improving node resource utilization, avoiding node overload or idleness, and reducing the cost of manual maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0024] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0025] Figure 1 is a schematic diagram of a hardware environment of an interaction method of a smart device according to an embodiment of the present application;

[0026] Figure 2 It is a flowchart of the main steps of the service request distribution method according to an embodiment of the present application;

[0027] Figure 3 It is a schematic diagram of the main structural block diagram of a service request distribution system according to an embodiment of the present application;

[0028] Figure 4 is a schematic diagram of the overall framework of a service request distribution system according to an embodiment of the present application;

[0029] Figure 5 is a schematic diagram of the working process of a service request distribution system according to an embodiment of the present application;

[0030] Figure 6 The figure is a schematic diagram of the connection relationship between the processor and the memory of a smart device according to an embodiment of the present application. DETAILED DESCRIPTION

[0031] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0032] It should be noted that the terms "first", "second", etc. in the specification and claims 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 sequence. It should be understood that the data used in this way can be interchanged 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 of their variations 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. The terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected, it can be indirectly connected through an intermediate medium, it can also be the internal communication of two elements, it can be a wireless connection, or it can be a wired connection.

[0033] In addition, "module" and "processor" may include hardware, software or a combination of the two. A module may include hardware circuits, various suitable sensors, communication ports, and memories, and may also include software parts, such as program codes, or a combination of software and hardware. The processor may be a central processing unit, a microprocessor, an image processor, a digital signal processor, or any other suitable processor. The processor has data and / or signal processing functions. The processor may be implemented in software, hardware, or a combination of the two. Computer-readable storage media include any suitable media that can store program codes, such as magnetic disks, hard disks, optical disks, flash memory, read-only memory, random access memory, etc.

[0034] In addition, if the meaning of "and / or" appears in this application, it includes three parallel solutions. Taking "A and / or B" as an example, it includes solution A, solution B, or a solution that satisfies both A and B. In addition, the technical solutions between the various embodiments can be combined with each other, but it must be based on the ability of ordinary technicians in this field to implement. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by this application. The term "at least one A or B" or "at least one of A and B" has a similar meaning to "A and / or B" and can include only A, only B, or A and B. The singular terms "one" and "this" can also include plural forms.

[0035] The relevant user personal information that may be involved in the various embodiments of this application is strictly in accordance with the requirements of laws and regulations, following the principles of legality, legitimacy and necessity, based on the reasonable purposes of business scenarios, to process the personal information that users actively provide during the use of products / services or generated due to the use of products / services, as well as the personal information obtained with the user's authorization.

[0036] This application attaches great importance to the security of user personal information and has taken reasonable and feasible security protection measures that meet industry standards to protect user information and prevent personal information from being accessed, disclosed, used, modified, damaged or lost without authorization.

[0037] According to one aspect of an embodiment of the present application, a method for interacting with a smart home device is provided. The method for interacting with a smart home device is widely used in smart home, smart home, smart home device ecosystem, smart home ecosystem and other whole-house intelligent digital control application scenarios. Optionally, in this embodiment, the method for interacting with the smart home device can be applied to Figure 1 In the hardware environment composed of the terminal device 102 and the server 104 shown in FIG. Figure 1As shown, the server 104 is connected to the terminal device 102 via a network, and can be used to provide services (such as application services, etc.) for the terminal or a client installed on the terminal. A database can be set on the server or independently of the server to provide data storage services for the server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data computing services for the server 104.

[0038] The network may include but is not limited to at least one of the following: wired network, wireless network. The wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the wireless network may include but is not limited to at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The terminal device 102 may be but is not limited to a PC, a mobile phone, a tablet computer, a smart air conditioner, a smart range hood, a smart refrigerator, a smart oven, a smart stove, a smart washing machine, a smart water heater, a smart washing device, a smart dishwasher, a smart projection device, a smart TV, a smart clothes drying rack, a smart curtain, a smart audio and video, a smart socket, a smart speaker, a smart fresh air device, a smart kitchen and bathroom device, a smart bathroom device, a smart sweeping robot, a smart window cleaning robot, a smart mopping robot, a smart air purification device, a smart steamer, a smart microwave oven, a smart kitchen treasure, a smart purifier, a smart water dispenser, a smart door lock, etc.

[0039] In a distributed system, the distribution and processing of service requests are key links. Existing request distribution mechanisms usually rely on static configurations or fixed rules, and are difficult to adapt to dynamically changing business needs, such as sudden increases in traffic, service expansion or reduction, etc. Specifically, in traditional Java backend development, request distribution mechanisms are usually implemented through load balancers. Common methods include polling, minimum number of connections, hashing, etc. Although these methods are effective in certain scenarios, they have the following problems and shortcomings when facing complex business needs:

[0040] (1) Static configuration is difficult to cope with dynamic changes: When the system traffic or service nodes change, the fixed distribution strategy cannot be adjusted in time, which may cause some service nodes to be overloaded or idle.

[0041] (2) Lack of intelligent adjustment: Existing load balancing methods cannot make intelligent adjustments based on real-time monitoring data (such as system performance, network latency, etc.), resulting in the overall system performance not being optimal.

[0042] (3) Poor scalability: For large-scale distributed systems, adding or reducing service nodes requires manual configuration adjustments.

[0043] (4) Slow response: When faced with sudden traffic or service expansion, the system cannot quickly adjust its distribution strategy.

[0044] (5) Uneven resource utilization: A fixed distribution strategy may cause some service nodes to be overloaded while other node resources are idle.

[0045] (6) High maintenance cost: Frequent manual configuration adjustments are required, which increases the complexity of system operation and maintenance.

[0046] In order to solve the above problems, one aspect of the embodiments of the present application provides a service request distribution method. Figure 2 , Figure 2 FIG. 1 is a flow chart of the main steps of a service request distribution method according to an embodiment of the present application. Figure 2 As shown, the service request distribution method mainly includes the following steps S202 to S206:

[0047] Step S202: Acquire monitoring data and service requests of the service node, where the monitoring data is used to reflect the performance and operation status of the service node.

[0048] In this embodiment, a service node refers to one or more independent server instances or computer nodes in a distributed system. Each node, i.e., a service node, has its own computing and storage resources, can independently process service requests, and communicate and collaborate with other service nodes to jointly complete tasks in the distributed system. A service request refers to a request sent by a client to multiple service nodes in a distributed system to obtain the required services or data. These requests may involve different services, such as database queries, file access, user authentication, etc., and these services may be distributed in different physical locations or provided by different service nodes. The monitoring data of the service node is used to reflect the performance and operating status of the service node, including but not limited to: the node's CPU load, memory usage, disk usage, network traffic, database query status, network latency, user behavior (such as click-through rate, bounces), response time, throughput, number of concurrency, etc. As an example, the monitoring data of the node can be selected:

[0049] CPU load: refers to the number of CPU processes being executed by the node. A high CPU load usually means that the processing capacity of the node may be over-occupied due to excessive number of service requests, unreasonable code design, or hardware resource limitations.

[0050] Memory usage: refers to the size of the allocated space in the node memory. The memory usage may be high when there are too many service requests or memory leaks.

[0051] Network delay: refers to the delay in data transmission between nodes. Network delay includes multiple parts such as network propagation delay, processing delay, and queuing delay.

[0052] In one implementation, the monitoring data of the service node may be obtained using various types of probes. The following are some common probe examples:

[0053] Health Check Probe: Used to check whether the service is in normal operation. This probe sends a specific request to the service and determines whether the service is healthy based on the response result.

[0054] Metric Collector Probe: Used to collect service metrics and statistics, such as the number of requests per second and response time. These metrics and statistics can be used to monitor the performance and health of the entire system.

[0055] In one implementation, interception of service requests can be achieved by adding an interceptor or other middleware. As an example, suppose there is a microservice for purchasing a product that receives a purchase request from a client. By adding an HTTP (Hypertext Transfer Protocol) gateway between the client and the server, the gateway can intercept the service request issued by the client before the client initiates the request.

[0056] In one implementation, the monitoring data includes real-time monitoring data or monitoring data acquired based on a preset time interval.

[0057] In this embodiment, acquiring the monitoring data of the service node may be acquiring the real-time monitoring data of the node, or acquiring the node monitoring data based on a preset time interval, thereby achieving the purpose of reducing data transmission overhead.

[0058] Step S204, determining a distribution strategy based on the monitoring data using preset distribution rules and a node prediction model, the node prediction model is used to predict the performance and operating status change trend of the service node, and the distribution strategy includes a target service node.

[0059] In this embodiment, the preset distribution rules include artificially formulated business rules and configuration strategies, such as "high-priority service requests must be forwarded to nodes with a load of less than 80%". Such rules can be predefined in the system, so that the distribution strategy is determined according to these rules after receiving the node monitoring data. In addition, the node prediction model is used to predict the performance and operating status of the service node. For example, the node prediction model is used to predict the load change of a certain node in the future, determine whether it will have a bottleneck in the short term, or calculate the node load balance, response time trend, etc. Among them, the node prediction model includes but is not limited to machine learning models, statistical methods, data flow analysis methods, and model-based prediction algorithms (such as time series analysis). The above-mentioned preset distribution rules and node prediction models are used to determine the optimal service request distribution strategy, wherein determining the distribution strategy includes determining the target service node. By sending the service node to the target service node, the purpose of maximizing node resource utilization, balancing load, and avoiding node overload or idleness can be achieved.

[0060] In one implementation, in addition to determining the target service node, determining the distribution strategy may also include adding additional resources to certain bottleneck services, adjusting service priorities, etc., which is not specifically limited in this embodiment.

[0061] Step S206: distribute the service request to the target service node according to the distribution strategy.

[0062] In this embodiment, the obtained service request is distributed to the target service node according to the distribution strategy determined in the above step S204.

[0063] For example, suppose there is a service node based on an online retail platform, and the load level of the node needs to be monitored and optimized. Specifically, the impact of various factors on the load over a period of time in the past can be collected, such as the number of visits, sales, advertising activities, the response time of the service node at different load levels, error rate and other indicators as training data for the model. When a new service request arrives, the feature information of these new requests (such as time, user source, request type, etc.) is merged with the previously collected feature information, and the merged data is input into the machine learning model, so that the model can predict the impact of the current service request on the node load based on past data, thereby determining the factors most likely to cause load changes and making corresponding predictions for them.

[0064] Based on the above steps S202 to S206, by obtaining the monitoring data and service requests of the service nodes, and determining the distribution strategy based on the monitoring data using preset distribution rules and node prediction models, the purpose of fully considering the performance and operating status change trends of the service nodes when distributing service requests is achieved, and the effect of timely and automatic adjustment of request distribution according to the change trend is achieved, which is conducive to ensuring the balance of node resource utilization, improving node resource utilization, avoiding node overload or idleness, and reducing manual maintenance costs.

[0065] In one implementation of the embodiment of the present application, step S203 may be further included before the above step S204, specifically including the following steps S2032 and S2034:

[0066] Step S2032, obtaining historical monitoring data and business logs.

[0067] In this embodiment, the historical monitoring data (of the service node) is used to reflect the performance and operating status of the service node. For example, the historical monitoring data includes: CPU load, memory usage, disk usage, network traffic, etc. during the historical operation of the service node. The specific content of the monitoring data can refer to the other embodiments mentioned above and will not be repeated here. The business log is a log record output during the execution of the system, which is mainly used to track and record the operation of the business system. Specifically, the business log includes detailed information on the distribution of service requests, such as the path of each request distribution and the processing results. As an example, the processing results of the request distribution include information such as request distribution success, failure, and timeout.

[0068] Step S2034, training a machine learning model based on historical monitoring data and business logs to obtain a node prediction model.

[0069] In this embodiment, the node prediction model is a machine learning model trained using the above-mentioned historical monitoring data and business logs. Since the historical monitoring data and business logs refer to data recorded in chronological order, including date, time, and corresponding numerical values ​​or events, the trained model can predict the performance and operating status of the service node. Changing trends.

[0070] In one implementation of the embodiment of the present application, the above step S204 may further include the following steps S2042 and S2044:

[0071] Step S2042, obtaining prediction data of the service node using the node prediction model based on the monitoring data.

[0072] In this embodiment, the collected monitoring data is input into an existing node prediction model to obtain prediction data of the service node. For example, the prediction data is load changes and memory usage trends of the service node over a period of time in the future.

[0073] Step S2044, determining a distribution strategy based on preset distribution rules, prediction data, and monitoring data.

[0074] In this embodiment, the distribution strategy of the service request is determined based on the monitoring data, the preset distribution rules, and the load change and memory usage trend of the service node in the future period obtained in step S2042.

[0075] In one embodiment, when there is a conflict between determining a distribution strategy based on preset distribution rules and monitoring data and determining a distribution strategy based on predicted data, the distribution strategy is determined based on the preset distribution rules. In other words, the preset distribution rules have a higher priority. For example, if the predicted load of a node is low, but the node is restricted to be unavailable by the preset distribution rules for some reason, the node will not be determined as the target service node. In the absence of obvious rule conflicts, the target service node can be determined based on the predicted data (the optimal node is selected).

[0076] In one implementation of the embodiment of the present application, after the above step S206, step S208 may be further included as follows:

[0077] Step S208: In response to an abnormality in the predicted data or the monitored data, an alarm is triggered.

[0078] In this embodiment, after obtaining the monitoring data of the service node or obtaining the prediction data of the service node using the node prediction model, if an abnormality is found in the service node, an alarm may be triggered.

[0079] In one implementation, the abnormality of the service node may be found when the monitoring data of the service node exceeds a preset threshold, such as when the network delay of the service node is too high or the CPU load is too heavy.

[0080] In one implementation of the embodiment of the present application, the distribution strategy further includes: additional resources and service priority. After the above step S206 or step S208, step S210 may be further included, specifically including the following steps S2102 and S2104:

[0081] Step S2102, obtaining the distribution path and processing result of the service request.

[0082] In this embodiment, the distribution path of the service request is used to describe the calling sequence, dependency, priority, etc. between the services that the service request passes through during the system transmission process, and the processing result can be information such as successful request, failed request, timeout request, etc. Among them, a successful request means that the request has been successfully processed and returns the expected result; a failed request means that the request has not been successfully processed; a timeout request means that the request processing time exceeds the preset threshold and other special request processing results caused by abnormalities such as server downtime, security vulnerabilities, etc.

[0083] Step S2104: Optimize the target service node, additional resources, and service priority of the service request according to the distribution path and the processing result.

[0084] In this embodiment, a more effective service distribution strategy can be formulated according to the service request distribution path obtained in step S2102. The following are some specific examples of optimizing the service request distribution strategy:

[0085] Requests are grouped based on their similarities so that multiple related requests can be processed simultaneously. Requests are prioritized based on their importance and urgency. When a service is unavailable, requests are redirected to other available services. Requests are distributed to related services based on specific keywords included in the request path. Dependencies and interactions between different services are analyzed and a service graph is created. The service distribution strategy is adjusted based on the topology in the graph to distribute requests more efficiently.

[0086] In one implementation, a feedback mechanism may be established between services to update the service list according to the processing results, thereby achieving the purpose of automatically adjusting the distribution strategy according to the service processing results.

[0087] In one implementation, the above data can be used to train a suitable machine learning model, such as a support vector machine, random forest, gradient boosting decision tree, neural network, etc., and then the trained model can be used to continuously monitor service performance and availability, capture potential problems and bottlenecks, and add additional resources to certain bottleneck services or adjust service priorities based on actual conditions.

[0088] This embodiment uses a dynamic proxy mechanism to solve the problems of untimely adjustment and uneven node resource utilization in the static proxy case, realizes intelligent service request distribution, and can automatically adjust the request distribution strategy, thereby improving the flexibility and scalability of the system and ensuring the stability and efficiency of the system in a high concurrency environment.

[0089] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art can understand that in order to achieve the effect of the present application, different steps do not have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders. These adjusted schemes are equivalent to the technical schemes described in this application, and therefore will also fall within the scope of protection of this application.

[0090] Another aspect of the present application also provides a service request distribution system, such as Figure 3 As shown, the device includes: a data monitoring module 301, which is used to obtain monitoring data and service requests of service nodes, and the monitoring data is used to reflect the performance and operating status of the service nodes; a policy engine module 302, which is used to determine the distribution strategy based on the monitoring data using preset distribution rules and a node prediction model, and the node prediction model is used to predict the changing trend of the performance and operating status of the service node, and the distribution strategy includes a target service node; a service distribution module 303, which is used to distribute the service request to the target service node according to the distribution strategy.

[0091] In a technical solution of the above-mentioned service request distribution system, the system also includes: a data and log acquisition module, which is used to obtain historical monitoring data and business logs; and a model training module, which is used to train a machine learning model based on historical monitoring data and business logs to obtain a node prediction model.

[0092] In a technical solution of the above-mentioned service request distribution system, the policy engine module includes: a data prediction unit, which is used to obtain prediction data of the service node based on the monitoring data using the node prediction model; and a policy determination unit, which is used to determine the distribution strategy based on preset distribution rules, prediction data and monitoring data.

[0093] In a technical solution of the above-mentioned service request distribution system, the strategy determination unit includes: a priority determination subunit, which is used to determine the distribution strategy based on the preset distribution rules when there is a conflict between the distribution strategy determined based on the preset distribution rules and monitoring data and the distribution strategy determined based on the prediction data.

[0094] In a technical solution of the above service request distribution system, the system further includes: an alarm module, which is used to trigger an alarm in response to an abnormality in the predicted data or the monitored data.

[0095] In a technical solution of the above-mentioned service request distribution system, the distribution strategy also includes: additional resources and service priorities. The system also includes: a path and result acquisition module, which is used to obtain the distribution path and processing results of the service request; a strategy optimization module, which is used to optimize the target service node, additional resources and service priority of the service request according to the distribution path and processing results.

[0096] In a technical solution of the above service request distribution system, the monitoring data includes real-time monitoring data or monitoring data acquired based on a preset time interval.

[0097] Microservices is a software architecture design method that splits an application into a series of small, independent, and composable services. Each service focuses on a single function, and these services are connected to each other through lightweight communication protocols. In an example of an application scenario in this application, Figure 4 FIG. 1 is a schematic diagram of the overall framework of a service request distribution system according to an embodiment of the present application. Figure 4 As shown, the service request distribution system includes a client service layer (client dynamic proxy module), an application access layer, a logic layer (monitoring module, policy engine, log and feedback module) and a storage layer. Among them, the client dynamic proxy module is embedded in the distributed system node, the application access layer is a communication framework such as HTTP, GRpc (Google Remote Procedure Call), Apache Dubbo, etc., which is used to realize the communication between the client and the server, and the storage layer is used to store the relevant data of the service request distribution, and the storage layer is not limited to: MySQL, Elasticsearch, Redis, HDFS (Hadoop Distributed File System) and other databases or file systems.

[0098] Specifically, the monitoring module in the logic layer collects monitoring data, monitors the service nodes through various probes (such as system monitoring, service performance monitoring, etc.), and collects key performance indicators such as the node's CPU load, memory usage, network latency, and I / O (Input / Output) operations. Then, real-time data analysis is performed through the data processor, such as using statistical methods, data flow analysis, or model-based prediction algorithms to evaluate the operating status of the node, calculate the node load balance, response time trend, etc. The above analysis results can be sent to the policy engine through a data transmitter, and the monitoring module can also store the monitoring data and issue an alarm for abnormal data. Among them, data transmission can use notification mechanisms such as message queues, REST APIs, and event-driven.

[0099] The strategy engine uses machine learning models (node ​​prediction models) and rule bases (preset distribution rules) to analyze data based on analysis results and monitoring data, and determines specific distribution strategies through decision modules and decision generators. For specific distribution strategy determination methods, see Figure 2Step S204 of the illustrated embodiment will not be described in detail here. It can be understood that the machine learning model mainly provides prediction information, that is, the prediction results of the machine learning model are used to provide the policy engine with future trend change information of the service node. As an example, the current load of node A is normal, and the model predicts that its load will reach 90% within 10 minutes due to some reasons (such as the execution of periodic tasks). At this time, the policy engine will adjust in advance to distribute subsequent service requests to other nodes. The rule base mainly provides rule information, that is, according to the predefined requirements of the business, to ensure that the decision under specific conditions meets the standards of system security, performance, etc. For example, a node currently has a low load, but it is marked as "under maintenance" or "unavailable", and the rule base will refuse to forward the service request to the node. The combination of prediction information and rule information can follow the principle of "rule priority, prediction auxiliary", that is, the hard restrictions in the rule base have a higher priority. Even if a node predicts a low load, but it is unavailable due to some reasons due to the rule restriction, the policy engine will not select the node as the target service node; when there is no obvious rule conflict, the policy engine will select the optimal node based on the prediction information.

[0100] The log and feedback module includes data collection layer, data processing layer, data storage and data analysis and visualization. It can be used to collect, record and store the distribution path and processing results of each request, and send them to the policy engine as the basis for policy optimization. It can also perform visual analysis and display on the stored data.

[0101] In one implementation, the workflow of the service request distribution system can refer to Figure 5 , the client (consumer) initiates a service request, and the dynamic proxy (module) intercepts the request. The client obtains a service (provider) list (such as all available service nodes) from the registration center. The service request distribution system collects the real-time status of each service node through the monitoring module and passes the data to the policy engine. The policy engine analyzes the data, generates the optimal distribution strategy, returns the optimal service obtained to the client, and instructs the dynamic proxy module to forward the service request to the optimal node (target service node), and finally returns the data according to the execution logic.

[0102] In one implementation, after the service request is processed by the target service node, the log and feedback module will record the relevant information of this distribution. Based on the above information, the policy engine can continuously optimize the distribution strategy and achieve adaptive adjustment.

[0103] In one implementation, service distribution may be performed only for unstable services, ie, service requests that may result in application performance degradation, system crash, or data loss.

[0104] This embodiment achieves the purpose of real-time monitoring of the operating status of each service node and automatically adjusting the request distribution strategy according to preset rules or machine learning algorithms by introducing a dynamic proxy mechanism in the client. The service request distribution system in this embodiment has the following advantages: high flexibility, the system can dynamically adjust the request distribution strategy according to real-time data to adapt to complex and changing business scenarios; maximize resource utilization, through the intelligent request distribution mechanism, ensure the efficient utilization of resources of each service node to avoid overload or idleness; low maintenance cost, the automated distribution strategy adjustment reduces the complexity of system operation and maintenance, and reduces maintenance costs.

[0105] It is understood by those skilled in the art that all or part of the processes in the method for implementing the above-mentioned embodiment of the present application can also be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable storage medium may include: any entity or device, medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory, random access memory, electrical carrier signal, telecommunication signal and software distribution medium, etc. that can carry the computer program code.

[0106] Another aspect of the present application also provides a computer-readable storage medium.

[0107] In an embodiment of a computer-readable storage medium according to the present application, the computer-readable storage medium may be configured to store a program for executing the service request distribution method of the above-mentioned method embodiment, and the program may be loaded and run by a processor to implement the service request distribution method in the above-mentioned first aspect or any technical solution corresponding thereto. For ease of explanation, only the parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present application. The computer-readable storage medium may be a storage device formed by various electronic devices. Optionally, the computer-readable storage medium in the embodiment of the present application is a non-temporary computer-readable storage medium.

[0108] Another aspect of the present application provides an electronic device.

[0109] In an embodiment of an electronic device according to the present application, the electronic device may include at least one processor; and a memory connected to the at least one processor in communication; wherein a computer program is stored in the memory, and when the computer program is executed by the at least one processor, the service request distribution method in the first aspect or any corresponding technical solution thereof is implemented. Figure 6 , Figure 6 Schematically shows that the memory 11 and the processor 12 are connected via a bus communication.

[0110] In some embodiments of the present application, the electronic device may further include at least one sensor, and the sensor is used to sense information. The sensor is connected to any type of processor mentioned in the present application. The electronic device described in the present application may be, but is not limited to, a PC, a mobile phone, a tablet computer, a smart air conditioner, a smart range hood, a smart refrigerator, a smart oven, a smart stove, a smart washing machine, a smart water heater, a smart washing equipment, a smart dishwasher, a smart projection equipment, a smart TV, a smart clothes drying rack, a smart curtain, a smart audio and video, a smart socket, a smart speaker, a smart speaker, a smart fresh air equipment, a smart kitchen and bathroom equipment, a smart bathroom equipment, a smart sweeping robot, a smart window cleaning robot, a smart mopping robot, a smart air purification equipment, a smart steamer, a smart microwave oven, a smart kitchen treasure, a smart purifier, a smart water dispenser, a smart door lock, etc.

[0111] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A service request distribution method, characterized in that: include: Acquire monitoring data and service requests of the service node, wherein the monitoring data is used to reflect the performance and operation status of the service node; Determine a distribution strategy based on the monitoring data using a preset distribution rule and a node prediction model, wherein the node prediction model is used to predict the performance and operating status change trend of the service node, and the distribution strategy includes a target service node; The service request is distributed to the target service node according to the distribution strategy.

2. The service request distribution method according to claim 1, characterized in that: The method further comprises: obtaining historical monitoring data and business logs; A machine learning model is trained based on the historical monitoring data and business logs to obtain the node prediction model.

3. The service request distribution method according to claim 1 or 2, characterized in that: Determining the distribution strategy based on the monitoring data using a preset distribution rule and a node prediction model includes: The node prediction model is used to obtain prediction data of the service node based on the monitoring data; and a distribution strategy is determined based on a preset distribution rule, the prediction data and the monitoring data.

4. The service request distribution method according to claim 3, characterized in that: The determining of the distribution strategy based on the preset distribution rule, the prediction data and the monitoring data includes: When there is a conflict between the distribution strategy determined based on the preset distribution rule and the monitoring data and the distribution strategy determined based on the prediction data, the distribution strategy is determined based on the preset distribution rule first.

5. The service request distribution method according to claim 3, characterized in that: The method further includes: in response to an abnormality in the prediction data or the monitoring data, triggering an alarm.

6. The service request distribution method according to claim 1, characterized in that: The distribution strategy also includes: additional resources and service priority, and the method further includes: Get the distribution path and processing results of the service request; The target service node, additional resources and service priority of the service request are optimized according to the distribution path and the processing result.

7. The service request distribution method according to claim 1, characterized in that: The monitoring data includes real-time monitoring data or monitoring data acquired based on a preset time interval.

8. A service request distribution system, characterized in that: include: A data monitoring module, used to obtain monitoring data and service requests of service nodes, wherein the monitoring data is used to reflect the performance and operation status of the service nodes; A policy engine module, configured to determine a distribution strategy based on the monitoring data using a preset distribution rule and a node prediction model, wherein the node prediction model is configured to predict a performance trend and a change trend of an operation status of the service node, and the distribution strategy includes a target service node; A service distribution module is used to distribute the service request to the target service node according to the distribution strategy.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method according to any one of claims 1 to 7 when executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images