A fine-grained service splitting and dynamic deployment method for object-oriented applications

Abstract

This invention belongs to the field of software refactoring and serverless computing technology, specifically relating to a fine-grained service decomposition and dynamic deployment method for object-oriented applications in edge environments. By constructing a method call graph through static analysis, and for the first time applying a hybrid heuristic algorithm combining particle swarm optimization and genetic operators to this graph partitioning problem, it can intelligently find a decomposition scheme that minimizes cross-function communication overhead while satisfying the limited resource constraints of edge nodes. This fundamentally solves the contradiction between computing resources and communication latency that traditional decomposition methods struggle to balance. Furthermore, by introducing Function-as-a-Service (FaaS) proxies and wrappers, it achieves automated refactoring of the original object-oriented code, enabling seamless migration of tightly coupled local calls to a distributed FaaS environment. This significantly reduces the technical threshold and operational complexity of application migration, achieving fine-grained resource utilization and elastic scaling.

Description

Technical Field

[0001] This invention belongs to the field of software refactoring and serverless computing technology, specifically relating to a fine-grained service decomposition and dynamic deployment method for object-oriented applications in an edge environment. Background Technology

[0002] With the rapid development of 5G, IoT, and edge computing, the massive amounts of data generated by terminal devices need to be processed in real time at the network edge to reduce transmission latency and alleviate pressure on the core network. Against this backdrop, serverless computing, as an emerging cloud-native architecture paradigm, is gradually becoming a crucial supporting technology for application deployment in edge computing scenarios due to its advantages such as on-demand resource allocation, automatic elastic scaling, pay-as-you-go billing, and simplified operation and maintenance. The core of serverless computing is Function as a Service (FaaS). Developers only need to focus on writing function code for business logic, while the platform handles underlying resource scheduling and runtime management. Function instances are dynamically created and executed only when a request is triggered, thereby achieving fine-grained resource utilization and cost optimization.

[0003] However, many enterprise applications are still developed based on traditional object-oriented programming paradigms, such as monolithic systems or distributed applications built using languages ​​like Java and C#. These applications are typically designed to run in a single process, with internal methods tightly coupled through object references and local calls, resulting in complex method call relationships and reliance on shared state and memory address spaces. Migrating such applications to serverless edge environments presents a series of technical challenges:

[0004] On the one hand, deploying the entire application as a coarse-grained function fails to realize the elastic scaling potential of FaaS, resulting in long cold start times and low resource utilization. On the other hand, excessively fine-grained decomposition, such as making each method an independent function, leads to a surge in cross-function communication overhead, significantly increasing application response latency and even causing network congestion due to numerous remote calls. Finding a balance between method call relationships, resource consumption, and communication costs—achieving fine-grained decomposition that satisfies resource constraints while minimizing communication overhead—has become a key challenge hindering the serverless migration of object-oriented applications.

[0005] Furthermore, the internal program structure of traditional object-oriented applications does not inherently support distributed deployment. Their method calls are based on direct jumps from memory addresses, making it impossible to cross node boundaries. In a FaaS environment, function instances typically communicate via RESTful APIs or message queues, requiring adaptive refactoring of the original code. Existing technologies largely rely on manual experience for function boundary delineation or simple static rules for splitting, lacking automated and systematic methods. For example, patent CN112817567A proposes a method for migrating Openwhisk serverless frameworks in microservice applications, identifying stateful and stateless modules through abstract syntax tree analysis. However, its delineation is primarily based on a simple classification of function types, failing to comprehensively consider the call frequency between methods, data transfer volume, and resource constraints of edge nodes, making it difficult to achieve an optimal balance between communication overhead and resource utilization. Simultaneously, most solutions do not fully consider the resource-constrained characteristics of edge nodes; split functions may fail to function properly due to exceeding the resource limits of a single container, or resource waste may occur due to improper resource configuration. At the collaborative deployment level, existing FaaS platforms mainly focus on the lifecycle management of individual functions, lacking descriptions of dependencies between multiple functions and automatic deployment support. Developers need to maintain function discovery, routing, and load balancing themselves, which increases the complexity of application development and operation.

[0006] Therefore, how to provide an automated, fine-grained service splitting and deployment mechanism for object-oriented applications, which can efficiently adapt to serverless edge environments while taking into account resource utilization, communication overhead, and application performance, has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] In view of the above problems, this application provides a fine-grained service decomposition and dynamic deployment method for object-oriented applications to solve the technical problems involved in the background art.

[0008] To achieve the above objectives, firstly, this application provides a fine-grained service decomposition and dynamic deployment method for object-oriented applications, applied to serverless edge computing environments, comprising the following steps:

[0009] S1. Obtain the source code of the object-oriented application and construct the method call graph of the application through static code analysis; the method call graph is based on methods as nodes and the calling relationships between methods as edges.

[0010] S2. The method call graph is divided based on a heuristic algorithm to obtain multiple method call subgraphs; wherein, the heuristic algorithm combines particle swarm optimization algorithm and genetic operator to perform iterative search with the goal of minimizing cross-subgraph communication overhead under the condition of satisfying the preset single deployment unit resource constraints, and the communication overhead is determined based on the call frequency and data transmission volume between methods;

[0011] S3. Based on each method call subgraph obtained from the division, reconstruct the source code to generate a function or service wrapper corresponding to each method call subgraph, and generate a function or service proxy for the application;

[0012] The function-as-a-service proxy is used to intercept the original method call request and forward the request to the local method or the corresponding remote function-as-a-service wrapper according to the preset mapping relationship. The function-as-a-service wrapper is an independent deployment unit that encapsulates one or more methods in its corresponding method call subgraph and provides a unified remote call interface for external or other function-as-a-service wrappers to call.

[0013] Unlike existing technologies, this application's technical solution constructs a method call graph through static analysis and, for the first time, applies a hybrid heuristic algorithm combining particle swarm optimization and genetic operators to this graph partitioning problem. This intelligently finds a partitioning scheme that minimizes cross-function communication overhead while satisfying the limited resource constraints of edge nodes, fundamentally resolving the contradiction between computational resources and communication latency that traditional partitioning methods struggle to balance. Furthermore, by introducing Function as a Service (FaaS) proxies and wrappers, it achieves automated refactoring of the original object-oriented code, enabling seamless migration of tightly coupled local calls to a distributed FaaS environment. This significantly reduces the technical threshold and operational complexity of application migration, achieving fine-grained resource utilization and elastic scaling.

[0014] In one embodiment of the present invention, step S1, which involves constructing the method call graph of the application through static code analysis, includes:

[0015] Starting with the entry method of the application, the statement set of each method is recursively analyzed;

[0016] When a statement is detected to contain a method call keyword, the method signature of the called method is extracted.

[0017] Record the current method as the caller of the called method, and find or create the node of the called method in the method node set;

[0018] Record or update the call relationship between the current method and the called method and its call frequency in the call relationship set.

[0019] As described above, by performing recursive analysis starting from the entry method and accurately identifying method call keywords and call frequencies, the complex runtime call relationships in object-oriented applications can be captured completely and accurately at the compiled code level. This method does not rely on manual annotation or dynamic execution trajectories, ensuring the comprehensiveness and automation of method call graph construction. It provides a precise data foundation for subsequent intelligent decomposition based on graph theory, avoiding decomposition decision errors caused by missing call relationships.

[0020] As one embodiment of the present invention, in step S2, the heuristic algorithm uses a discrete encoding method to represent the partitioning scheme. Each particle encodes the connection or disconnection state of each edge in the method call graph. The nodes connected by the edges in the connected state of the particles constitute a method call subgraph.

[0021] As described above, the discrete encoding method directly maps the partitioning scheme of the method call graph into a binary sequence of particles. Each gene position intuitively corresponds to the "connected / disconnected" state of the edges in the graph. This encoding method has inherent completeness and non-redundancy, ensuring that the solution space is completely covered without repetitive representations. Subgraphs are naturally formed through connected edges in the particles, allowing the partitioning results to be processed and evaluated directly and efficiently by the algorithm, greatly simplifying the solution difficulty of complex graph partitioning problems.

[0022] As one embodiment of the present invention, the particle update strategy of the heuristic algorithm includes an inertial part, an individual cognitive part, and a social cognitive part;

[0023] The inertial component is achieved through a mutation operation controlled by inertial weights, which is used to flip and mutate some gene positions of the particle.

[0024] The individual cognitive part and the social cognitive part are respectively implemented through two-point cross-operations controlled by the first cognitive factor and the second cognitive factor, which are used to exchange gene fragments with the individual's historical best particle and the global best particle, respectively.

[0025] As described above, this approach deeply integrates the global search framework of the particle swarm optimization (PSO) algorithm with the mutation and crossover operators of the genetic algorithm. The inertia component maintains population diversity through mutation, preventing the algorithm from prematurely getting trapped in local optima; the individual cognition and social cognition components, through crossover, enable particles to learn from their own historical best and the group's global best experiences, effectively guiding the search direction. This hybrid strategy combines the advantages of both algorithms, demonstrating stronger global optimization capabilities and faster convergence speed when solving the complex combinatorial optimization problem of method call graph partitioning.

[0026] In one embodiment of the present invention, the inertial weight is dynamically adjusted based on the degree of difference between the current particle and the global optimal particle, and the degree of difference is quantified according to the difference between the values ​​of the particle and the global optimal particle at each gene.

[0027] As described above, by quantifying the difference between the current particle and the global optimal particle in real time and dynamically adjusting the inertia weight accordingly, the algorithm's search capability is adaptively adjusted. In the early stages of iteration, when the particle differs significantly from the optimal solution, a larger inertia weight helps enhance the global exploration capability; in the later stages of iteration, when the particle is close to the optimal solution, a smaller inertia weight is beneficial for refined local search. This dynamic adjustment mechanism balances the algorithm's exploration and development capabilities, further improving the solution quality and stability.

[0028] In one embodiment of the present invention, in step S3, the generation of the function, i.e., the service proxy, includes:

[0029] Create a proxy method for the original method, wherein the signature of the proxy method is the same as that of the original method;

[0030] Add service lookup logic to the proxy method to obtain the service identifier of the target function, i.e., the service wrapper, from the configuration file based on the method signature of the called method.

[0031] Add call routing logic to the proxy method to determine the call type based on the service identifier: if it is a local call, call the local method directly; if it is a remote call, encapsulate the method signature and call parameters into a request payload, send it to the target function (service wrapper) via Hypertext Transfer Protocol, and parse the returned result.

[0032] As described above, the generated function-as-a-service proxy transparently intercepts and forwards the original method call. The proxy method maintains the same signature as the original method, remaining completely non-intrusive to the upper-layer caller. Through built-in service lookup and routing logic, the proxy can dynamically determine the call target (local or remote) based on the configuration file and automatically complete parameter serialization, HTTP communication, and result deserialization. This design completely encapsulates the complex details of distributed calls, allowing developers to use remote functions as if they were calling local methods, greatly simplifying the programming model of distributed applications.

[0033] In one embodiment of the present invention, in step S3, the generation of the function, i.e., the service wrapper, includes:

[0034] Create a wrapper class for its corresponding method call subgraph;

[0035] Create an entry point component in the wrapper class. The entry point component contains an endpoint unit that serves as a remote call endpoint and a binder unit for binding multiple methods within a subgraph.

[0036] The endpoint unit is used to listen for and receive external Hypertext Transfer Protocol requests, and parse the method signature and parameters in the requests;

[0037] The binder unit is used to call the corresponding target method in the wrapper class according to the parsed method signature and return the execution result.

[0038] As described above, by introducing the entry point component, a unified and standardized remote invocation facade is provided for each Function-as-a-Service wrapper. The endpoint unit, as a fixed RESTful API interface, solves the problem of FaaS instances being difficult to address externally; the binder unit implements dynamic dispatching of external request signatures to internal concrete methods. This structure allows a wrapper to provide services for multiple methods externally, avoiding the fine-grained explosion problem of deploying a separate function for each method, while maintaining the efficiency of local calls between internal methods and reducing the overall number of cross-function calls.

[0039] As one embodiment of the present invention, after deploying the generated multiple function-service wrappers to a serverless edge environment, the method further includes:

[0040] Each function / service wrapper instance registers its metadata with the service registry upon startup; the metadata includes at least the service identifier and its corresponding endpoint information.

[0041] When any function-as-a-service proxy or function-as-a-service wrapper needs to call the target function-as-a-service wrapper, it obtains the endpoint information of the target function-as-a-service wrapper by querying the service registry, and initiates a remote call based on the endpoint information to achieve collaboration between multiple independent deployment units.

[0042] As described above, the introduction of a service registry-based collaboration mechanism solves the communication and addressing problem between dynamic, distributed FaaS instances. Each wrapper instance actively registers its own metadata upon startup, enabling the entire system to dynamically perceive the service's availability and access address. The caller obtains the target endpoint by querying the registry rather than hard-coded addresses, decoupling the caller and the callee. This enhances the system's robustness and scalability in the face of elastic scaling, instance failures, or migrations, providing infrastructure-level support for building robust distributed serverless applications.

[0043] In one embodiment of the present invention, in step S1, the preset resource constraints of a single deployment unit include an upper limit and / or a lower limit of computing resources, wherein the computing resources are estimated based on the execution cost of all methods within the subgraph.

[0044] As described above, by explicitly setting upper and lower limits for resource constraints on individual deployment units, it is ensured that each method call subgraph (i.e., function-as-a-service wrapper) after splitting can adapt to the limited and heterogeneous resource configurations of edge nodes. The upper limit constraint avoids the problem of functions being too large or having excessive resource requirements, preventing them from running on specific nodes; the lower limit constraint helps aggregate fine-grained methods, improves container resource utilization, and prevents excessive management and scheduling overhead caused by overly fine-grained functions. This design is a key guarantee for making the splitting scheme feasible and deployable in real-world edge environments.

[0045] As one embodiment of the present invention, the fitness function of the heuristic algorithm is constructed based on the total completion time of the application, wherein the total completion time is the sum of the total execution time of all methods within the subgraph and the total communication time of cross-subgraph calls; wherein, for partitioning schemes that do not meet the resource constraints, their fitness value is set to a preset maximum penalty value.

[0046] As described above, constructing a fitness function oriented towards the total application completion time directly addresses the core optimization objective—reducing user-perceived response latency. Using the sum of total execution time and total communication time as the fitness value ensures consistency between the algorithm's search direction and the performance optimization goal. Specifically, by assigning a preset maximum penalty value to infeasible solutions that do not meet resource constraints, the search space can be effectively guided towards feasible solutions, preventing the algorithm from wasting computational resources on invalid solutions and guaranteeing the practicality and effectiveness of the final output partitioning scheme.

[0047] The above description of the invention is merely an overview of the technical solution of this application. In order to enable those skilled in the art to better understand the technical solution of this application and to implement it based on the description and drawings, and to make the above-mentioned objectives and other objectives, features and advantages of this application easier to understand, the following description is provided in conjunction with the specific embodiments and drawings of this application. Attached Figure Description

[0048] The accompanying drawings are only used to illustrate the principles, implementation methods, applications, features, and effects of specific embodiments of this application and other related content, and should not be considered as limitations on this application.

[0049] In the accompanying drawings of the instruction manual:

[0050] Figure 1This is a flowchart illustrating the steps of a fine-grained service decomposition and dynamic deployment method for an object-oriented application according to this application.

[0051] Figure 2 Example diagram of particle encoding scheme for the method of this application;

[0052] Figure 3 This is a schematic diagram illustrating the delayed calculation situation of the method in this application;

[0053] Figure 4 This is a schematic diagram of the particle mutation operation in this application;

[0054] Figure 5 This is a schematic diagram of the particle crossover operation in this application;

[0055] Figure 6 This is the MPPGA flowchart for this application;

[0056] Figure 7 This is a schematic diagram of the source code structure of this application;

[0057] Figure 8 This is a schematic diagram of the target program structure of this application;

[0058] Figure 9 This application provides source code and Function as a Service (FaaS) proxy. Code diagram;

[0059] Figure 10 The function-service wrapper of this application ( )and Code diagram;

[0060] Figure 11 This is a call diagram for the "face detection" application method in this application;

[0061] Figure 12 This is a schematic diagram of the method call graph partitioning results for the "face detection" application in this application;

[0062] Figure 13 Here are the structure diagrams of each FaaS_Wrapper in this application;

[0063] Figure 14 This is a schematic diagram illustrating the call relationship of the target application in this application;

[0064] Figure 15 This is a schematic diagram of the "face detection" application in this application during runtime;

[0065] Figure 16 This is a structural block diagram of a fine-grained service decomposition and dynamic deployment system for an object-oriented application according to this application;

[0066] The reference numerals used in the above figures are explained as follows:

[0067] 1. Processor; 2. Memory. Detailed Implementation

[0068] To illustrate the possible application scenarios, technical principles, implementable specific solutions, and achievable objectives and effects of this application in detail, the following description, in conjunction with the listed specific embodiments and accompanying drawings, provides a detailed explanation. The embodiments described herein are merely illustrative of the technical solutions of this application and are therefore intended to limit the scope of protection of this application.

[0069] In this document, the term "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The term "embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment, nor does it specifically limit its independence or connection with other embodiments. In principle, in this application, as long as there are no technical contradictions or conflicts, the technical features mentioned in each embodiment can be combined in any way to form corresponding implementable technical solutions.

[0070] Unless otherwise defined, the technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the use of related terms herein is merely for the purpose of describing particular embodiments and is not intended to limit this application.

[0071] In the description of this application, the term "and / or" is used to describe the logical relationship between objects, indicating that three relationships can exist. For example, X and / or Y means: X exists, Y exists, and X and Y exist simultaneously. Additionally, the character " / " in this document generally indicates that the preceding and following objects have an "or" logical relationship.

[0072] In this application, terms such as “first” and “second” are used only to distinguish one entity or operation from another, and do not necessarily require or imply any actual quantity, hierarchy or order relationship between these entities or operations.

[0073] Unless otherwise specified, the use of terms such as “comprising,” “including,” “having,” or other similar expressions in this application is intended to cover non-exclusive inclusion, which does not exclude the presence of additional elements in a process, method, or product that includes the stated elements, such that a process, method, or product that includes a list of elements may include not only those defined elements but also other elements not expressly listed, or elements inherent to such a process, method, or product.

[0074] As understood in the Examination Guidelines, in this application, expressions such as "greater than," "less than," and "exceeding" are understood to exclude the stated number; expressions such as "above," "below," and "within" are understood to include the stated number. Furthermore, in the description of the embodiments in this application, "multiple" means two or more (including two), and similar expressions related to "multiple" are also understood in this way, such as "multiple groups" and "multiple times," unless otherwise explicitly specified.

[0075] In the description of the embodiments of this application, the space-related expressions used, such as "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "vertical," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential," indicate the orientation or positional relationship based on the orientation or positional relationship shown in the specific embodiments or drawings. They are only for the purpose of describing the specific embodiments of this application or for the reader's understanding, and do not indicate or imply that the device or component referred to must have a specific position, a specific orientation, or be constructed or operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0076] Unless otherwise expressly specified or limited, the terms "installation," "connection," "linking," "fixing," and "setting," as used in the description of the embodiments of this application, should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral setting; it can be a mechanical connection, an electrical connection, or a communication connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be the internal connection of two components or the interaction between two components. For those skilled in the art to which this application pertains, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0077] Example 1

[0078] like Figure 1 As shown, the present invention provides a fine-grained service decomposition and dynamic deployment method for object-oriented applications, which mainly includes three core stages: static analysis of program code, method call graph partitioning, and code refactoring.

[0079] First, the source code of the object-oriented application is analyzed using static code analysis techniques. This invention preferably employs the Soot analysis framework, which abstracts and models the application as a method call graph. This method call graph uses methods as nodes and call relationships and parameter passing as edges, comprehensively depicting the runtime call structure within the application.

[0080] Next, the method call graph is partitioned based on the heuristic algorithm MPPGA (Method Partition based on Particle Swarm Optimization combined with Genetic Operators Algorithm) proposed in this invention, aiming to obtain method call subgraphs suitable for offloading in a serverless edge environment. This algorithm uses particle swarm optimization as a framework, integrating mutation and crossover operators from genetic algorithms. While satisfying the computational resource constraints of each subgraph, it minimizes cross-subgraph communication overhead, achieving optimized configuration for computational migration.

[0081] Finally, to support the deployment and operation of object-oriented applications in serverless edge environments, this invention proposes a target program structure and achieves adaptive transformation of the application through code analysis techniques. Specifically, after obtaining a suitable method call subgraph using the MPPGA algorithm, the application is transformed into the target program structure through code refactoring, and two core code components are introduced: a FaaS proxy (FaaS_Proxy) and a FaaS wrapper (FaaS_Wrapper). For each obtained method call subgraph, a corresponding FaaS proxy and FaaS wrapper are generated to support the application's operation in serverless edge environments.

[0082] Example 2: Construction of the method call graph

[0083] This embodiment details the process of constructing the method call graph in step S1.

[0084] Definition 1: The program structure of an object-oriented application can be represented by a method call graph. To indicate, among which This indicates that the method calls the entry method of the graph; This indicates the set of nodes in the graph that the method calls. This indicates that a method is called from the graph. This represents the set of call relationships between nodes in the method call graph. Indicates method call to method in the diagram and There is a calling relationship between them. The weight represents the frequency of method calls.

[0085] Definition 2: Each method is represented as a tuple of its method signature and the set of its callers. ,in Representation method Method signature, For method The set of callers.

[0086] Definition 3: The execution cost of a method is... To represent the method The execution cost, .in Representation method Required computing resources Indicates calling a method Data transmission volume, Indicates the required computing resources Below, method Execution time.

[0087] Algorithm 1 describes the specific process of extracting the method call graph. This algorithm uses the main method... As the entry point of the program, from the method We begin by gradually constructing the method call graph of the entire application. See Table 1 below for details:

[0088]

[0089]

[0090] Table 1

[0091] The algorithm uses a HashMap structure to record the call relationship. The key of a HashMap is defined as < >, its corresponding value representation method Calling methods The number of times. The algorithm's input includes the program entry point. as well as statement set Statement set Extracted by Soot, where express The first in Lines 2 through 20 of Algorithm 1 are recursive calls. The method call graph is constructed step by step. The parameters in this method... These represent the methods that need to be analyzed and their corresponding sets of statements. Specifically, line 4 is used for parsing. The keyword "Soot" in the text, such as: The keyword indicates that the statement is a method call. Detailed definitions of these keywords can be found in the Soot official documentation. If the current statement contains the method call keyword, the algorithm will process the set in lines 6 through 15. Perform an update. During the update, first, line 7 will... Marked as The caller; then line 8 in Searching by method signature If in Found in Then update The list of callers (lines 10-11); otherwise, create a new method node. Add it to (Lines 12-15). Then, lines 16-21 address the set of call relationships. Update. Specifically, if and The calling relationship will then be the key. Increment the corresponding value by 1 (lines 16-17); otherwise, increment the value by 1. Add new key-value pairs (Lines 18-21). After the recursive call ends, the algorithm outputs the complete method call graph.

[0092] Example 3: Fine-grained decomposition of method call graph (MPPGA algorithm)

[0093] This embodiment details the implementation of the MPPGA algorithm in step S2.

[0094] 3.1 Problem Formalization

[0095] According to Definition 1, an application is modeled as a method call graph. According to definition 3, using To represent the method The execution cost.

[0096] Assume Let represent the method call subgraph obtained after splitting the method call graph. Assume the method call subgraph... There is One method, which consumes total resources It can be represented as:

[0097]

[0098] For any two methods Its transmission time It can be represented as:

[0099]

[0100] in, This indicates the data transfer rate when calls occur between methods that are not within the same subgraph. Representation method The subgraph to which it is split, for example Then the method is represented. Split into subgraph .

[0101] Based on the above definition, the total completion time of the application can be expressed as:

[0102]

[0103] in, The total execution time of a method is represented by the following definition:

[0104]

[0105] The total transmission time between methods is defined as follows:

[0106]

[0107] This paper aims to find a method call graph partitioning scheme that is as efficient as possible to minimize the total application completion time. Meanwhile, to ensure container resource utilization, we introduce a resource constraint upper bound for the method call subgraph. With the lower bound of resource constraints Therefore, the problem can be formulated as follows:

[0108]

[0109] 3.2 Problem Coding

[0110] This invention employs a discrete encoding method, and the encoding of the i-th particle in the t-th iteration can be expressed as: Each encoded particle corresponds to a potential solution to the method partitioning problem. The particle code consists of r elements, where r is the number of edges in the obtained method call graph. This represents the connection status of the j-th edge for the i-th particle after the t-th iteration. Specifically, The value is ,when When, it indicates that the j-th edge in the graph is in a connected state; when When the method calls the j-th edge in the graph, it indicates that the edge is disconnected. Figure 2 An example of encoding particles for a method partitioning scheme. With this encoding method, in the final method partitioning scheme, all nodes that are connected by unbroken edges will naturally form several connected subgraphs, and each connected subgraph is a method call subgraph.

[0111] 3.3 Fitness Function

[0112] The fitness function is used to evaluate the performance of particles in order to select the globally optimal particle. and individual optimal particles Based on our optimization objective, we use the total response time of the applied solution as the fitness value of the particles; particles with smaller fitness values ​​represent better candidate solutions. Since some solutions may correspond to CSGs where one or more CSGs require computational resources exceeding resource limits, we define the fitness function as follows:

[0113]

[0114] During the initialization phase, the feasibility of all particles is guaranteed. Simultaneously, the algorithm consistently retains particles based on a merit-based selection principle, thus preventing situations where two particles simultaneously represent infeasible solutions. In the fitness function, , representing the total latency of the application response. As can be seen from the formula, the application response latency consists of two parts: (1) the time consumed by the method execution. (1) Execution time of each method in the application; (2) Communication latency The latency caused by data transfer between methods is only considered when the caller and the called method are assigned to different CSGs. For example... Figure 3 As shown in (a) the caller With the method of being modulated , (a) They are assigned to the same CSG, therefore their communication latency is not calculated; (b) the caller in the diagram With the method of being modulated , If they are assigned to different CSGs, their communication latency needs to be calculated.

[0115] 3.4 Particle Update Strategy

[0116] The particle update strategy affects the convergence of the algorithm. During particle iteration, its state update is jointly influenced by its current state, the individual's historical best solution, and the population's global best solution. These correspond to the inertia term, individual cognition, and social cognition in the particle update strategy, respectively. For this problem, the particle update formula can be expressed as:

[0117]

[0118] In formula (8), This represents the updated particles. These are particles of the current generation; This indicates a two-point intersection operation; Indicates the mutation operation; and For cognitive factors, It is inertial weight; This represents the individual optimal solution for particle i in generation t; This represents the optimal solution for all particles in generation t.

[0119] Inertial component:

[0120]

[0121] Equation (9) illustrates the mutation operation used in MPPGA for the inertial part. Wherein, random number... Values ​​in the interval when At that time, Perform mutation operation , Particles will be selected randomly. A specific quantile gene is identified, and a position flipping mutation is performed on that gene; when If so, no mutation operation will be performed. For example... Figure 4 As shown, the fractions in the old particles The gene value changes from 0 to 1, thus generating a new particle.

[0122] Individual cognition and social cognition:

[0123]

[0124]

[0125] Formulas (10) and (11) describe the two-point crossover operation used in the individual cognition and social cognition parts of MPPGA, respectively. Among them, random numbers... and Values ​​in the interval .when At that time, Perform cross operation , It will randomly select two quantiles of the particle, for and Perform crossover operations; when In this case, no crossover operation will be performed. Figure 5 This demonstrates the process of particle crossover, where particles A and B are randomly selected. and Two quantiles, placing two particles in the interval [ Gene exchange occurs within the cells, thereby generating new particles C.

[0126] 3.5 Dynamic parameter adjustment

[0127] Parameter settings include inertia weight w and individual cognitive factor. Social cognitive factors The setting of the inertia weight w has a significant impact on the algorithm's search capability and convergence. A larger w... A higher w value corresponds to a stronger global search capability, while a smaller w value reflects a better local search capability. MPPGA introduces dynamic parameter adjustment, which adaptively adjusts the inertia factor w based on the current state of the population and the historical best. During the iteration process, the algorithm selects an appropriate w value by adjusting the formula to improve the algorithm's global search capability or enhance the algorithm's local search efficiency. Formula (12) shows the update method of the inertia factor w.

[0128]

[0129]

[0130] Inertia weight The maximum and minimum values ​​are respectively expressed in formula (12). and express; Used to measure the current particle With historical global optimal particles The degree of difference between them. The definition is shown in formula (13). Wherein, This represents the number of gene positions of a particle, and its value is the number of edges in the method call graph; It is a statistic, when the particle and When the value at the j-th position is different, ,otherwise .

[0131] For individual cognitive factors Social cognitive factors For updates, MPPGA employs a linear increment / decrement strategy. The update method is shown in formulas (14) and (15). Wherein, and They represent The start and end values, and They represent The start and end values, Indicates the current iteration number. This indicates the maximum number of iterations set by the algorithm.

[0132]

[0133]

[0134] 3.6 MPPGA Algorithm Flow

[0135] like Figure 6 As shown, the MPPGA algorithm flow is as follows:

[0136] (1) Initialize the parameters of MPPGA, including population size G and maximum number of iterations. The upper limit of inertia weight and lower limit Meanwhile, an initial population is generated using a random method.

[0137] (2) Calculate the fitness of each particle according to formula (6), select the initial particle fitness as its individual optimal solution, and select the particle with the best fitness as the current global optimal solution.

[0138] (3) Update the particle state according to formula (7) and recalculate the fitness of the updated particle.

[0139] (4) Compare the current fitness of each particle with its historical best solution. If a better solution is found, update the individual's best solution. At the same time, if there is a fitness value that surpasses the existing global best solution, replace it with the new global best solution.

[0140] (5) Check if the algorithm has reached the termination condition. If not, update. If the parameters are equal, return to step (3) to continue iterating; otherwise, the algorithm ends.

[0141] Example 4: Target Program Structure and Code Refactoring

[0142] This embodiment details the process of generating the function-as-a-service proxy and function-as-a-service wrapper in step S3.

[0143] 4.1 Comparison of Program Structures

[0144] The implementation of application functionality can typically be abstracted into method calls within or between objects. Without compute migration technology, applications are usually deployed as a whole on local smart terminals. In this case, interactions between methods are completed through local command calls, resulting in a relatively simple application structure but limited available computing resources, relying solely on the computing power of local nodes. To support fine-grained deployment of applications in serverless edge environments, we designed an application basic deployment unit suitable for serverless edge environments. This basic deployment unit changes the application structure, enabling interactions between methods to be implemented through remote calls, thus better utilizing the dispersed computing resources in serverless edge environments. The generated basic deployment unit will be deployed and scaled independently. Applications deployed based on independent deployment units can exhibit better performance when dealing with high-concurrency scenarios and fluctuating loads. Next, we will introduce the basic deployment unit in detail.

[0145] In classic object-oriented application architectures, their internal structural design is typically limited to a single-machine operating environment, such as... Figure 7 As shown, the methods used in the application Calling methods within the same object or between different objects The process can be abstracted into the following steps: First, locate and obtain The memory address is referenced; secondly, the object is based on this reference. The process involves initiating a method call request, and finally, receiving the return value of the target method and passing it to the caller. A key characteristic of this program structure is that it cannot implement distributed method calls across multiple serverless edge nodes.

[0146] Figure 7 This paper showcases a classic object-oriented application architecture, but its design is limited to a single-machine environment. Method calls are based on memory address references, making cross-node distributed calls impossible. To overcome the limitations of the traditional method call model and enable applications to migrate computations at the method level in serverless edge environments, a program structure is needed to support the deployment of object-oriented methods in a FaaS (Fast as a Service) manner to serverless computing nodes. Based on this, this paper proposes a mechanism from a program structure perspective to support application migration using multiple serverless edge computing servers. It also focuses on the effective utilization of distributed computing resources in serverless edge environments and the handling of dynamic loads in these environments.

[0147] like Figure 8 As shown, the core of the target program structure consists of two components: function-as-a-service wrappers. Function as a Service Proxy Its operation process is as follows:

[0148] (1) right Initiate the call.

[0149] (2) As a proxy, it is responsible for controlling and forwarding invocation requests. Based on configuration file information, it determines the actual execution location of the method—whether to invoke a local method or a specific remote target. If it is remote , It serializes parameters and uses HTTP tools to communicate with the REST API interface, forwarding the call request to the target. .

[0150] (3) The CSGs obtained by the MPPGA algorithm are reconstructed, and each CSG is reconstructed into a corresponding... Since a single CSG typically contains multiple methods that can be called externally, each We need to support external calls to multiple methods, and we plan to use a REST API to implement multiple... Collaborative interaction between them. Therefore, we... Introduced in Component, as The REST API provides external calls and manages the calls to multiple internal methods. It provides a unified external call interface, in Including and Two components. Among them, for The REST API call endpoint is responsible for providing a REST API-style call interface and receiving external call requests; Then responsible for Multiple methods within are bound to When an external request passes through of Address sent to hour, It will parse the parameter information in the request and trigger... Call the relevant methods. Through this design, It can effectively support multi-method management and collaborative interaction in a serverless environment, while improving the system's flexibility and scalability.

[0151] 4.2 Generation of FaaS Proxy

[0152] like Figure 9 As shown, Figure 9 (a) is an example of the application source code. Figure 9 (b) is the stateless method obtained through the FUNOff reconstruction in the previous work. Figure 9 (d) and Figure 9 (e) are the definitions of the ReturnValue class and the Params class, respectively.

[0153] Figure 9 (c) Shows the target code for the FaaS agent, constructed according to the following steps:

[0154] Step 1: Create a function / service proxy whose return value and parameter list are consistent with the original method, such as... Figure 9 (c) Line 1.

[0155] Step 2: Add a service name lookup statement. Line 2 passes the method signature as a parameter to the `getSvc()` method, retrieving the corresponding remote service from the configuration file. The service name. The configuration file records the mapping between method signatures and service names.

[0156] Step 3: Add method call logic statements to invoke the serverless edge environment. or local .like Figure 9 As shown in lines 4 to 12 of (c), the proxy determines whether the call is a local or remote call based on the service name. If it is a local call ( If it is a local call, then a local call is made directly to the method (line 5); if it is a remote call, then the method signature and parameters are encapsulated into a request payload (lines 7-8), and a POST request is constructed and sent to the remote method. (Line 9). Remote The method is identified based on the method signature and the target method is invoked. The execution result is returned. Then, the proxy parses the result returned by the remote call (line 10), obtains the method return value, and updates the relevant data.

[0157] 4.3 Generation of FaaS Wrappers

[0158] Function as a Service Wrapper ( This is a result generated after reconstructing the CSG. It contains several methods that can be called externally, and we have introduced them. Structure to The internal methods are uniformly scheduled and a REST API interface is provided to implement multiple... The collaborative interaction between them. Next, from the perspective of program structure, we will discuss the serverless wrapper. A detailed introduction will be provided.

[0159] Figure 10 (a) showed The target code structure. Line 2 defines... It is a private member variable; lines 3 to 6 are accessed via a call. of The method will The various methods within and of Binding; line 8 indicates invocation of Methods for listening for incoming calls The request.

[0160] The code structure is as follows Figure 10 As shown in (b). Lines 2-3 declare two member variables: and . Defined in the form of "service name:port number", it serves as the externally exposed calling interface; Then used for binding The methods within. Lines 5 through 9 describe... The operating logic is as follows: A listener is started. The REST interface is defined on line 5; when a request arrives (line 6), the request payload is extracted from the request body (line 7), and the request payload is parsed to obtain the required method signature and its parameter list (line 8). Then, the method signature and its corresponding parameters are used as... of The parameters of the method, for The method in the middle is invoked (line 9).

[0161] Example 5: Collaboration between basic deployment units

[0162] This embodiment details how the target program structure introduced through basic deployment units supports the collaborative deployment of object-oriented applications in a serverless edge environment. Based on the proposed sub-call graph generation method, the original application is first split into multiple independent sub-modules. According to the target program structure mentioned above, these split sub-modules are reconstructed and transformed into multiple basic deployment units. Each basic deployment unit is instantiated as an independent FaaS service unit during the actual deployment phase. FaaS service units are independent functional units based on the serverless computing model; they can be deployed on demand and automatically scale during invocation, greatly improving the application's flexibility and resource utilization efficiency. After this reconstructed deployment, the original application functionality is decomposed into multiple FaaS instances, which collaborate with each other to complete the entire application's functionality. These FaaS instances together form a complete call chain, ensuring that the application's business logic can be executed smoothly in a distributed environment. However, since FaaS instances exist independently, it is necessary to ensure that their collaboration and communication are smooth and efficient.

[0163] To achieve this goal, we The introduction of server endpoints ( In FaaS, a service endpoint serves as a unique identifier for each instance. By registering its metadata (including service name, status, health information, and invocation method) with a centralized or decentralized registry during deployment, the global accessibility of FaaS instances is ensured. When a target FaaS instance needs to be invoked, the caller simply obtains the target FaaS instance's metadata from the service registry, parses its exposed API, and then initiates a request. This endpoint-based collaborative deployment mechanism not only enables the refactored FaaS application to maintain functional integrity in a distributed environment but also provides programmatic support for the dynamic construction of the call chain while preserving service autonomy.

[0164] Example 6: Case Study – Face Detection Application

[0165] This embodiment uses a commonly used "face detection" intelligent application as an example to verify the effectiveness of the method of the present invention.

[0166] 6.1 Method Call Graph Construction

[0167] The method described in this paper is used to modify it, and the modification operations include:

[0168] (1) Construct the method call graph of the "face detection" application through static code analysis;

[0169] (2) The MPPGA algorithm is used to divide the method call graph of the "face detection" application;

[0170] (3) Based on the target program structure, the "face detection" application is reconstructed, and the method call graph corresponding to the "face detection" application is reconstructed as follows: And add a FaaS agent to it;

[0171] (4) Deploy the reconstructed application to the prototype platform we built;

[0172] (5) Use JMeter to replay the serviceless call dataset exposed by Azure and observe the changes in the replicas of each service of the “Face Detection” application.

[0173] Figure 11 The method call graph for the "face detection" application is shown. Each node in the graph represents a method of the "face detection" application, and the arrows between nodes indicate the calling relationship between methods. For example, the directed arrow connecting node 1 and node 2 indicates that there is a calling relationship between the methods corresponding to node 1 and node 2. Table 2 shows the computational cost of the method corresponding to each node in the method call graph, expressed as execution time. Table 3 shows the information of each edge in the method call graph. The starting point of the edge represents the node corresponding to the calling method, and the ending point represents the node corresponding to the called method. The weight of the edge is in the format <number, data transfer (KB)>, which represents the number of times the call occurs and the amount of data transferred in one call. For example, <3, 103.2> indicates that the number of calls is 3 and the amount of data transferred in each call is 103.2.

[0174]

[0175] Table 2

[0176]

[0177]

[0178] Table 3

[0179] 6.2 Method Call Graph Partitioning

[0180] By performing static analysis on the "face detection" application, the method call graph of the application was obtained (e.g., Figure 11 As shown in the figure, this is used as input to the MPPGA algorithm. The MPPGA algorithm outputs a reasonable partitioning scheme based on the input method call graph. Figure 12 The diagram illustrates the results after partitioning using the MPPGA algorithm, where nodes are assigned to different sub-call graphs. In the graph, nodes with the same grayscale value indicate that these methods belong to the same sub-call graph. Solid lines between nodes indicate that method calls occur within the same sub-call graph, while dashed lines indicate that method calls occur between different sub-call graphs. For example, nodes 3, 4, 12, and 13 are all the same grayscale value, indicating they belong to the same sub-call graph; the solid line between nodes 13 and 3 indicates that their method calls occur within the same sub-call graph, while the dashed line between nodes 2 and 3 indicates that their calls occur between different sub-call graphs.

[0181] 6.3 Code Refactoring

[0182] like Figure 13 As shown, the method call graph for each method has been restructured and transformed into... (Hereinafter referred to as FW). Specifically, each method call graph extracted from the original application corresponds to an independent... Module: , , and Each A module represents an independent deployment unit that can run independently and collaborate with other modules in a serverless architecture. It contains a method (node ​​0) that provides external calls; It contains two methods that provide external calls (node ​​1 and node 5). It contains three methods that provide external calls (nodes 3, 4, and 12). It contains two methods that provide external calls (node ​​9 and node 17).

[0183] From a macro perspective, the restructured "face detection" application is no longer a single program, but rather comprises multiple... A distributed application consisting of modules that call each other. Different modules communicate and collaborate through clearly defined interfaces to jointly complete the application's business logic. Runtime call relationships between modules, such as Figure 14As shown. At runtime, the establishment of the call chain does not rely on traditional static configuration, but is achieved through a dynamic service discovery and registration mechanism. Whenever a... When a module needs to call another module, it will look up the metadata of the target service through the service registry and initiate a request through the interface.

[0184] 6.4 Runtime Verification

[0185] Figure 15 This demonstrates a real-world example of a "face detection" application. Representative request patterns were selected from Azure's publicly available serverless call dataset, and their request curves were simulated and scaled. The results are as follows: Figure 15 As shown in (a). Subsequently, the obtained request curves were replayed using JMeter, and a variable load was initiated to the "face detection" application deployed on the prototype platform. During the request, each request in the application was monitored. The number of copies was determined to verify the effectiveness of the proposed method. Figure 15 (b) Shows four steps in the request process. Changes in the number of copies.

[0186] By comparison Figure 15 (a) and Figure 15 (b) The following phenomenon can be observed: when the request traffic reaches the first peak (i.e. Figure 15 (a) At 3-5 minutes on the time curve and The number of copies remains unchanged, while The number of copies gradually increases from 1 to 7. The number of replicas was increased from 1 to 5; when the request traffic reached the second peak (i.e. Figure 15 (a) At 8-10 minutes on the time curve, and The number of copies remains unchanged. The number of copies increased from 5 to 6, while The number of replicas increased from one to two. Finally, when request traffic remained at a low level for more than 5 minutes (i.e., Figure 15 (a) After 10 minutes on the time curve), the number of replicas of each FaaS_Wrapper will gradually recover to 1.

[0187] Example 7

[0188] See Figure 16The present invention also provides a fine-grained service decomposition and dynamic deployment system for object-oriented applications, including a processor 1 and a memory 2. The memory 2 stores programs or instructions, and when the programs or instructions are executed by the processor 1, they implement the following steps:

[0189] S1. Obtain the source code of the object-oriented application and construct the method call graph of the application through static code analysis; the method call graph is based on methods as nodes and the calling relationships between methods as edges.

[0190] S2. The method call graph is divided based on a heuristic algorithm to obtain multiple method call subgraphs; wherein, the heuristic algorithm combines particle swarm optimization algorithm and genetic operator to perform iterative search with the goal of minimizing cross-subgraph communication overhead under the condition of satisfying the preset single deployment unit resource constraints, and the communication overhead is determined based on the call frequency and data transmission volume between methods;

[0191] S3. Based on each method call subgraph obtained from the division, reconstruct the source code to generate a function or service wrapper corresponding to each method call subgraph, and generate a function or service proxy for the application;

[0192] The function-as-a-service proxy is used to intercept the original method call request and forward the request to the local method or the corresponding remote function-as-a-service wrapper according to the preset mapping relationship. The function-as-a-service wrapper is an independent deployment unit that encapsulates one or more methods in its corresponding method call subgraph and provides a unified remote call interface for external or other function-as-a-service wrappers to call.

[0193] By embedding complex methodologies and processes into the hardware system, users only need to input the source code of their object-oriented applications, and the system automatically outputs function units suitable for serverless edge deployments. No manual intervention in splitting decisions or code rewriting is required, significantly lowering the technical barrier for migrating enterprise applications to cloud-native architectures. The system's built-in processor is dedicated to executing the MPPGA heuristic algorithm, efficiently handling the partitioning search of large-scale method call graphs. While meeting edge node resource constraints, it quickly approximates the globally optimal splitting solution, ensuring the migrated application has minimal cross-function communication latency. The system seamlessly integrates program analysis, algorithm optimization, and code generation, forming an automated pipeline for transforming monolithic applications into distributed FaaS applications. This avoids the problems of data format incompatibility and process disruptions between multiple independent tools in traditional migration processes, improving migration efficiency and reliability. The system can be deployed in the cloud as a service for enterprise users or integrated into edge computing gateways or developers' integrated development environments. It is suitable for various scenarios requiring the offloading of traditional applications to the edge for processing, such as smart cities, industrial internet, and connected vehicles, demonstrating significant industrial practicality and commercial value.

[0194] Those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the claims, any of the claimed embodiments can be used in any combination.

[0195] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application. In particular, as long as there is no structural conflict, the various technical features mentioned in the embodiments can be combined in any way. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A method for fine-grained service splitting and dynamic deployment of object-oriented applications, characterized in that, For serverless edge computing environments, the following steps are included: S1. Obtain the source code of the object-oriented application and construct the method call graph of the application through static code analysis; the method call graph is based on methods as nodes and the calling relationships between methods as edges. S2. The method call graph is divided based on a heuristic algorithm to obtain multiple method call subgraphs; wherein, the heuristic algorithm combines particle swarm optimization algorithm and genetic operator to perform iterative search with the goal of minimizing cross-subgraph communication overhead under the condition of satisfying the preset single deployment unit resource constraints, and the communication overhead is determined based on the call frequency and data transmission volume between methods; S3. Based on each method call subgraph obtained from the division, reconstruct the source code to generate a function or service wrapper corresponding to each method call subgraph, and generate a function or service proxy for the application; The function-as-a-service proxy is used to intercept the original method call request and forward the request to the local method or the corresponding remote function-as-a-service wrapper according to the preset mapping relationship. The function-as-a-service wrapper is an independent deployment unit that encapsulates one or more methods in its corresponding method call subgraph and provides a unified remote call interface for external or other function-as-a-service wrappers to call.

2. The method of claim 1, wherein, In step S1, the construction of the application's method call graph through static code analysis includes: Starting with the entry method of the application, the statement set of each method is recursively analyzed; When a statement is detected to contain a method call keyword, the method signature of the called method is extracted. Record the current method as the caller of the called method, and find or create the node of the called method in the method node set; Record or update the call relationship between the current method and the called method and its call frequency in the call relationship set.

3. The method for fine-grained service decomposition and dynamic deployment of object-oriented applications according to claim 1, characterized in that, In step S2, the heuristic algorithm uses a discrete encoding method to represent the partitioning scheme. Each particle is encoded to correspond to the connection or disconnection state of each edge in the method call graph. The nodes connected by the edges in the connected state of the particles constitute a method call subgraph.

4. The method for fine-grained service decomposition and dynamic deployment of object-oriented applications according to claim 3, characterized in that, The particle update strategy of the heuristic algorithm includes an inertial component, an individual cognitive component, and a social cognitive component. The inertial component is achieved through a mutation operation controlled by inertial weights, which is used to flip and mutate some gene positions of the particle. The individual cognitive part and the social cognitive part are respectively implemented through two-point cross-operations controlled by the first cognitive factor and the second cognitive factor, which are used to exchange gene fragments with the individual's historical best particle and the global best particle, respectively.

5. The method for fine-grained service decomposition and dynamic deployment in object-oriented applications according to claim 4, characterized in that, The inertia weight is dynamically adjusted based on the degree of difference between the current particle and the global optimal particle, and the degree of difference is quantified according to the difference between the particle's values ​​and those of the global optimal particle at each gene.

6. The method for fine-grained service decomposition and dynamic deployment in object-oriented applications according to claim 1, characterized in that, In step S3, the generation of the function, i.e., the service proxy, includes: Create a proxy method for the original method, wherein the signature of the proxy method is the same as that of the original method; Add service lookup logic to the proxy method to obtain the service identifier of the target function, i.e., the service wrapper, from the configuration file based on the method signature of the called method. Add call routing logic to the proxy method to determine the call type based on the service identifier: if it is a local call, call the local method directly; if it is a remote call, encapsulate the method signature and call parameters into a request payload, send it to the target function (service wrapper) via Hypertext Transfer Protocol, and parse the returned result.

7. The method for fine-grained service decomposition and dynamic deployment in object-oriented applications according to claim 1, characterized in that, In step S3, the generation of the function, i.e., the service wrapper, includes: Create a wrapper class for its corresponding method call subgraph; Create an entry point component in the wrapper class. The entry point component contains an endpoint unit that serves as a remote call endpoint and a binder unit for binding multiple methods within a subgraph. The endpoint unit is used to listen for and receive external Hypertext Transfer Protocol requests, and parse the method signature and parameters in the requests; The binder unit is used to call the corresponding target method in the wrapper class according to the parsed method signature and return the execution result.

8. The method for fine-grained service decomposition and dynamic deployment of object-oriented applications according to claim 1, characterized in that, After deploying the generated multiple function-as-a-service wrappers to a serverless edge environment, the following is also included: Each function / service wrapper instance registers its metadata with the service registry upon startup; the metadata includes at least the service identifier and its corresponding endpoint information. When any function-as-a-service proxy or function-as-a-service wrapper needs to call the target function-as-a-service wrapper, it obtains the endpoint information of the target function-as-a-service wrapper by querying the service registry, and initiates a remote call based on the endpoint information to achieve collaboration between multiple independent deployment units.

9. The method for fine-grained service decomposition and dynamic deployment in object-oriented applications according to claim 1, characterized in that, In step S1, the preset resource constraints for a single deployment unit include an upper limit and / or a lower limit for computing resources, and the computing resources are estimated based on the execution cost of all methods within the subgraph.

10. The method for fine-grained service decomposition and dynamic deployment of object-oriented applications according to claim 1, characterized in that, The fitness function of the heuristic algorithm is constructed based on the total completion time of the application, which is the sum of the total execution time of all methods within the subgraph and the total communication time of cross-subgraph calls; wherein, for partitioning schemes that do not meet the resource constraints, their fitness value is set to a preset maximum penalty value.

Images