Routing scheduling method, system and electronic device

Abstract

The application provides a routing scheduling method, system and electronic equipment. The method is applied to a routing scheduling system, which is a unified entrance and scheduling hub for function invocation between different ends. The method comprises the following steps: based on a routing request of a calling party, capturing an implicit context of the calling party; analyzing the routing request, executing interceptor logic based on public control parameters, after the execution, querying a routing mapping table according to a path identifier to determine a target executor, and transmitting private business parameters to the target executor to execute business logic; returning a business logic execution result of the target executor to the calling party, executing a post-linkage operation based on the implicit context; and recording execution state information of each stage and outputting the execution state information at each stage of executing the routing request. The application can separate public control parameters and private business parameters, avoid invalid target positioning and business processing, and improve the automation degree of routing invocation and realize the observability of routing invocation.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a routing scheduling method, system and electronic device. Background Technology

[0002] In today's multi-platform development environment, an application often needs to run on multiple platforms. These platforms refer to different carriers of the application, primarily including mobile applications (Apps), web pages, and mini-programs. To enable function calls and page navigation between these platforms, developers typically employ various technology stacks to build their business logic, such as native development, cross-platform frameworks, and pure front-end technologies.

[0003] In cross-platform interaction scenarios, developers need to deal with multiple calling mechanisms independently defined by each front-end platform. Specifically: On the App side: External applications can be invoked via URL Scheme (Uniform Resource Locator Scheme), while internal page navigation and module calls are implemented through custom routes.

[0004] Web-based: Page access and API (Application Programming Interface) interaction are conducted via HTTP (Hypertext Transfer Protocol) / HTTPS.

[0005] Mini Program: Redirection and function calls are achieved through dedicated APIs provided by the platform.

[0006] Furthermore, the front-end platform may also need to interact with back-end services, further increasing the complexity of the calling scenario. For example, back-end services may provide services to the outside world through RPC (Remote Procedure Call) or RESTful (Representational State Transfer) interfaces for the front-end to call.

[0007] In addition to the aforementioned calling mechanisms, to meet the interaction needs between different technology stacks within the same platform or between different platforms, each platform or scenario also defines corresponding bridging mechanisms. For example, native communication within an app and the web is achieved through JSBridge; cross-platform frameworks within an app and native communication are achieved through Platform Channel for method calls.

[0008] The aforementioned invocation mechanisms are independent and incompatible with each other in terms of syntax, execution mode, parameter passing method, and invocation context. Due to the lack of a unified abstraction layer and governance system, they face the following technical problems in complex application architectures: 1. Protocol fragmentation: Different terminals use different protocol formats, and business code needs to adapt to multiple calling methods, resulting in high coupling and high maintenance costs.

[0009] 2. Risk of synchronous blocking: Traditional routing calls are mostly synchronous, which can easily cause the main thread to freeze when performing time-consuming operations such as network requests or permission verification.

[0010] 3. Lack of dynamic capabilities: The routing path and parameter structure are hard-coded in the client, making it impossible to implement path redirection, protocol upgrades, or canary releases online without requiring a new version release.

[0011] 4. Dispersed logic: Common logic such as login verification, permission checks, and event tracking reporting are scattered across the call entry points of various business modules, making it difficult to configure and maintain them in a unified manner.

[0012] 5. Unobservable invocation process: The lack of transparency in the invocation execution process makes it difficult to fully grasp the overall execution status of the invocation and the processing status of each stage, making it difficult to quickly locate the cause when problems occur.

[0013] 6. Lack of source context awareness: It is impossible to accurately identify the source of the call and perform corresponding related processing. Furthermore, due to the lack of records of the source of the call, it is difficult to achieve fine-grained monitoring, accurate problem attribution, and subsequent processing.

[0014] In summary, existing cross-platform invocation solutions have significant shortcomings in terms of protocol uniformity, execution efficiency, dynamic governance, logic management, observability, and context awareness, resulting in low development efficiency, high maintenance costs, limited business iteration, difficulty in troubleshooting, and difficulty in ensuring user experience. Summary of the Invention

[0015] In view of the above problems, embodiments of this application provide a routing scheduling method, system, and electronic device that overcomes or at least partially solves the above problems.

[0016] In a first aspect, embodiments of this application provide a routing scheduling method applied to a routing scheduling system, wherein the routing scheduling system serves as a unified entry point and scheduling hub for function calls between different endpoints, and the method includes: In response to receiving a routing request initiated by a caller that follows a unified protocol format, the implicit context of the caller is captured, wherein the unified protocol format includes path identifiers, public control parameters, and private business parameters; After parsing the routing request, at least one interceptor logic is executed based on the public control parameters. During the execution of the at least one interceptor logic, if it is detected that the condition is not met, a context snapshot is encapsulated and the current routing process is suspended. Once the condition is met, the execution of the current routing process is resumed based on the context snapshot. After the at least one interceptor logic is executed successfully, the target execution body is determined by querying the routing mapping table based on the path identifier carried in the routing request, and the private business parameters are passed through to the target execution body, which then executes the business logic. The business logic execution result of the target executor is returned to the caller, and after returning the business logic execution result, a follow-up linkage operation is executed based on the implicit context; Specifically, at each stage from the receipt of the routing request to its completion, the execution status information of each stage is recorded and output.

[0017] Secondly, embodiments of this application provide a routing scheduling system, which serves as a unified entry point and scheduling hub for function calls between different endpoints. The system includes: The capture module is used to capture the implicit context of the caller in response to receiving a routing request initiated by the caller that follows a unified protocol format. The unified protocol format includes path identifiers, public control parameters, and private business parameters. An execution module is configured to execute at least one interceptor logic based on the public control parameters after parsing the routing request. During the execution of the at least one interceptor logic, if a condition is not met, a context snapshot is encapsulated and the current routing process is suspended. Once the condition is met, the execution of the current routing process is resumed based on the context snapshot. The processing module is configured to, after the at least one interceptor logic has been executed, query the routing mapping table based on the path identifier carried in the routing request to determine the target execution body, and pass the private business parameters to the target execution body so that the target execution body can execute the business logic; The return execution module is used to return the business logic execution result of the target executor to the caller, and after returning the business logic execution result, to perform a post-linkage operation based on the implicit context; The recording and output module is used to record and output the execution status information of each stage from the receipt of the routing request to its completion.

[0018] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the routing scheduling method described in the first aspect above.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the routing scheduling method described in the first aspect above.

[0020] The technical solution of this application, based on a routing request initiated by the caller following a unified protocol format, captures the caller's implicit context, providing necessary execution target and environment information for subsequent linkage operations. Simultaneously, the unified protocol format enables protocol standardization for multi-terminal calls. After parsing the routing request, at least one interceptor logic is executed based on public control parameters. After the execution of at least one interceptor logic, the target execution body is determined by querying the routing mapping table based on the path identifier. Private business parameters are then passed through to the target execution body, which executes the business logic. This achieves a clear separation between public control parameters and private business parameters and avoids invalid target location and business processing when the interceptor logic does not meet the conditions. After the target execution body executes the business logic, the execution result is returned to the caller, allowing the caller to know the final state of this routing call. After returning the business logic execution result to the caller, subsequent linkage operations are executed based on the implicit context, further improving the automation level of the routing call.

[0021] Furthermore, during the execution of at least one interceptor logic, if a condition is not met, the context of the current route call is encapsulated to obtain a context snapshot, and the current route process is suspended to avoid blocking the main thread. After the condition is met, the suspended route process is resumed based on the context snapshot, which can ensure the integrity of the process while achieving a non-blocking route execution experience.

[0022] By recording and outputting the execution status information of each stage from the receipt of a routing request to its completion, the entire routing call process can be made observable for performance monitoring and anomaly alerts. It also supports the rapid location of the specific stage and cause of a fault, significantly improving the efficiency of troubleshooting. Attached Figure Description

[0023] Figure 1 A schematic diagram illustrating the routing scheduling method provided in an embodiment of this application; Figure 2 This document illustrates a flowchart illustrating the implementation process of determining a target executor based on a path identifier and transmitting parameters to that target executor, as provided in an embodiment of this application. Figure 3 This document presents a flowchart illustrating the runtime environment version verification failure handling process provided in this embodiment. Figure 4This diagram illustrates the implementation flowchart of the implicit context of the caller based on routed requests provided in this application. Figure 5 This diagram illustrates the call identifier allocation and asynchronous response provided in the embodiments of this application. Figure 6 This diagram illustrates the routing and scheduling system provided in an embodiment of this application. Figure 7 This is a schematic diagram of the electronic device structure provided in the embodiments of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Multiple embodiments in this application may include two or more.

[0026] In the various embodiments of this application, it should be understood that the sequence number of each process described below does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0027] This application provides a routing scheduling method applied to a routing scheduling system, which serves as a unified entry point and scheduling hub for function calls between different endpoints. For example, the routing scheduling system includes a routing scheduling module deployed on a client device and / or a routing scheduling service deployed on a server device. For local call scenarios that do not rely on the server (e.g., calls within the same endpoint or calls between different endpoints on the same device), the routing scheduling module deployed on the client device independently handles the scheduling. For scenarios requiring dynamic configuration or remote services (e.g., cloud-based configuration information delivery or remote service calls), the routing scheduling module deployed on the client device and the routing scheduling service deployed on the server device work together. For purely cloud-managed scenarios (e.g., business routing entirely server-driven), the routing scheduling service deployed on the server device is responsible for scheduling.

[0028] A single client device can host multiple platforms (such as native modules, web applications, and mini-programs). Furthermore, the routing and scheduling system must handle remote calls between client devices and backend services, as well as cross-device calls between different client devices. By uniformly coordinating function calls and page navigation within client devices, between client devices and backend services, and between different client devices, the routing and scheduling system achieves comprehensive unified governance.

[0029] The routing scheduling method provided in the embodiments of this application is described below, such as... Figure 1 As shown, the method includes the following steps: Step 101: In response to receiving a routing request initiated by the caller that follows a unified protocol format, capture the caller's implicit context. The unified protocol format includes path identifiers, public control parameters, and private business parameters.

[0030] Upon receiving a routing request from a caller that follows a unified protocol format, the implicit context related to the caller is captured based on this request. The caller is the source of the routing request and can be a specific module within different platforms, such as a mini-program (mini-program page or component), a web page (JavaScript code in a web page), or a native module (native code within an app); it can also be an external application (another app that invokes the current application and carries the call parameters) or an application on another device (such as initiating a call through a cross-device communication protocol). Furthermore, the backend service can send instructions to the client device via push notifications, long connections, or RPC to trigger the routing scheduling module within the client device to actively initiate a routing call. In this case, the backend service acts as the triggering source, not the direct routing request caller.

[0031] Routing requests, as a special type of invocation request, follow a unified protocol format to standardize multi-terminal invocation protocols. This unified protocol format includes path identifiers, public control parameters, and private business parameters. Path identifiers are used to determine the target execution body, public control parameters are used to trigger interceptor logic, and private business parameters are used to encapsulate specific business-related data. The implicit context of the caller captured by the routing request is not explicitly passed by the caller in the routing request; instead, it is obtained by the routing scheduling system at the invocation entry point, and the caller is unaware of it.

[0032] Step 102: After parsing the routing request, execute at least one interceptor logic based on public control parameters. During the execution of at least one interceptor logic, if a condition is not met, encapsulate a context snapshot and suspend the current routing process. Once the condition is met, resume the execution of the current routing process based on the context snapshot.

[0033] After receiving and parsing the routing request, the system extracts the path identifier, public control parameters, and private business parameters carried in the request. Based on the public control parameters, at least one interceptor logic is executed. This interceptor logic is the preprocessing logic in the routing scheduling system, used to uniformly handle common tasks unrelated to specific business logic (e.g., login checks, permission verification, version checks, etc.). It belongs to pre-interception logic, executed before the target executor is called, and is used to determine whether to continue the routing process, terminate the current request, or suspend and wait based on conditions. For example, the interceptor logic includes login verification, permission checks, and version checks. During the execution of the interceptor logic, if a condition is not met (e.g., user not logged in, insufficient permissions, client version lower than the minimum required version), the context of the current routing call is encapsulated, a context snapshot is obtained, and the current routing process is suspended to avoid blocking the main thread. After suspending the current routing process, if the conditions are met (e.g., user login completed, permissions granted, client upgraded to a compliant version), the suspended routing process is resumed based on the context snapshot, and subsequent processing continues. This routing mechanism, which suspends operations due to insufficient conditions and automatically resumes operations when conditions are met, ensures process integrity while providing a non-blocking routing execution experience.

[0034] Step 103: After at least one interceptor logic has been executed, the target execution body is determined by querying the routing mapping table based on the path identifier carried in the routing request, and the private business parameters are passed through to the target execution body, which then executes the business logic.

[0035] If at least one interceptor logic is executed successfully based on public control parameters, the route mapping table is queried based on the parsed path identifier. The route mapping table records the correspondence between path identifiers and target executables. By querying the route mapping table, the target executable corresponding to this route request is determined, thereby locating the specific functional module or page that needs to be called.

[0036] After identifying the target executor, the private business parameters are passed through to the target executor, which then executes the business logic. Since the private business parameters encapsulate specific business-related data, passing them through to the target executor allows the target executor to focus on business logic processing.

[0037] By executing interceptor logic based on public control parameters, unified management of control flow is achieved. Private business parameters are passed through to the target executor, which then executes the business logic, thus clearly separating public and private control parameters. Through this separation mechanism, the routing and scheduling system is responsible for control flow management, while the target executor focuses on business logic. The two do not interfere with each other and can be modified and upgraded independently.

[0038] By determining the target execution body and passing private business parameters to the target execution body after at least one interceptor logic has passed, it can be ensured that only legitimate requests that meet the conditions can trigger business processing, thus avoiding the execution of invalid target location and business processing when the interceptor logic does not meet the conditions.

[0039] Step 104: Return the business logic execution result of the target executor to the caller, and after returning the business logic execution result, perform the post-linkage operation based on the implicit context.

[0040] After the target executor executes the business logic, the execution result is returned to the caller, allowing the caller to know the final status of this routing call. Specifically, at each stage from the receipt of the routing request to its completion, the execution status information of each stage is recorded and output. The recorded execution status information at each stage includes at least the execution time and the execution result. By recording the execution status information at each stage, the entire routing call process can be made observable: the execution time and result of each stage can be collected in real time for performance monitoring and anomaly alerts; when an anomaly occurs during the call, the specific stage and cause of the failure can be quickly located based on the recorded execution status information, significantly improving troubleshooting efficiency.

[0041] After returning the business logic execution result to the caller, subsequent linkage operations can be executed based on the implicit context. The implicit context, as context information obtained at the call entry point, is used to provide the necessary execution target and environment information for the subsequent linkage operations, enabling the routing scheduling system to complete the associated operations without intruding on the business code, and further improving the automation level of routing calls.

[0042] The above-described implementation scheme of this application, based on the routing request initiated by the caller following a unified protocol format, captures the caller's implicit context, which can provide necessary execution target and environment information for subsequent linkage operations. Simultaneously, the unified protocol format enables protocol standardization for multi-terminal calls. After parsing the routing request, at least one interceptor logic is executed based on public control parameters. After at least one interceptor logic passes execution, the target executor is determined by querying the routing mapping table based on the path identifier, and private business parameters are passed through to the target executor, which then executes the business logic. This achieves a clear separation between public control parameters and private business parameters and avoids invalid target location and business processing when the interceptor logic does not meet the conditions. After the target executor executes the business logic, the execution result is returned to the caller, allowing the caller to know the final state of this routing call. After returning the business logic execution result to the caller, subsequent linkage operations are executed based on the implicit context, further improving the automation level of the routing call.

[0043] Furthermore, during the execution of at least one interceptor logic, if a condition is not met, the context of the current route call is encapsulated to obtain a context snapshot, and the current route process is suspended to avoid blocking the main thread. After the condition is met, the suspended route process is resumed based on the context snapshot, which can ensure the integrity of the process while achieving a non-blocking route execution experience.

[0044] By recording and outputting the execution status information of each stage from the receipt of a routing request to its completion, the entire routing call process can be made observable for performance monitoring and anomaly alerts. It also supports the rapid location of the specific stage and cause of a fault, significantly improving the efficiency of troubleshooting.

[0045] In an optional embodiment of this application, the target executor is determined by querying the routing mapping table based on the path identifier carried in the routing request, and private service parameters are passed through to the target executor, including, for example... Figure 2 The following steps are shown: Step 201: Query the routing mapping table to identify whether the path identifier carried by the routing request matches the old path in the routing mapping table. The routing mapping table stores the basic mapping and redirection mapping. The basic mapping is the correspondence between the path identifier and the target execution body. The redirection mapping includes the correspondence between the old path and the new path, as well as the mapping rules between the old parameter fields and the new parameter fields.

[0046] The routing table stores basic mappings and redirection mappings. Basic mappings include the correspondence between path identifiers and target execution entities, while redirection mappings include the correspondence between old paths and new paths, and the mapping rules between old parameter fields and new parameter fields. The basic mappings are used to map the final path identifier to a specific target execution entity. The final path identifier is either a new path after redirection or the path identifier carried in the routing request. After at least one interceptor logic has executed successfully, the routing table is queried based on the path identifier carried in the routing request. During the query, it is determined whether the path identifier matches an old path, and step 202 is executed based on the matching result.

[0047] Step 202: In response to the path identifier carried in the routing request matching an old path, redirect the path identifier carried in the routing request to the corresponding new path, and query the base mapping based on the new path obtained after redirection to determine the target execution body; or, in response to the path identifier carried in the routing request not matching any of the old paths, query the base mapping based on the path identifier carried in the routing request to determine the target execution body.

[0048] If the path identifier carried in the routing request matches an old path, the path identifier is redirected to the corresponding new path based on the correspondence between old and new paths. Then, the base mapping is queried based on the new path obtained after redirection to determine the target executor. If the path identifier carried in the routing request does not match any of the old paths, the base mapping is queried directly based on the path identifier to determine the target executor.

[0049] If there is no old path matching the path identifier in the routing table, nor is there a new path matching the path identifier, it indicates that the target requested by the routing request does not exist. In this case, preset exception handling can be performed, such as returning a failure message, redirecting to the default page, or logging an error.

[0050] Step 203: After determining the target execution body, according to the mapping rules, convert the old parameter fields in the private business parameters of the routing request into new parameter fields, and pass the converted private business parameters through to the target execution body.

[0051] After determining the target execution body, the old parameter fields in the private business parameters of the routing request can be converted into new parameter fields according to the mapping rules to obtain the converted private business parameters, and then the converted private business parameters can be passed through to the target execution body.

[0052] While both public control parameters and private business parameters are carried in routing requests, the field names of public control parameters are uniformly defined and remain stable at the protocol level by the routing scheduling system. Business modules cannot change these field names and do not need to concern themselves with their definitions; therefore, field mapping is unnecessary. This solution implements field mapping for private business parameters, ensuring the independent evolution of business modules.

[0053] The field mapping mechanism is used to map old parameter fields in private business parameters to new parameter fields. When a business module undergoes an upgrade that changes parameter names, the new target execution body expects to receive the new field names, while the old caller still transmits parameters according to the old field names. If these old fields are directly passed through, the new business module will not be able to recognize them, leading to business failure. Therefore, the routing and scheduling system automatically completes the field conversion according to the mapping rules between old and new parameter fields, enabling the private business parameters to be correctly parsed and executed by the new business module.

[0054] The routing mapping table in this embodiment can be uniformly distributed by the configuration center deployed on the server-side device, and the client device can receive updates in real time through periodic fetching or long-term connections. When it is necessary to adjust the business path or protocol version, it is only necessary to modify the mapping relationship in the configuration center to achieve the binding of path identifiers with target execution entities, redirection from old paths to new paths, and automatic conversion of old parameter fields to new parameter fields. The entire process does not require client release or user to actively update the version.

[0055] In the above implementation scheme, after at least one interceptor logic has executed successfully, the routing map table is queried based on the path identifier in the routing request. If the path identifier matches an old path in the routing map table, the path identifier is redirected to the corresponding new path. The target execution body is then determined by querying the base mapping based on the new path. This path redirection mechanism ensures that old version routing requests can still be correctly forwarded when the access path of a business module changes. According to the field mapping rules, old parameter fields in private business parameters are converted to new parameter fields, and the converted private business parameters are passed through to the target execution body. This allows the private business parameters to be correctly parsed and executed by the target execution body. This parameter field mapping mechanism automatically adapts to changes in the parameter structure of business modules, further improving version compatibility.

[0056] By combining path redirection and parameter field mapping, legacy requests can still be correctly guided to the target execution body and executed normally without modifying any code, thus effectively solving the compatibility problem.

[0057] In an optional embodiment of this application, it also includes Figure 3 The following scheme is shown: Step 301: After determining the target executor, obtain the minimum runtime environment version supported by the target executor.

[0058] After locating the target executable based on the path identifier, it is necessary to obtain the minimum runtime environment version supported by the target executable. As a specific functional module or page, the normal operation of the target executable requires a specific runtime environment (such as operating system version, application version), and therefore it will specify the minimum runtime environment version it supports.

[0059] Step 302: In response to detecting that the version of the current runtime environment is lower than the minimum runtime environment version supported by the target executor, the routing request is intercepted, the routing request is redirected to the upgrade guide page, and a failure status information is returned to the caller; wherein, the upgrade guide page is used to prompt for upgrading the current runtime environment, and the failure status information is used to indicate version incompatibility.

[0060] After obtaining the minimum runtime environment version supported by the target executor, the current runtime environment version is compared with the minimum runtime environment version supported by the target executor. If the current runtime environment version is lower than the minimum runtime environment version supported by the target executor, it indicates that the current runtime environment cannot meet the running conditions of the target executor. In this case, the business logic cannot continue to be executed, the routing request needs to be intercepted, the routing request needs to be redirected to the upgrade guide page, and a failure status information needs to be returned to the caller.

[0061] Redirecting the routing request to the upgrade guide page essentially means that the routing scheduling system stops passing private business parameters to the target execution body. Instead, it intercepts the routing request and changes the target to a dedicated page prompting the user to upgrade. This informs the user that their current runtime environment version is too low and an upgrade is required before proceeding with subsequent operations. The upgrade guide page typically includes upgrade instructions or a redirect entry point to guide the user through the runtime environment upgrade, ensuring that subsequent routing calls can execute successfully.

[0062] The failure status information returned to the caller is, for example, a specific status code or error message. The caller is responsible for handling the upgrade logic, such as logging the failure, pausing related function calls, or actively triggering the upgrade guidance process.

[0063] Redirecting routing requests to the upgrade guide page provides users with visual upgrade guidance, resolving environmental upgrade issues at the user experience level; returning failure status information to the caller helps the caller understand the reason for the failure and take appropriate action; based on the processing mechanism of redirecting routing requests to the upgrade guide page and returning failure status information to the caller, business anomalies caused by incompatible runtime environments can be effectively avoided, ensuring the integrity of the call process under incompatible runtime environment conditions.

[0064] The above implementation scheme, after determining the target executor, compares the minimum operating environment version supported by the target executor with the version of the current operating environment. If the version of the current operating environment is lower than the minimum operating environment version supported by the target executor, the routing request is redirected to the upgrade guide page and a failure status information is returned to the caller. This can effectively avoid business anomalies caused by incompatibility of the operating environment and ensure business continuity.

[0065] The following describes the implementation process of capturing the caller's implicit context based on routed requests. For example... Figure 4 As shown, the process includes the following steps: Step 401: In response to receiving a routing request initiated by the caller, obtain the calling environment information at the call entry point. The calling environment information includes at least the current page identifier and the caller's source identifier.

[0066] Upon receiving a routing request from the caller, the system retrieves the calling environment information at the call entry point of the routing request. This information includes at least the current page identifier and the caller's source identifier. The call entry point serves as the starting point for the routing scheduling system to process the routing request. By proactively retrieving the caller's calling environment information at the entry point, the system can automatically collect the calling context even when the routing request itself does not carry this information, providing data for subsequent processing.

[0067] The current page identifier indicates the page that initiated this routing call, allowing the corresponding page to be located and manipulated. The caller's source identifier indicates the identity of the call source, such as the page name and module identifier. If the caller is a specific module within the client, the current page identifier is the identifier of the page where the module's code is executing; if the caller is a specific page within the client, the current page identifier is the identifier of that page itself; if the caller is an external application or an application on another device, the current page identifier is the identifier of the entry page opened after the current application is launched.

[0068] Step 402: Encapsulate the calling environment information into an implicit context, wherein the current page identifier is encapsulated into the initiating page operation interface in the implicit context, and the source identifier is encapsulated into the source identifier in the implicit context.

[0069] After obtaining the invocation environment information at the entry point of the route request, the invocation environment information, including the current page identifier and the caller's source identifier, is encapsulated to obtain the implicit context. The invocation environment information is not an explicit parameter carried in the route request, but rather implicit information automatically captured by the routing scheduling system at the invocation entry point, without the caller needing to be aware of or pass it on.

[0070] The implicit context, obtained by encapsulating the calling environment information, is a structured object. The implicit context includes the interface for initiating the page operation and the source identifier. The interface for initiating the page operation is encapsulated from the current page identifier in the calling environment information, and the source identifier is encapsulated from the source identifier in the calling environment information.

[0071] By obtaining call environment information, including the current page identifier and the caller's source identifier, at the call entry point of the routing request and encapsulating it as an implicit context, the caller's environment information can be integrated into the routing process in a structured form, providing a data foundation for subsequent processing, while enabling context passing to the caller without their awareness.

[0072] Based on encapsulating the calling environment information into an implicit context, this application provides an optional embodiment in which a post-linked operation is performed based on the implicit context, including the following process: After the target executor completes the business logic execution and returns a success result, check whether the public control parameters include a post-linkage identifier; In response to the public control parameters containing a follow-up linkage identifier, the operation interface of the initiating page in the implicit context is called to perform a preset follow-up action on the initiating page, which is the associated page of this routing request.

[0073] After the private business parameters are passed to the target executor and the target executor executes the business logic, and the target executor completes the business logic execution and returns a successful result, the routing scheduling system checks whether the public control parameters contain a post-linkage identifier. The public control parameters, as control information passed by the caller in the routing request, can carry an identifier field (i.e., a post-linkage identifier) ​​indicating whether post-linkage needs to be executed. This identifier can indicate whether post-linkage needs to be executed, or further specify the linkage type (such as closing the page, refreshing data, etc.), so that the routing scheduling system can determine the specific linkage action based on this identifier.

[0074] If the public control parameters include a follow-up linkage identifier, the initiating page operation interface in the implicit context is called. The initiating page of this call is located through this interface, and the corresponding follow-up action is performed on the initiating page based on the linkage type indicated by the follow-up linkage identifier (such as closing the page, refreshing data, etc.).

[0075] The initiating page, as a page instance of the caller, is the associated page for this routing request; the specific form of the initiating page varies depending on the caller. For example, if the caller is a specific module within the client, the initiating page is the page where the module's code is executed; if the caller is a specific page within the client, the initiating page is the page itself; if the caller is an external app or an application on another device, the initiating page is the entry page opened according to the routing request after the current application is launched.

[0076] If the target executor completes the business logic execution and returns a failure result, then regardless of whether the public control parameters include a follow-up linkage flag, no follow-up linkage operation is required. If the target executor completes the business logic execution and returns a success result, but the public control parameters do not include a follow-up linkage flag, then the routing scheduling system does not execute any follow-up linkage operation, and the process terminates normally.

[0077] By locating the page that initiated this call based on the interface of the page initiating the call in the implicit context, and performing the follow-up linkage operation based on the linkage type indicated by the follow-up linkage identifier contained in the public control parameters, the automation level of the route call can be further improved.

[0078] Based on encapsulating the invocation environment information into an implicit context, this application provides another optional embodiment, which includes the following operations: After returning the business logic execution result to the caller, traffic statistics are performed based on the source identifier; and when the business logic execution fails, the cause of the exception is attributed based on the source identifier.

[0079] After returning the execution result of the target executor's business logic to the caller, traffic statistics can be performed based on the source identifier, regardless of whether the business logic execution was successful or failed. Specifically, the routing and scheduling system records information such as the source identifier, path identifier, execution time, and execution result of this call, thereby statistically analyzing the total number of calls, the number of successful calls, the number of failed calls, and the response speed by source dimension, providing a data foundation for analyzing the call quality of each source.

[0080] If business logic execution fails, exception attribution can be performed based on the source identifier. Specifically, the source identifier of this call is associated with the reason for failure (such as interceptor block, business logic exception, timeout, etc.). The recorded information is used to analyze the number of failures and failure types by source dimension to help locate the source of the problem and improve the efficiency of troubleshooting.

[0081] In an optional embodiment of this application, the method further includes Figure 5 The following steps are shown: Step 501: Assign a globally unique call identifier to the route request.

[0082] The routing scheduling system assigns a globally unique call identifier to each routing request initiated by the caller. That is, each routing request generates a new, non-repeating identifier globally. Since the routing scheduling system may process a large number of routing requests simultaneously, the call identifier provides a unique identity for each request, avoiding confusion and thus enabling accurate differentiation between different routing requests.

[0083] Furthermore, at each stage of the routing request from receipt to completion, the call identifier is recorded as a key field in the execution status information, thereby connecting the status data scattered in each stage into a complete call chain and achieving full-process observability.

[0084] Step 502: In the asynchronous call scenario, establish a correspondence between the routed request and the business logic execution result based on the call identifier, and return the business logic execution result to the corresponding caller based on the correspondence.

[0085] In asynchronous call scenarios (such as cross-platform, cross-device, and cross-service), the call identifier serves as a credential linking the routed request and the business logic execution result, establishing a correspondence between the two. Based on this correspondence, the routing and scheduling system can accurately return the business logic execution result to the corresponding caller, completing the asynchronous callback loop.

[0086] In addition, when a routing request encounters an anomaly, the entire execution log and status data of the request can be quickly retrieved by calling the identifier, enabling precise location and cause analysis of the fault stage.

[0087] In the various embodiments of this application, the routing request involved in the process from receipt to completion includes a startup phase, an interception phase, a query phase, an execution phase, a result return phase, and a completion phase. In the startup phase, the routing scheduling system initiates the routing process based on the routing request launched by the caller. In the interception phase, the routing scheduling system executes the corresponding interceptor logic according to public control parameters to perform precondition checks and processing on the routing request. In the query phase, after the interceptor logic executes successfully, the routing scheduling system queries the routing mapping table based on the path identifier to determine the target executor. In the execution phase, the target executor executes business logic based on private business parameters. In the result return phase, after the target executor completes the execution of the business logic, the routing scheduling system returns the execution result to the caller. In the completion phase, the routing scheduling system completes all processing of this routing request (such as post-processing operations), and the entire routing process ends.

[0088] The execution status information recorded at each stage can be chained together by call identifier to form complete call chain data, which can be used for traffic monitoring and performance analysis. For example, performance bottlenecks can be located based on the time consumption data of each stage, and anomalies can be attributed based on execution results and error codes to improve troubleshooting efficiency.

[0089] Optionally, execution status information supports multi-granularity consumption: for example, global-level consumption is used to collect the full-link status data of all routing requests to achieve big data monitoring; local-level consumption is used to obtain the status information of a specified routing request at a specific stage to achieve single-call tracing; and result-level consumption is used to obtain the final execution result of the routing request to achieve simple callbacks in the business layer.

[0090] The routing call process in this application embodiment realizes full-process transparency from data recording and link connection to multi-granularity consumption, providing flexible and scalable data support for system performance optimization and business debugging.

[0091] This application provides a routing scheduling system, which serves as a unified entry point and scheduling hub for function calls between different endpoints, such as... Figure 6 As shown, the system includes: The capture module 601 is used to capture the implicit context of the caller in response to receiving a routing request initiated by the caller that follows a unified protocol format. The unified protocol format includes path identifiers, public control parameters, and private business parameters. The execution module 602 is used to execute at least one interceptor logic based on the public control parameters after parsing the routing request. During the execution of the at least one interceptor logic, if it is detected that the condition is not met, a context snapshot is encapsulated and the current routing process is suspended. After the condition is met, the execution of the current routing process is resumed based on the context snapshot. The processing module 603 is configured to, after the at least one interceptor logic has been executed, query the routing mapping table based on the path identifier carried in the routing request to determine the target execution body, and pass the private business parameters to the target execution body so that the target execution body can execute the business logic; The return execution module 604 is used to return the business logic execution result of the target executor to the caller, and after returning the business logic execution result, to perform a post-linkage operation based on the implicit context; The recording output module 605 is used to record and output the execution status information of each stage from the receipt of the routing request to its completion.

[0092] Optionally, the determining processing module includes: The query submodule is used to query the routing mapping table and identify whether the path identifier carried by the routing request matches the old path in the routing mapping table. The routing mapping table stores the basic mapping and the redirection mapping. The basic mapping is the correspondence between the path identifier and the target execution body. The redirection mapping includes the correspondence between the old path and the new path, as well as the mapping rules between the old parameter field and the new parameter field. The determination submodule is configured to, in response to a path identifier carried by the routing request matching an old path, redirect the path identifier carried by the routing request to the corresponding new path, and query the base mapping based on the new path obtained after redirection to determine the target execution body; or, in response to a path identifier carried by the routing request not matching any of the old paths, query the base mapping based on the path identifier carried by the routing request to determine the target execution body. The conversion and pass-through submodule is used to convert the old parameter fields in the private business parameters of the routing request into new parameter fields according to the mapping rules after determining the target execution body, and then pass-through the converted private business parameters to the target execution body.

[0093] Optionally, the system also includes: The acquisition module is used to acquire the minimum runtime environment version supported by the target executable after the target executable has been determined; The processing module is configured to, in response to detecting that the version of the current operating environment is lower than the minimum operating environment version supported by the target executor, intercept the routing request, redirect the routing request to the upgrade guide page, and return failure status information to the caller; The upgrade guide page is used to prompt users to upgrade the current operating environment, and the failure status information is used to indicate version incompatibility.

[0094] Optionally, the capture module includes: The acquisition submodule is used to obtain the call environment information at the call entry point in response to receiving a routing request initiated by the caller. The call environment information includes at least the current page identifier and the source identifier of the caller. An encapsulation submodule is used to encapsulate the calling environment information into the implicit context, wherein the current page identifier is encapsulated into the initiating page operation interface in the implicit context, and the source identifier is encapsulated into the source identifier in the implicit context.

[0095] Optionally, the return execution module includes: The detection submodule is used to detect whether the public control parameters contain a post-linkage identifier after the target executor completes the business logic execution and returns a success result. The execution submodule is invoked in response to the public control parameters containing the post-linkage identifier. It then invokes the initiating page operation interface in the implicit context to perform a preset post-action on the initiating page, where the initiating page is the associated page of this routing request.

[0096] Optionally, the system also includes: The statistical analysis module is used to perform traffic statistics based on the source identifier after returning the execution result of the business logic to the caller; and to perform anomaly attribution based on the source identifier when the business logic execution fails.

[0097] Optionally, the system also includes: The allocation module is used to allocate a globally unique call identifier to the routing request; A return module is established to establish a correspondence between the route request and the execution result of the business logic based on the call identifier in asynchronous call scenarios, and to return the execution result of the business logic to the corresponding caller based on the correspondence.

[0098] Optionally, the various stages include a startup stage, an interception stage, a query stage, an execution stage, a result return stage, and a completion stage; The execution status information recorded at each stage includes at least the execution time and the execution result.

[0099] As the system implementation is basically similar to the method implementation, it is described in a relatively simple way. For relevant details, please refer to the description of the method implementation.

[0100] This application also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described routing scheduling method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0101] For example, Figure 7 A schematic diagram of the physical structure of an electronic device is shown. (For example...) Figure 7 As shown, the electronic device may include a processor 710, a communications interface 720, a memory 730, and a communication bus 740. The processor 710, communications interface 720, and memory 730 communicate with each other via the communication bus 740. The processor 710 can call logical instructions stored in the memory 730. The processor 710 is used to execute various processes of the routing scheduling method according to the embodiments of this application, which will not be described in detail here.

[0102] Furthermore, the logical instructions in the aforementioned memory 730 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium 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 described in the various embodiments of this application.

[0103] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described routing scheduling method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0104] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0105] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0106] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A routing scheduling method, characterized in that, Applied to a routing scheduling system, which serves as a unified entry point and scheduling hub for function calls between different endpoints, the method includes: In response to receiving a routing request initiated by a caller that follows a unified protocol format, the implicit context of the caller is captured, wherein the unified protocol format includes path identifiers, public control parameters, and private business parameters; After parsing the routing request, at least one interceptor logic is executed based on the public control parameters. During the execution of the at least one interceptor logic, if it is detected that the condition is not met, a context snapshot is encapsulated and the current routing process is suspended. Once the condition is met, the execution of the current routing process is resumed based on the context snapshot. After the at least one interceptor logic is executed successfully, the target execution body is determined by querying the routing mapping table based on the path identifier carried in the routing request, and the private business parameters are passed through to the target execution body, which then executes the business logic. The business logic execution result of the target executor is returned to the caller, and after returning the business logic execution result, a follow-up linkage operation is executed based on the implicit context; Specifically, at each stage from the receipt of the routing request to its completion, the execution status information of each stage is recorded and output.

2. The method according to claim 1, characterized in that, The step of querying the routing mapping table to determine the target execution entity based on the path identifier carried in the routing request, and then passing the private service parameters to the target execution entity, includes: The routing mapping table is queried to identify whether the path identifier carried by the routing request matches the old path in the routing mapping table. The routing mapping table stores basic mapping and redirection mapping. The basic mapping is the correspondence between path identifier and target execution body. The redirection mapping includes the correspondence between old path and new path, as well as the mapping rules between old parameter fields and new parameter fields. In response to the path identifier carried by the routing request matching an old path, the path identifier carried by the routing request is redirected to the corresponding new path, and the base mapping is queried based on the new path obtained after redirection to determine the target execution body; or, in response to the path identifier carried by the routing request not matching any of the old paths, the base mapping is queried based on the path identifier carried by the routing request to determine the target execution body. After determining the target execution body, according to the mapping rules, the old parameter fields in the private business parameters of the routing request are converted into new parameter fields, and the converted private business parameters are passed through to the target execution body.

3. The method according to claim 1, characterized in that, Also includes: After determining the target executor, obtain the minimum runtime environment version supported by the target executor; In response to detecting that the version of the current runtime environment is lower than the minimum runtime environment version supported by the target executor, the routing request is intercepted, the routing request is redirected to the upgrade guide page, and a failure status information is returned to the caller; The upgrade guide page is used to prompt users to upgrade the current operating environment, and the failure status information is used to indicate version incompatibility.

4. The method according to claim 1, characterized in that, The step of responding to a routing request initiated by a caller that follows a unified protocol format and capturing the caller's implicit context includes: In response to receiving a routing request initiated by the caller, the call environment information is obtained at the call entry point. The call environment information includes at least the current page identifier and the source identifier of the caller. The invocation environment information is encapsulated into the implicit context, wherein the current page identifier is encapsulated into the initiating page operation interface in the implicit context, and the source identifier is encapsulated into the source identifier in the implicit context.

5. The method according to claim 4, characterized in that, The execution of the follow-up linkage operation based on the implicit context includes: After the target executor completes the business logic execution and returns a success result, it is detected whether the public control parameters include a post-linkage identifier; In response to the public control parameters including the post-linkage identifier, the initiating page operation interface in the implicit context is invoked to perform a preset post-action on the initiating page, where the initiating page is the associated page of this routing request.

6. The method according to claim 4, characterized in that, The method includes: After returning the execution result of the business logic to the caller, traffic statistics are performed based on the source identifier; and when the business logic fails to execute, the cause of the failure is attributed based on the source identifier.

7. The method according to claim 1, characterized in that, Also includes: Assign a globally unique call identifier to the routing request; In asynchronous call scenarios, a correspondence is established between the route request and the execution result of the business logic based on the call identifier, and the execution result of the business logic is returned to the corresponding caller based on the correspondence.

8. The method according to any one of claims 1 to 7, characterized in that, The various stages include the initiation stage, interception stage, query stage, execution stage, result return stage, and completion stage; The execution status information recorded at each stage includes at least the execution time and the execution result.

9. A routing scheduling system, characterized in that, The routing scheduling system serves as a unified entry point and scheduling hub for function calls between different endpoints. This system includes: The capture module is used to capture the implicit context of the caller in response to receiving a routing request initiated by the caller that follows a unified protocol format. The unified protocol format includes path identifiers, public control parameters, and private business parameters. An execution module is configured to execute at least one interceptor logic based on the public control parameters after parsing the routing request. During the execution of the at least one interceptor logic, if a condition is not met, a context snapshot is encapsulated and the current routing process is suspended. Once the condition is met, the execution of the current routing process is resumed based on the context snapshot. The processing module is configured to, after the at least one interceptor logic has been executed, query the routing mapping table based on the path identifier carried in the routing request to determine the target execution body, and pass the private business parameters to the target execution body so that the target execution body can execute the business logic; The return execution module is used to return the business logic execution result of the target executor to the caller, and after returning the business logic execution result, to perform a post-linkage operation based on the implicit context; The recording and output module is used to record and output the execution status information of each stage from the receipt of the routing request to its completion.

10. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the routing scheduling method as described in any one of claims 1 to 8.

Images