Sharding active exploration method, traffic scheduling method, device, equipment and storage medium

Abstract

Embodiments of the present application provide a method and device for slice alive detection, a method and device for traffic scheduling, and a storage medium, relating to the field of financial technology or other related fields. The method comprises: a load balancer of a unit extracting a domain name and a slice marker in a health check request in response to the health check request sent by a service invoker; determining a target slice based on the domain name and the slice marker; generating a check result and returning the service invoker based on a comparison result of the number or proportion of nodes in a normal state of the target slice and a preset threshold. The method realizes more fine-grained health detection by performing independent alive detection with slice granularity, and improves the accuracy of alive detection.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a method for sharding liveness detection, a traffic scheduling method, an apparatus, an equipment, and a storage medium. Background Technology

[0002] In the fintech sector, with the continuous expansion of business scale and the increasing complexity of system architecture, ensuring high availability, stability, and disaster recovery capabilities has become a critical requirement. Health checks are used to monitor the operational status of service units in real time, ensuring that only healthy units participate in traffic processing.

[0003] In existing technologies, the liveness detection method mainly relies on the service caller sending a health check request to the unit where the service provider is located. These requests are received and processed by the load balancer located in each unit. The load balancer detects the number of live service providers in the current unit and compares it with a preset minimum liveness threshold to generate a health check result, which serves as the basis for determining whether the unit has the capacity to provide services.

[0004] However, in existing technologies, liveness detection methods rely on load balancers comparing the number of live service providers within a unit to a fixed threshold to determine health status. For example, some nodes may still be considered healthy even when some are abnormal or experiencing performance degradation. Therefore, existing technologies suffer from low accuracy in liveness detection. Summary of the Invention

[0005] This application provides a fragmented liveness detection method, a traffic scheduling method, an apparatus, a device, and a storage medium to solve the problem of low liveness detection accuracy in the prior art.

[0006] Firstly, this application provides a sharding liveness detection method applied to a unit's load balancer, wherein the data within the unit is divided into multiple shards, and different shards store different databases. The method includes:

[0007] In response to a health check request sent by the service caller, extract the domain name and sharding tag from the health check request;

[0008] The target shard is determined based on the domain name and the sharding tag;

[0009] Based on the comparison between the number or proportion of nodes in the normal state of the target shard and a preset threshold, an inspection result is generated and returned to the service caller.

[0010] Secondly, this application provides a traffic scheduling method applied to a service caller, the method comprising:

[0011] The inspection results of the target fragment are obtained multiple times consecutively; wherein the inspection results are obtained based on the method provided in the first aspect.

[0012] When the inspection results of the target fragment are obtained multiple times in a row and all indicate that the target fragment is unhealthy, when the call request for the target fragment is converted into a Hypertext Transfer Protocol (HTTP) request, the domain name of the HTTP request is constructed based on the unit identifier of the takeover unit of the unit corresponding to the target fragment.

[0013] Send the HTTP request.

[0014] Thirdly, this application provides a sharding liveness detection device applied to a unit's load balancer, wherein the data within the unit is divided into multiple shards, and different shards store different databases. The device includes:

[0015] The parameter extraction module is used to extract the domain name and sharding tag from the health check request sent by the service caller in response to the health check request.

[0016] The sharding determination module is used to determine the target shard based on the domain name and the sharding tag;

[0017] The health check module is used to generate check results and return them to the service caller based on the comparison results of the number or proportion of nodes in the normal state of the target shard with a preset threshold.

[0018] Fourthly, this application provides a traffic scheduling device applied to a service caller, the device comprising:

[0019] The inspection result acquisition module is used to acquire the inspection results of the target fragment multiple times consecutively; wherein the inspection results are obtained based on the method provided in the first aspect;

[0020] The traffic scheduling module is used to convert the call request for the target shard into an HTTP request and construct the domain name of the HTTP request based on the unit identifier of the takeover unit corresponding to the target shard when the check results of the target shard are obtained multiple times in a row and the target shard is unhealthy.

[0021] The request initiation module is used to send the HTTP request.

[0022] Fifthly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the methods provided in the first aspect and the second aspect above.

[0023] In a sixth aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the first aspect and the second aspect above.

[0024] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the first aspect and the second aspect.

[0025] The sharding liveness detection method, traffic scheduling method, apparatus, device, and storage medium provided in this application involve a load balancer in a unit responding to a health check request sent by a service caller, extracting the domain name and sharding tag from the health check request; determining the target shard based on the domain name and the sharding tag; generating a check result and returning it to the service caller based on a comparison of the number or proportion of nodes in the target shard in a normal state with a preset threshold; this method achieves finer-grained health detection by performing independent liveness detection at the shard level, thereby improving the accuracy of liveness detection. Attached Figure Description

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

[0027] Figure 1 An application scenario diagram provided for an embodiment of this application;

[0028] Figure 2 A schematic flowchart of a segmented liveness detection method provided in an embodiment of this application;

[0029] Figure 3 A flowchart illustrating a traffic scheduling method provided in an embodiment of this application;

[0030] Figure 4 A relationship diagram of service caller, unit, and fragmentation provided in an embodiment of this application;

[0031] Figure 5 A flowchart illustrating a fragmentation detection method and a traffic scheduling method provided in an embodiment of this application;

[0032] Figure 6 This is a schematic diagram of the structure of a segmented liveness detection device provided in an embodiment of this application;

[0033] Figure 7 This is a schematic diagram of the structure of a traffic scheduling device provided in an embodiment of this application;

[0034] Figure 8This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0035] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0036] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0037] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0038] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0039] It should be noted that the sharding liveness detection method, traffic scheduling method, apparatus, equipment and storage medium provided in this application can be used in the fintech field, or in any field other than fintech. The application fields of the sharding liveness detection method, traffic scheduling method, apparatus, equipment and storage medium in this application are not limited.

[0040] Figure 1 This is an application scenario diagram provided for an embodiment of this application. For example... Figure 1As shown, this application is applied to a scenario where a service caller sends a health check request to the load balancer of the unit. Specifically, before a user initiates a transfer transaction, the bank's online payment processing platform (i.e., the service caller) needs to call the account balance query service (i.e., the unit) to confirm the account status. To ensure the availability of this service, the platform proactively sends a health check request to the unit load balancer responsible for the service through its system devices. The purpose of this health check request is to detect whether the specific node providing the service (i.e., the target shard) is in a normal operating state, preventing subsequent business requests from being sent to faulty or unavailable nodes. After receiving the health check request, the load balancer generates a check result based on the current actual operating status of the specific node providing the service and returns the result to the bank's online payment processing platform.

[0041] If a bank's online payment processing platform receives multiple consecutive checks indicating that a specific node providing a service is unhealthy, it considers that the node is temporarily unable to provide service. In this case, if there is still a need to call that specific node, the bank's online payment processing platform will convert the original service call request into HTTP (Hypertext Transfer Protocol) format. Based on the identifier information (such as a domain name or IP address) of the takeover unit corresponding to the specific node providing the service, the platform will construct the HTTP request's domain name. Subsequently, the constructed HTTP request will be sent to a load balancer, which will forward the request to a healthy takeover unit, thereby ensuring the continuous operation of critical business processes such as payments.

[0042] As business scale continues to expand and system architecture becomes increasingly complex, the health check mechanism serves as a crucial support for system stability. It is used to monitor the operational status of service units in real time, ensuring that only healthy units participate in traffic processing. Traffic scheduling, on the other hand, dynamically adjusts request routes based on the health check results, achieving fault isolation, load balancing, and automatic takeover.

[0043] In existing technologies, the liveness detection method mainly relies on the service caller sending a health check request to the target unit, which is then received and processed by the load balancers deployed in each unit. The load balancer counts the number of live service providers within the unit and compares it with a preset minimum liveness threshold to generate a health check result, which serves as the basis for determining whether the unit has the capability to provide services.

[0044] However, some units may exhibit issues such as response delays, increased error rates, or decreased processing capacity, yet they may still be deemed healthy. Therefore, existing liveness detection methods have low accuracy and are insufficient to meet the requirements of refined flow control.

[0045] The sharding liveness detection method provided in this application aims to solve the aforementioned technical problems of the prior art. Specifically, after receiving a health check request from a service caller, the load balancer of the unit first extracts the domain name and sharding tag involved in the request, and locates the corresponding target shard accordingly. Subsequently, the load balancer generates the corresponding health check result based on the comparison between the number or proportion of normal nodes in the target shard and a preset threshold, and returns it to the service caller. This method achieves finer-grained health detection by performing independent liveness detection at the shard level, thereby improving the accuracy of liveness detection.

[0046] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0047] Figure 2 This is a flowchart illustrating a segmented liveness detection method provided in an embodiment of this application. The method provided in this application can be... Figure 1 The load balancer within a unit can be executed, or it can be executed by a device that communicates with the unit's load balancer, such as a computer or server. Within a unit, data is divided into multiple shards, and different shards store different databases. For example... Figure 2 As shown, the segmented liveness detection method provided in this embodiment includes the following steps:

[0048] Step S201: In response to the health check request sent by the service caller, extract the domain name and fragmentation tag from the health check request.

[0049] In this context, the service caller is the party that initiates the interaction. It sends a health check request to the unit's load balancer. This request includes a domain name used to identify the service or data set and a shard tag used to distinguish different data shards.

[0050] Health check requests include the domain name and shard tag. Health check requests are a proactive way to probe the health status of shard nodes, verifying shard availability and collecting status data in real time by carrying the domain name and shard tag.

[0051] A domain name is one of the key pieces of information contained in a health check request. It is an identifier used to identify the network location of the target service and is usually composed of multiple parts (such as hostname, organization name, network type name, and top-level domain).

[0052] The shard identifier can be the context root in the request header, the content of the shard field, or extracted from the domain name (where a certain field in the domain name is the shard identifier), or it can be directly carried in the request message. It is a key information element contained in a health check request; it is a specific identifier used to distinguish and identify different shard nodes. In a distributed system or sharded architecture, when probing the health status of numerous shard nodes, the shard identifier can accurately locate the specific shard.

[0053] A Server Load Balancer (SLB) is used to distribute traffic to various shards within a given unit, thereby balancing the load on each shard. A single SLB is dedicated to managing traffic distribution within a single unit, ensuring both the independence and controllability of traffic scheduling within that unit and simplifying traffic management complexity.

[0054] During health check operations, combining domain name and shard tagging can accurately locate specific shards, enabling effective management, status monitoring, and availability verification of shard nodes. The synergy between the two ensures accurate access, efficient operation, and stable reliability of the load balancer.

[0055] Specifically, in a distributed service architecture, service callers, to ensure the normal operation of the service nodes they depend on, periodically or on demand send health check requests to the unit's load balancer. This request is used to probe the health status of the service. When the unit's load balancer receives a health check request from the service caller, it initiates an analysis and processing flow of the request content, extracting the domain name and sharding tags.

[0056] For example, in a bank's distributed core system, the account query service is deployed across multiple units. Each unit contains multiple shard nodes that process account data for different customer groups, and the unit's load balancer is responsible for traffic distribution. When the mobile banking app (Application) initiates a health check request for an account query as a service caller, the request carries the domain name and sharding tag. After receiving the request, the load balancer extracts the domain name and sharding tag by parsing the request header or specific fields.

[0057] Step S202: Determine the target shard based on the domain name and shard tag.

[0058] The target shard can be a single shard within the unit or any of the shards within the unit. The target shard is a specific data or service processing node precisely located by the unit's load balancer based on the domain name and shard tag carried in the health check request sent by the service caller.

[0059] For example, in a bank's distributed core system, the account inquiry service is deployed across multiple units based on the customer's account opening region, such as the East China unit, the North China unit, and the South China unit. Each unit is further divided into multiple shard nodes based on the customer's asset size. For example, the East China unit includes shards for high-net-worth customers and shards for ordinary customers, used to process account data for different customer groups.

[0060] When a user initiates a health check request for account inquiry through the mobile banking app, assuming the user is a high-net-worth client in East China, the domain name carried in the request relates to the account inquiry service; the fragmentation tag points to the high-net-worth client group in East China.

[0061] Upon receiving this request, the load balancer in the East China unit will extract the domain name and sharding tag by parsing the request header or specific fields. Based on the domain name, the load balancer determines that the request is for the account query service and belongs to the East China unit; combined with the sharding tag, the load balancer can accurately locate the high-net-worth client shard that specifically handles high-net-worth client account data in East China from among the multiple sharding nodes in the East China unit as the target shard.

[0062] Step S203: Based on the comparison result of the number or proportion of nodes in the normal state of the target shard with the preset threshold, generate the inspection result and return it to the service caller.

[0063] Among them, nodes in the target shard in normal condition refer to server nodes in the shard that can provide services normally, and these nodes have not experienced downtime, overload, network failure or other situations that affect service.

[0064] The preset threshold is a standard set according to business needs and fault tolerance capabilities, used to determine whether the target shard can process business normally.

[0065] Specifically, in distributed systems, to ensure service reliability and availability, services are typically split and deployed across multiple units, each containing multiple shard nodes to handle specific business logic. The unit's load balancer is responsible for monitoring the status of these nodes, and when it receives a health check request from a service caller (such as a mobile banking app), it first determines the target shard.

[0066] The load balancer counts the number of nodes in a normal state within the target shard, or calculates the percentage of these normal nodes among all nodes in the shard. Then, the load balancer compares the counted number or percentage of normal nodes with a pre-set threshold.

[0067] Finally, the load balancer generates a check result based on the comparison results. The load balancer then returns this check result to the service caller, allowing the caller to take appropriate action, such as continuing to initiate business requests or selecting other available services.

[0068] Optionally, the inspection results include a first inspection result and a second inspection result. The inspection results are generated based on the comparison between the number or proportion of nodes in the normal state of the target shard and a preset threshold. The results include: if the number or proportion of nodes in the normal state of the target shard is greater than or equal to the preset threshold, a first inspection result is generated; if the number or proportion of nodes in the normal state of the target shard is less than the preset threshold, a second inspection result is generated.

[0069] The inspection results are clearly divided into a first inspection result and a second inspection result. The first inspection result represents a healthy inspection result, meaning that the target shard is in a normal working state, has sufficient resources and service capabilities to handle business requests, and can operate stably and efficiently. The second inspection result represents an unhealthy inspection result, indicating that the target shard may have problems such as failure, overload, or insufficient resources, and cannot provide services normally. Business requests may be affected or even cannot be processed.

[0070] If the number of nodes in the target shard that are in a normal state, or the calculated percentage of nodes in a normal state in all nodes of the shard, is greater than or equal to this preset threshold, it indicates that the target shard currently has a sufficient number of normal nodes to support business processing and has the ability to provide stable services. At this time, the first check result will be generated, which means that the target shard is in a healthy and usable state. Subsequent service callers can confidently allocate business requests to the shard for processing based on this result.

[0071] If the number of nodes in a normal state, or the percentage of nodes in a normal state among all nodes in a shard, is found to be lower than a pre-set threshold, it means that there are not enough normally functioning nodes in the target shard. This may prevent the effective processing of business requests and pose a risk of service degradation or even interruption. In this case, a second check result will be generated, which usually indicates that the target shard is in an unhealthy state. Service callers need to adjust their strategies in a timely manner based on this result to avoid sending business requests to this shard and prevent service anomalies.

[0072] The sharding liveness detection method provided in this embodiment responds to a health check request sent by a service caller, extracts the domain name and sharding tag from the health check request, determines the target shard based on the domain name and sharding tag, and generates a check result based on the comparison result of the number or proportion of nodes in the target shard in a normal state with a preset threshold and returns it to the service caller. This method achieves finer-grained health detection by performing independent liveness detection at the sharding level, thereby improving the accuracy of liveness detection.

[0073] In some embodiments, a method for determining the number of nodes in a normal state of a target shard includes: checking the state of each node in a unit through a preset thread; and after determining the target shard, counting the number of nodes in a normal state of the target shard based on the state of each node obtained in the last check.

[0074] Among them, the preset thread is a specific thread that is planned and created in advance. It performs status checks on each node in the unit and continuously checks the nodes in the unit according to the pre-set rules to obtain information such as whether each node is online, whether it can respond to commands normally, and whether resource usage is within a reasonable range.

[0075] For example, in a bank's distributed core system, to improve the efficiency and stability of account inquiry services, this service is split and deployed across multiple units based on the customer's account opening region (e.g., North China, East China, South China). The system has a preset thread that checks the node status in each unit every 10 minutes. The checks include whether the nodes are running normally, whether they can quickly respond to account inquiry requests, whether the database connection is stable, and whether memory usage is within reasonable thresholds. When the target shard is the East China account inquiry shard, the status information of the relevant nodes in this shard is extracted from the last check record. It is found that this shard has 15 nodes, of which 13 nodes are functioning normally and can efficiently handle account inquiry business, while the other 2 nodes experienced response timeouts. Ultimately, the number of nodes in normal condition for this target shard is calculated to be 13.

[0076] In some embodiments, the target fragment is a fragment of each of the multiple units, and the inspection result includes the unit corresponding to each target fragment.

[0077] In distributed system architectures, to improve scalability, fault tolerance, and performance, services or data are typically split and deployed across multiple units according to certain rules. Each unit can be viewed as a relatively independent subsystem, undertaking specific business functions or data storage tasks. Target shards are further subdivisions within these units, representing a more granular division of resources or services within a unit. For example, in a distributed system of a large e-commerce platform, data from different regions (such as East China, North China, and South China) can be deployed in different units. Within each regional unit, multiple target shards can be further divided based on product categories (such as clothing, digital products, and food). This approach enables more efficient handling of various business requests and achieves rational allocation and utilization of resources.

[0078] By reviewing the inspection results, the operational status of each target shard within its unit can be understood, allowing for rapid location of the problem. For example, when a target shard fails, the unit to which it belongs can be quickly identified through the inspection results, facilitating in-depth investigation and repair of that unit. Secondly, this inclusion relationship aids in fault isolation and recovery. If a target shard within a unit experiences a problem, knowing its unit allows for targeted measures, such as isolating other healthy target shards within that unit from the faulty shard to prevent the fault from spreading, while simultaneously repairing or replacing the faulty shard without affecting the normal operation of other units. Understanding the unit status corresponding to each target shard allows for the rational allocation of service requests to different target shards based on the unit's load, improving overall system performance and response speed. For instance, when a unit's load is low, more service requests can be allocated to the target shards within that unit to fully utilize system resources.

[0079] Figure 3 This is a flowchart illustrating a traffic scheduling method provided in an embodiment of this application. The method provided in this application can be... Figure 1 The service can be executed by the service caller, or by a device that communicates with the service caller, such as a computer or server. Figure 3 As shown, the traffic scheduling method provided in this embodiment includes the following steps:

[0080] Step S301: Obtain the inspection results of the target fragment multiple times consecutively.

[0081] For example, in a distributed system scenario, to ensure the accuracy of the target shard inspection results, since the target shard may be affected by factors such as network fluctuations and temporary hardware failures, resulting in unstable states or momentary anomalies, it is necessary to obtain the target shard inspection results multiple times consecutively. This multiple timeout can be set to three times, with no specific limit on the exact number. By performing multiple consecutive inspections, the results are analyzed to more accurately determine the actual operating state of the target shard, avoiding misjudgments due to inaccurate single inspection results. This ensures that the service caller makes correct decisions based on the inspection results, maintaining the stable operation of the service caller.

[0082] Optionally, obtaining the inspection results of the target shard includes: calculating the shard tag of the target shard to be inspected and adding the shard tag to the health check request; the domain name of the health check request is determined based on the unit corresponding to the target shard; and sending a health check request to obtain the inspection results of the target shard.

[0083] First, the service caller calculates the shard tag for the target shard to be inspected. This shard tag is a key piece of information that uniquely identifies the shard and is used to explicitly specify which shard needs to be inspected in subsequent requests.

[0084] Next, the service caller will add the shard tag to the constructed health check request as part of the request parameters or HTTP request header. Simultaneously, the domain name of this health check request will be determined based on the service unit to which the target shard belongs. In other words, this domain name points to the health check interface address of the unit where the shard resides, ensuring that the request can be correctly routed to the corresponding unit for processing.

[0085] Finally, the service caller will send the health check request to the load balancer of the corresponding unit. After receiving the request, the unit's load balancer will perform a health status check on the target shard according to the sharding tag and return the corresponding check result (such as healthy or unhealthy).

[0086] Optionally, obtaining the inspection results of the target fragment includes: in response to the preset switch being in the on state, calculating the fragment tag of the target fragment to be inspected, and adding the fragment tag to the health check request; sending a health check request to obtain the inspection results of the target fragment.

[0087] To accurately obtain the health status of the target shard, the service caller will first determine whether the execution conditions are met before performing a health check operation. Specifically, the service caller will check whether a preset switch is in the "on" state. This switch controls whether the health check process for the target shard is enabled, thus playing a control role.

[0088] The service caller will only proceed with subsequent health check steps when this preset switch is enabled. First, the service caller calculates the shard tag of the target shard to be checked, which is a key piece of information that uniquely identifies the target shard. Then, the service caller embeds this shard tag into the constructed health check request, usually as a request parameter or part of the HTTP request header, so that the backend service can identify which shard needs to be checked.

[0089] Finally, the service caller sends the health check request to the corresponding health check service interface. By parsing the returned result, the service caller can obtain the check result of the target shard (such as "healthy" or "unhealthy"), and thus decide whether to continue to initiate business calls to that shard, or to take measures such as failover or unit takeover.

[0090] Step S302: When the inspection results of the target shard obtained multiple times indicate that the target shard is unhealthy, for the call request of the target shard, the call request is converted into an HTTP request, and the domain name of the HTTP request is constructed based on the unit identifier of the takeover unit corresponding to the target shard.

[0091] If the service caller receives multiple consecutive check results for the target shard indicating that the shard is unhealthy (i.e., the second check result), it means that the shard is currently unable to process requests normally. In this case, to ensure service availability and stability, the caller will no longer send requests directly to the target shard.

[0092] For these call requests that should originally be sent to the target shard (e.g., RPC requests (Remote Procedure Calls)), the service caller will adjust and transform the request path. Specifically, the original RPC call request will be converted into an HTTP request, and the identifier of the designated takeover unit will be found based on the service unit information corresponding to the target shard.

[0093] When constructing this HTTP request, the service caller uses the unit identifier of the takeover unit to generate a new request domain name. This automatically forwards requests that would otherwise be sent to unhealthy shards to other units specified by the service caller that have takeover capabilities for processing.

[0094] In this way, even if a certain shard or service unit fails, the service caller can automatically route its request to a healthy unit, thereby achieving fault isolation and fault tolerance.

[0095] Step S303: Send an HTTP request.

[0096] When the service caller converts the original RPC request into an HTTP request and constructs a new domain name based on the identifier of the takeover unit, the HTTP request will be sent to the load balancer corresponding to the target unit, which is the unit SLB.

[0097] In some embodiments, when the target unit is unhealthy, a method for sending a request to dispatch traffic to the takeover unit of the target unit includes: when the state of a preset switch is closed, obtaining the inspection results of the target unit multiple times consecutively; when the inspection results obtained multiple times consecutively indicate that the target unit is unhealthy, for the call request of the target unit, converting the call request into an HTTP request, constructing the domain name of the HTTP request based on the unit identifier of the takeover unit of the target unit, and sending the HTTP request.

[0098] When the preset switch is detected to be in the off state, it means that the health status at the segment level will no longer be finely checked, but the health check will be moved from the target segment to the target cell level.

[0099] At this point, the service caller will continuously retrieve the health check results of the target unit multiple times. The target unit here refers to a service unit containing multiple shards, and its health status represents the overall availability of the entire unit. By retrieving the check results multiple times, it is possible to more accurately determine whether the unit is truly in an abnormal state, avoiding misjudgments due to occasional failures.

[0100] When multiple consecutive checks indicate that the target unit is unhealthy, all calls (such as RPC requests) that should have been sent to that unit will be routed differently. Specifically, these requests will be converted into HTTP requests, and the domain name of the HTTP request will be reconstructed based on the identification information of the takeover unit configured for that target unit.

[0101] Finally, the service caller sends the completed HTTP request to the load balancer of the corresponding takeover unit, which then routes the request to the specific service node within the takeover unit. This step enables unit-level failover and traffic switching, ensuring that services continue to operate normally even if the target unit becomes unavailable.

[0102] In some embodiments, a method for sending a health check request to a target unit and obtaining the check result includes: in response to a preset switch being in a closed state, constructing a domain name using the unit identifier of the target unit, generating a health check request for the target unit; and sending the health check request to obtain the check result of the target unit.

[0103] When the preset switch is detected to be in the off state, it indicates that health status checks at the shard level are no longer performed; instead, the granularity of health checks is increased to the target unit level. At this point, a unit-level health check strategy is used to determine whether the entire service unit is in an available state.

[0104] In this mode, the service caller constructs a domain name for health checks based on the target unit's unit identifier. This domain name typically points to the health check interface address corresponding to that unit. Health check requests constructed using this domain name can accurately locate the target unit's health check service endpoint.

[0105] The health check request will then be sent, and the system will wait for the backend to return the check results. The returned results will reflect the overall health status of the target unit, such as healthy or unhealthy.

[0106] In some embodiments, the method of sending a traffic scheduling request includes: when the inspection result of the target shard indicates that the target shard is healthy, for the target shard, a call request is made, the call request is converted into an HTTP request, and a domain name of the HTTP request is constructed based on the unit identifier of the unit corresponding to the target shard; and the HTTP request is sent.

[0107] When the check result of the target shard is obtained and it is determined that the target shard is in a healthy state, it means that the shard currently has the ability to process requests normally. At this time, the call requests originally intended for that shard can continue to be forwarded for processing.

[0108] These calls (e.g., originally RPC requests) are converted into HTTP requests for routing and transmission within a unified service governance framework. During the construction of this HTTP request, the request domain name is generated based on the unit identifier of the service unit corresponding to the target shard.

[0109] Once the request is completed, it is sent out and distributed to the specific service node within the service unit to which the target shard belongs for processing. This method achieves normal access path control for healthy shards while maintaining the flexibility of the call chain.

[0110] The traffic scheduling method provided in this embodiment involves the service caller repeatedly obtaining the check results of the target shard. When the check results of the target shard repeatedly indicate that the target shard is unhealthy, for the call request of the target shard, when converting the call request into an HTTP request, the domain name of the HTTP request is constructed based on the unit identifier of the takeover unit corresponding to the target shard. The HTTP request is then sent to the load balancer. This method automatically switches the call request to the takeover unit when the target shard remains unhealthy, thereby realizing traffic transfer and service assurance in fault scenarios.

[0111] Figure 4 This application provides a diagram illustrating the relationship between a service caller, a unit, and a fragment. For example... Figure 4 As shown, the load balancer applied to the unit is the processing layer. The data within the unit is divided into multiple shards, and different shards store different databases, including:

[0112] The unit consists of Unit 1 and Unit 2. The service caller is responsible for initiating the health check request, and the unit is the core part of the service provision. Each unit is further processed by data sharding.

[0113] Service callers interact with units by carrying a "unit + shard route" identifier. That is, when a service caller initiates a health check request, it needs to explicitly specify the target unit and the target shard within that unit.

[0114] The processing layer, acting as a load balancer applied to the unit, is responsible for receiving health check requests from service callers and routing the requests to the appropriate shards based on the sharding information in the health check requests. The processing layer plays a crucial role in request distribution and load balancing, ensuring that requests are efficiently allocated to suitable shards for processing.

[0115] The data within a unit is divided into multiple shards, and different shards store different databases. For example, unit 1 contains: shard 1, ..., shard n, and unit 2 contains: shard n+1, ..., shard 2n.

[0116] When a service caller initiates a health check request, the target unit and the target shard within that unit are first determined. The health check request is then sent to the processing layer of the corresponding unit. Upon receiving the health check request, the processing layer routes the request to the appropriate shard for processing based on the shard information within the request. After processing the request, the shard returns the result to the processing layer, which then returns the result to the service caller.

[0117] Figure 5 This is a flowchart illustrating a fragmentation-based liveness detection method and a traffic scheduling method provided in an embodiment of this application. Figure 5 The diagram illustrates the interaction between the consumer (i.e., the service caller) and the provider (i.e., the service provider where the unit's load balancer (SLB) resides). The following is a description of... Figure 5 Detailed explanation:

[0118] The provider configures the SLB load balancing strategy for unit health checks according to the "cluster + unit + shard" configuration; sets the minimum survival threshold (i.e., the preset threshold) for the provider at the "cluster + unit + shard" granularity; and adds global configuration for distributed services: the mapping relationship between shards and units.

[0119] The consumer initiates a unit health check request (i.e., a health check request), the provider performs the health check and returns the result (i.e., the check result), and the consumer determines the traffic scheduling strategy based on the result. The consumer initiates a unit health check HTTP request (HTTP request 1, i.e., the health check request) according to "cluster + unit + shard 1" (i.e., shard tag), and sends it to the provider.

[0120] SLB compares the number of surviving units on the provider with a pre-set minimum survival threshold. If the number of surviving units is greater than or equal to the threshold, the unit is considered healthy, and a health check result (healthy) along with the fragment and unit mapping is returned to the consumer. If the number of surviving units is less than the threshold, the unit is considered unhealthy, and a health check result (unhealthy) along with the fragment and unit mapping is also returned to the consumer.

[0121] The consumer initiates health check HTTP requests (HTTP request 2) for each unit and shard according to the "cluster + unit + shard" model, and sends them to the provider. The provider repeats the above health check logic (comparing with the SLB minimum survival threshold) for each shard's health check request and returns the result.

[0122] If a unit is found to be unhealthy after three consecutive checks, it is considered unhealthy, triggering a unit takeover process. Subsequently, cross-unit HTTP requests are initiated according to the "cluster + target unit takeover unit + shard" model to switch traffic to the takeover unit.

[0123] If the unit is healthy, the unit routing will be executed normally, and the unit will continue to provide services.

[0124] Figure 6 This is a schematic diagram of a segmented liveness detection device provided in an embodiment of this application. Figure 6 As shown, the sharding detection device provided in this embodiment is applied to the load balancer of a unit. The data within the unit is divided into multiple shards, and different shards store different databases. It includes: parameter extraction module 401, sharding determination module 402, and health check module 403.

[0125] The parameter extraction module 401 is used to extract the domain name and sharding tag from the health check request in response to the health check request sent by the service caller.

[0126] The sharding determination module 402 is used to determine the target shard based on the domain name and sharding tag;

[0127] The health check module 403 is used to generate check results and return them to the service caller based on the comparison results of the number or proportion of nodes in the normal state of the target shard with a preset threshold.

[0128] Optional, health check module 403, specifically used for:

[0129] If the number or percentage of nodes in the target shard that are in a normal state is greater than or equal to a preset threshold, a first check result is generated; if the number or percentage of nodes in the target shard that are in a normal state is less than the preset threshold, a second check result is generated.

[0130] Optionally, the segmented liveness detection device also includes: a quantity statistics module 404, specifically used for:

[0131] The status of each node in the unit is checked by a preset thread; after the target shard is determined, the number of nodes in the target shard in normal status is counted based on the status of each node obtained from the last check.

[0132] Optionally, the segmented liveness detection device also includes: an information processing module 405, specifically used for:

[0133] The target fragment is a fragment of each cell in a multi-cell set, and the inspection result includes the cells corresponding to each target fragment.

[0134] The segmented liveness detection device provided in this application can be used to execute the segmented liveness detection method provided in any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be described again here.

[0135] Figure 7 This is a schematic diagram of a traffic scheduling device provided in an embodiment of this application. Figure 7 As shown, the traffic scheduling device provided in this embodiment is applied to the service caller and includes: a check result acquisition module 501, a traffic scheduling module 502, and a request initiation module 503.

[0136] The inspection result acquisition module 501 is used to acquire the inspection results of the target fragment multiple times consecutively; wherein the inspection results are obtained based on the method provided in the above embodiments;

[0137] The traffic scheduling module 502 is used to convert the call request for the target shard into an HTTP request and construct the domain name of the HTTP request based on the unit identifier of the takeover unit corresponding to the target shard when the check results of the target shard are obtained multiple times in a row and the target shard is unhealthy.

[0138] Request initiation module 503 is used to send HTTP requests.

[0139] Optionally, the inspection result acquisition module 501 is specifically used for:

[0140] Calculate the fragment tag of the target fragment to be inspected and add the fragment tag to the health check request; the domain name of the health check request is determined based on the unit corresponding to the target fragment; send the health check request to obtain the inspection result of the target fragment.

[0141] Optionally, the inspection result acquisition module 501 is specifically used for:

[0142] In response to the preset switch being in the ON state, the fragment tag of the target fragment to be inspected is calculated and added to the health check request; a health check request is sent to obtain the inspection results of the target fragment.

[0143] Optionally, the traffic scheduling device further includes: a takeover request initiation module 504, specifically used for:

[0144] When the preset switch is in the off state, the inspection results of the target unit are obtained multiple times in succession; when the inspection results obtained multiple times indicate that the target unit is unhealthy, for the call request of the target unit, the call request is converted into an HTTP request, and the domain name of the HTTP request is constructed based on the unit identifier of the takeover unit of the target unit; and the HTTP request is sent.

[0145] Optionally, request initiation module 503 is used specifically for:

[0146] In response to the preset switch being in the off state, a domain name is constructed using the target unit's unit identifier, and a health check request for the target unit is generated; the health check request is sent to obtain the check results of the target unit.

[0147] Optionally, request initiation module 503 is used specifically for:

[0148] When the inspection result of the target shard indicates that the target shard is healthy, for the call request to the target shard, the call request is converted into an HTTP request, and the domain name of the HTTP request is constructed based on the unit identifier of the unit corresponding to the target shard; then the HTTP request is sent.

[0149] The traffic scheduling device provided in this application can be used to execute the traffic scheduling method provided in any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be described again here.

[0150] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device of this embodiment may include: at least one processor 601; and a memory 602 communicatively connected to the at least one processor; wherein the memory 602 stores instructions that can be executed by the at least one processor 601, and the instructions are executed by the at least one processor 601 to cause the electronic device to perform the method as described in any of the above embodiments.

[0151] Optionally, the memory 602 can be either standalone or integrated with the processor 601. When the memory 602 is set up independently, the device also includes a bus for connecting the memory 602 and the processor 601.

[0152] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0153] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, the methods provided in any of the foregoing embodiments can be implemented.

[0154] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in any of the foregoing embodiments.

[0155] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0156] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0157] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0158] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0159] Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as resistive random access memory (RRAM), dynamic random access memory (DRAM), static random access memory (SRAM), enhanced dynamic random access memory (EDRAM), high-bandwidth memory (HBM), hybrid memory cube (HMC), etc.

[0160] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, 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. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0161] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0162] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0163] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for segmented liveness detection, characterized in that, A load balancer applied to a unit, wherein data within the unit is divided into multiple shards, and different shards store different databases, the method includes: In response to a health check request sent by a service caller, the domain name and shard tag in the health check request are extracted; wherein, the shard tag is used to distinguish and identify specific identifiers of different shard nodes; The target shard is determined based on the domain name and the sharding tag; Based on the comparison between the number or proportion of nodes in the normal state of the target shard and a preset threshold, an inspection result is generated and returned to the service caller; The method further includes: The status of each node in the unit is checked using a preset thread; After determining the target shard, the number of nodes in the target shard in a normal state is counted based on the state of each node obtained from the last check.

2. The method according to claim 1, characterized in that, The inspection results include a first inspection result and a second inspection result. The inspection results are generated based on the comparison between the number or proportion of nodes in the normal state of the target shard and a preset threshold, including: If the number or proportion of nodes in the target shard in a normal state is greater than or equal to the preset threshold, then the first inspection result is generated; If the number or percentage of nodes in the target shard in a normal state is less than the preset threshold, then the second inspection result is generated.

3. The method according to any one of claims 1-2, characterized in that, The target fragment is a fragment of each unit in a plurality of units, and the inspection result includes the unit corresponding to each target fragment.

4. A traffic scheduling method, characterized in that, Applied to the service caller, the method includes: The inspection results of the target fragment are obtained multiple times consecutively; wherein the inspection results are obtained based on the method provided in any one of claims 1-3; When the inspection results of the target fragment are obtained multiple times in a row and all indicate that the target fragment is unhealthy, when the call request for the target fragment is converted into a Hypertext Transfer Protocol (HTTP) request, the domain name of the HTTP request is constructed based on the unit identifier of the takeover unit of the unit corresponding to the target fragment. Send the HTTP request.

5. The method according to claim 4, characterized in that, The process of obtaining the inspection results of the target fragment includes: Calculate the fragment tag of the target fragment to be inspected, and add the fragment tag to the health check request; the domain name of the health check request is determined based on the unit corresponding to the target fragment; Send the health check request to obtain the check results of the target fragment.

6. The method according to claim 4, characterized in that, The process of obtaining the inspection results of the target fragment includes: In response to the preset switch being in the on state, the fragmentation mark of the target fragment to be inspected is calculated, and the fragmentation mark is added to the health check request; Send the health check request to obtain the check results of the target fragment.

7. The method according to claim 6, characterized in that, The method further includes: When the preset switch is in the off state, the inspection results of the target unit are acquired multiple times consecutively; When multiple consecutive inspection results indicate that the target unit is unhealthy, for the call request of the target unit, the call request is converted into an HTTP request, and the domain name of the HTTP request is constructed based on the unit identifier of the takeover unit of the target unit; Send the HTTP request.

8. The method according to claim 7, characterized in that, The method further includes: In response to the preset switch being in the off state, a domain name is constructed using the unit identifier of the target unit, and a health check request for the target unit is generated; Send the health check request to obtain the check results of the target unit.

9. The method according to any one of claims 4-8, characterized in that, The method further includes: When the inspection result of the target shard indicates that the target shard is healthy, for the call request of the target shard, the call request is converted into an HTTP request, and the domain name of the HTTP request is constructed based on the unit identifier of the unit corresponding to the target shard; Send the HTTP request.

10. A segmented liveness detection device, characterized in that, A load balancer applied to a unit, wherein the data within the unit is divided into multiple shards, and different shards store different databases; the device includes: The parameter extraction module is used to extract the domain name and sharding tag from the health check request sent by the service caller in response to the health check request; wherein the sharding tag is used to distinguish and identify the specific identifier of different sharding nodes; The sharding determination module is used to determine the target shard based on the domain name and the sharding tag; The health check module is used to generate check results and return them to the service caller based on the comparison results of the number or proportion of nodes in the normal state of the target shard with a preset threshold. The health check module is also used to check the status of each node in the unit through a preset thread; after determining the target shard, it counts the number of nodes in the target shard in a normal state based on the status of each node obtained from the last check.

11. A flow scheduling device, characterized in that, Applied to a service caller, the device includes: The inspection result acquisition module is used to acquire the inspection results of the target fragment multiple times consecutively; wherein the inspection results are obtained based on the method provided by any one of claims 1-3; The traffic scheduling module is used to convert the call request for the target shard into an HTTP request and construct the domain name of the HTTP request based on the unit identifier of the takeover unit corresponding to the target shard when the check results of the target shard are obtained multiple times in a row and the target shard is unhealthy. The request initiation module is used to send the HTTP request.

12. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.

14. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-9.

Images