Service call method, application program, storage medium, and program product

Abstract

Embodiments of the present application provide a service calling method, an application program, a storage medium and a program product. The application program comprises a business layer and a multi-layer service architecture. The business layer of the multi-layer service architecture comprises a plurality of business domains corresponding to business implementation logic for implementing business functions. A service proxy layer is configured to provide proxy instances of a plurality of service functions defined by a service interface layer. A service implementation layer comprises service implementation logic of the plurality of service functions. The business layer is configured to determine and execute target business implementation logic in response to a business processing request. During the execution process, a target service function and a target business domain are determined. The service proxy layer is configured to determine a target proxy instance corresponding to the target service function and the target business domain. The target service implementation logic corresponding to the target service function is executed by the service implementation layer through the target proxy instance. The embodiments of the present application can improve the stability and security of the service calling process.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a service invocation method, application program, storage medium, and program product. Background Technology

[0002] With the rapid development of mobile internet technology, it has become commonplace for a single application to support multiple independent business functions (such as service object search, instant messaging, and service object payment). To cover multiple platforms such as Android and iOS, traditional cross-platform user interface frameworks or underlying bridging solutions are typically used to develop applications. This traditional approach essentially provides the application with a "global, shared" service access point. When multiple business functions call their respective required services through this shared access point, risks such as chaotic business logic and data leaks arise. For example, timeout parameters set in the payment function may affect the connection status of the instant messaging session, significantly impacting the stability and security of the service call process. Summary of the Invention

[0003] This application provides a service invocation method, application, storage medium, and program product to solve the problems of poor stability and operational risks in the service invocation process of existing applications.

[0004] Firstly, this application provides a service invocation method applied to an application, which includes a business layer and a multi-layer service architecture. The multi-layer service architecture includes a service proxy layer, a service interface layer, and a service implementation layer. The business layer includes business implementation logic for implementing business functions corresponding to multiple business domains, and the business implementation logic is shared across multiple platforms. The service proxy layer is used to provide proxy instances for multiple service functions. The proxy instances are defined through the service interface layer. The service implementation layer includes the service implementation logic for the multiple service functions.

[0005] The method includes:

[0006] The business function identifier of the target business function to be processed is determined by the business layer in response to the business processing request.

[0007] The business layer uses the business function identifier to determine the target business implementation logic corresponding to the target business function in the business layer;

[0008] The target business implementation logic is executed using the business layer, and during the execution of the target business implementation logic, the business domain and target service function identifier corresponding to the required target service function are determined.

[0009] Using the service proxy layer, the target service function identifier and the target proxy instance corresponding to the business domain are determined, and the target service implementation logic corresponding to the target service function is executed through the service implementation layer using the target proxy instance.

[0010] Secondly, embodiments of this application provide an application that includes a business layer and a multi-layer service architecture. The multi-layer service architecture includes a service proxy layer, a service interface layer, and a service implementation layer. The business layer includes business implementation logic for implementing business functions corresponding to multiple business domains, and the business implementation logic is shared across multiple platforms. The service proxy layer is used to provide proxy instances for multiple service functions. The proxy instances are defined through the service interface layer. The service implementation layer includes the service implementation logic for the multiple service functions. When the application is executed by a processing component, it implements the service invocation method as described in the first aspect above.

[0011] Thirdly, this application provides a computing device, including a processing component and a storage component; the storage component stores a computing program; the computer program includes an application program, which includes a business layer and a multi-layer service architecture; the multi-layer service architecture includes a service proxy layer, a service interface layer, and a service implementation layer; the business layer includes business implementation logic corresponding to multiple business domains, which is shared across multiple platforms; the service proxy layer provides proxy instances for multiple service functions; the proxy instances are defined through the service interface layer; the service implementation layer includes the service implementation logic for the multiple service functions; the computer program is invoked and executed by the processing component to implement the service invocation method described in the first aspect above.

[0012] Fourthly, this application provides a computer storage medium storing a computer program thereon. The computer program includes an application program, which includes a business layer and a multi-layer service architecture. The multi-layer service architecture includes a service proxy layer, a service interface layer, and a service implementation layer. The business layer includes business implementation logic corresponding to multiple business domains, which is shared across multiple platforms. The service proxy layer provides proxy instances for multiple service functions. The proxy instances are defined through the service interface layer. The service implementation layer includes the service implementation logic for the multiple service functions. When the computer program is executed by a processing component, it implements the service invocation method described in the first aspect above.

[0013] The service scheduling method provided in this application is applied to an application that includes a business layer and a multi-layer service architecture. This multi-layer service architecture includes a service proxy layer, a service interface layer, and a service implementation layer. The business layer includes business implementation logic for multiple business domains, each corresponding to a business function. This business implementation logic is shared across multiple platforms. The service proxy layer provides proxy instances for multiple service functions; these proxy instances are defined through the service interface layer. The service implementation layer includes service implementation logic for multiple service functions. A service invocation method implemented based on this application includes: utilizing the business layer in response to a business processing request, determining the business function identifier of the target business function to be processed, and determining and executing the target business implementation logic corresponding to the target business function in the business layer based on the business function identifier; during the execution of the target business implementation logic, determining the business domain and target service function identifier corresponding to the required target service function; utilizing the service proxy layer to determine the target proxy instance corresponding to the target service function identifier and business domain, and using the target proxy instance, executing the target service implementation logic corresponding to the target service function through the service implementation layer.

[0014] This embodiment provides an application with a multi-layered service architecture. By introducing a proxy pattern, proxy instances corresponding to different service functions in the service proxy layer are associated with both service function identifiers and business domains. This allows different business functions to transparently and securely share the same set of cross-platform proxy instances based on service function identifiers and business domains to execute related service implementation logic. This ensures that each business function enjoys a completely logically isolated service runtime environment, fundamentally eliminating data interference between different business domains and improving the security and stability of the application's service call process. Furthermore, this embodiment decouples the business implementation logic of the business layer from the service implementation logic through the business layer and the multi-layered service architecture. Different platforms can share the business implementation logic of the business layer, while the service implementation logic adapted to each platform is configured in the service implementation layer of the multi-layered service architecture. This approach not only improves application development efficiency and ensures the consistency of the same business function across different platforms, but also facilitates the expansion and maintenance of business and service implementation logic, enhancing the maintainability and scalability of the application. This is unprecedented in existing application service scheduling processes, creating a new working paradigm.

[0015] These or other aspects of this application will become more apparent in the following description of the embodiments. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 This application provides a schematic diagram of the service architecture of a service application.

[0018] Figure 2 A flowchart of one embodiment of a service scheduling method provided in this application is shown;

[0019] Figure 3 A schematic diagram of the structure of the computing device provided in this application is shown. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0022] Additionally, it should be noted that when user interaction operations or triggering operations are involved in the embodiments of this application, these operations include, but are not limited to, various interaction methods such as touch operations, gesture operations, voice operations, head movement operations, and eye movement operations. Touch operations include, but are not limited to, click operations, double-click operations, long-press operations, swipe operations, pinch operations, or mouse hover operations. Swipe operations include, but are not limited to, straight-line swipes and curved-line swipes.

[0023] With the rapid development of mobile internet technology, current application development needs to support multiple different platforms, such as Android and iOS. Since each platform has its specific Application Programming Interface (API) and service function implementation methods, the traditional application development approach involves writing the corresponding business logic for each platform's API and service function implementation. This leads to the problem of duplicated business logic for the same functions across different platforms, impacting not only application development efficiency but also the efficiency of updating and maintaining the business logic.

[0024] To address this issue, the inventors conceived of using a cross-platform user interface framework or underlying bridging solution during the application development phase. This approach allows business modules to implement business functions by calling services on the same platform (such as payment services, location services, etc.). However, this architecture essentially provides the application with a "global, shared" service access point. In other words, this architecture is based on a service abstraction pattern of interfaces and implementations, initially designed to solve the unified implementation of single business logic across multiple platforms. Therefore, when an application hosts multiple independent business functions, the service registration and discovery mechanism, centered on the service interface, cannot identify and distinguish the business domain to which the business processing request belongs. This leads to all business modules sharing the same service instance and service status data. Consequently, risks such as chaotic business logic and data leakage arise. For example, the timeout parameters set in the payment function may affect the connection status of the instant messaging session.

[0025] To address this technical problem, the inventors, through a series of studies, have provided a solution as described in this application. The basic idea is to design an application that includes a business layer and a multi-layered service architecture. This multi-layered service architecture includes a service proxy layer, a service interface layer, and a service implementation layer. The business layer includes business implementation logic for multiple business domains, each corresponding to a business function. This business implementation logic is shared across multiple platforms. The service proxy layer provides proxy instances for multiple service functions; these proxy instances are defined through the service interface layer. The service implementation layer includes the service implementation logic for multiple service functions. The service invocation method implemented based on this application includes: utilizing the business layer in response to a business processing request, determining the business function identifier of the target business function to be processed, and determining and executing the target business implementation logic corresponding to the target business function in the business layer based on the business function identifier; during the execution of the target business implementation logic, determining the business domain and target service function identifier corresponding to the required target service function; utilizing the service proxy layer to determine the target proxy instance corresponding to the target service function identifier and business domain, and using the target proxy instance, executing the target service implementation logic corresponding to the target service function through the service implementation layer.

[0026] This embodiment provides an application with a multi-layered service architecture. This application introduces a proxy pattern, where proxy instances corresponding to different service functions in the service proxy layer are associated with both the service function identifier and the business domain. Therefore, it enables different business functions to transparently and securely share the same set of cross-platform proxy instances based on the service function identifier and business domain to execute related service implementation logic. This ensures that each business function enjoys a completely logically isolated service runtime environment, fundamentally eliminating data interference between different business domains and improving the security and stability of the application's service call process. Furthermore, this embodiment decouples the business implementation logic of the business layer from the service implementation logic through the business layer and the multi-layered service architecture. Different platforms can share the business implementation logic of the business layer, while the service implementation logic adapted to each platform is configured in the service implementation layer of the multi-layered service architecture. This approach not only improves application development efficiency and ensures the consistency of the same business function across different platforms, but also facilitates the expansion and maintenance of the business implementation logic and service implementation logic, enhancing the maintainability and scalability of the application.

[0027] 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, and 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.

[0028] The implementation details of the technical solutions in the embodiments of this application are described in detail.

[0029] Figure 1 This application provides a schematic diagram of the service architecture of a service application, as shown below. Figure 1 As shown, the application includes a business layer 10 and a multi-layer service architecture 11; the multi-layer service architecture 11 includes a service proxy layer 110, a service interface layer 111, and a service implementation layer 112.

[0030] The business layer 10 includes business implementation logic for implementing business functions corresponding to multiple business domains, and the business implementation logic is shared by multiple platforms.

[0031] A business domain can be an industry field defined for the business functions provided by an application, representing the service scope of the application. For example, an e-commerce application can provide services such as shopping, instant messaging, and publishing multimedia content. The corresponding business domains for such an e-commerce application could include: an e-commerce transaction domain, an instant messaging domain, and a content community domain. Each business domain of the application contains at least one business function associated with that domain. For example, the e-commerce transaction domain includes shopping-related business functions such as browsing products, placing orders, and making payments; the instant messaging domain includes real-time communication-related business functions such as private messaging, group chat, and message notifications; and the content community domain includes content creation and interaction-related business functions such as publishing content (e.g., text or video), liking, commenting, and forwarding. The business implementation logic of a business function can be the logic code written by developers to implement that business function. Since the business implementation logic is shared by multiple platforms, in this embodiment, the business implementation logic is the same business logic executed by multiple platforms when implementing business functions. For platform-specific service function implementation logic, it can be configured in the service implementation layer 112 of the multi-layer service architecture 11 and executed through service calls. Specific service call methods will be described in detail in subsequent embodiments.

[0032] It should be noted that in this example, the calling interfaces for each business implementation logic in the business layer 10 are uniformly defined by the service interface layer 111 to ensure the consistency of functions across multiple platforms.

[0033] The service proxy layer 110 provides proxy instances for multiple service functions; these proxy instances are defined through the service interface layer 111. The service implementation layer 112 includes the service implementation logic for the multiple service functions.

[0034] Service functions refer to the functions that an application needs to implement in order to rely on the underlying capabilities of the operating system (such as taking pictures, positioning, and storage). Therefore, for the same service function, different platforms need to write corresponding service implementation logic and encapsulate and store it in the service implementation layer 112.

[0035] A proxy instance is an object instance used in the multi-layer service architecture 11 to represent a specific service function. Its interface is uniformly defined by the service interface layer 111, which encapsulates the call to the specific platform-related service implementation logic in the service implementation layer 112.

[0036] In some embodiments, considering that different platforms may have some unique service function implementations, the multi-layer service architecture 11 described above in this embodiment may further include a platform-specific implementation layer for storing the service implementation logic specific to each platform, so that the proxy instance of the service proxy layer 110 can call it. This improves the flexibility of the application in use on different platforms.

[0037] In the multi-layer service architecture 11 of this embodiment, the service interface layer 111 defines standardized service interfaces that are independent of the platform, based on the contract priority principle. Each interface corresponds to a single business capability point, and its usage specifications are clarified through contract metadata (such as version, platform support matrix, invocation strategy, etc.). At the same time, a runtime contract verification mechanism is established to ensure that each platform implementation conforms to the unified interface agreement, providing a stable and consistent service invocation contract for the business layer 10. The service proxy layer 110 relies on the service manager to realize dynamic service binding: it maintains the mapping relationship between interface identifier, platform type, and implementation logic (i.e., implementation class) through a centralized registry, supporting static or dynamic registration and coexistence of multiple versions. When the business layer 10 initiates a service call through the proxy instance, the service manager automatically discovers and loads the most matching platform implementation on demand based on the current business domain, target service function identifier, and running platform characteristics. The service implementation layer executes the specific implementation logic, thereby ensuring cross-platform reuse of business logic while flexibly adapting to the underlying capability differences of different operating systems.

[0038] Figure 2 A flowchart illustrating an embodiment of a service invocation method provided in this application; the technical solution of this embodiment can be applied to... Figure 1 The architecture diagram shown illustrates the development of an application (APP). This application is installed on an electronic device and depends on the device to run. The electronic device may have a display screen and support information browsing, and could be a personal mobile terminal such as a mobile phone, tablet, personal computer, desktop computer, smart speaker, smartwatch, etc.

[0039] Figure 2 The service invocation method shown may include the following steps:

[0040] S201, using the business layer's response to the business processing request, determines the business function identifier of the target business function to be processed.

[0041] Among them, a business processing request can be a request generated when a user performs a triggering operation on the application's user interface. For example, in an e-commerce application, if a user clicks the "Add to Cart" control on a product details page, the triggered business processing request is a request to add the product to the cart. A business function identifier is a unique identifier set to distinguish different business processing requests. Through this business function identifier, the business implementation logic of the corresponding business function can be located and invoked.

[0042] When an application receives any business processing request triggered by a user action, if the request carries a business function identifier for the target business function to be processed, the business layer can directly obtain the business function identifier from the request. If the request does not carry the business function identifier, the business layer can parse the request to extract or match the specific business function corresponding to the request, i.e., the target business function, and then determine the business function identifier corresponding to the target business function.

[0043] S202, using the business layer to determine the target business implementation logic corresponding to the target business function in the business layer based on the business function identifier.

[0044] Optionally, the business layer can locally store the mapping relationship between business function identifiers and business implementation logic identifiers. In this case, based on the business function identifier, the business implementation logic identifier that matches the target business function identifier can be found in the mapping relationship, and then the business implementation logic corresponding to the matching business implementation logic identifier can be used as the target business implementation logic. This achieves the mapping from abstract business function definitions to specific executable logic.

[0045] S203, utilize the business layer to execute the target business implementation logic, and during the execution of the target business implementation logic, determine the business domain and target service function identifier corresponding to the required target service function.

[0046] When the business layer executes S202 to determine the target business implementation logic, it dynamically identifies the service functions that the business implementation logic depends on to complete the logic, i.e., the target service functions (such as storage functions, location functions, etc.), based on the actual needs of the target business implementation logic (such as saving images, obtaining user location, etc.). Then, it uses the business domain of the target business function that needs to call the target service function as the corresponding business domain and obtains the target service function identifier. Finally, it transmits the determined business domain and target service function identifier to the service proxy layer.

[0047] S204. Using the service proxy layer, determine the target service function identifier and the target proxy instance corresponding to the business domain, and use the service implementation layer to execute the target service implementation logic corresponding to the target service function through the target proxy instance.

[0048] The service proxy layer searches for the corresponding target proxy instance from the set of proxy instances pre-registered during startup or declared through configuration files or annotations, based on the target service function identifier and its business domain transmitted by the business layer. Each proxy instance in this set is bound to a set of business domains and service function identifiers, has a standard interface uniformly defined by the service interface layer, and encapsulates the calling logic for platform-related service functions in the service implementation layer.

[0049] Each proxy instance in this embodiment encapsulates the calling logic for platform-related code in the service implementation layer. For example, on the iOS platform, it might encapsulate calls to the CoreLocation framework for location services, while on the Android platform, it encapsulates access to FusedLocationProviderClient. Similarly, when calling the camera, the iOS proxy instance uses UIImagePickerController, while the Android proxy instance integrates CameraX or an Intent to invoke the system camera. This encapsulation allows the business layer to be unaware of any platform differences, only needing to initiate calls through a unified interface. After determining the target proxy instance, the service proxy layer can further define a standard interface through the service interface layer to determine the target service implementation logic in the service implementation layer that matches the currently running operating system platform. Then, the service implementation layer executes the target service implementation logic to achieve the target service functionality.

[0050] This embodiment provides an application with a multi-layered service architecture. By introducing a proxy pattern, proxy instances corresponding to different service functions in the service proxy layer are associated with both service function identifiers and business domains. This allows different business functions to transparently and securely share the same set of cross-platform proxy instances based on service function identifiers and business domains to execute relevant service implementation logic. This ensures that each business function enjoys a completely logically isolated service runtime environment, fundamentally eliminating data interference between different business domains and improving the security and stability of the application's service call process. Furthermore, this embodiment decouples the business implementation logic of the business layer from the service implementation logic through the business layer and the multi-layered service architecture. Different platforms can share the business implementation logic of the business layer, while the service implementation logic adapted to each platform is configured in the service implementation layer of the multi-layered service architecture. This approach not only improves application development efficiency and ensures the consistency of the same business function across different platforms, but also facilitates the expansion and maintenance of business and service implementation logic, enhancing the maintainability and scalability of the application.

[0051] In some embodiments, after the service implementation layer executes the target service implementation logic, the process may further include: obtaining the processing result obtained by the service implementation layer from the execution of the target service implementation logic using the business layer, and continuing to execute the target business implementation logic based on the processing result. That is, the processing result of the service implementation layer executing the target service implementation logic needs to be transmitted back to the business layer through the target proxy instance of the service proxy layer. The business layer then continues to execute subsequent target business implementation logic based on this processing result to achieve the target business function, i.e., complete the relevant processing operations of the business processing request. Because this embodiment isolates the business domain of the target service function implementation logic call when executing the business processing request, it prevents data confusion or mutual interference between different business domains, thus improving the stability and security of service calls.

[0052] In some embodiments, to further improve the flexibility of the mapping process from target service function identifiers to target proxy instances, this embodiment may also include initializing a hierarchical state index structure using the service proxy layer when the application starts. The hierarchical state index structure is an index structure used to map business domains and service function identifiers to corresponding proxy instances. It includes organizational classifications built based on hierarchical naming rules for business domains, and the mapping relationship between service function identifiers and proxy instances corresponding to any category within the organizational classification. This multi-level state index structure adopts a tree-like hierarchical design. Through hierarchical naming rules for business domains (e.g., a multi-level naming convention of domain-subdomain-specific business), it constructs organizational classifications related to business domains, while maintaining a direct mapping between service function identifiers and specific proxy instances under each category. This design achieves a precise correspondence between business semantics and technical implementation, supporting efficient hierarchical navigation and instance location.

[0053] Specifically, during the application startup phase, the service proxy layer performs a global initialization, initializing (e.g., creating) the in-memory data structure of the aforementioned hierarchical state index structure. This structure is organized in a tree or nested dictionary format, with its top-level nodes divided into multiple organizational categories according to predefined business domain hierarchical naming rules. Under each organizational category, a mapping relationship between a service function identifier and a proxy instance is further maintained. These mapping relationships originate from platform service registration information submitted through configuration files, annotation scanning, or registration APIs during application startup, and are categorized and stored according to business domain prefixes, thus forming an efficient and searchable index system.

[0054] Accordingly, when performing the above-mentioned use of the service proxy layer to determine the target service function identifier and the target proxy instance corresponding to the business domain, the service proxy layer can be used to determine the corresponding category of the business domain from the organization classification based on the prefix matching positioning rule, and to find the target proxy instance corresponding to the target service function identifier from the mapping relationship of the classification.

[0055] Optionally, in addition to traversing the entire set of registered proxy instances as described in the above embodiments to find the target proxy instance, the service proxy layer can also utilize prefix matching positioning rules to quickly navigate and locate the target proxy instance. Specifically, firstly, the target business domain (such as the order business domain) is used as a prefix to match the corresponding organizational category in the hierarchical state index structure. For example, all categories starting with "order business domain" are found, or the root category of "order business domain" is precisely matched. Then, in the mapping relationship within this category, the target service function identifier is used as the key to directly find the corresponding target proxy instance (i.e., the value). This hierarchical indexing mechanism based on namespace prefixes significantly improves the efficiency of finding the target proxy instance, while supporting modular isolation and expansion of business domains, providing a maintainable and high-performance service routing foundation for large-scale multi-service integrated applications.

[0056] In some embodiments, the mapping relationship corresponding to any category in the organizational classification can be a mapping relationship between business domains and service function identifiers and proxy instances. For example, the key in the mapping relationship is a combination of service function identifiers and business domains, and the value is the proxy instance corresponding to that group of service function identifiers and business domains. Optionally, this mapping relationship can use hash concurrent mapping to store business domains and service function identifiers to corresponding proxy instances. That is, the target service function identifier has a mapping relationship with different proxy instances under different business domains; for example, the location function identifier corresponds to a high-precision location proxy instance in the order business domain and a low-precision location proxy instance in the instant messaging business domain. The location implementation logic called by the high-precision location proxy instance and the low-precision location proxy instance is different. For example, the high-precision location proxy instance may correspond to high-precision location implementation logic, and the low-precision location proxy instance may correspond to low-precision location implementation logic. In this case, finding the target proxy instance corresponding to the target service function identifier from the mapping relationship of the classification includes: finding the target proxy instance corresponding to the target service function identifier under the business domain from the mapping relationship of the business category. For example, in the mapping relationship within the category, the corresponding target proxy instance can be directly found using the combination of the target service function identifier and the business domain as the key. It not only solves the problem of instance ambiguity of service functions with the same name in different business domains, but also realizes a service proxy index paradigm that is semantically understandable, highly efficient in querying, and highly elastic in scalability from the architectural level.

[0057] In some embodiments, if the mapping relationship in this embodiment is a mapping relationship between a service function identifier and a corresponding proxy instance, and the same service function identifier may have a mapping relationship with multiple proxy instances, then finding the target proxy instance corresponding to the target service function identifier from the mapping relationship of the corresponding category of the business domain includes: finding multiple proxy instances corresponding to the target service function identifier from the mapping relationship of the category; and determining the target proxy instance from the multiple proxy instances based on the application scenario of the business domain.

[0058] Specifically, one approach is to first identify multiple proxy instances that map to the target service function identifier from the mapping relationships of the corresponding categories within the business domain. Then, the target proxy instance is selected from these instances based on the application scenario of the business domain. There are many ways to select the target proxy instance based on the application scenario, and this is not limited to any one method. One approach is to pre-configure the proxy selection requirements for different application scenarios and then determine the target proxy instance based on these requirements. For example, if the target service function is location services, and the order business domain corresponds to the order placement scenario in the shopping process, this scenario involves obtaining a contact address, which needs to accurately contact the user. Therefore, the proxy selection requirement for this scenario is high-precision location. If the location function corresponds to multiple location proxy instances with different positioning accuracies, then a high-precision location proxy instance can be selected as the target proxy instance. Another approach is to pre-set instance proxy identifiers for different application scenarios. In this case, the target proxy instance can be found based on the proxy instance identifier corresponding to the application scenario. This approach first identifies multiple candidate proxy instances within the business domain category, and then dynamically filters the target proxy instance based on the specific application scenario. This achieves semantically accurate, policy-pluggable, and runtime adaptive service routing capabilities, balancing flexibility, controllability, and high availability.

[0059] In practical applications, to ensure the efficient and low-overhead auxiliary determination of target proxy instances using the hierarchical state index structure, for business domains that have not sent business processing requests, their corresponding mapping relationships can be left uninitialized during the initialization of the hierarchical state index structure. That is, when performing the above-mentioned target proxy instance determination operation on the initialized hierarchical state index structure, the required target proxy instance may be missing from the mapping relationships contained in the hierarchical state index structure. To ensure that service function calls can still be completed in this case, this embodiment can utilize the service proxy layer to create a corresponding target proxy instance for the target service function when the target proxy instance is not found. For example, the service proxy layer, based on the target service function identifier and its business domain, parses service contract metadata (such as protocol type, security policy, etc.), dynamically constructs logical proxy instances with protocol adaptation, circuit breaking and degradation, load balancing, and health awareness capabilities through a proxy factory, and injects business domain context and unique identifiers into them to achieve on-demand, autonomous, and manageable instance generation. Subsequent operations are then performed based on the created target proxy instance. Simultaneously, the service proxy layer is used to construct a mapping relationship between the target proxy instance and the target service function identifier (or a mapping relationship between the target proxy instance, the target service function identifier, and the business domain), and the constructed mapping relationship is updated in the hierarchical state index structure. This solution incorporates the creation of proxy instances into a unified lazy loading mechanism framework. Not only is the mapping relationship loaded on demand, but its dynamic construction and initialization are only triggered when the target proxy instance is first confirmed to be missing in the initial query. This dual lazy strategy of "index-level lazy loading combined with proxy entity lazy instantiation" avoids the startup delay and resource redundancy caused by full pre-warming, and ensures that any new business function can still obtain a service access point with complete governance capabilities in real time without pre-configuration. Thus, it fundamentally realizes end-to-end on-demand supply from the index structure to the running entity, significantly improving the system's adaptability, lightweight level, and production readiness in scenarios such as microservice dynamic evolution, canary release, and sudden business access.

[0060] To ensure the structural consistency of the hierarchical state index under high concurrency scenarios, this embodiment can also precisely anchor the Double-Checked Locking (DCL) mechanism to the Trie node (i.e., the node in the organization classification). Specifically, when multiple threads simultaneously request a service function identifier under the same business domain, the service proxy layer first checks without locking whether a corresponding proxy instance already exists in the mapping table of the Trie node (first-level check); if it does not exist, a fine-grained lock is added to the Trie node for further confirmation (second-level check); only when it is confirmed to be empty is a proxy instance created.

[0061] The hierarchical state index structure in this embodiment is not merely a simple lookup table, but a dynamic management system encompassing business domain organization classifications and mapping relationships. This hierarchical state index structure can intelligently perform classification navigation and precise matching based on business domain identifiers. This design enables the allocation and management of service proxy instances to possess business semantic awareness capabilities, supports the dynamic addition, deletion, and reorganization of business domains, and provides unprecedented organizational flexibility for large and complex applications.

[0062] In some embodiments, to further enhance the dual lazy loading strategy of "index-level lazy loading combined with proxy entity lazy instantiation", when the target proxy instance is not found, creating a corresponding target proxy instance for the target service function using the service proxy layer includes: when the target proxy instance is not found, using the service proxy layer to determine whether the business domain meets the instance creation requirements; if it does, creating a corresponding target proxy instance for the target service function; if it does not, using the service proxy layer to create a corresponding virtual proxy object for the target service function, and executing the target service function through the virtual proxy object.

[0063] There are many ways to determine whether a business domain meets the instance creation requirements using the service proxy layer. One approach is to determine whether the business domain is authorized to use dynamic proxies; if so, the instance creation requirements are met; otherwise, they are not. Another approach is to use the service proxy layer to determine whether the resource consumption rate corresponding to the business domain is greater than a first value, and / or whether the historical call frequency corresponding to the business domain is greater than a second value.

[0064] Specifically, when determining resource consumption rate, the service proxy layer can periodically (e.g., every 10 seconds) collect real-time operating metrics of all registered proxy instances under the business domain. These metrics may include, but are not limited to, average CPU usage, heap memory utilization, active connections, average response latency, and error rate. These metrics are then weighted and integrated into a comprehensive resource consumption rate for the business domain. If the resource consumption rate is greater than a first quantitative value, it indicates that the business domain is a high-resource-consuming business domain and meets the instance creation requirements. If the resource consumption rate is less than or equal to the first quantitative value, it indicates that the business domain does not meet the instance creation requirements.

[0065] When determining based on historical call frequency, the service proxy layer can rely on a built-in lightweight sliding window counter to count the total call frequency (i.e., historical call frequency) of the business domain for the target service function identifier (or other service function identifiers of its category) within a preset time period (e.g., the last 5 minutes). If the historical call frequency is greater than a second value, it indicates that the business domain has a stable and observable call baseline, i.e., it meets the instance creation requirements; if the historical call frequency is less than or equal to the second value, it indicates that the business domain does not meet the instance creation requirements.

[0066] This embodiment upgrades the creation of proxy instances from unconditional triggering to evidence-based decision triggering by quantitatively assessing the real-time resource pressure and actual call volume of the business domain. This effectively prevents invalid instance expansion caused by low-frequency exploratory requests and avoids vicious resource competition in high-load scenarios, significantly improving the system's resource utilization efficiency and service governance accuracy.

[0067] In this embodiment, if the business domain meets the instance creation requirements, a corresponding target proxy instance can be created for the target service function using the method described in the previous embodiment. If the instance creation requirements are not met, the service proxy layer parses its interface contract based on the target service function identifier and its business domain, and dynamically generates a virtual proxy object without service instance binding. This virtual proxy object is in an inactive state before its first execution. When the application initiates its first call, the proxy layer triggers service discovery in real time, obtains a healthy backend instance from the registry center based on the context (such as regional tags and environment identifiers), completes address injection, protocol adapter initialization, security credential loading, and governance plugin parameter activation, and performs actual forwarding. Subsequent calls reuse the binding result, thereby achieving on-demand physicalization of the virtual object and zero-aware service access. It should be noted that although the virtual proxy object can also execute the target service function, the processing result of executing the target service implementation logic through the service implementation layer via the target proxy instance is more accurate than the result of executing the target service function through the virtual proxy object. This embodiment uses the creation of a target proxy instance as a strong pre-verification step to avoid blind instantiation in invalid or high-risk scenarios. This prevents proxy creation failures or runtime malfunctions caused by missing configurations, insufficient permissions, or abnormal environments, while ensuring clear system governance boundaries and controllable security. At the same time, this policy-based admission mechanism, in conjunction with lazy loading, enables on-demand creation and prudent supply, balancing agility and stability.

[0068] This embodiment employs a delayed creation strategy, where service proxy instances are only instantiated when the corresponding business domain meets the instance creation requirements, such as the first invocation, thus avoiding unnecessary resource overhead during application startup. Furthermore, combined with state context initialization and dynamic index updates, a complete lazy loading and lifecycle management system is formed. This not only reduces memory consumption but also, through linkage with hierarchical state indexes, achieves efficient instance location, caching, and consistency maintenance, optimizing resource utilization while ensuring isolation.

[0069] In practical application scenarios, the above-mentioned target proxy instance uses the service implementation layer to execute the target service implementation logic corresponding to the target service function. After obtaining the processing result, the service proxy layer needs to synchronously collect the service status data involved in this call (such as call success / failure, delay, error code, context label) and use this as an incremental synchronization event to drive the update and cross-node propagation of the status data of the corresponding business domain and the target service function.

[0070] Specifically, before invoking the corresponding service implementation logic in the service implementation layer through the target proxy instance to obtain service status data, the service implementation layer can determine the state synchronization mode based on the application scenario of the business domain. The state synchronization mode refers to the data propagation mode that is strongly bound to the business semantics when the service implementation layer synchronizes service running status data, which may include: master-slave synchronization mode, multi-master synchronization mode, and delayed synchronization mode.

[0071] Specifically, if the application scenario is of a high-security or strong-control type, a service proxy instance is selected as the master instance, and the remaining proxy instances are synchronized in a read-only master-slave mode; if the application scenario supports multi-terminal collaborative editing, multiple service proxy instances are allowed to write concurrently, and a multi-master synchronization process is triggered after writing, i.e., a multi-master synchronization mode is selected; if the status data is a non-critical configuration or user preference in the application scenario, a delayed synchronization mode is selected, i.e., the synchronization operation is delayed until the system is idle to avoid blocking the current service call path.

[0072] Accordingly, after obtaining service status data by calling the corresponding service implementation logic in the service implementation layer through the target proxy instance, the service implementation layer writes the service status data obtained by executing the target service implementation logic into the cache, updates the cache version information of the service status data, and performs the corresponding status synchronization operation according to the status synchronization mode to synchronize the service status data to the associated proxy instance of the target proxy instance.

[0073] Among them, the cache version information is a metadata field used to uniquely identify the logical timeliness and update sequence number of service status data in the local cache. Its value increases monotonically or evolves in a strictly ordered manner with each valid write of the status data.

[0074] After completing the execution of the target service function, the service implementation layer serializes the relevant service status data (e.g., call result code, response time, error type, context label, and business domain identifier) ​​into structured objects and writes them to a local high-performance cache. Simultaneously, it atomically updates the version information of the cache entry (i.e., cache version information). Subsequently, based on the state synchronization mode determined by the application scenario, the corresponding synchronization behavior is triggered. For example, in a master-slave synchronization mode, only the master instance encapsulates the latest state and version information in the cache into a synchronization event and pushes it to all associated proxy instances (i.e., read-only replicas under the same business domain) through a reliable message channel. The replicas receive the event, verify the version information, and apply it in sequence. In a multi-master synchronization mode, each instance broadcasts its local cache state along with its logical clock and operation type, and a coordination mechanism resolves conflicts and achieves global state convergence. In a delayed synchronization mode, only cache entries are marked as "pending synchronization," and a background daemon thread batch-fetches, compresses, merges, and asynchronously pushes the cached data during system idle periods. The entire process ensures that state data writing and synchronization are decoupled, version is traceable, and mode can be switched, while taking into account real-time performance, consistency, and system load balancing.

[0075] This embodiment deeply integrates state synchronization strategies with business scenarios and combines version-identified cache writing with patterned synchronous execution to achieve on-demand, orderly, and controllable propagation of service state data among distributed proxy nodes. It avoids consistency risks caused by concurrent writes at multiple points in high-security scenarios, meets the low-latency multi-master update requirements of collaborative scenarios, and also ensures zero interference to system performance from non-critical data. Overall, without increasing global coordination overhead, it uniformly supports the diverse needs of various businesses for state consistency, real-time performance, and resource sensitivity, significantly improving the adaptability, reliability, and manageability of the hierarchical state index structure.

[0076] Next, the process of resolving conflicts in the multi-master synchronization mode of the embodiment will be described, which may include: when the state synchronization mode is a multi-master synchronization mode, the service implementation layer receives the synchronization state data sent by the associated proxy instance of the target proxy instance and the synchronization version information corresponding to the synchronization state data; the business domain and service function corresponding to the synchronization state data are the same as those corresponding to the service state data; the service implementation layer determines the merging strategy corresponding to the business domain based on the synchronization version information and the cached version information, and merges the cached service state data and the synchronization state data based on the merging strategy, and updates the cached version information.

[0077] Specifically, in the multi-master synchronization mode, the service implementation layer actively receives synchronization status data and its corresponding synchronization version information from the associated proxy instances of the target proxy instance (i.e., other proxy nodes with write permissions under the same business domain). This synchronization status data and the locally cached service status data constitute a potential concurrent update pair. The service implementation layer compares the received synchronization version information with the cached version information of the locally cached service status data to determine whether there is a concurrent modification event. If a concurrent modification event is determined to exist, the service implementation layer queries the pre-configured state merging strategy for the business domain (such as a field priority-based overwrite strategy, a numerical accumulation strategy, a conflict-free replicated data type (CRDT) set merging strategy, or a manually defined business rule script), and performs semantic-level merging (i.e., non-simple overwrite) of the locally cached service status data and the received synchronization status data accordingly. After merging, the local cached version information is updated, and the merged service status information and the updated cached version information are written to the cache. If it is determined that there are no concurrent modification events, the version of the synchronized status data can be determined based on the synchronized version information and the cached version information. If so, the synchronized status data will overwrite the locally cached service status data; otherwise, no processing will be performed.

[0078] In this embodiment, the version information (such as cached version information and synchronized version information) can be used to characterize the structured metadata representing the logical update sequence number and time sequence relationship of service status data in a distributed environment. Its values ​​meet the requirements of monotonicity and comparability, supporting unambiguous determination of cross-node state evolution relationships. In this scheme, the version information can take the form of a vector clock, i.e., a key-value mapping set, where each key is a unique identifier for a service proxy instance (such as proxy instance A, proxy instance B), and the corresponding value is the number of times the service proxy instance locally updates the service status data. For example, if a version information is [proxy instance A: 3, proxy instance B: 1, proxy instance C: 0], this version information indicates that proxy instance A has performed 3 updates, proxy instance B has performed 1 update, and proxy instance C has not yet participated in the update.

[0079] Optionally, this embodiment includes a process for determining whether concurrent modification events exist: the service implementation layer receives synchronization status data and its synchronization version information (denoted as vector clock V) from the associated proxy instance. S After that, it is compared component by component with the cache version information (denoted as V1) associated with the status data of the corresponding business domain and service function in the local cache: if V S ≥ V1 (i.e., the number of updates i for all proxy instances is V) S [i] ≥ V1[i]), or V1 ≥ V S， Then it is determined that there are no concurrent modification events; if V S Incomparable to V1 (i.e., there exist some proxy instances whose update count i satisfies V) S If [i] > V1[i] (some do not meet the condition), it indicates that both parties have generated updates unknown to each other on their respective independent paths. Confirming the occurrence of a concurrent modification event, a preset business domain-level merging strategy needs to be triggered to perform state fusion.

[0080] To support high-concurrency, highly isolated service call scenarios across multiple business domains, this embodiment integrates a lightweight semantic context container within the proxy instance. This container is bound to the business domain identifier and service function identifier during proxy instance initialization, and embeds the current cache version information and vector clock to ensure a unified version view for state changes, conflict detection, and index updates. The context ensures that asynchronous callbacks, retries, circuit breaking, and degradation processes do not lose business semantics by implementing call chain pass-through. During the active phase, it carries service call statistics, state change events, and synchronization trigger condition judgments, and serves as the context basis for writing state data to the cache and initiating multi-master synchronization. Before destruction, the latest vector clock and key state snapshots are automatically persisted for index reconstruction or fault rollback. Thus, the context is no longer an isolated storage unit, but a consistent anchor point throughout the proxy instance's lifecycle, connecting the service call flow and hierarchical state index.

[0081] This solution's dynamic scalability is achieved using a "business domain as granularity, index as view, and proxy as carrier" approach. Each business domain corresponds to an independent category node, and its proxy instances all use a dedicated class loader to load and implement logic, ensuring class isolation and safe unloading. When a new service function identifier is requested for the first time, the service proxy layer dynamically generates adaptation code based on the contract metadata of that business domain and securely injects it into the corresponding Trie node through the DCL mechanism—the entire process does not restart or interrupt existing calls. Configuration hot updates are deeply integrated with the context container. After the configuration listener detects a configuration change in a business domain, it immediately triggers a context refresh for all proxy instances under that domain and writes the new configuration version information to the vector clock, driving the state synchronization mechanism to broadcast the change to associated proxy instances. Simultaneously, the configuration difference analysis module automatically identifies the scope of impact based on the Trie path and service function identifier, avoiding a full reload.

[0082] The security mechanism of this solution is deeply embedded in the hierarchical state index structure: each Trie category node has built-in cross-domain call policy rules, limiting which other business domains can access the service function identifiers under that business domain. The policy is loaded during the initialization of the proxy instance and participates in the routing decision. At the same time, relying on the vector clock in the context container, dynamic permission degradation driven by state timeliness is implemented. When the state version of a business domain lags behind the latest version of the cluster by more than a preset threshold, its proxy instance automatically enters read-only mode, prohibiting state writing and synchronization, and preventing outdated data from polluting the index. All policy decisions and degradation events generate audit records with Trie path and version information, which are written to the shard as part of the index state change, forming a traceable and verifiable index evolution audit chain. Thus, security capabilities become an inherent governance attribute of the index structure, rather than an external constraint.

[0083] This embodiment addresses the issue of data interference between different business domains, achieving deep isolation between them. By dynamically creating and maintaining a dedicated, isolated service proxy instance for each business domain and assigning it a private state context, the architecture ensures that service calls from different business domains are completely independent in terms of memory state, configuration parameters, and other dimensions. This approach is not simple instantiation, but rather intelligent lifecycle and mapping management implemented through a hierarchical state index structure, ensuring the systematic nature, consistency, and efficiency of isolation, and completely resolving the problem of data interference between different business domains in traditional shared models.

[0084] This embodiment shields the differences between different platforms while ensuring the transparency and reliability of business processing calls. By using a service proxy instance as a unified, isolated execution intermediary, the business layer does not need to know which underlying system platform it is implementing. The proxy instance dynamically obtains the corresponding implementation based on the current platform. Because this process occurs within their respective isolated contexts, the business layer enjoys both cross-platform transparency and the security and reliability of calls within its business domain.

[0085] This solution provides a unified and scalable architectural foundation, reducing maintenance costs. Through the service interface layer, it organically combines the standardization of proxy instances in the service proxy layer, centralized registration, indexed instance management, and isolated state maintenance, forming a clear, layered, and loosely coupled architectural model. This model simplifies and controls the addition of new business domains, platform support, service implementation updates, or adjustments to business categories, significantly reducing code duplication, the coupling between business logic and service functionality, and long-term system evolution and maintenance costs.

[0086] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear in this document, or they may be executed in parallel. The sequence numbers of the operations are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should also be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0087] Figure 3 This is a schematic diagram of the structure of one embodiment of a computing device provided in this application. Figure 3 As shown, in practice, the computing device may include a storage component 301 and a processing component 302.

[0088] Storage component 301 is used to store computer programs and can be configured to store various other data to support operation on a computing device. Examples of this data include instructions for any application or method used to operate on the computing device, data structures, contact data, phone book data, messages, pictures, videos, etc. The computer program includes an application program, which includes a business layer and a multi-layered service architecture. The multi-layered service architecture includes a service proxy layer, a service interface layer, and a service implementation layer. The business layer includes business implementation logic corresponding to multiple business domains, which is shared across multiple platforms. The service proxy layer provides proxy instances for multiple service functions; these proxy instances are defined through the service interface layer. The service implementation layer includes the service implementation logic for the multiple service functions.

[0089] Processing component 302, coupled to storage component 301, is used to execute computer programs in storage component 301 for implementing, etc. Figure 1 The service invocation method is shown.

[0090] Furthermore, such as Figure 3 As shown, the computing device may also include other components such as a communication component 303, a display component 304, a power supply component 305, and an audio component 306. Figure 3 The diagram only shows some components and does not mean that the device includes only these components. Figure 3 The components shown. Additionally... Figure 3 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the computing device. The computing device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT (Internet of Things) device, or a server-side device such as a conventional server, cloud server, or server array. If the computing device in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 3 The components within the dashed box; if the computing device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., then it may not include... Figure 3 The component within the dashed box.

[0091] The processing component described above includes one or more processors to execute computer instructions to complete all or part of the steps in the method described above. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the method described above.

[0092] The aforementioned storage components can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0093] The aforementioned communication component is configured to facilitate wired or wireless communication between the device housing the communication component and other devices. The device housing the communication component can access wireless networks based on communication standards, such as mobile communication networks, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0094] The aforementioned display components may include a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0095] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0096] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0097] Accordingly, this application also provides a computer-readable storage medium storing a computer program, the computer program including an application program, the application program including a business layer and a multi-layer service architecture; the multi-layer service architecture including a service proxy layer, a service interface layer, and a service implementation layer; the business layer including business implementation logic corresponding to multiple business domains to implement business functions, the business implementation logic being shared across multiple platforms; the service proxy layer is used to provide proxy instances of multiple service functions; the proxy instances are defined through the service interface layer; the service implementation layer includes the service implementation logic of the multiple service functions; when the computer program is executed by a processor, it causes the processor to implement the steps in the above method embodiments. The computer-readable storage medium may be volatile, non-volatile, or a combination thereof, and may be portable or non-portable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium.

[0098] Accordingly, this application also provides an application program, which includes a business layer and a multi-layer service architecture. The multi-layer service architecture includes a service proxy layer, a service interface layer, and a service implementation layer. The business layer includes business implementation logic for implementing business functions corresponding to multiple business domains, and the business implementation logic is shared across multiple platforms. The service proxy layer is used to provide proxy instances for multiple service functions. The proxy instances are defined through the service interface layer. The service implementation layer includes the service implementation logic for the multiple service functions. When the application program is executed by a processor, it enables the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by a computer program or instructions. In addition, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, so that the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device can be implemented as a means to implement the corresponding functions in the above method embodiments.

[0099] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0100] It should also be noted that 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 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.

[0101] Finally, it should be noted that the above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A service invocation method, characterized in that, This is applied to an application, which includes a business layer and a multi-layered service architecture. The multi-layered service architecture includes a service proxy layer, a service interface layer, and a service implementation layer. The business layer includes business implementation logic corresponding to multiple business domains, which is shared across multiple platforms. The service proxy layer is used to provide proxy instances for multiple service functions. The proxy instance is defined through the service interface layer; The service implementation layer includes the service implementation logic for the multiple service functions; The method includes: The business function identifier of the target business function to be processed is determined by the business layer in response to the business processing request. The business layer uses the business function identifier to determine the target business implementation logic corresponding to the target business function in the business layer; The target business implementation logic is executed using the business layer, and during the execution of the target business implementation logic, the business domain and target service function identifier corresponding to the required target service function are determined. Using the service proxy layer, based on the prefix matching positioning rule, the category corresponding to the business domain is determined from the organization classification constructed based on the business domain hierarchical naming rule. Then, from the mapping relationship of the category corresponding to the business domain, the target proxy instance corresponding to the target service function identifier is found. Through the target proxy instance, the target service implementation logic corresponding to the target service function is executed by the service implementation layer.

2. The method according to claim 1, characterized in that, Also includes: When the application starts, the hierarchical state index structure is initialized using the service proxy layer; The hierarchical state index structure includes organizational classifications built based on business domain hierarchical naming rules, and the mapping relationship between service function identifiers and proxy instances corresponding to any classification in the organizational classification.

3. The method according to claim 2, characterized in that, The target service function identifier has a mapping relationship with different proxy instances under different business domains; The step of finding the target proxy instance corresponding to the target service function identifier from the mapping relationship of the category corresponding to the business domain includes: From the mapping relationship of the categories corresponding to the business domain, find the target proxy instance corresponding to the target service function identifier under the business domain.

4. The method according to claim 2, characterized in that, The step of finding the target proxy instance corresponding to the target service function identifier from the mapping relationship of the category corresponding to the business domain includes: From the mapping relationship of the categories corresponding to the business domain, find multiple proxy instances corresponding to the target service function identifier; Based on the application scenario of the business domain, the target proxy instance is determined from multiple proxy instances.

5. The method according to any one of claims 2-4, characterized in that, Also includes: If the target proxy instance is not found, the service proxy layer is used to create a corresponding target proxy instance for the target service function. The service proxy layer is used to construct a mapping relationship between the target proxy instance and the target service function identifier, and the constructed mapping relationship is updated in the hierarchical state index structure.

6. The method according to claim 5, characterized in that, If the target proxy instance is not found, creating a corresponding target proxy instance for the target service function using the service proxy layer includes: If no target proxy instance is found, the service proxy layer is used to determine whether the business domain meets the instance creation requirements; if it does, a corresponding target proxy instance is created for the target service function. The method further includes: If the conditions are not met, a corresponding virtual proxy object is created for the target service function using the service proxy layer, and the target service function is executed through the virtual proxy object.

7. The method according to claim 6, characterized in that, The step of using the service proxy layer to determine whether the business domain meets the instance creation requirements includes: The service proxy layer is used to determine whether the resource consumption rate corresponding to the business domain is greater than a first quantity value, and / or whether the historical call frequency corresponding to the business domain is greater than a second quantity value.

8. The method according to any one of claims 1-4, characterized in that, After the service implementation layer executes the target service implementation logic corresponding to the target service function, the method further includes: The business layer obtains the processing result obtained by the service implementation layer from the execution of the target service implementation logic, and continues to execute the target business implementation logic based on the processing result.

9. The method according to any one of claims 1-4, characterized in that, Also includes: The service implementation layer determines the state synchronization mode based on the application scenario of the business domain. The service implementation layer uses the service state data of the target service implementation logic to write to the cache, updates the cache version information of the service state data, and performs the corresponding state synchronization operation according to the state synchronization mode to synchronize the service state data to the associated proxy instance of the target proxy instance.

10. The method according to claim 9, characterized in that, Also includes: When the state synchronization mode is a multi-master synchronization mode, the service implementation layer receives the synchronization state data sent by the associated proxy instance of the target proxy instance and the synchronization version information corresponding to the synchronization state data; the business domain and service function corresponding to the synchronization state data are the same as those corresponding to the service state data. Using the service implementation layer, based on the synchronized version information and the cached version information, if concurrent modification events are detected, a merging strategy corresponding to the business domain is determined. Based on the merging strategy, the cached service status data and the synchronized status data are merged, and the cached version information is updated.

11. An application architecture system, characterized in that, The application's architecture includes a business layer and a multi-layered service architecture; The multi-layer service architecture includes: a service proxy layer, a service interface layer, and a service implementation layer; the business layer includes business implementation logic corresponding to multiple business domains to implement business functions, and the business implementation logic is shared across multiple platforms; the service proxy layer is used to provide proxy instances for multiple service functions; the proxy instances are defined through the service interface layer; the service implementation layer includes the service implementation logic for the multiple service functions; when the application is executed by the processing component, it implements the service invocation method as described in any one of claims 1-10.

12. A computing device, characterized in that, It includes processing components and storage components; the storage components store computer programs; the computer programs include application programs, and the application programs include a business layer and a multi-layer service architecture. The multi-layered service architecture includes: a service proxy layer, a service interface layer, and a service implementation layer; the business layer includes business implementation logic for implementing business functions corresponding to multiple business domains, and the business implementation logic is shared across multiple platforms; the service proxy layer is used to provide proxy instances for multiple service functions; the proxy instances are defined through the service interface layer; the service implementation layer includes the service implementation logic for the multiple service functions; The computer program is used to be invoked and executed by the processing component to implement the service invocation method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, It stores computer programs, including application programs, which include a business layer and a multi-layer service architecture. The multi-layered service architecture includes: a service proxy layer, a service interface layer, and a service implementation layer; the business layer includes business implementation logic for implementing business functions corresponding to multiple business domains, and the business implementation logic is shared across multiple platforms; the service proxy layer is used to provide proxy instances for multiple service functions; the proxy instances are defined through the service interface layer; the service implementation layer includes the service implementation logic for the multiple service functions; When the computer program is executed by the processing component, it implements the service invocation method as described in any one of claims 1-10.

Images