Cross-architecture application program migration method and device, equipment and medium

Abstract

The invention relates to the technical field of computers, in particular to a cross-architecture application program migration method and device, equipment and a medium. According to the embodiment of the invention, firstly, the source code is automatically analyzed, the function dependency relationship is obtained, and the specific code segment of the original architecture is accurately identified, so that high cost and low efficiency caused by manual intervention are avoided, and the problem of insufficient automatic migration capability is solved; secondly, a cross-architecture migration mapping library is utilized, an original architecture code segment is automatically converted into a target architecture compatible code according to a rule, third-party library dependence is processed in batches through a preset rule, and the risk of migration failure caused by the library compatibility problem is reduced; finally, the converted codes are reconstructed based on the function dependency relationship, it is ensured that calling logic among the modules is correct, and normal operation of the third-party library under the target architecture is further ensured. Through the series of automatic operations, efficient and stable application migration is achieved, and the success rate and reliability of cross-architecture migration are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a cross-architecture application migration method, device, equipment and medium. BACKGROUND

[0002] In the prior art, there are migration tools and Python migration packages (PythonMigrator) to solve the problem of migrating Python applications from X86 architecture to ARM architecture. Among them, the migration tool focuses on solving the migration from x86 Linux to Yitian Linux, simplifying the migration process by automatically identifying and modifying incompatible parts of the code, providing modification suggestions and test tools; the Python migration package is for Python code version upgrade migration, which can automatically analyze incompatible parts of the old version code, give modification suggestions and support library compatibility check and multiple migration strategies.

[0003] However, the migration tool in these existing solutions cannot completely cover all complex migration scenarios, especially for applications that deeply depend on specific x86 platform features or have special optimization needs, which require manual adjustment and optimization by developers; the Python migration package has limited automation when dealing with large-scale code libraries or complex projects, and may have function lag problems due to rapid iteration of Python versions. In addition, the current migration tools generally have the problems of insufficient ability to automatically identify and convert architecture-specific code, difficulty in analyzing and converting third-party library dependencies, lack of targeted performance bottleneck optimization suggestions, high cost of cross-platform testing, and lack of general standard solutions, resulting in time-consuming and laborious migration work, easy to introduce errors, and difficult to meet the efficient migration needs. SUMMARY

[0004] Therefore, the embodiments of the present application provide a cross-architecture application migration method, device, equipment and medium to solve the problems of insufficient automatic migration capability and difficult third-party library compatibility processing in the prior art.

[0005] In a first aspect, the embodiments of the present application provide a cross-architecture application migration method, which comprises:

[0006] obtaining the source code of an application, obtaining the function dependency relationship in the source code, and identifying a first code segment in the source code suitable for the original architecture;

[0007] converting the first code segment into a second code segment compatible with the target architecture by using the conversion rules in the cross-architecture migration mapping library;

[0008] reconstructing the second code segment based on the function dependency relationship to obtain a reconstructed code segment, and generating an executable file of the target architecture based on the reconstructed code segment.

[0009] deploying the executable file to the target architecture to migrate the application to the target architecture.

[0010] Further, the function dependency relationship in the source code is acquired, including:

[0011] The source code is converted into a syntax tree, and syntax structure and functions are extracted from the syntax tree;

[0012] For each function, function call conditions of the function are analyzed, and call correlation information between the functions is analyzed;

[0013] The function dependency relationship is constructed based on the function call conditions and the call correlation information.

[0014] Further, the second code segment is reconstructed based on the function dependency relationship to obtain a reconstructed code segment, including:

[0015] Based on the function dependency relationship, call correlation conditions between the second code segment and other functions are determined;

[0016] Based on the call correlation conditions and dependency conflicts or logical discontinuities caused by architecture migration, the second code segment is reconstructed to obtain a reconstructed code segment that is adapted to the target architecture and consistent with the function dependency relationship.

[0017] Further, after the executable file is deployed to the target architecture, the method further includes:

[0018] A performance test case is acquired;

[0019] In the target architecture, the executable file is verified by using the performance test case to obtain performance test conditions of the executable file in different scenarios.

[0020] Further, the method further includes:

[0021] According to the performance test conditions, a performance bottleneck point to be optimized in the executable file is determined;

[0022] An optimization strategy corresponding to the performance bottleneck point is acquired, and the executable file is optimized according to the optimization strategy to obtain an optimized executable file;

[0023] The optimized executable file is verified by using the performance test case;

[0024] If the optimized executable file does not have a newly added performance bottleneck point, the optimized executable file is deployed in the target architecture.

[0025] Further, the method further comprises:

[0026] running the optimized executable file in the target architecture to start and run the target application;

[0027] monitoring running data of the application in the target architecture;

[0028] performing real-time analysis and trend prediction based on the running data to determine potential problems;

[0029] triggering an optimization script based on the potential problems, determining optimization items from a performance function, a resource allocation log and a call track of the optimized executable file by using the optimization script, and performing code-level reconstruction or configuration parameter tuning on the optimization items to obtain an adjusted executable file.

[0030] Further, the method further comprises:

[0031] obtaining first performance data of the application running on the original architecture and second performance data of the application running on the target architecture;

[0032] analyzing differences between the first performance data and the second performance data to obtain a performance influence of the cross-architecture migration on the application;

[0033] generating a performance optimization suggestion by using the performance influence.

[0034] In a second aspect, an embodiment of the present application provides a cross-architecture application migration device, and the device comprises:

[0035] an acquisition module configured to acquire source code of an application, acquire function dependency relationships in the source code, and identify a first code segment in the source code that is suitable for an original architecture;

[0036] a conversion module configured to convert the first code segment into a second code segment compatible with a target architecture by using conversion rules in a cross-architecture migration mapping library;

[0037] a reconstruction module configured to reconstruct the second code segment based on the function dependency relationships to obtain a reconstructed code segment, and generate an executable file of the target architecture based on the reconstructed code segment;

[0038] a deployment module configured to deploy the executable file to the target architecture to migrate the application to the target architecture.

[0039] In a third aspect, an embodiment of the present application provides a computer device, comprising a memory and a processor, which are communicatively connected with each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the method in the first aspect or any of the corresponding embodiments.

[0040] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores computer instructions, and the computer instructions are used to make a computer perform the method in the first aspect or any of the corresponding embodiments.

[0041] The embodiment of the present application firstly automatically analyzes the source code, acquires the function dependency relationship, and accurately identifies the original architecture specific code segment, avoids the high cost and low efficiency caused by manual intervention, solves the problem of insufficient automatic migration capability, secondly, uses the cross-architecture migration mapping library to automatically convert the original architecture code segment into target architecture compatible code according to the rules, processes the third-party library dependency in batches through the preset rules, reduces the risk of migration failure caused by library compatibility problems, and finally, reconstructs the converted code based on the function dependency relationship, ensures the correct calling logic between modules, and further guarantees the normal operation of the third-party library under the target architecture. Through a series of automatic operations, efficient and stable application migration is realized, and the success rate and reliability of cross-architecture migration are improved. BRIEF DESCRIPTION OF DRAWINGS

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0043] Figure 1 is a flowchart of a cross-architecture application migration method according to some embodiments of the present application;

[0044] Figure 2 is a flowchart of another cross-architecture application migration method according to some embodiments of the present application;

[0045] Figure 3 is a flowchart of another cross-architecture application migration method according to some embodiments of the present application;

[0046] Figure 4 is a flowchart of another cross-architecture application migration method according to some embodiments of the present application;

[0047] Figure 5is a structural block diagram of a cross-architecture application migration device according to an embodiment of the present application;

[0048] Figure 6 is a hardware structure schematic diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0049] To make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0050] According to the embodiments of the present application, a cross-architecture application migration method, device, equipment and medium are provided. It should be noted that the steps shown in the flowchart of the drawings can be executed in a computer system such as a group of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in a different order.

[0051] In the present embodiment, a cross-architecture application migration method is provided, Figure 1 is a flowchart of a cross-architecture application migration method according to an embodiment of the present application, as Figure 1 shown, the flow includes the following steps:

[0052] Step S101, obtaining the source code of the application, obtaining the function dependency relationship in the source code and identifying the first code segment suitable for the original architecture in the source code.

[0053] In the embodiments of the present application, first, the complete Python application source code is obtained through a version control tool (such as Git) or a local storage path, the source code is deeply parsed by using a source code parser (such as the built-in ast module of Python or a third-party parsing tool), an abstract syntax tree is generated, and syntax information such as function definition and class structure is extracted; then, a dependency relationship analyzer traverses the abstract syntax tree, traces the calling statements between functions and imported modules, and constructs a function dependency graph containing function call levels, parameter passing relationships and data flow directions; at the same time, with the help of an X86 specific code identifier, code segments involving X86 architecture underlying hardware operations, exclusive instruction sets (such as SSE instructions) or X86 libraries in the source code are scanned through preset rule matching (such as regular expression matching X86 assembly instructions) or semantic analysis, and are marked as the first code segment suitable for the original architecture, and finally an analysis report containing the function dependency graph and the position of the first code segment is output.

[0054] Specifically, the function dependency relationship in the source code is acquired, including the following steps A1-A3:

[0055] Step A1, the source code is converted into a syntax tree, and syntax structures and functions are extracted from the syntax tree.

[0056] First, the complete Python source code is parsed into an abstract syntax tree (AST) using the ast module of Python or a third-party parsing tool (such as libCST), and the tree structure represents the syntax structure of the code (such as modules, classes, functions, expressions, etc.) in the form of nodes. Then, the AST nodes are traversed, and syntax structures such as function definitions (including function names, parameter lists, return value types), class methods, global variables, etc. are extracted, while recording the position information (such as line numbers, column numbers) of each function in the source code. For nested functions or anonymous functions (such as lambda expressions), recursively extract their internal structures and establish hierarchical relationships, and finally form structured data containing all functions and their syntax context, providing a basis for subsequent analysis.

[0057] Step A2, for each function, analyze the function call situation and analyze the call association information between functions.

[0058] For each function, the call statements (such as funcA(), module.funcB()) inside the function body are analyzed in depth, and by tracing the Call nodes in the AST, the name of the called function, the parameter passing mode and the return value usage are identified. At the same time, the module path is parsed by combining the import statement to establish the mapping relationship of cross-file function calls. For dynamic calls (such as calling functions through variable names), through static analysis combined with type inference technology, the possible call targets are identified. Finally, the call association information table between functions is constructed, recording the callers (upstream functions) and the callees (downstream functions) of each function, as well as the parameter passing mode and data flow during the call.

[0059] Step A3, based on the function call situation and the call association information, the function dependency relationship is constructed.

[0060] Based on the generated call association information, a function dependency relationship in the form of a directed graph is constructed: each function is abstracted as a node in the graph, and the call relationship between functions is represented as a directed edge (such as function A calling function B, then there is an edge from A to B). Attach attributes to each edge (such as call frequency, parameter type, data dependency strength), and identify indirect dependency relationships through transitive closure analysis (such as A→B→C leading to A indirectly depending on C). For circular dependencies (such as A→B→A), mark a special set of nodes and analyze their impact. Finally, a complete function dependency graph is generated, which is stored in JSON or DOT format, visually displaying the dependency hierarchy and data flow path between functions, providing a structured basis for subsequent code conversion and refactoring.

[0061] In step S102, the first code segment is converted into a second code segment compatible with the target architecture using the conversion rules in the cross-architecture migration mapping library.

[0062] In the embodiments of the present application, for X86 assembly instructions, the mapping library replaces them with equivalent instructions under the ARM architecture (such as converting X86 movdqa to ARM NEON vld1.32); for X86-specific hardware operation interfaces, convert them to API calls of ARM device drivers; for functions that depend on X86 libraries, replace them with interfaces of ARM-compatible libraries. During the conversion process, the rule engine verifies the syntax correctness of the converted code in real time and records the application of each rule, and finally outputs the second code segment that conforms to the syntax specifications and running logic of the ARM architecture.

[0063] Specifically, the second code segment is reconstructed based on the function dependency relationship to obtain a reconstructed code segment, including: determining the call association between the second code segment and other functions based on the function dependency relationship; based on the call association and the dependency conflicts or logical discontinuities caused by architecture migration, the second code segment is reconstructed to obtain a reconstructed code segment that is adapted to the target architecture and consistent with the function dependency relationship.

[0064] When determining the call association between the second code segment and other functions based on the function dependency relationship, first extract the function nodes directly or indirectly associated with the second code segment from the generated function dependency graph, and analyze the call paths, parameter passing modes and data dependency relationships between these functions. For example, identify the upstream functions that call the second code segment (such as through function name matching or call stack analysis), and determine the parameter types (such as pointers, structures) and call conventions (such as call frequency, synchronous / asynchronous mode) passed by them; at the same time, track the downstream functions called by the second code segment, and check the usage of their return values and their impact on subsequent logic.

[0065] Through this analysis, a local dependency subgraph centered on the second code segment is constructed, and the dependency strength of each correlation function (such as the proportion of call times and data throughput) is quantified, providing accurate context information for subsequent reconstruction.

[0066] Based on the call correlation and the dependency conflicts or logical discontinuities caused by architecture migration, when reconstructing the second code segment, first, a repair strategy is developed for the identified conflict points. For example, if the upstream function passes floating-point parameters through registers according to the X86 convention, and ARM requires stack transmission, a parameter conversion layer is inserted around the second code segment to encapsulate the register values into a stack structure; if the downstream function depends on the sorting algorithm of the X86-specific library, replace it with the implementation of the ARM-compatible library and adjust the calling parameters.

[0067] For logical discontinuities (such as the memory alignment assumption specific to X86 that is invalid in the ARM environment), the data structure definition is reconstructed, and explicit alignment instructions (such as __attribute__((aligned(8)))) are added. The function signature remains unchanged during the reconstruction process to ensure that the upstream calling function does not need to be modified; the correctness of the reconstructed code in the ARM environment is verified through unit testing, and finally, a reconstructed code segment is generated that conforms to the characteristics of the target architecture and seamlessly connects with the original function dependency relationship.

[0068] Step S103, reconstructing the second code segment based on the function dependency relationship to obtain a reconstructed code segment, and generating an executable file of the target architecture based on the reconstructed code segment.

[0069] In the embodiments of the present application, based on the generated function dependency graph, the call correlation between the second code segment and other functions is analyzed, including the parameter passing mode of the upstream function, the return value processing of the downstream function, etc., and the dependency conflicts caused by architecture conversion (such as the differences between ARM and X86 in register usage and memory alignment methods) are identified. For conflict points, interface adaptation and logic reconstruction are performed on the second code segment, such as inserting a parameter conversion layer to adapt to the stack calling rules of ARM, adjusting the data structure to match the memory management mechanism of ARM. After reconstruction, the cross-compilation tool chain (such as QEMU+GCC or ARM GNU Toolchain) selected in step 3.2 is used to configure the target architecture parameters (such as -march=armv8-a), and the complete Python source code containing the reconstructed code segment is compiled into an executable file of the ARM architecture, while linking the ARM-compatible runtime library to generate a binary program that can run directly in the ARM environment.

[0070] Step S104, deploying the executable file to the target architecture to migrate the application program to the target architecture.

[0071] In the embodiments of the present application, the ARM executable file generated in step S103 is uploaded to the target ARM environment (such as an ARM server or an embedded device) through a file transfer protocol such as FTP or SCP, and the dependent environment required for running (such as an ARM version of Python interpreter and system library) is installed and configured. After deployment, the application is started with the startup parameters (such as resource limit and environment variable) set, and a smoke test is performed to verify the availability of the core function; at the same time, performance test cases and compatibility test suites are run, and the performance indicators such as CPU occupation and memory usage of the application under ARM architecture are monitored, and the function stability is ensured through regression test, and finally the complete migration of the application from X86 architecture to ARM architecture is completed.

[0072] In the embodiments of the present application, after deploying the executable file to the target architecture, the method further comprises: obtaining performance test cases; and verifying the executable file in the target architecture using the performance test cases to obtain the performance test situation of the executable file under different scenarios.

[0073] When obtaining the performance test cases, the test cases suitable for the function and performance evaluation of the application are first selected from the existing test case library, which covers different business scenarios, different load intensities and boundary conditions, and at the same time, the expected performance indicators of each test case are specified, such as upper limit of response time, throughput requirement, resource occupation threshold, etc. After deploying the executable file to the actual ARM environment in the target architecture, the performance test cases are run using an automated test tool (such as JMeter for web applications or Gatling for distributed systems), and in the execution process, system resource data (including CPU usage, memory occupation, disk I / O, network bandwidth, etc.) and business performance data of the application (such as request response time, transaction processing success rate, data processing capacity, etc.) are collected in real time.

[0074] By dynamically adjusting the test parameters, simulating normal business traffic, high concurrency access, large data processing and other diversified scenarios, the data collected under each scenario is statistically analyzed and compared with the expected performance indicators, and finally a detailed performance test report is generated, which comprehensively presents the performance test situation of the executable file under different scenarios and provides data basis for subsequent optimization.

[0075] The embodiment of the present application first automatically parses the source code, obtains function dependencies and accurately identifies specific code segments of the original architecture, avoiding the high cost and low efficiency caused by manual intervention and solving the problem of insufficient automated migration capabilities; secondly, using the cross-architecture migration mapping library, the original architecture code segments are automatically converted into target architecture compatible codes according to the rules, and third-party library dependencies are processed in batches through preset rules to reduce the risk of migration failure due to library compatibility issues; finally, the converted code is reconstructed based on the function dependencies to ensure that the calling logic between modules is correct, further ensuring the normal operation of the third-party library under the target architecture. Through this series of automated operations, efficient and stable application migration is achieved, and the success rate and reliability of cross-architecture migration are improved.

[0076] Figure 2 FIG. 1 is a flow chart of a cross-architecture application migration method according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0077] Step S201: determining the performance bottleneck to be optimized in the executable file according to the performance test result.

[0078] In an embodiment of the present application, by analyzing key indicators in the performance test report (such as high CPU usage functions, long-running threads, and frequent memory allocation operations), combined with system call tracking data (such as hot spot functions recorded by perf) and application logs, code segments in the executable file whose response time exceeds the threshold and resource consumption is abnormal are located, such as sorting functions with high algorithm complexity, resource management modules with memory leaks, and thread blocking points caused by lock contention, to form a list of performance bottlenecks to be optimized.

[0079] Step S202 : obtaining an optimization strategy corresponding to the performance bottleneck point, and optimizing the executable file according to the optimization strategy to obtain an optimized executable file.

[0080] In the embodiments of the present application, for each performance bottleneck, a corresponding solution is matched from the optimization strategy library: for computationally intensive functions, vectorized computing (such as using the ARMNEON instruction set) or algorithm replacement (such as changing bubble sort to quick sort) is adopted; for memory issues, data structure alignment is optimized or resource pooling management is implemented; for IO blocking, asynchronous IO or batch processing mechanisms are introduced. Optimization is implemented by modifying the source code, adjusting compilation parameters (such as enabling -O3 optimization), or updating configuration files (such as adjusting JVM heap parameters), and recompiling to generate the optimized executable file.

[0081] Step S203: Verify the optimized executable file using performance test cases;

[0082] In the embodiments of the present application, the performance test cases used in step S201 are executed again to compare the changes in key indicators before and after optimization: whether the CPU usage is reduced, the response time is shortened, the throughput is improved, and whether the resource consumption trend tends to be stable. The functional integrity is verified through an automated test framework (such as JUnit, pytest) to ensure that no new functional defects are introduced by the optimization, and a verification report containing detailed performance comparison data is generated.

[0083] In step S204, if the optimized executable file does not have new performance bottleneck points, the optimized executable file is deployed in the target architecture.

[0084] In the embodiments of the present application, if the verification report shows that all performance indicators meet the expectations and no new bottleneck points are found, the optimized executable file is deployed to the target architecture in the production environment. The deployment process includes configuring the running environment (such as setting environment variables, mounting storage volumes), registering service monitoring (such as accessing the Prometheus alarm system), and gradually switching traffic through a gray release strategy to ensure smooth transition to the optimized version, and finally completing the performance optimization loop.

[0085] As an example, after performing performance testing on an executable file running on an ARM architecture, it is found through analysis of the test data that in a high concurrency scenario, the response time of the file read-write module is as high as 500ms, the CPU occupancy rate is maintained at more than 90% for a long time, and the memory leak detection tool shows that the module has a resource unreleased situation, thus determining that the file read-write module is a performance bottleneck point to be optimized. To address the performance bottleneck of the file read-write module, the corresponding optimization strategy is obtained, the synchronous read-write operation is changed to asynchronous I / O operation to reduce thread blocking, the memory pool technology is introduced to avoid frequent memory allocation and release, and the file cache mechanism is optimized; the source code is modified according to these strategies, and the optimized executable file is obtained after recompilation. The same performance test cases as before are run again, and the performance indicators of the optimized executable file in a high concurrency scenario are monitored, and the response time, CPU occupancy rate and memory usage of the file read-write module are recorded. Through comparative analysis, it is found that the response time of the file read-write module of the optimized executable file in a high concurrency scenario is reduced to 100ms, the CPU occupancy rate is stabilized at about 40%, and there is no memory leak problem, and there is no new performance bottleneck point, and then it is deployed to the production environment of the target architecture to ensure efficient and stable operation of the application program.

[0086] In addition, the embodiment of the application can also extract multi-dimensional indexes such as CPU usage, memory allocation rate, IO waiting time and the like from historical performance data to construct a time series data set; use an LSTM network to train a prediction model, continuously learn the system operation mode through a sliding window mechanism, and capture the change trend of the performance indexes; set risk indexes such as memory leakage growth rate and response time fluctuation threshold, and automatically trigger an alarm when the predicted value exceeds the threshold; after the alarm is triggered, the system calls the corresponding scheme (such as memory pooling and asynchronous IO modification) in the optimization strategy library, automatically generates a code patch and injects it into the module to be optimized; then, the optimization effect is verified through automated testing, and if the expected result is met, the system enters a gray release stage, and the performance of the new and old versions is compared through A / B testing; finally, the optimal scheme is integrated into the continuous integration / deployment process to form a closed-loop system from risk identification to optimization landing.

[0087] The embodiment of the application can accurately locate the performance bottleneck point in the executable file based on performance test data, avoid blind optimization, and improve optimization efficiency; secondly, corresponding optimization strategies are matched for different bottleneck points, and the executable file is optimized from multiple dimensions such as algorithm improvement and parameter adjustment, solving the problem of insufficient targeting of performance optimization in the traditional scheme; thirdly, the optimized executable file is verified by using the original performance test case, ensuring that the optimization effect can be quantitatively evaluated and ensuring the effectiveness of the optimization strategy; finally, after verification confirms that there is no new performance bottleneck point, the deployment is performed, avoiding the use of a version with hidden dangers, and reducing the risk of system instability caused by performance problems. The whole-process closed-loop management is realized, and the running performance and stability of the application program in the target architecture are significantly improved.

[0088] Figure 3 is a flowchart of a cross-architecture application program migration method according to the embodiment of the application, as shown in Figure 3 The flowchart includes the following steps:

[0089] Step S301, running the optimized executable file in the target architecture to start and run the target application program.

[0090] In the embodiment of the application, the optimized executable file is deployed into the target ARM architecture environment, the dependent components (such as ARM version Python interpreter and necessary system library) and environment variables required for running are configured, the executable file is triggered to run through a start script (such as systemd service configuration or Docker container), the application program service process is initialized, and it is ensured that the application program service process is normally started and provides services externally in the target architecture, laying a foundation for subsequent performance monitoring.

[0091] Step S302, monitoring the running data of the application program in the target architecture.

[0092] In the embodiments of the present application, during the running of the application, the monitoring tools such as Prometheus and Grafana are integrated to collect real-time data of system-level indicators (CPU usage, memory occupation, disk I / O rate, network bandwidth) and application-level indicators (request response time, throughput, error rate, thread pool state).

[0093] By burying points in key business processes (such as HTTP request processing entry, database query interface), combined with system call tracking (such as strace, perf), function call chain, resource allocation track and other fine-grained running data are obtained, and the data is stored in a time series database to form a complete running state data set.

[0094] Step S303, real-time analysis and trend prediction based on running data to determine potential problems.

[0095] In the embodiments of the present application, based on the collected running data, time series analysis algorithms (such as moving average, exponential smoothing) and anomaly detection models (such as isolation forest, ARIMA) are used to identify the fluctuation trend and abnormal pattern of performance indicators. For example, by comparing the historical baseline, it is found that the CPU usage is continuously increasing, the memory leakage rate is above the threshold, the response time distribution shows a long tail phenomenon, and other potential problems.

[0096] At the same time, combined with the knowledge of business scenarios (such as peak traffic characteristics), correlation analysis is performed to locate the root cause of the problem (such as high algorithm complexity, intense lock competition, and untimely resource release), and a potential problem list containing problem description, impact range, and severity level is generated.

[0097] Step S304, triggering optimization scripts based on potential problems, using optimization scripts to determine optimization items from performance functions of optimized executable files, resource allocation logs and call traces, and performing code-level reconstruction or configuration parameter tuning on the optimization items to obtain adjusted executable files.

[0098] In the embodiments of the present application, according to the potential problem list, predefined optimization scripts are automatically triggered. The script first extracts optimization items from performance hot functions (such as high CPU occupied calculation functions), resource allocation logs (such as memory allocation points triggering GC frequently) and call traces (such as database slow query paths), and then implements optimization according to specific problems: for algorithm efficiency problems, replace with an implementation with lower time complexity; for memory leakage, fix resource release vulnerability; for unreasonable configuration parameters, dynamically adjust parameters such as JVM heap size and thread pool core number. After optimization, the adjusted executable files are recompiled and generated, and regression testing is automatically triggered to verify the functionality, ensuring that the optimization effect is achieved while avoiding the introduction of new defects.

[0099] As an example, the optimized executable file is deployed to a Kubernetes cluster of the target ARM architecture, the container resource limit (such as 2-core CPU and 4GB memory) is configured through a HelmChart, and the application is started to ensure that it runs normally in the target architecture.

[0100] The container CPU usage, memory usage, request response time and other indicators are collected through Prometheus, the application logs are collected through ELKStack, the distributed call link is tracked through Jaeger, and the application running state is monitored in all directions. Based on the real-time performance indicators calculated based on the Prometheus data, it is found that the memory usage increases by 5% per hour and has no downward trend, and the ARIMA model predicts that OOM will be triggered after 48 hours; at the same time, the average time consumption of database query call track increases from 20ms to 80ms, and it is determined that there are two potential problems of memory leakage and database performance degradation. The optimization script is automatically triggered to analyze the GC log, and the object holding time of the cache class is located to the problem, and the code of the class is reconstructed to add a weak reference mechanism; at the same time, the database connection pool configuration parameters (such as the maximum number of connections from 10 to 20) are adjusted, and the adjusted executable file is recompiled to ensure that the application runs stably on the ARM architecture.

[0101] The application embodiment can quickly capture the changes of key indicators such as CPU usage, memory occupation and response time by monitoring the application running data in real time, and avoid the deterioration of performance problems; based on data analysis and trend prediction, potential risks can be identified in advance, and the traditional passive problem solving mode can be changed; after triggering the optimization script, the optimization items are accurately located from the performance function, resource allocation log and call track, and code-level reconstruction or parameter tuning is implemented for algorithm redundancy, memory leakage and unreasonable parameter configuration, which is more efficient and accurate than manual troubleshooting; finally, the adjusted executable file is generated to ensure that the application program continuously maintains a good running state, reduces the operation and maintenance cost, and enhances the system reliability and user experience.

[0102] Figure 4 is a flowchart of a cross-architecture application migration method according to an embodiment of the application, as shown in Figure 4 The flowchart includes the following steps:

[0103] In step S401, first performance data of an application running on an original architecture and second performance data of the application running on a target architecture are obtained.

[0104] In the embodiments of the present application, the same version of application program is respectively deployed on the original X86 architecture and the target ARM architecture, and a benchmark test suite (such as SPECCPU, ApacheJMeter) consistent with each other is run to synchronously collect performance data. In the X86 environment, the perf tool is used to record underlying indexes such as CPU cycles, cache hit rate, branch prediction, and the application log is used to collect business indexes such as request response time and throughput to form first performance data.

[0105] In the ARM environment, the same test case and monitoring tool (such as ARMDS-5 or GDB) are used to obtain corresponding indexes, and special attention is paid to ARM architecture characteristic related data such as NEON instruction utilization rate and memory bandwidth to generate second performance data. The consistency of the test environment (such as load intensity and data volume) is ensured, and the average value is obtained through multiple tests to eliminate random errors, and finally the comparable dual-architecture performance data set is obtained.

[0106] Step S402, analyze the difference between the first performance data and the second performance data to obtain the performance influence of cross-framework migration on the application program.

[0107] In the embodiments of the present application, the first performance data and the second performance data are aligned and analyzed. First, the absolute value difference of the key indexes (such as the average response time of 50 ms on X86 and 80 ms on ARM) is compared, and then the relative change rate (such as an increase of 60% in ARM response time) is calculated.

[0108] For indexes with significant differences (such as ARM CPU usage rate being 20% higher), the underlying architecture reasons are analyzed in depth. It is checked whether there is X86 exclusive optimization (such as SSE instruction not converted to NEON) causing calculation efficiency to decrease, or memory access mode not matching the ARM cache architecture. At the same time, combined with function call chain analysis, the code path with the most serious performance degradation (such as the database query module consuming time increasing by 3 times on ARM) is located, and finally a detailed report containing performance difference details, root cause analysis and influence range is generated.

[0109] Step S403, generate performance optimization suggestions by using the performance influence.

[0110] In the embodiments of the present application, based on the performance influence analysis result, combined with the advantageous characteristics of the target ARM architecture (such as NEON vector processing and large cache design), optimization suggestions are generated from multiple dimensions:

[0111] For calculation-intensive functions, it is suggested to use NEONintrinsics to rewrite vector operation logic (such as matrix multiplication) to improve parallel processing capability;

[0112] For ARM architecture characteristics, change the recursive algorithm to an iterative implementation to reduce stack space usage, or replace it with an algorithm more suitable for ARM cache characteristics (such as block matrix calculation);

[0113] Adjust Linux kernel parameters (such as vm.dirty_ratio) to optimize memory management, and configure CPU governor to performance mode to improve peak performance;

[0114] Enable ARM-specific compilation options such as -march=armv8-a, and reduce function call overhead through link-time optimization (LTO);

[0115] For code that relies on X86-specific functions (such as memory alignment assumptions), add ARM-compatible conditional compilation logic.

[0116] Each suggestion is marked with expected performance improvement potential (such as "expected response time reduction of 20%") and implementation cost (such as "low / medium / high"), forming a prioritized optimization plan that ensures measures are consistent with ARM architecture characteristics and engineering feasibility.

[0117] As an example, deploy the application on an X86 server, and use perf and top tools to record CPU usage, memory usage, interface response time, and other data to obtain the first performance data; at the same time, deploy the same version of the application on an ARM architecture Raspberry Pi device, and use ARM DS-5 and custom scripts to collect the same indicators to obtain the second performance data. In step S402, it is found that the average response time of the application in the X86 environment is 100ms, and in the ARM environment it increases to 180ms, and the CPU usage increases from 30% to 65%. After analysis, it is determined that the SSE instructions used in the X86 architecture are not effectively converted in the ARM architecture, and some data structures are not adapted to the ARM cache mechanism, thus explicitly indicating that cross-framework migration has a significant negative impact on application performance. In step S403, according to the above performance impact, generate performance optimization suggestions: rewrite the calculation logic involving SSE instructions using ARM NEON instruction set, optimize the memory alignment method of the data structure to adapt to the ARM cache line size, and adjust the application thread pool parameters to fully utilize the ARM multi-core characteristics and reduce CPU resource competition.

[0118] The embodiment of the application obtains performance data under the original architecture and the target architecture, ensures that the analysis is based on a real running scenario, and avoids subjective speculation. Secondly, by systematically comparing and analyzing the differences between the two, the changes in key indicators such as CPU usage, response time, and memory occupation during the migration process can be clearly presented, and the root cause of performance degradation can be deeply mined. Finally, based on the quantified performance impact, optimization suggestions are generated, and targeted strategies are proposed from multiple dimensions such as instruction set adaptation, algorithm improvement, and parameter tuning, changing the traditional experience-based optimization mode. This scheme makes performance optimization targeted, helps developers efficiently solve performance problems caused by architecture differences, improves the running efficiency and stability of the application program under the target architecture, and reduces optimization cost and time loss.

[0119] In the embodiment, a cross-architecture application migration device is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and details are not repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware is also possible and is contemplated.

[0120] The embodiment provides a cross-architecture application migration device, as shown in Figure 5 The device includes:

[0121] The obtaining module 501 is configured to obtain the source code of the application program, obtain the function dependency relationship in the source code, and identify the first code segment in the source code that is suitable for the original architecture.

[0122] The conversion module 502 is configured to convert the first code segment into a second code segment compatible with the target architecture by using a conversion rule in a cross-architecture migration mapping library.

[0123] The reconstruction module 503 is configured to reconstruct the second code segment based on the function dependency relationship to obtain a reconstructed code segment, and generate an executable file of the target architecture based on the reconstructed code segment.

[0124] The deployment module 504 is configured to deploy the executable file to the target architecture to migrate the application program to the target architecture.

[0125] In the embodiment of the application, the obtaining module 501 is configured to convert the source code into a syntax tree, extract syntax structures and functions from the syntax tree, analyze function call conditions of each function, and analyze calling association information between functions, and construct a function dependency relationship based on the function call conditions and the calling association information.

[0126] In the embodiment of the present application, the reconstruction module 503 is configured to determine the call association between the second code segment and other functions based on the function dependency relationship; and reconstruct the second code segment based on the call association, the dependency conflict or the logical discontinuity caused by the architecture migration, to obtain a reconstructed code segment that is adapted to the target architecture and consistent with the function dependency relationship.

[0127] In the embodiment of the present application, the device further comprises a test module configured to obtain a performance test case; and verify the executable file in the target architecture by using the performance test case, to obtain the performance test situation of the executable file in different scenarios.

[0128] In the embodiment of the present application, the device further comprises an optimization module configured to determine a performance bottleneck point to be optimized in the executable file according to the performance test situation; obtain an optimization strategy corresponding to the performance bottleneck point, and optimize the executable file according to the optimization strategy, to obtain an optimized executable file; verify the optimized executable file by using the performance test case; and if the optimized executable file does not have a newly added performance bottleneck point, deploy the optimized executable file in the target architecture.

[0129] In the embodiment of the present application, the device further comprises a monitoring module configured to run the optimized executable file in the target architecture, to start and run the target application program; monitor the running data of the application program in the target architecture; perform real-time analysis and trend prediction based on the running data, to determine potential problems; trigger an optimization script based on the potential problems, determine optimization items from the performance function, resource allocation log and call track of the optimized executable file by using the optimization script, and perform code-level reconstruction or configuration parameter tuning on the optimization items, to obtain an adjusted executable file.

[0130] In the embodiment of the present application, the device further comprises an analysis module configured to obtain first performance data of the application program running on the original architecture, and second performance data of the application program running on the target architecture; analyze the difference between the first performance data and the second performance data, to obtain the performance influence situation of the cross-framework migration on the application program; and generate a performance optimization suggestion by using the performance influence situation.

[0131] Please refer to Figure 6 , Figure 6 is a structural schematic diagram of a computer device provided in an optional embodiment of the present application, as shown in Figure 6As shown, the computer device includes one or more processors 10, memory 20, and interfaces 30 for external devices such as a keyboard and a mouse and peripheral devices such as disk devices or other storage devices. One or more busses 10 can be used to implement the interface between the various internal and external components and can be implemented using any one or more of a variety of bus technologies including a System bus, PCI, SCSI, AGP, Super- I / O bus, etc. Furthermore, various buses can be used in front side buses, back side buses, and memory buses (including extension buses, to name a few). Similarly, various processors 10 can be used including microprocessors, i7, i5, i3, Pentium®, Xeon®, Phenom®, Athlon®, Duron®, PowerPC®, 68000, 6502, 65802, 65802, 68000, 68010, 68020, 68030, 68040, 68060, ARM, MIPS, AMD, Intel, IBM, Sun, DEC, Hewlett-Packard, Compaq, Silicon Graphics, etc. Moreover, various operating systems can be used including Windows®, Linux, UNIX, Solaris, VxWorks, etc. Furthermore, various application programs can be used including web browsers, media players, etc.

[0132] The processor 10 can be a central processing unit, a network processor, or a combination thereof. The processor 10 can further include a hardware chip. The hardware chip can be an application specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device can be a complex programmable logic device, a field programmable logic gate array, a generic array logic, or any combination thereof.

[0133] The memory 20 stores instructions that can be executed by the at least one processor 10, to cause the at least one processor 10 to perform the methods described in the above embodiments.

[0134] The memory 20 can include a program storage area and a data storage area. The program storage area can store an operating system, application programs, etc. The data storage area can store data created by the at least one application programs, etc. Additionally, the memory 20 can include a high-speed random access memory and can also include a non-volatile memory, such as at least one disk storage device, flash memory, or other non-volatile solid-state storage device. In some alternative embodiments, the memory 20 can optionally include memory that is remote from the processor 10, such as the memory / storage devices illustrated in the cloud 100. Examples of such networks include, without limitation, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0135] The memory 20 can include a volatile memory, such as a random access memory, and can also include a non-volatile memory, such as at least one disk storage device, flash memory, or other non-volatile solid-state storage device. The memory 20 can further include a combination of the above-mentioned types of storage.

[0136] The computer device further includes a communication interface 30 for communicating with other devices and networks.

[0137] The embodiments of the present application further provide a computer readable storage medium, and the method according to the embodiments of the present application can be implemented in hardware, firmware, or recorded in a storage medium, or be implemented as computer codes stored in a remote storage medium or a non-transitory machine readable storage medium and downloaded through a network and stored in a local storage medium, so that the method described herein can be processed by such software on a storage medium using a general purpose computer, a special purpose processor, or programmable or special hardware. The storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid state disk, etc. Further, the storage medium can also include a combination of the above-mentioned types of memories. It can be understood that the computer, the processor, the microprocessor controller, or the programmable hardware includes a storage component that can store or receive software or computer codes, when the software or computer codes are accessed and executed by the computer, the processor, or the hardware, the method shown in the above embodiments is implemented.

[0138] Although the embodiments of the present application are described in conjunction with the drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application, and such modifications and changes fall within the scope defined by the appended claims.

Claims

1. A cross-architecture application migration method, characterized in that: The method comprises: Obtaining source code of an application, obtaining function dependencies in the source code, and identifying a first code segment in the source code that is applicable to an original architecture; Using conversion rules in a cross-architecture migration mapping library, convert the first code segment into a second code segment that is compatible with the target architecture; Reconstructing the second code segment based on the functional dependency to obtain a reconstructed code segment, and generating an executable file of the target architecture based on the reconstructed code segment; Deploy the executable file to the target architecture to migrate the application to the target architecture.

2. The method according to claim 1, characterized in that The obtaining of the function dependency relationship in the source code includes: Converting the source code into a syntax tree, and extracting syntax structures and functions from the syntax tree; For each function, analyzing the function call status of the function and analyzing the call association information between the functions; The function dependency relationship is constructed based on the function calling situation and the call association information.

3. The method according to claim 1, characterized in that The reconstructing the second code segment based on the functional dependency to obtain a reconstructed code segment includes: Determine, based on the function dependency, a call association between the second code segment and other functions; Based on the call association situation and the dependency conflict or logic fault caused by the architecture migration, the second code segment is reconstructed to obtain a reconstructed code segment that is adapted to the target architecture and consistent with the function dependency relationship.

4. The method according to claim 1, wherein After deploying the executable file to the target architecture, the method further includes: Get performance test cases; In the target architecture, the executable file is verified using the performance test case to obtain performance test results of the executable file in different scenarios.

5. The method according to claim 4, characterized in that The method further comprises: Determine the performance bottlenecks to be optimized in the executable file based on the performance test results; Obtaining an optimization strategy corresponding to the performance bottleneck point, and optimizing the executable file according to the optimization strategy to obtain an optimized executable file; Verifying the optimized executable file using the performance test case; If the optimized executable file does not have any new performance bottlenecks, the optimized executable file is deployed in the target architecture.

6. The method according to claim 5, characterized in that The method further comprises: Running the optimized executable file in the target architecture to start and run the target application; Monitoring the running data of the application in the target architecture; Perform real-time analysis and trend prediction based on the operating data to identify potential problems; Based on the potential problem, an optimization script is triggered, and the optimization script is used to determine the optimization items from the performance function, resource allocation log and call trace of the optimized executable file, and the optimization items are reconstructed at the code level or the configuration parameters are tuned to obtain the adjusted executable file.

7. The method according to claim 1, characterized in that The method further comprises: Obtaining first performance data of the application running on the original architecture and second performance data of the application running on the target architecture; Analyze the difference between the first performance data and the second performance data to obtain the performance impact of the cross-framework migration on the application; Generate performance optimization recommendations based on the performance impact.

8. A cross-architecture application migration device, characterized in that: The device comprises: an acquisition module, configured to acquire source code of an application, obtain function dependencies in the source code, and identify a first code segment in the source code that is applicable to an original architecture; a conversion module, configured to convert the first code segment into a second code segment compatible with the target architecture by using conversion rules in a cross-architecture migration mapping library; a reconstruction module, configured to reconstruct the second code segment based on the functional dependency to obtain a reconstructed code segment, and generate an executable file of the target architecture based on the reconstructed code segment; A deployment module is used to deploy the executable file to the target architecture to migrate the application to the target architecture.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images