Cross-unit service registration and discovery methods, routing and scheduling methods, devices and media

Abstract

This application provides a cross-unit service registration and discovery method, a routing and scheduling method, a device, and a medium, relating to the field of computer technology. The method is applied to a soft load management system, which includes a management module, a configuration template engine module, and soft load nodes. The method includes: a target soft load node responding to a service call request sent by a service consumer, searching for the cross-unit registration information of the target service according to the configuration file provided by the configuration template engine module, performing a health check on the target service provided by the target unit, and if the health check result is unqualified, routing the service call request to a backup soft load node and forwarding it to the service provider. This application can automatically perform unit switching when the target unit fails, improving the stability of the target service.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a cross-unit service registration and discovery method, routing scheduling method, device and medium. Background Technology

[0002] With the development of computer technology, distributed service architectures are deployed according to a multi-site, multi-center, unitized architecture.

[0003] Currently, distributed service architecture does not meet the requirements of a multi-site, multi-center, unitized architecture for the following reasons: Since the microservice registry is shared, the impact of a failure is still global. According to the requirements of a unitized architecture, the microservice registry needs to be deployed in a closed loop within the unit to support closed-loop business traffic within the unit.

[0004] Therefore, when a unit in a modular structure fails, the service provider in the prior art cannot continue to provide services, the service becomes unavailable, and service stability is poor. Summary of the Invention

[0005] This application provides a cross-unit service registration and discovery method, a routing and scheduling method, a device, and a medium to solve the problem of service unavailability when a unit in a unitized architecture fails in the prior art.

[0006] According to a first aspect of this application, a cross-unit routing scheduling method is provided, wherein it is applied to a soft load management system, the soft load management system comprising a management module, a configuration template engine module, and soft load nodes, including:

[0007] The target soft load balancing node, in response to a service call request sent by the service consumer, searches for the cross-unit registration information of the target service according to the configuration file provided by the configuration template engine module; wherein, the target service is a service provided through the target unit based on the service call request, and the target soft load balancing node is a node selected from the soft load balancing nodes based on the target service when the call type of the target service is a cross-unit call type;

[0008] The target soft load node performs a health check on the target service provided by the target unit based on the cross-unit registration information of the target service;

[0009] If the health check result of the target soft load node is unqualified, the target service in the target unit is determined to be in an unavailable state. According to the configuration file, the service call request is routed to the backup soft load node corresponding to the backup unit, so that when the target service in the backup unit is in an available state, the backup soft load node forwards the service call request to the service provider. The backup unit is another unit that has registered the target service.

[0010] Optionally, before routing the service call request to the backup soft load node corresponding to the backup unit according to the configuration file, the method further includes:

[0011] The target soft load node feeds back the health check results to the management module;

[0012] The management module issues a switching command to the target soft load node.

[0013] Optionally, after determining that the state of the target service in the target unit is unavailable, the method further includes:

[0014] The target soft load node feeds back the health check results to the service consumer, so that the service consumer can regenerate the service call request based on the health check results and re-execute the cross-unit routing scheduling steps.

[0015] Optionally, the soft load management system further includes a database and cache nodes;

[0016] The management module updates the information stored in the database based on the health check results to obtain updated information;

[0017] The management module updates the information stored in the cache node according to the update information.

[0018] Optionally, the cross-unit registration information includes the address information of the service provider within the target unit that provides the target service, and the method further includes:

[0019] If the target soft load node passes the health check, it forwards the service call request to the service provider based on the address information, so that the service provider can process the service call request.

[0020] Optionally, the selection process for the target soft load node includes:

[0021] Analyze the service call request to determine the characteristic information of the target service;

[0022] Based on the characteristic information of the target service, find the parameter information of the target unit;

[0023] Based on the parameter information of the target unit, the target soft load node is determined.

[0024] Optionally, when the unit to which the service consumer belongs does not exist in the service cluster to which the target unit belongs, the parameter information of the target unit includes the domain name information of the target unit and the domain name information of the service cluster to which the target unit belongs;

[0025] The step of determining the target soft load node based on the parameter information of the target unit includes:

[0026] According to preset rules, the domain name information of the service cluster and the domain name information of the target unit are concatenated to generate cross-unit access domain name information;

[0027] The target soft load node is determined based on the cross-unit access domain name information.

[0028] According to a second aspect of this application, a cross-unit service registration and discovery method is provided, wherein the method is applied to a soft load management system, the soft load management system including a management module, a configuration template engine module, and soft load nodes, the method comprising:

[0029] The configuration template engine module is used to provide configuration files to the target soft load nodes;

[0030] The management module sends monitoring instructions to the target soft load node;

[0031] The target soft load node receives cross-unit registration information for the target service registered in the target region, sent by the service provider at startup, based on the monitoring instructions.

[0032] The target soft load node, in conjunction with the configuration file, feeds back the cross-unit registration information to the management module.

[0033] According to a third aspect of this application, an electronic device is provided, comprising: at least one processor and a memory;

[0034] The memory stores computer-executed instructions;

[0035] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the cross-unit routing scheduling method as described in the first aspect above or the cross-unit service registration and discovery method as described in the second aspect.

[0036] According to a fourth aspect of this application, a computer-readable storage medium is provided, wherein computer-executable instructions are stored therein, which, when executed by a processor, are used to implement the cross-unit routing scheduling method as described in the first aspect above or the cross-unit service registration and discovery method as described in the second aspect.

[0037] According to a fifth aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the cross-unit routing scheduling method of the first aspect or the cross-unit service registration and discovery method of the second aspect.

[0038] This application provides a cross-unit routing and scheduling method applied to a soft load management system. The soft load management system includes a management module, a configuration template engine module, and soft load nodes. The method includes: a target soft load node, responding to a service call request sent by a service consumer, searching for the cross-unit registration information of the target service according to a configuration file provided by the configuration template engine module; wherein, the target service is a service provided by a target unit based on the service call request, and the target soft load node is a node selected from the soft load nodes based on the target service when the call type of the target service is a cross-unit call type; the target soft load node performs a health check on the target service provided by the target unit according to the cross-unit registration information of the target service; if the health check result is unqualified, the target soft load node determines that the status of the target service in the target unit is unavailable, and routes the service call request to the backup soft load node corresponding to the backup unit according to the configuration file, so that when the status of the target service in the backup unit is available, the backup soft load node forwards the service call request to the service provider; the backup unit is another unit that has registered the target service.

[0039] This application pre-registers the target service across regions within the soft load management system. Based on this, the application determines the target service's status through health checks performed by the target soft load nodes. If the target service is unavailable, it indicates a target unit failure, automatically triggering a unit switchover to a backup unit. When the backup soft load node detects that the target service in the backup unit is available, it forwards the service call request to the service provider for processing. This application automatically performs unit switchover in the event of a target unit failure, improving both unit switchover efficiency and the stability of the target service.

[0040] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0041] 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.

[0042] Figure 1 This is a schematic diagram of the structure of a soft load management system provided in an embodiment of this application;

[0043] Figure 2 Example diagram of soft load nodes deployed in a unitized architecture provided in the embodiments of this application;

[0044] Figure 3 A flowchart illustrating a cross-unit service registration and discovery method provided in an embodiment of this application;

[0045] Figure 4 A flowchart illustrating a cross-unit routing scheduling method provided in an embodiment of this application;

[0046] Figure 5 A flowchart illustrating another cross-unit routing and scheduling method provided in an embodiment of this application;

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

[0048] 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

[0049] 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 represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0050] Currently, distributed service architecture does not meet the requirements of a multi-site, multi-center, unitized architecture for the following reasons: Since the microservice registry is shared, the impact of a failure is still global. According to the requirements of a unitized architecture, the microservice registry needs to be deployed in a closed loop within the unit to support closed-loop business traffic within the unit.

[0051] Therefore, when a unit in a modular structure fails, the service provider in the prior art cannot continue to provide services, the service becomes unavailable, and service stability is poor.

[0052] To address the aforementioned technical problems, the overall inventive concept of this application is to provide a cross-unit routing scheduling method / cross-unit service registration and discovery method applicable to the computer field, which provides unit switching capabilities, improves unit switching efficiency, and enhances the stability of target services.

[0053] 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.

[0054] Example 1:

[0055] like Figure 1 As shown, this embodiment provides a soft load management system, which includes a management module, a configuration template engine module, soft load nodes, cache nodes, and a database.

[0056] The management module is also known as the control platform or the Server Load Balancer (SLB) management platform. The soft load balancer nodes are also called SLB nodes. There is a relationship between SLB nodes and configuration template engine modules; for example, each SLB node within a unit corresponds to its own configuration template engine module. Therefore, the configuration template engine modules corresponding to two SLB nodes can be understood as different programs deployed on the same machine.

[0057] The configuration template engine module generates a template based on the configuration rules of the SLB node. This template enables dynamic rendering, using the cache node as the data source to retrieve the required data. The cache node can support various types, such as the distributed storage system ETCD. In this embodiment, based on some dynamic rules defined by the configuration template engine, the required data can be retrieved from the cache node and then converted into the SLB node's preset rules. By adding the configuration template engine, various registration modes can be flexibly accommodated. Therefore, regardless of the number of services registered on this SLB node, or the number of strategies and routing strategies, the template can be nested cyclically.

[0058] In practical applications, the quantity relationship between configuration template engine modules and SLB nodes can be flexibly configured. For example, four partition units correspond to one set of configuration template engine modules, and two access units correspond to another set of configuration template engine modules.

[0059] Each SLB node is equipped with a corresponding configuration template engine module, and this module is deployed at the same level as the SLB node. Running the configuration template engine module on the SLB node allows it to pull configurations from the cache nodes and generate the corresponding configurations according to preset rules.

[0060] The configuration files on all SLB nodes remain consistent, and the rendering templates included in all configuration template engine modules are identical. They retain dynamic parameter interfaces, and all registration information parameters are stored on a cache node. Whenever an SLB node / management platform writes data to the cache node, it automatically retrieves information from the configuration template engine module. For example, a service's information needs to be registered once, including its IP address, the mapping between domain name and IP address, detailed rules, and checks on service liveness. This set of strategies constitutes the basic elements for providing services externally.

[0061] This embodiment defines a tree structure in a specific directory. Registering this tree structure signifies the registration of a service. If there are 100 services, it's unnecessary to utilize all engine templates and information from the tree structure. Instead, the registration information is stored in a cache node, and the services are registered 100 times according to the data structure, thus enabling the provision of 100 services. This functionality is implemented through templates in the configuration template engine module, thereby achieving flexible service registration.

[0062] In practical applications, the quantity relationship between SLB nodes and cache nodes can be flexibly configured. Since many SLB nodes are used for forwarding data streams, and their configurations can be based on the configurations pulled by cache nodes, the relationship between SLB nodes and cache nodes can be many-to-one, meaning one set of cache nodes can correspond to multiple SLB nodes.

[0063] In this embodiment, combined with a unitized architecture, one cache node can be configured for each unit to achieve unit isolation. Generally, configuring one SLB node per unit is the minimum configuration, with at least one SLB node within each unit used for functions such as registration.

[0064] A single SLB node configuration can also consist of two or more such combinations forming a cluster, used to achieve high availability. That is, one unit can correspond to multiple SLB nodes. For example, each of the four partition units can include multiple SLB nodes. In summary, the specific correspondence between the two can be customized according to business needs. Optionally, the management platform, SLB nodes, and cache nodes exist independently, and the functions of each module are as follows:

[0065] The management platform receives information monitored by SLB nodes and other modules, including information used to determine whether to perform a unit switch (e.g., the survival rate of services in the target unit), and other abnormal trigger information.

[0066] In addition, the documents issued by the management platform mainly involve two aspects: one is a list of resource-related information such as the registration of the monitored services. This list indicates which SLB node is monitoring which service consumers' data. The other is a configuration template file. This configuration template file is a fixed-format template used for rendering, containing the rules for generating configuration files—that is, information for generating a specific configuration file according to a fixed format. Therefore, this file contains information related to the configuration template engine module. This template can be dynamically adjusted; if it remains unchanged after adjustment, it will continue to be deployed on the SLB nodes.

[0067] In other words, the management platform sends a file to the SLB node, listing the information that the SLB node is listening for. The SLB node is used to listen for service registration changes based on the configuration file provided by the configuration template engine. The configuration template engine module, in turn, listens for data changes on the cache nodes based on the listening list and updates the changed data accordingly. Among these, resource changes are most typically service changes. On the one hand, this refers to changes in dynamic service registration, deregistration, and discovery; on the other hand, it refers to changes in configuration policies (including some instructions, whether to switch domain names, etc.). Changes in these areas also fall within the scope of listening.

[0068] The configuration template engine module can monitor changes to the registration information stored in the cache nodes in real time, and retrieve the changes when they occur. The configuration template engine module updates a configuration file on the SLB node.

[0069] The configuration template engine, in conjunction with the configuration template file, continuously acquires changing data. After acquiring the changing data, it converts it into a configuration file according to rules. This configuration file is then reloaded onto the SLB node, thus enabling the dynamic configuration information (including service personnel information, etc.) to be loaded onto the running SLB node.

[0070] according to Figure 1 As can be seen, the embodiments of this application can run in both IaaS (Infrastructure as a Service) and PaaS (Platform as a Service) environments. The management platform can manage SLB nodes within multiple units, as well as manage registration configuration, linkage, configuration activation, and other related items.

[0071] modular architecture, such as Figure 2As shown, this modular architecture consists of a first service cluster, a second service cluster, and a third service cluster. The first service cluster comprises two access units, the second service cluster comprises four partition units, and the third service cluster comprises one common unit. Each unit has a corresponding registry center deployed within it; for example, access units have access unit registry centers, partition units have partition unit registry centers, and common units have common unit registry centers. This modular architecture enables service registration and discovery within each unit. In this application, all services can be microservices (Distributed Service Framework, DSF).

[0072] The access unit, partition unit, and common unit are described as follows:

[0073] The logic of the access unit is as follows: an application first passes through the access unit, which calculates which partition unit the application should land in, similar to the front-end of a client. Different partition units can provide the same functionality. The public unit depends on the external environment, such as the registration of other externally dependent public services and public consumption, such as investment marketing, money transfers, and third-party authentication logins. Services within the public unit have the following characteristics: they require cross-unit access. In practical applications, since not all applications are placed in the unitized architecture at the same time, this embodiment includes a public unit.

[0074] The process for a service consumer in Access Unit 1 to access services in Partition Unit 1 is similar to that for a service consumer in the Common Unit to access services in Partition Unit 1. Taking the access unit's service consumer accessing services in Partition Unit 1 as an example, the entire process involves the service consumer in Access Unit 1 calling the SLB node to achieve cross-unit access when accessing services in Partition Unit 1.

[0075] The embodiments of this application do not impose specific limitations on the number of service clusters under the unitized architecture, nor on the number of units within the service clusters; these can be set according to actual needs.

[0076] Based on this modular architecture, the deployment of SLB nodes is described as follows: Each unit in any service cluster corresponds to at least one SLB node. The SLB nodes deployed for partition unit 1 in this application are as follows: Figure 2 As shown, the deployment of SLB nodes for the other three partition units is similar. Similarly, the deployment of SLB nodes for any access unit is also similar, as is the deployment of SLB nodes for the common unit. These details will not be elaborated here.

[0077] This soft load management system is used to implement cross-unit registration and discovery of services as well as cross-unit routing and scheduling.

[0078] By combining the registration center and soft load management system corresponding to each unit, this unitized architecture enables both intra-unit and cross-unit service calls. Furthermore, if the target unit fails during cross-unit service calls, automatic unit switching can occur. For example, if access unit 1 accesses a target service provided by a service provider within partition unit 1, and partition unit 1 fails, this application pre-configures a target service registered in both partition unit 1 and partition unit 3. Therefore, partition unit 1 and partition unit 3 act as backup units for each other for this target service. Thus, this embodiment can forward service call requests from the SLB node corresponding to partition unit 1 to the SLB node corresponding to partition unit 3. The SLB node corresponding to partition unit 3 then performs health checks on the target service and fault assessment of partition unit 3. If the health check result is satisfactory and partition unit 3 is fault-free, service calls can be made from partition unit 3, enabling unit switching, improving call efficiency, and ultimately enhancing the stability of the target service.

[0079] The soft load management system provided in this embodiment can be used to execute the cross-unit service registration and discovery method and / or cross-unit routing scheduling method provided in any of the following method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0080] Based on the above embodiments, the technical solution of this application will be described in more detail below with reference to several specific embodiments.

[0081] Example 2:

[0082] Figure 3 This is a flowchart illustrating a cross-unit service registration and discovery method provided in an embodiment of this application. Figure 3 As shown, the method of this embodiment, applied to the above-mentioned soft load management system, includes the following steps:

[0083] S10, Configure the template engine module, which is used to provide configuration files to the target soft load nodes.

[0084] S20, the management module, sends monitoring commands to the target soft load nodes.

[0085] S30, the target soft load balancer node, receives cross-unit registration information for the target service registered in the target region, sent by the service provider at startup, based on monitoring instructions. This cross-unit registration information is simply referred to as registration information.

[0086] S40, the target soft load node, in conjunction with the configuration file, feeds back cross-unit registration information to the management module.

[0087] When registering for a target service, the service provider can choose a registration method, including at least one registration method: registration within this unit and registration across units.

[0088] When a service provider chooses to register the target service using either local registration or cross-unit registration, on the one hand, the service provider performs local registration of the target service in the local unit's registration center; on the other hand, the service provider performs cross-unit registration of the target service in the software load management system. Cross-unit registration is a complete process, whereby the relevant information of the target service to be registered is first transmitted to the management platform in a preset data transmission format. The management platform stores this information in its database, and in this embodiment, the cross-unit registration information can be modified on the management platform.

[0089] In other words, the target service itself needs to be registered across units. The service provider chooses whether or not to register across units. If cross-unit registration is selected, it will be registered in two places at the same time: one is to register in the registration center within the unit, and the other is to transmit the registration data according to a preset format and call the SLB node management platform to register the target service on the SLB node.

[0090] Currently, the choice of where to register the target service and whether cross-unit registration is allowed is made by the service provider. If the registration process evolves in the future, the evolved registration process will be used by default.

[0091] In addition, the management platform sends files to the SLB nodes. The purpose of this is to monitor the service registration status in the corresponding unit through the SLB nodes. When a change in the service registration status is detected, the data in the cache nodes is updated by updating the data so that the configuration template engine module can obtain the latest data from the cache nodes.

[0092] In this embodiment, the cross-unit registration information of the target service is stored in both the cache node and the database. After the management platform distributes the file, the SLB node sends success / failure information to it. In this embodiment, even if a management platform failure occurs, it does not affect the SLB node's ability to switch between units or its routing capabilities.

[0093] The configuration files provided by the template engine module are deployed on the SLB nodes. Typically, the SLB nodes report the information they monitor to the management platform, such as service liveness rates within the corresponding unit, changes in service registration information, and service deregistration. Additionally, the SLB nodes upload their own operational status to the management platform so that, in the event of a failure, a backup SLB node can be controlled to take over and continue registering, discovering, and invoking the target service within the target unit.

[0094] The discovery of the target service involves two layers of logic. The first layer is that the SLB node discovers the cross-unit registration of the target service, and the second layer is that the service consumer discovers the cross-unit registration of the target service. The service consumer can be a consumer in another unit within the same service cluster, or a consumer in another unit within another service cluster; no specific limitation is made here.

[0095] After the target service is registered with the local registry center and SLB node, if the local registry center fails when the service consumer in this unit calls the target service, it is determined that the registry center cannot be used normally and a unit switch operation is required. For example, if the information of the service provider of the target service in this unit cannot be accessed, the unit switch operation is triggered, and the remote procedure call (RPC) method within the unit is switched to the cross-unit routing scheduling method, so as to realize the access / call of the target service.

[0096] During registration, a dual-write approach is used: one writes the registration information to a cache node, and the other writes it to the database. There is a correspondence between cache nodes and units; for example, one unit corresponds to one set of cache nodes. There is also a correspondence between cache nodes and SLB nodes; for example, multiple SLB nodes each correspond to one cache node. The information stored in the cache nodes can be updated periodically so that the configuration template engine module can read the registration information.

[0097] For example, since the service unit is registered on the SLB node corresponding to partition unit 1 and the SLB node corresponding to partition unit 3, when the cross-unit registration information changes, both SLB nodes can perform the above-mentioned judgment and scheduling. Subsequently, if a service consumer in access unit 1 calls the service through partition unit 1, a fault check is performed on partition unit 1. If partition unit 1 is not faulty, the service call request is routed to partition unit 1. If partition unit 1 is faulty, the service call request is routed to partition unit 3, thus ensuring the callability of the target service in the event of a fault in the target unit.

[0098] In summary, the cross-unit registration and discovery method based on SLB nodes provided in this application, through a management platform combined with distributed cache nodes and a configuration template engine module, can realize load balancing routing strategies and dynamic registration and discovery of microservice containers. The main process is as follows:

[0099] (1) When registering a service, the service provider not only registers the service with the registration center within the unit, but also registers the service's IP address, port and other information with the corresponding cache node of the unit.

[0100] (2) By configuring the template engine module, the SLB node can dynamically check the registration status of the service in the cross-unit scenario and update the relevant information of the service to the configuration file in the SLB node.

[0101] In summary, the embodiments of this application, through the cross-unit registration method of the target service, enable the service consumer in Unit 1 to access the target service registered in the SLB node corresponding to Unit 2. If the target service is registered in both Unit 2 and Unit 3, then in the event of a failure in Unit 2, the system can quickly switch to Unit 3 to process the target service. This provides switching capability and a fast switching rate, thereby improving the stability of the target service.

[0102] Example 3:

[0103] Figure 4 This is a flowchart illustrating a cross-unit routing scheduling method provided in an embodiment of this application. Based on Embodiment 2, this embodiment focuses on refining the routing scheduling strategy after the target service is registered and discovered. For example... Figure 4 As shown, the method of this embodiment is applied to a soft load management system. The soft load management system includes a management module, a configuration template engine module, and soft load nodes. The method of this embodiment includes the following steps:

[0104] S70, Target Soft Load Node, responds to the service call request sent by the service consumer and searches for the cross-unit registration information of the target service based on the configuration file provided by the configuration template engine module; wherein, the target service is the service provided by the target unit based on the service call request, and the target soft load node is the node selected from the soft load nodes based on the target service when the call type of the target service is the cross-unit call type.

[0105] Before executing step S70, the service consumer connected to the soft load management system in this embodiment of the application is also used to perform the following steps:

[0106] S50. When the call type of the target service is identified as a cross-unit call type based on the service call request, the target soft load balancing node is determined. The target soft load balancing node is the corresponding soft load balancing node that the management module has pre-allocated to the target unit. The target unit is the unit that has registered the target service.

[0107] S60, the service consumer, sends service call requests to the target soft load balancer node via HTTP.

[0108] S80, the target soft load node, performs a health check on the target service provided by the target unit based on the cross-unit registration information of the target service.

[0109] In addition to performing a health check on the target service before invoking it, this embodiment also periodically checks the operational status of the target service, the target unit, and the SLB node itself. For this periodic health check, the time interval can be customized, such as 3 seconds or 4 seconds.

[0110] For example, in this embodiment, health checks are performed on the SLB nodes corresponding to the four partition units. After the checks, the service provider of the target service is determined to be fault-free based on the health check results. The service consumer can periodically initiate its own health check probes and confirm whether the scheduled target service is running effectively. The SLB node provides the service consumer with health check results, running status, and other information as a basis for determining whether to switch units.

[0111] S90, if the health check result is unqualified, the target soft load node determines that the target service in the target unit is in an unavailable state, and routes the service call request to the backup soft load node corresponding to the backup unit according to the configuration file, so that when the target service in the backup unit is in an available state, the backup soft load node forwards the service call request to the service provider; the backup unit is another unit that has registered the target service.

[0112] It is important to note that the same target service may run on different carriers within different units. In other words, the availability of a target service specifically refers to its availability within that target unit. For example, service A may be unavailable in partition unit 1, but available in partition unit 2.

[0113] This application's embodiments propose a routing and scheduling scheme to address unit failures, such as infrastructure failures, network failures, or problems with the environment on which the unit depends. This scheme enables unit switching even when units are isolated.

[0114] Since this embodiment does not simultaneously deploy an upgrade-like deployment of the same target service across all units, it addresses the issue of a fault in the program upon which the target service depends by adding concepts such as canary deployments. For example, if partition unit 1 and partition unit 3 are mutually redundant, when deploying a new version of the target service, this embodiment first performs the upgrade in partition unit 1, and then in partition unit 3. Therefore, a program problem at any given time only affects one of partition unit 1 and partition unit 3, while the other partition unit continues to operate normally.

[0115] This embodiment allows for custom configuration of the backup unit, i.e., pre-setting certain interface rules, such as which shards belong to unit 1 and which shards belong to unit 2. There are takeover rules between units, which are pre-set and can be adjusted after being pre-set.

[0116] The service consumers in Access Unit 1 accessing services in Partition Unit 1, and the service consumers in Partition Unit 2 accessing services in Partition Unit 1, follow similar routing processes. However, the routing strategies they employ on the SLB nodes corresponding to Partition Unit 1 differ, such as domain names and rules. A domain name is a fundamental access rule.

[0117] When accessing across units, this embodiment can also superimpose rules to determine whether partition unit 1 is alive. If partition unit 1 contains 10 services, the determination is based on the number of services that are alive. This embodiment can define a minimum threshold, assuming this threshold is 5. Therefore, the number of services alive in partition unit 1 must be greater than 5 for partition unit 1 to be considered available. In this case, service call requests are directly load-loaded onto partition unit 1. If the number of alive services is less than the threshold, for example, 4, then partition unit 1 is considered unavailable, and a switch to another partition unit is required. One switching process is as follows: the switching criteria information is returned to the service consumer in access unit 1, notifying the service consumer that partition unit 1 is unavailable. The service consumer can then switch to the entry point of another partition unit to make service calls according to the originally predetermined rules.

[0118] It should be noted that for calls within this unit, such as when a service consumer in partition unit 1 calls a service in partition unit 1, a closed loop can be achieved within partition unit 1 without the soft load management system provided in this application embodiment, and the cross-unit scheduling method provided in this embodiment is also unnecessary.

[0119] In summary, this application embodiment pre-registers the target service across regions within the soft load management system. Based on this, the embodiment determines the target service's status through health checks performed by the target soft load nodes. If the target service is unavailable, it indicates a target unit failure, leading to automatic unit switching to a backup unit. When the backup soft load node detects that the target service in the backup unit is available, it forwards the service call request to the service provider for processing. This application embodiment solves the problem that existing detection mechanisms cannot deeply identify the true status of the unit's backend service in extreme scenarios such as target unit failure. Automatic unit switching during target unit failure improves both efficiency and accuracy, while also enhancing the stability of the target service.

[0120] In one possible implementation, the selection process for the target soft load node includes the following steps:

[0121] S51. Parse the service call request and determine the characteristic information of the target service.

[0122] It should be understood that the characteristic information of the aforementioned target service may include service name, service number, service type, etc.

[0123] S52. Based on the characteristic information of the target service, find the parameter information of the target unit.

[0124] It should be understood that the parameter information of the aforementioned target unit may include the domain name of the target unit where the target service is located, provided by the service provider. For example, if a service consumer in access unit 1 directly accesses the target service in partition unit 1, then this access is a cross-unit access. Based on this, the service consumer can parse the service call request according to its pre-stored table, and thus obtain information such as the domain name used to determine the target soft load balancing node.

[0125] S53. Determine the target soft load node based on the parameter information of the target unit.

[0126] In this embodiment of the application, for the target service to be invoked, the service consumer can calculate which unit to call based on the mapping relationship between the target service and the target unit, and after the calculation is completed, send a service invocation request to the soft load node corresponding to that unit.

[0127] For example, if a service consumer in access unit 1 needs to call a service in partition unit 1, it closes the loop within partition unit 1, meaning it first accesses the domain name of partition unit 1, which corresponds to a soft load balancer node. In other words, the service consumer in access unit 1 pointing to the domain name corresponding to the SLB node of partition unit 1 is considered normal traffic and does not require unit switching. Therefore, the service call request is directly mapped to this soft load balancer node through the domain name, and this part of the computation process is executed on the service consumer side.

[0128] For service providers, their target service can receive service call requests from multiple service consumers, and each request contains some characteristic information of the target service, such as a service ID. For the same customer ID, calculations based on the service ID and other characteristic information yield consistent results. For example, if a service consumer belongs to access unit 1, and its calculated target unit is partition unit 1, then it is determined to be a cross-unit scenario. The liveness rate of the target unit is assessed by accessing the SLB node. If the liveness rate meets the requirements, the service call request is forwarded to partition unit 1. If the liveness rate does not meet the requirements, a unit switch occurs to ensure normal access to the target service, thus improving the stability of the target service.

[0129] In other words, there is a correspondence between domain names and units, and also a correspondence between units and SLB nodes. Therefore, in this embodiment, a domain name can be used to specify an SLB node corresponding to a unit. Simply put, under normal circumstances, the target unit and target service are directly specified by the service consumer. Before sending a service call request, the consumer already knows which unit to send it to, and can directly point to the unit corresponding to the domain name. Based on the domain name of that unit, the request can be sent to its corresponding SLB node.

[0130] In scenarios involving cross-unit service calls, unit switching is generally unnecessary. However, in cases where the target unit fails, the continued operation of the target service must be considered, thus requiring unit switching. For example, if traffic within access unit 1 is directed to partition unit 1 corresponding to the SLB node, normally, service consumers in access unit 1 do not actively switch traffic to partition unit 3. Unit switching is only performed when the target service is unavailable, the unit fails, or the SLB node fails. Specifically, based on the SLB node's operational status, the service consumers in access unit 1 are first notified whether a unit switch is necessary.

[0131] For example, after the service consumer in access unit 1 completes its calculations, it can first determine whether to access partition unit 1, partition unit 2, or partition unit 3. In a scenario with two access units and four partition units, there is a correspondence between the access units and the partition units. For instance, access unit 1 corresponds to partition units 1 and 3, and access unit 2 corresponds to partition units 2 and 4.

[0132] This embodiment performs calculations according to preset rules (e.g., hash calculation based on service number) and then determines the target unit.

[0133] The embodiments of this application can accurately identify target soft load nodes, thereby enabling accurate target service scheduling.

[0134] In one possible implementation, when the unit to which the service consumer belongs does not exist in the service cluster to which the target unit belongs, the parameter information of the target unit includes the domain name information of the target unit and the domain name information of the service cluster to which the target unit belongs; Step S53, determining the target soft load balancing node based on the parameter information of the target unit, includes the following steps:

[0135] S531. According to preset rules, concatenate the domain name information of the service cluster and the domain name information of the target unit to generate cross-unit access domain name information.

[0136] S532. Determine the target soft load node based on the cross-unit access domain name information.

[0137] When both the service consumer and the target unit belong to the same service cluster, this embodiment of the application can parse the domain name information of the specified unit carried in the service call request according to preset rules, thereby determining the SLB node. However, when the service consumer and the target unit do not belong to the same service cluster, this embodiment of the application can parse the domain name information of the specified unit and the domain name information of the service cluster carried in the service call request according to preset rules, thereby determining the SLB node.

[0138] For example, the service consumer in access unit 1 directly calculates which partition unit the target unit is and which service cluster the target unit belongs to according to preset rules. Based on this, the service call request sent by the service consumer directly lands on the SLB node corresponding to partition unit 1. The functions of the SLB node are as follows: to realize service registration and discovery, cross-unit switching in case of target unit failure, and to allow the backup unit to take over the service call request.

[0139] Therefore, the first routing scheduling process between different units within the same service cluster and the second routing scheduling process between different units in different service clusters are similar, but differ in details. For example, calling a service in partition unit 1 from partition unit 2 and calling a service in partition unit 1 from access unit 1 are two different calling logics. For the first routing scheduling process, access unit 1 can schedule to partition unit 1 based on information such as domain name. Since there are multiple partition units and the possibility of failure, this embodiment can also determine whether partition unit 1 is available.

[0140] In this embodiment, the strategies among the four partition units are equivalent. When calling services within each partition unit, the SLB node corresponding to each partition unit first determines whether the service within its own partition unit is available. Since cross-unit routing is implemented based on the target service having already been registered across units, and each partition unit can register service registration information from other partition units, this information is shared among the partition units. The SLB node corresponding to the current partition unit first determines whether the target service is available. If the target service is available, it routes to the current partition unit. If the target service is unavailable, it indicates a failure in the current partition unit, and a unit switchover operation is then performed.

[0141] In this embodiment, the service call between partition unit 1 and partition unit 2 is itself a cross-unit routing and scheduling, and this embodiment implements unit isolation based on the unitized architecture. Therefore, each service is a closed loop within a unit. However, in the event of a failure in this partition unit, a unit switchover operation is required, calling another unit to take over. This mainly focuses on the four partition units within this service cluster. From a business perspective, the four partition units can provide equivalent functions. Any partition unit can provide this service externally, so after a partition unit fails, it can still be taken over by other units. The original unitized architecture does not support cross-unit routing and scheduling. In this embodiment, based on the unitized architecture, a cross-unit registration is performed for the service through the SLB node, so that this service in partition unit 1 is registered simultaneously on the SLB node corresponding to partition unit 1 and the SLB node corresponding to partition unit 3. Based on this, the takeover rule that can be set in this embodiment is that partition unit 1 and partition unit 3 take over each other, and partition unit 2 and partition unit 4 take over each other. This rule is a custom rule, and can also be set to partition unit 1 and partition unit 2 take over each other, and partition unit 3 and partition unit 4 take over each other.

[0142] For example, for a specific target service, partition unit 1 and partition unit 3 take over from each other. When the registry center in partition unit 1 registers the target service, it simultaneously registers a copy on the SLB node corresponding to partition unit 1 and another copy on the SLB node corresponding to partition unit 3. Therefore, the SLB nodes corresponding to both partition units 1 and 3 can be aware of the registration of the target service, and it is a cross-unit registration.

[0143] The embodiments of this application can accurately identify the target soft load node based on the parameter information of the target unit, thereby achieving accurate target service scheduling.

[0144] In one possible implementation, before routing service call requests to the corresponding backup soft load node of the backup unit according to the configuration file, the cross-unit routing scheduling method further includes the following steps:

[0145] S91, the target soft load node, feeds back the health check results to the management module.

[0146] S92, the management module, issues a switching command to the target soft load node.

[0147] The SLB node has pre-defined cross-cell routing rules. For example, partition cell 3 takes over partition cell 1. When the target service is unavailable in partition cell 1, it is automatically routed to partition cell 3.

[0148] The management platform, under the unitized architecture, sends instructions indicating whether or not to switch between units based on the service survival rate dynamically monitored by the SLB nodes in the target unit. It is similar to a switch, automatically issuing instructions to set the switch state to the switching state when switching between units, so that traffic is switched to the backup unit.

[0149] The embodiments of this application are based on a management platform, which enables the switching of units, thereby improving the stability of services.

[0150] In one possible implementation, after determining that the target service in the target unit is unavailable, the cross-unit routing scheduling method further includes the following steps:

[0151] S93. The target soft load node feeds back the health check results to the service consumer, so that the service consumer can regenerate the service call request based on the health check results and re-execute the cross-unit routing scheduling steps.

[0152] In this embodiment, if the call type is an intra-unit call, the target service call is implemented within the unit via RPC. If the call type is a cross-unit call, it flows through the SLB node via the Hypertext Transfer Protocol (HTCP) so that the SLB node performs a health check on the target service. The health check result can be used as the basis for determining whether to perform a unit switch. If the target service is unavailable, the health check result can be sent to the service consumer to notify it that the target service it wants to access is unavailable in the target unit, and the service consumer can then make adjustments.

[0153] Service consumers can manually switch units by resending another service call request. For example, before a service consumer in access unit 1 calls a service in partition unit 1, the SLB node corresponding to partition unit 1 sends a health check result back to access unit 1. After receiving the information that the health check result is unqualified, access unit 1 determines that partition unit 1 is faulty. It can then switch the domain name according to the original routing scheduling process, switching the access domain name from partition unit 1 to partition unit 3. Subsequent service call requests flow through the SLB node corresponding to partition unit 3, thus switching the entire link to partition unit 3.

[0154] In summary, this application provides two unit switching methods. The first method is to automatically switch using a management platform based on a pre-configured file, and the second method is for users to switch manually. Regardless of the method used, unit switching can be performed in the event of a target unit failure, thus ensuring the stability of calling the target service.

[0155] Optionally, if a service consumer in access unit 1 accesses a target service in partition unit 1, and the SLB node corresponding to partition unit 1 fails, the health check result of the target service cannot be fed back to the service consumer. After discovering that the SLB node has not responded or has an abnormal response within a preset time period, the service consumer switches to another unit according to predetermined rules on the service consumer. Therefore, this embodiment can still ensure the stability of calling the target service through the above-described unit switching method.

[0156] In one possible implementation, the soft load management system also includes a database and cache nodes. The cross-unit routing and scheduling method further includes the following steps:

[0157] S100, the management module, updates the information stored in the database based on the health check results to obtain updated information.

[0158] S110, the management module, updates the information already stored in the cache nodes according to the update information.

[0159] The management platform and SLB nodes have a manager-managed relationship. All configurations (including switching commands) can be translated into configuration items on the SLB nodes. On the management platform, all configuration items can be written to a database. This includes domain names similar to routers, control switches, and templates for corresponding service rules. Information such as the IP addresses of the obtained services is also processed and written to the database through the management platform.

[0160] The cache nodes also store registration information, so the configuration template engine module can run independently of the management platform and retrieve it from the cache nodes. Therefore, the management platform writes the changed information back to the cache nodes to ensure the accuracy of the information stored in the cache nodes.

[0161] For example, a domain name is an identifier that differentiates services. If it changes, it can be modified through the management platform, and the changes must also be synchronized to the cache nodes. After the information stored in the cache nodes is updated, the configuration template engine module can obtain accurate registration data from the cache nodes and then update the information in the actual running SLB nodes accordingly.

[0162] The embodiments of this application enable the rapid application of updated information and improve the accuracy of unit switching operations.

[0163] In one possible implementation, the cross-unit registration information includes the address information of the service provider within the target unit that provides the target service. The cross-unit routing and scheduling method further includes:

[0164] If the target soft load node passes the health check, it forwards the service call request to the service provider based on the address information, so that the service provider can process the service call request.

[0165] It should be understood that the four partition units correspond to four domain name entry points, with each partition unit corresponding to one domain name, and each domain name corresponding to one SLB node entry point. Therefore, this embodiment can perform scheduling based on domain names. In other words, an application can determine which partition unit to access based on the domain name carried in its business request, and then schedule the request to the SLB node corresponding to that partition unit. When the SLB node determines that the target service is available, it forwards the request to the service provider.

[0166] For example, such as Figure 5 As shown, the cross-unit routing scheduling method provided in this embodiment can execute the following HTTP call mechanism flow:

[0167] When the service providers in S1 and Unit 2 start up, they register their IP addresses with the corresponding SLB nodes and their RPC ports with the registration center.

[0168] S2. After the service consumer in Unit 1 calls the service and determines the target unit, if the target unit is Unit 2, which is different from Unit 1, then the corresponding scenario is determined to be a cross-unit call scenario. In this scenario, the domain name of the service cluster and the domain name of the target unit are concatenated according to fixed rules, and the SLB node corresponding to Unit 2 where the service is located is accessed by HTTP call.

[0169] S3, the SLB node corresponding to Unit 2 forwards HTTP protocol service call requests to the IP address of the service provider within the target unit.

[0170] S4. The service provider handles service call requests via the HTTP protocol.

[0171] In this embodiment, during the execution of S1 to S4, a soft load management system is introduced to provide a cross-unit registration and discovery solution, supporting the transformation of microservice DSF applications based on a unitized architecture. This embodiment simultaneously registers services to the microservice registry center (i.e., the aforementioned registry center) and the SLB node within the unit, enabling cross-unit registration, discovery, and routing scheduling capabilities, thus meeting the requirements for automatic unitized failover.

[0172] In this embodiment, DSF adds a cross-unit HTTP call mechanism based on SLB nodes, while using the existing RPC mechanism to handle calls between the current unit, common units, and the existing environment. Therefore, the service provider supports handling HTTP protocol service call requests in addition to supporting RPC port processing.

[0173] In summary, this embodiment adds a cross-unit service registration and discovery function based on SLB nodes to DSF, which is used for cross-unit service invocation scenarios, while the intra-unit service registration, discovery, and invocation mechanism still adopts the existing method. This embodiment also adds a unit routing function to DSF, providing transparent unit computation and service invocation for applications. Furthermore, this embodiment adds an automatic unit takeover function to DSF, automatically routing requests to its backup unit when a service in the target unit is determined to be unavailable based on the node's health check results.

[0174] In other words, this application embodiment implements a cross-unit service registration and discovery method and a routing scheduling method through a soft load management system, which solves the problem of cross-unit scheduling that cannot be achieved in the RPC call scenario within a unit, and realizes fast switching between multiple units under the unitized architecture, thereby improving service quality.

[0175] It should be noted that the user information and data involved in this application (including but not limited to data used for analysis, stored data, and displayed data) are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0176] In other words, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0177] According to embodiments of this application, this application also provides an electronic device and a readable storage medium.

[0178] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. The electronic device includes a receiver 60, a transmitter 61, at least one processor 62, and a memory 63. The electronic device composed of the above components can be used to implement the above-described specific embodiments of this application, which will not be described in detail here.

[0179] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of the methods described above.

[0180] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the various steps in the methods described above.

[0181] Various embodiments of the systems and technologies described above in this application can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0182] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or electronic device.

[0183] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be a machine-readable signal medium or a machine-readable storage medium. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of computer-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0184] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0185] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as data electronic devices), or computing systems that include middleware components (e.g., application electronic devices), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0186] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0187] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this application should be included within the scope of protection of this application.

Claims

1. A cross-unit routing scheduling method, characterized in that, A soft load management system applied to a unitized architecture, the soft load management system including a management module, a configuration template engine module, and soft load nodes, the soft load management system including multiple units, each unit corresponding to at least one soft load node, the method including: The target soft load balancing node, in response to a service call request sent by a service consumer, searches for the cross-unit registration information of the target service according to the configuration file provided by the configuration template engine module; wherein, the configuration file includes registration information dynamically obtained through the configuration template engine module; the target service is a service provided by a target unit based on the service call request; the target soft load balancing node is the soft load balancing node corresponding to the target unit selected from the soft load balancing nodes based on the target service when the call type of the target service is a cross-unit call type; the target unit is a unit that has registered the target service. The target soft load node performs a health check on the target service provided by the target unit based on the cross-unit registration information of the target service; If the health check result of the target soft load node is unqualified, the target service in the target unit is determined to be in an unavailable state. According to the configuration file, the service call request is routed from the target soft load node corresponding to the target unit to the backup soft load node corresponding to the backup unit. When the target service in the backup unit is in an available state, the backup soft load node forwards the service call request to the service provider corresponding to the backup unit. The backup unit is a pre-configured unit that has registered the target service but is different from the target unit. The unavailable state is the state in which the target service is unavailable due to the failure of the target unit.

2. The method according to claim 1, characterized in that, Before routing the service call request to the backup soft load node corresponding to the backup unit according to the configuration file, the method further includes: The target soft load node feeds back the health check results to the management module; The management module issues a switching command to the target soft load node.

3. The method according to claim 1, characterized in that, After determining that the state of the target service in the target unit is unavailable, the method further includes: The target soft load node feeds back the health check results to the service consumer, so that the service consumer can regenerate the service call request based on the health check results and re-execute the cross-unit routing scheduling steps.

4. The method according to claim 1, characterized in that, The soft load management system also includes a database and cache nodes; The management module updates the information stored in the database based on the health check results to obtain updated information; The management module updates the information stored in the cache node according to the update information.

5. The method according to claim 1, characterized in that, The cross-unit registration information includes the address information of the service provider within the target unit that provides the target service, and also includes: If the health check result is satisfactory, the target soft load node forwards the service call request to the service provider based on the address information, so that the service provider can process the service call request.

6. The method according to claim 1, characterized in that, The selection process for the target soft load node includes: Analyze the service call request to determine the characteristic information of the target service; Based on the characteristic information of the target service, find the parameter information of the target unit; Based on the parameter information of the target unit, the target soft load node is determined.

7. The method according to claim 6, characterized in that, When the unit to which the service consumer belongs does not exist in the service cluster to which the target unit belongs, the parameter information of the target unit includes the domain name information of the target unit and the domain name information of the service cluster to which the target unit belongs; The step of determining the target soft load node based on the parameter information of the target unit includes: According to preset rules, the domain name information of the service cluster and the domain name information of the target unit are concatenated to generate cross-unit access domain name information; The target soft load node is determined based on the cross-unit access domain name information.

8. A cross-unit service registration and discovery method, characterized in that, A soft load management system applied to a unitized architecture, the soft load management system including a management module, a configuration template engine module, and soft load nodes, the soft load management system including multiple units, each unit corresponding to at least one soft load node, the method including: The configuration template engine module is used to provide configuration files to the target soft load nodes; The management module sends monitoring instructions to the target soft load node; The target soft load node receives cross-unit registration information for the target service registered in the target region, sent by the service provider at startup, based on the monitoring instructions. The target soft load node, in conjunction with the configuration file, feeds back the cross-unit registration information to the management module; The target soft load node is the target soft load node as described in any one of claims 1-7.

9. An electronic device, characterized in that, include: At least one processor and memory; The memory stores computer-executed instructions; The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the cross-cell routing scheduling method as described in any one of claims 1 to 7 or the cross-cell service registration and discovery method as described in claim 8.

10. 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 cross-unit routing scheduling method as described in any one of claims 1 to 7 or the cross-unit service registration and discovery method as described in claim 8.

Images