Cross-platform Serverless function execution system and method

Abstract

The invention provides a cross-platform Serverless function execution system and a cross-platform Serverless function execution method. The cross-platform Serverless function execution system and the cross-platform Serverless function execution method are used for solving the problem of migration and execution of Serverless functions among different cloud platforms. The system comprises a dynamic adapter module, a configuration parsing engine, a service discovery mechanism and an execution environment initializer. And the dynamic adapter module converts API calling and service interaction between different cloud platforms in real time during function operation. And the configuration analysis engine analyzes the declarative configuration file describing the mapping relationship between the function and the cloud service. The service discovery mechanism locates and binds equivalent cloud services among different platforms. The execution environment initializer configures a runtime environment of the function according to the target platform. According to the method, cross-platform function execution is realized through the steps of analyzing a configuration file, initializing an adapter, converting API calling in real time and the like. The method has the advantages that cross-platform compatibility of the Serverless function is achieved, source codes do not need to be modified, the implementation cost and complexity of a multi-cloud strategy are greatly reduced, the development efficiency is improved, and a way is laid for wide application of the Serverless technology.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a cross-platform function execution system and method in a Serverless computing architecture. The present invention aims to solve the compatibility and portability issues of Serverless functions between different cloud service provider platforms, and provide technical support for the development and deployment of Serverless applications in a multi-cloud environment. Background Art

[0002] As an emerging model of cloud computing, serverless computing has developed rapidly in recent years, providing developers with a more efficient and economical way to deploy applications. In the serverless architecture, developers only need to focus on writing business logic without having to manage the underlying infrastructure, which greatly simplifies the application development and operation and maintenance process. Serverless technology has important applications in microservices, the Internet of Things, data processing and other fields. Its on-demand expansion and pay-per-use features make it an ideal choice for building modern cloud-native applications.

[0003] Currently, major cloud service providers such as Amazon AWS, Microsoft Azure, and Google Cloud Platform all provide their own Serverless platforms, such as AWS Lambda, Azure Functions, and Google Cloud Functions. These platforms allow developers to upload function codes and automatically execute them based on trigger conditions. However, each platform has its own specific API, service integration method, and runtime environment, which makes it difficult for Serverless functions developed for one platform to run directly on another platform.

[0004] However, this platform-specific development approach has obvious shortcomings in practical applications. First, it creates a serious vendor lock-in problem, making it difficult for enterprises to implement a multi-cloud strategy or migrate applications between different cloud platforms. Second, developers need to learn and adapt to the characteristics and APIs of different platforms, which increases learning costs and development complexity. In addition, it becomes extremely difficult to maintain and manage cross-platform Serverless applications in a multi-cloud environment, affecting the maintainability and scalability of the system.

[0005] To solve the above problems, the industry has proposed some standardization efforts, such as the CloudEvents specification, which aims to unify the event data format. At the same time, some open source projects such as Knative and OpenFaaS attempt to provide a cross-platform Serverless framework. Although these methods have improved cross-platform compatibility to a certain extent, they still have limitations. They either require specific infrastructure support or cannot fully utilize the unique services and advantages of each cloud platform, making it difficult to meet the flexibility and performance needs of enterprises.

[0006] Therefore, developing a technical solution that can seamlessly execute Serverless functions between different cloud platforms while making full use of the characteristics of each platform has become a research hotspot in this field. This solution not only needs to solve the problem of technical compatibility, but also needs to consider multiple aspects such as performance optimization, development convenience, and operation and maintenance efficiency to meet the diverse needs of enterprises for Serverless applications in the modern cloud computing environment. Summary of the invention

[0007] The purpose of the present invention is to solve the compatibility issues faced by existing Serverless functions when migrating and executing between different cloud platforms. Specifically, the present invention aims to provide a system and method that can implement cross-platform Serverless function execution without modifying the original function code. In addition, the present invention also aims to reduce the implementation cost of the multi-cloud strategy, improve development efficiency, and make full use of the unique services and advantages of each cloud platform.

[0008] To achieve the above objectives, the present invention provides a cross-platform Serverless function execution system, characterized by: including a dynamic adapter module, a configuration parsing engine, a service discovery mechanism, and an execution environment initializer. The system can dynamically convert API calls and service interactions between different cloud platforms when the function is running, and realize the cross-platform compatibility of Serverless functions. In some embodiments, the present invention also provides a corresponding cross-platform Serverless function execution method for realizing the functions of the above system.

[0009] Specifically, the dynamic adapter module includes multiple platform-specific adapters, each of which contains the API mapping rules and service call conversion logic of the corresponding cloud platform. The module also includes a dynamic proxy component that intercepts the API calls of the original function and converts them into equivalent calls of the target platform in real time.

[0010] Furthermore, the configuration parsing engine is used to parse the declarative configuration file that describes the mapping relationship between functions and cloud services. The engine includes a configuration validator and an execution plan generator, which are used to check the syntax correctness and version compatibility of the configuration file and dynamically generate the execution plan of the function according to the configuration and target platform.

[0011] Preferably, the service discovery mechanism includes a service registry and a dynamic service binder. The service registry is used to store the mapping relationship between equivalent services on different platforms, while the dynamic service binder is responsible for connecting to the required cloud services in real time during the function execution process.

[0012] Optionally, the system also includes a context converter and a unified asynchronous operation interface. The context converter is used to handle the execution context differences between different platforms, including environment variables, event structures, etc. The unified asynchronous operation interface is used to encapsulate the asynchronous operation models of different platforms to ensure the consistency of function behavior.

[0013] In one embodiment, the system further includes an error handling module and a performance optimization component. The error handling module is used to unify the error types of different platforms and implement a configurable retry strategy, while the performance optimization component includes a cache mechanism based on an LRU algorithm for storing frequently used conversion results.

[0014] In certain embodiments, the method of the present invention includes receiving a deployment request containing function code and a declarative configuration file, parsing the configuration file to determine the target platform and required cloud services, initializing the corresponding dynamic adapter module, converting API calls and service interactions in real time during function execution, and finally processing the execution results and returning a response in a unified format.

[0015] In addition, the present invention can also use a context converter to adjust the execution environment before the function is executed to adapt to the characteristics of the target platform, and use a unified asynchronous operation interface to encapsulate platform-specific asynchronous calls.

[0016] In other embodiments, the method further includes using a service discovery mechanism to dynamically locate and bind required cloud services during execution, and using an error handling module to uniformly handle abnormal situations on different platforms and perform retries according to predefined strategies.

[0017] In a preferred embodiment, the system defines the mapping relationship between functions and cloud services through configuration files, uses dynamic adapters to convert API calls in real time at runtime, and uses service discovery mechanisms to dynamically bind cloud services, thereby achieving completely transparent cross-platform function execution.

[0018] In another preferred embodiment, the method supports multi-cloud deployment strategies, allowing the same function to be dynamically switched between different cloud platforms according to the configuration, thereby achieving load balancing and failover.

[0019] By adopting the above scheme, the present invention has the following beneficial effects: (1) It achieves cross-platform compatibility of Serverless functions without modifying the original function code, greatly reducing the implementation cost and complexity of the multi-cloud strategy; (2) Improved development efficiency: developers only need to write code once and then deploy and execute it on multiple cloud platforms; (3) It makes full use of the unique services and advantages of each cloud platform and flexibly selects and maps services through a configuration-driven approach; (4) It provides a unified error handling and asynchronous operation interface, simplifying the development and maintenance of cross-platform applications; (5) The portability and elasticity of applications are enhanced through dynamic service discovery and binding mechanisms.

[0020] In summary, the present invention provides an innovative cross-platform Serverless function execution solution, which effectively solves the problem of cloud vendor lock-in, provides strong technical support for enterprises to implement multi-cloud strategies, and promotes the wider application of Serverless technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solution of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work.

[0022] Figure 1 This is the overall architecture diagram of the cross-platform Serverless function execution system.

[0023] Figure 2 It is a structural diagram of the configuration parsing engine.

[0024] Figure 3 It is a composition diagram of the service discovery mechanism.

[0025] Figure 4 is a block diagram of the dynamic adapter module.

[0026] Figure 5 This is a diagram of the composition of the cache system.

[0027] Figure 6 It is a composition diagram of the distributed state synchronization mechanism.

[0028] Figure 7 It is a detailed structural diagram of the service discovery mechanism.

[0029] Figure 8It is a composition diagram of context switching and asynchronous operation processing.

[0030] Fig. 9 It is the structural diagram of the error handling and performance optimization module.

[0031] Fig.10 It is a cross-platform Serverless function execution flowchart.

[0032] Fig.11 It is a structural diagram of multi-cloud deployment and dynamic switching mechanism. DETAILED DESCRIPTION

[0033] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0034] In the description of the present invention, it should be noted that the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside" and the like indicate directions or positional relationships based on the directions or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore cannot be understood as a limitation on the present invention.

[0035] Example 1: Basic architecture of a cross-platform Serverless function execution system.

[0036] The cross-platform Serverless function execution system provided by the present invention aims to solve the compatibility problem of Serverless function migration and execution between different cloud platforms. The core innovation of the system lies in its dynamic adaptation mechanism and configuration-driven platform mapping, which enables the same function code to be seamlessly executed on multiple cloud platforms without modifying the source code.

[0037] like Figure 1 As shown, the system mainly includes the following core components: a dynamic adapter module 10, a configuration parsing engine 20, a service discovery mechanism 30, and an execution environment initializer 40. These components work together to achieve cross-platform compatibility of Serverless functions.

[0038] The dynamic adapter module 10 is the core of the system and is responsible for real-time conversion of API calls and service interactions between different cloud platforms when functions are running. This module contains multiple platform-specific adapters (such as Figure 111, 12, 13), each adapter corresponds to a mainstream cloud platform (such as AWS, Azure, Google Cloud). These adapters are not simple API mappings, but contain complex conversion logic that can handle semantic differences and special behaviors between different platforms.

[0039] The configuration parsing engine 20 is responsible for parsing the declarative configuration files describing the mapping relationship between functions and cloud services. The innovation of this engine is that it can understand and handle the complexity of cross-platform service mapping. Figure 2 As shown, the configuration parsing engine includes a configuration validator 21 and an execution plan generator 22. The configuration validator 21 not only checks the syntax correctness of the configuration file, but also verifies the consistency of the cross-platform service mapping. The execution plan generator 22 dynamically generates the execution plan of the function based on the configuration and the target platform. This plan includes a specific service call sequence and resource allocation strategy.

[0040] The service discovery mechanism30 is another key innovation of this system. Figure 3 As shown, it includes a service registry 31 and a dynamic service binder 32. The service registry 31 stores the mapping relationships of equivalent services on different platforms, which are obtained by in-depth analysis of the functional characteristics and performance indicators of each platform service. The dynamic service binder 32 is responsible for connecting to the required cloud services in real time during the function execution process. It can select the most suitable service instance according to the current execution environment and configuration.

[0041] The execution environment initializer 40 is responsible for configuring the runtime environment of the function according to the target platform. Its innovation lies in the ability to dynamically adjust the execution environment parameters to adapt to the characteristics of different platforms. This includes but is not limited to memory allocation, CPU time slice allocation, network configuration, etc.

[0042] The interaction flow between these components is as follows: 1. When the system receives a function deployment request, the configuration parsing engine 20 first parses the configuration file provided with the function code. 2. Based on the analysis results, the execution environment initializer 40 starts to prepare the function's running environment, including setting necessary environment variables, initializing the runtime library, etc. 3. The service discovery mechanism 30 searches for the corresponding service mapping in the service registry 31 according to the service requirements specified in the configuration file, and prepares the required service connection through the dynamic service binder 32. 4. When the function starts to execute, the dynamic adapter module 10 intervenes in the API call process of the function. It intercepts each external service call and selects the appropriate adapter (11, 12 or 13) for real-time conversion according to the current execution platform. 5. During the entire execution process, the system continuously monitors the execution status of the function and dynamically adjusts resource allocation and service binding to ensure optimal performance.

[0043] A key advantage of this system is its high scalability. When a new cloud platform needs to be supported, only the corresponding platform adapter needs to be developed and the service registry needs to be updated without modifying the core architecture of the system or the existing function code. This greatly reduces the implementation cost and complexity of the multi-cloud strategy.

[0044] In addition, the system also integrates advanced performance optimization mechanisms. For example, the dynamic adapter module 10 implements a cache system based on a least recently used (LRU) algorithm to store frequently used API conversion results.

[0045] It is worth noting that although this embodiment mainly describes the basic architecture of the system, the scope of the present invention is not limited to this. For example, the system can further integrate machine learning algorithms to optimize service selection and resource allocation, or introduce blockchain technology to enhance cross-platform data consistency. These potential extensions are all within the scope of protection of the present invention.

[0046] In summary, the cross-platform Serverless function execution system provided by the present invention effectively solves the cloud vendor lock-in problem through its innovative dynamic adaptation mechanism and intelligent configuration management, and provides strong technical support for enterprises to implement flexible multi-cloud strategies. This not only improves development efficiency, but also paves the way for wider application of Serverless technology.

[0047] Example 2: Implementation of a dynamic adapter module.

[0048] In Example 1, the overall architecture of the cross-platform Serverless function execution system was outlined. This example will elaborate on the implementation details of the core component of the system, the dynamic adapter module. The dynamic adapter module is the key innovation of the present invention, which enables seamless execution of Serverless functions across different cloud platforms.

[0049] like Figure 4 As shown, the dynamic adapter module includes multiple platform-specific adapters (such as AWS adapter 41, Azure adapter 42, Google Cloud adapter 43) and a central controller 44. Each platform-specific adapter contains the API mapping rules and service call conversion logic of the corresponding cloud platform.

[0050] The central controller 44 is the core of the dynamic adapter module, which is responsible for coordinating the work of different adapters and implementing dynamic proxy functions. The central controller uses reflection and dynamic proxy technology to intercept API calls of original functions. In the Java environment, the java.lang.reflect.Proxy class can be used to implement dynamic proxy; in the Node.js environment, the Proxy object can be used to implement similar functions.

[0051] The workflow of the dynamic adapter module is as follows: 1. Function initialization: When the Serverless function starts to execute, the central controller 44 first determines the target cloud platform based on the current execution environment and configuration file information. 2. Proxy creation: The central controller 44 creates a dynamic proxy object for the function. This proxy object intercepts all calls to the cloud service. 3. Call interception: When a function attempts to call a cloud service API, the call is first intercepted by a dynamic proxy object. 4. Adapter selection: The central controller 44 selects the corresponding platform-specific adapter according to the target platform. 5. Call conversion: The selected adapter converts the original API call into an equivalent call for the target platform. This process involves not only simple API mapping, but also complex parameter conversion and context adaptation. 6. Execute the call: The converted call is sent to the corresponding service of the target platform. 7. Result processing: The adapter receives the result returned by the service, performs necessary conversions, and then returns the result to the original function.

[0052] To illustrate this process, let's take the conversion of AWS S3 service to Azure Blob storage as an example. Assume that the original function contains the following code snippet: s3.putObject({Bucket:'myBucket',Key:'myKey',Body:data});

[0053] When this code is executed on the Azure platform, the dynamic adapter module converts it into: blobService.createBlockBlobFromText('myContainer','myKey',data);

[0054] This conversion process involves not only API mapping, but also parameter conversion (for example, mapping S3's "Bucket" concept to Azure's "Container" concept) and context adaptation (for example, handling differences in authentication and error codes).

[0055] A key innovation of the dynamic adapter module is its high scalability. Each platform-specific adapter is designed as a pluggable module that follows a unified interface specification. This allows the system to easily support new cloud platforms by simply developing the corresponding adapter module and registering it with the central controller.

[0056] To optimize performance, the dynamic adapter module implements an efficient caching mechanism. Figure 5 As shown, the cache system includes a cache storage 45 based on a least recently used (LRU) algorithm and a cache manager 46. The cache storage 45 is used to store frequently used API call conversion results, while the cache manager 46 is responsible for updating and maintaining the cache.

[0057] The cache system works as follows: 1. When an API call request is received, the system first checks whether there is a matching conversion result in the cache. 2. If there is a cache hit, the system directly returns the cached conversion result, thus avoiding repeated conversion calculations. 3. If the cache misses, the system performs the normal conversion process and stores the result in the cache. 4. The cache manager 46 periodically cleans up the least used cache items to maintain the efficiency of the cache.

[0058] This caching mechanism helps reduce API call conversion time and improves the efficiency of cross-platform function execution. The specific performance improvement may vary depending on the actual usage scenario and workload, and needs to be tested and evaluated in actual applications.

[0059] In addition, the dynamic adapter module also implements an intelligent error handling mechanism. Error codes and exception handling mechanisms often differ between different cloud platforms. The system maps error types on different platforms to a set of standardized error codes by establishing a unified error mapping table. This not only simplifies the error handling logic, but also improves the maintainability of cross-platform applications.

[0060] It is worth noting that although this embodiment mainly discusses the conversion of cloud service APIs, the application scope of the dynamic adapter module is far more than that. For example, it can also be used to handle the differences in event triggering mechanisms between different platforms, log format conversion, performance indicator unification, and other scenarios. These potential application extensions are all within the scope of protection of the present invention.

[0061] In short, the dynamic adapter module achieves seamless conversion and execution of Serverless functions between different cloud platforms through its innovative design. It not only solves the problem of cloud vendor lock-in, but also provides developers with a flexible and efficient cross-platform development solution.

[0062] Example 3: Working principle of configuration analysis engine.

[0063] In the first two examples, the overall architecture of the cross-platform Serverless function execution system and the implementation of the dynamic adapter module were introduced in detail. This example will explore in depth the working principle of the configuration parsing engine, which is another key innovation in achieving cross-platform function execution.

[0064] like Figure 2 As shown, the configuration parsing engine mainly consists of two parts: a configuration validator 61 and an execution plan generator 62. The core task of the configuration parsing engine is to parse the declarative configuration file describing the mapping relationship between functions and cloud services, and generate a corresponding execution plan.

[0065] The configuration file uses the YAML format, which is both human-readable and easy to parse by machines. A typical configuration file structure is as follows: function: name:myFunction runtime:nodejs14.x handler:index.handler services: -name:storage type:object-store mapping: aws:s3 azure:blob gcp:cloud-storage -name:database type:nosql mapping: aws:dynamodb azure:cosmos-db gcp:firestore

[0066] The configuration validator 61 first performs syntax checking and structural verification on the configuration file. It uses JSON Schema to define the structure and field types of the configuration file. This not only ensures the correctness of the configuration file, but also provides developers with functions such as automatic completion and error prompts. The workflow of the configuration validator is as follows: (1) Read the contents of the configuration file. (2) Convert the YAML format to a JSON object. (3) Use the predefined JSON Schema to validate the structure and field types of the configuration file. (4) Check the consistency of service mapping to ensure that each specified service has a corresponding mapping on all target platforms.

[0067] The configuration validator also implements the version compatibility check function. It maintains a version compatibility matrix to ensure that the configuration file is compatible with the current system version. This matrix defines the compatibility relationship between different versions, for example: "1.0":["1.0","1.1"], "1.1":["1.1","1.2"], "1.2":["1.2"] }

[0068] Through this matrix, the system can determine whether the current configuration file is compatible with the operating environment. If it is not compatible, it will give clear error prompts and upgrade suggestions.

[0069] The execution plan generator 62 is the core innovation of the configuration parsing engine. It does not simply parse the configuration, but dynamically generates the execution plan of the function based on the configuration information and the target platform. The execution plan is a structured object that contains all the information required for function execution, such as service mapping, resource configuration, trigger settings, etc.

[0070] The workflow of the execution plan generator is as follows: (1) Receive a validated configuration object. (2) Determine the target execution platform. (3) Select the corresponding service mapping based on the target platform. (4) Generate resource configuration information, including memory allocation, CPU limit, etc. (5) Parse the trigger configuration and generate the corresponding event source mapping. (6) Integrate the above information to generate a complete execution plan object.

[0071] An example structure of an execution plan object is as follows:

[0072] Another innovation of the configuration parsing engine is its extensibility. Through the plug-in mechanism, developers can easily add new configuration items and parsing logic to support new service types or platform features. Each plug-in implements a standard interface, including verification methods and plan generation methods. This design allows the system to flexibly adapt to the ever-changing cloud service ecosystem.

[0073] To improve parsing efficiency, the configuration parsing engine implements a lightweight caching mechanism. For frequently used configurations, the system caches their parsing results and generated execution plans. This greatly reduces the overhead of repeated parsing, especially when dealing with a large number of similar functions.

[0074] In addition, the configuration parsing engine also integrates intelligent inference capabilities. For example, when some optional fields in the configuration file are missing, the system will automatically infer appropriate values ​​based on other known information and best practices. This not only simplifies the configuration process, but also reduces runtime errors caused by improper configuration.

[0075] It is worth noting that although this embodiment mainly discusses configuration files based on YAML, the design of the configuration parsing engine is flexible enough to support configuration files in other formats, such as JSON or a custom domain-specific language (DSL). These potential extensions are all within the scope of protection of the present invention.

[0076] In short, the configuration parsing engine achieves complex cross-platform service mapping and execution plan generation through its innovative design. It not only simplifies the configuration work of developers, but also provides powerful scalability and flexibility for the entire system. With the continuous evolution of cloud services, this intelligent configuration management solution will play an increasingly important role in building portable and scalable Serverless applications.

[0077] Embodiment 4: Implementation method of service discovery mechanism.

[0078] The first three examples detailed the overall architecture of the cross-platform Serverless function execution system, the implementation of the dynamic adapter module, and the working principle of the configuration parsing engine. This example will explore in depth the implementation of the service discovery mechanism, which is another key innovation in achieving cross-platform function execution.

[0079] like Figure 7 As shown, the service discovery mechanism mainly consists of two parts: a service registry 71 and a dynamic service binder 72. The core task of the service discovery mechanism is to locate and bind equivalent cloud services between different cloud platforms, ensuring that Serverless functions can use corresponding services on different platforms without modifying the function code.

[0080] The service registry 71 is a dynamically maintained data structure that stores mappings of equivalent services on different platforms. These mappings are derived through in-depth analysis of the functional characteristics, performance indicators, and API design of services on each platform. The service registry contains the corresponding relationship of each service on different cloud platforms, including information such as service name, API version, and access endpoint.

[0081] The update mechanism of the service registry is an innovation of the present invention. The system adopts an event-driven real-time update strategy combined with regular full synchronization. When it detects that the cloud service provider releases a new service or API update, the system triggers an incremental update process to ensure that the service mapping is always kept up to date. This mechanism greatly improves the system's adaptability to changes in cloud services.

[0082] The dynamic service binder 72 is the core component of the service discovery mechanism and is responsible for connecting to the required cloud services in real time during the function execution process. Its workflow includes receiving the service requirements specified in the function configuration, querying the service registry to obtain equivalent service information on the target platform, dynamically generating a service client, and injecting the generated service client into the function execution environment.

[0083] A key innovation of the dynamic service binder is its "lazy loading" strategy. The service client is actually initialized only when it is called for the first time, which greatly reduces the function cold start time and resource consumption. For example, the cloud storage module referenced in the function code is actually a proxy object provided by the dynamic service binder. Only when the storage operation method is called will the system create the actual storage service client based on the current execution platform.

[0084] In order to handle the differences between services on different platforms, the dynamic service binder implements a set of intelligent adaptation layers. This adaptation layer not only handles the conversion of API calls, but also handles platform-specific details such as authentication methods, error handling, and retry strategies. For example, for storage services, the adaptation layer unifies the shard upload interface of different platforms, allowing developers to use a consistent API for large file uploads without having to worry about the differences in the underlying platforms.

[0085] The service discovery mechanism also integrates intelligent load balancing and failover functions. The system continuously monitors the performance and availability of each service instance and dynamically adjusts service bindings based on predefined policies. This not only improves application reliability, but also provides a technical foundation for multi-cloud deployment strategies.

[0086] In addition, the service discovery mechanism also implements service version control. Developers can specify the specific version of the required service in the configuration file, and the system will automatically handle version compatibility to ensure consistent behavior of functions in different environments. This greatly simplifies the application upgrade and rollback process.

[0087] It is worth noting that although this embodiment mainly discusses the discovery and binding of public cloud services, the design of this mechanism is flexible enough and can be extended to private cloud, hybrid cloud and even edge computing environments. For example, by integrating service mesh technology, this system can seamlessly support cross-cloud and cross-data center service discovery.

[0088] Another potential application of the service discovery mechanism is to support the "multi-cloud optimization" strategy. By analyzing the performance, cost, and availability data of equivalent services on different cloud platforms, the system can automatically select the optimal execution platform and service combination for each function. This capability will provide enterprises with unprecedented flexibility and efficiency.

[0089] In summary, the service discovery mechanism described in this embodiment realizes the dynamic binding and cross-platform compatibility of Serverless functions to cloud services through its innovative design. It not only simplifies application development and deployment in multi-cloud environments, but also paves the way for the realization of a truly "cloud-agnostic" application architecture. With the continuous development of cloud computing technology, this intelligent service discovery and binding mechanism will play an increasingly important role in building portable and scalable cloud-native applications.

[0090] Embodiment 5: Context switching and asynchronous operation processing.

[0091] This embodiment describes in detail the implementation method of context conversion and asynchronous operation processing in the cross-platform Serverless function execution system. These two components are the key links for the system to achieve cross-platform compatibility, and further improve the system's functions based on the previous embodiments.

[0092] like Figure 8 As shown, the context converter 81 and the unified asynchronous operation interface 82 are the core components of this embodiment. The context converter 81 is responsible for handling the differences in execution environments between different cloud platforms, including environment variables, event structures, etc. The unified asynchronous operation interface 82 provides a consistent abstraction layer for the asynchronous operation models of different platforms, ensuring that the function code has consistent behavior on different platforms.

[0093] The working principle of the context converter 81 is as follows: When the Serverless function starts to execute, the context converter first obtains the original execution context of the current platform. Then, it converts the original context into a standardized intermediate representation according to the predefined mapping rules. This intermediate representation contains all the key information required for function execution, such as function name, triggering events, environment variables, etc. Finally, the context converter converts this standardized context into the format required by the target platform.

[0094] For example, consider a function that handles an HTTP request. On AWS Lambda, the event object might look like this:

[0095] On Azure Functions, the same information can be represented as:

[0096] The context converter converts these two different representations into a standardized intermediate format:

[0097] This standardized intermediate representation allows function code to handle requests from different platforms in a consistent manner, greatly simplifying cross-platform development.

[0098] The unified asynchronous operation interface 82 is another innovation of this embodiment. It provides a unified abstraction layer for asynchronous operations of different cloud platforms. This interface is designed based on the Promise mode, but is extended to support more complex asynchronous operation modes. The core API includes:

[0099] The UnifiedAsync.run method is used to execute a single asynchronous operation, the parallel method is used to execute multiple operations in parallel, the series method is used to execute multiple operations in series, and the retry method implements asynchronous operations with retry logic.

[0100] The implementation of this unified interface takes into account the characteristics of different platforms. For example, when dealing with concurrency limits, it dynamically adjusts the concurrency strategy based on the current execution platform. On AWS Lambda, it may use Promise.all for parallel processing; on some platforms with weaker concurrency capabilities, it may adopt a batch execution strategy.

[0101] The unified asynchronous operation interface also integrates an intelligent retry mechanism. It can dynamically adjust the retry strategy based on the error type and context information. For example, for network timeout errors, it may use an exponential backoff algorithm; for resource limit errors, it may choose to delay the retry. This intelligent retry mechanism significantly improves the reliability of the function.

[0102] To optimize performance, both the context switch and the unified asynchronous operation interface implement a cache mechanism. For frequently used context switch rules and asynchronous operation modes, the system caches their results to reduce the overhead of repeated calculations. The cache is managed using the LRU (Least Recently Used) algorithm to ensure that the most frequently used data is always kept in memory.

[0103] Another innovation of this embodiment is its scalability. Both the context converter and the unified asynchronous operation interface are designed as pluggable modules. Developers can easily add new conversion rules and asynchronous operation modes through configuration files or APIs to support new platforms or specific application requirements.

[0104] It is worth noting that although this embodiment mainly discusses the scenario of Serverless functions, the context conversion and asynchronous operation processing techniques described here are also applicable to other types of cross-platform cloud applications. For example, in containerized applications or microservice architectures, these techniques can be used to handle differences between different container orchestration platforms or service grid implementations.

[0105] In summary, the context converter and unified asynchronous operation interface described in this embodiment provide key support for the cross-platform Serverless function execution system. They not only solve the problems of environmental differences and inconsistent asynchronous operation models between different cloud platforms, but also provide developers with a simple and unified programming model. This greatly reduces the complexity of cross-platform development and improves the portability and maintainability of applications. With the continuous development of cloud computing technology and the popularization of multi-cloud strategies, these technologies will play an increasingly important role in building truly cloud-agnostic applications.

[0106] Example 6: Error handling and performance optimization.

[0107] This embodiment describes in detail the implementation methods of the error handling module and performance optimization components in the cross-platform Serverless function execution system. These two components are the key links for the system to achieve reliability and efficiency, and further improve the system's functions based on the previous embodiments.

[0108] like Fig. 9 As shown, the error handling module 91 and the performance optimization component 92 constitute the core of this embodiment. The error handling module 91 is responsible for unifying the error types of different platforms and implementing a configurable retry strategy, while the performance optimization component 92 improves the overall performance of the system through various technical means.

[0109] The core of the error handling module 91 is a unified error mapping table. This table maps the error types of different cloud platforms to a set of standardized error codes. The structure of the error mapping table is as follows:

[0110] When the system captures an error, the error handling module first queries this mapping table to convert the platform-specific error into a standard error code. This unified error handling mechanism allows developers to write unified error handling logic without having to worry about the differences in the underlying platforms.

[0111] Another innovation of the error handling module is its configurable retry strategy. The system defines a set of basic retry strategies, such as fixed interval retry, exponential backoff retry, jitter retry, etc. These strategies can be customized through configuration files. For example:

[0112] This configurable retry mechanism not only improves the reliability of the system, but also provides optimized handling for different types of errors.

[0113] The performance optimization component 92 is another key innovation of this embodiment, which includes a multi-layer cache system, a preheating mechanism, and an adaptive resource allocation strategy.

[0114] The multi-layer cache system includes memory cache and distributed cache. The memory cache is managed using the LRU (Least Recently Used) algorithm and is used to store frequently accessed data, such as service mapping results, configuration parsing results, etc. The distributed cache is used to share data between multiple function instances to improve overall performance. The implementation of the cache system takes into account data consistency and expiration policies to ensure the accuracy of cached data.

[0115] The preheating mechanism is another important aspect of performance optimization. The system will pre-initialize some commonly used function instances and service connections during low load periods based on historical call patterns. This preheating mechanism significantly reduces cold start time and improves system response speed. The preheating strategy is adaptive and will dynamically adjust the type and number of preheated functions based on actual call conditions.

[0116] The adaptive resource allocation strategy is the core innovation of the performance optimization component. It dynamically adjusts resource allocation by monitoring the execution of functions in real time. For example, for CPU-intensive tasks, the system will allocate more computing resources; for I / O-intensive tasks, the system will optimize the network connection pool. This adaptive strategy uses machine learning algorithms to continuously learn and optimize resource allocation patterns.

[0117] The performance optimization component also implements intelligent load balancing. In a multi-cloud environment, the system dynamically determines the execution location of the function based on the current load, cost, and performance indicators of each platform. This not only improves resource utilization, but also achieves the optimal balance between cost and performance.

[0118] In order to quantify the performance improvement effect, the system integrates comprehensive performance indicator collection and analysis functions. This includes indicators in multiple dimensions such as function execution time, cold start delay, resource utilization, etc. These indicators are presented through a visual dashboard to help developers gain a deep understanding of system performance and provide a basis for further optimization.

[0119] It is worth noting that although this embodiment mainly discusses the scenario of Serverless functions, the error handling and performance optimization techniques described here are also applicable to other types of distributed systems. For example, in a microservice architecture, these techniques can be used to improve the reliability and performance of services.

[0120] In summary, the error handling module and performance optimization components described in this embodiment provide key support for the cross-platform Serverless function execution system. They not only improve the reliability and performance of the system, but also provide developers with a stable and efficient operating environment. These innovations significantly reduce the complexity of cross-platform development and improve the reliability and efficiency of applications. With the continuous development of cloud computing technology and the expansion of application scale, these technologies will play an increasingly important role in building large-scale, high-performance cloud-native applications.

[0121] Example 7: Specific steps of a cross-platform Serverless function execution method.

[0122] This embodiment describes in detail the specific steps of a cross-platform Serverless function execution method. The method integrates the various components and technologies described in the previous embodiments to form a complete cross-platform Serverless function execution process.

[0123] like Fig.10 As shown in the figure, the method includes the following key steps: receiving deployment requests, parsing configuration files, initializing the execution environment, executing functions, processing results, and returning responses. These steps together constitute a highly flexible and scalable cross-platform Serverless function execution method.

[0124] Step 1: Receive a deployment request. The system first receives a deployment request that contains the function code and a declarative configuration file. The configuration file uses the YAML format and defines the function's metadata, resource requirements, and service dependencies. A typical configuration file structure is as follows: function: name:imageProcessor runtime:nodejs s14.x handler:index.processImage memory:256 timeout:30 services: -name:imageStorage type:object-store mapping: aws:s3 azure:blob gcp:cloud-storage -name:imageAnalysis type:ai-vision mapping: aws:rekognition azure:cognitive-services gcp:vision-ai

[0125] Step 2: Parse the configuration file. The configuration parsing engine (as described in Example 3) parses the configuration file and generates a standardized function description object. This object contains all the necessary information of the function, such as the runtime environment, resource requirements, service dependencies, etc. During the parsing process, the system verifies the validity of the configuration and converts the platform-specific configuration into a common format.

[0126] Step 3: Initialize the execution environment. Based on the parsed function description, the execution environment initializer begins to prepare the function's runtime environment. This process includes: a) Select an appropriate runtime container (such as a Node.js 14.x environment). b) Configure environment variables, including function-specific variables and system-level variables. c) Set resource limits, such as memory limits and execution timeouts. d) Initialize the dynamic adapter module (as described in Example 2) and prepare for API call conversion.

[0127] Step 4: Execute the function. When the trigger event arrives, the system starts executing the function. This process involves several key operations: a) A context converter (as described in Example 5) converts the platform specific event data into a standard format. b) A dynamic service binder (as described in Example 4) dynamically connects the required cloud services according to the function configuration. c) The function code starts to execute, and the API calls are intercepted and converted by the dynamic adapter module. d) A unified asynchronous operation interface (as described in Example 5) handles asynchronous operations and ensures cross-platform compatibility.

[0128] During execution, the error handling module (as described in Example 6) continuously monitors and handles possible abnormal situations. For example, when a network timeout error is detected, the module may apply the following retry strategy:

[0129] At the same time, the performance optimization component (as described in Example 6) monitors the execution of the function in real time and dynamically adjusts resource allocation. For example, for computing-intensive tasks, the system may increase the CPU quota; for memory-intensive tasks, it may expand the memory allocation.

[0130] Step 5: Process the results. After the function is executed, the system processes the execution results. This includes: a) Convert the data returned by the function into a standard format. b) Clean up temporary resources, such as closing database connections, releasing file handles, etc. c) Record execution logs and performance indicators for subsequent analysis and optimization.

[0131] Step 6: Return the response. Finally, the system returns the processed result to the caller. The response format will be adjusted appropriately according to the triggering method (such as HTTP request, event trigger, etc.) to ensure that it is consistent with the response format of the native platform.

[0132] A key innovation of this method is its end-to-end cross-platform compatibility. From function deployment to execution to result return, each link takes platform differences into consideration and achieves seamless adaptation through various innovative technologies. This approach not only simplifies the development process, but also greatly improves the portability of Serverless applications.

[0133] Another important innovation is the extensibility of the approach. Through modular design and standardized interfaces, the approach can easily support new cloud platforms or service types. For example, to add support for a new platform, you only need to extend the configuration parsing engine, dynamic adapters, and service discovery mechanisms without modifying the core execution logic.

[0134] It is worth noting that although this embodiment mainly describes the execution method of Serverless functions, many of the techniques and principles here are also applicable to other types of cross-platform cloud applications. For example, this method can be extended to support cross-platform deployment and execution of containerized applications, or used to build IoT applications across multiple edge computing platforms.

[0135] In summary, the cross-platform Serverless function execution method described in this embodiment provides a comprehensive and flexible solution, effectively solves the problem of cloud vendor lock-in, and provides strong technical support for enterprises to implement multi-cloud strategies. With the continuous development of cloud computing technology and the increasing complexity of application scenarios, this cross-platform execution method will play an increasingly important role in building portable and scalable cloud-native applications, and promote the entire cloud computing ecosystem to develop in a more open and flexible direction.

[0136] Embodiment 8: Implementation of multi-cloud deployment and dynamic switching.

[0137] This embodiment describes in detail the implementation method of multi-cloud deployment and dynamic switching in a cross-platform Serverless function execution system. This method is based on the previous embodiment, further expands the functions of the system, and realizes true multi-cloud strategy execution.

[0138] like Fig.11 As shown, the multi-cloud deployment and dynamic switching mechanism mainly consists of a multi-cloud configuration manager 111, a load balancer 112, and an inter-cloud migration engine 113. These components work together to enable Serverless functions to be deployed on multiple cloud platforms simultaneously and dynamically adjust the execution location according to real-time conditions.

[0139] The multi-cloud configuration manager 111 is responsible for processing function configurations across multiple cloud platforms. It extends the configuration parsing engine described in Example 3, allowing multi-cloud deployment strategies to be defined in a single configuration file. The configuration file contains the basic information of the function, deployment strategy, service mapping, and extended parameters of each platform. The multi-cloud configuration manager 111 parses this configuration and generates appropriate deployment descriptors for each target cloud platform. It is also responsible for managing cross-platform configuration consistency to ensure that functions have consistent behavior on all platforms.

[0140] The load balancer 112 is a key innovation of this embodiment. It not only performs load balancing within a single cloud platform, but also distributes requests across multiple cloud platforms. The load balancer uses a dynamic weighted polling algorithm to consider the current load and performance indicators of each cloud platform, the historical execution time and success rate of the function on each platform, network latency and geographical location factors, and cost factors to determine the routing of the request. The load balancing algorithm can be expressed as:

[0141] Among them, W i is the weight of platform i, P i is the performance score, L i is the current load factor, S i is the success rate, C i is the relative cost, D i is the network delay factor. This algorithm ensures the flexibility and efficiency of request distribution.

[0142] The inter-cloud migration engine 113 is responsible for handling the migration of function instances between different cloud platforms. When the system detects that the performance of a platform has degraded or the cost has surged, the inter-cloud migration engine triggers the migration process. The migration process includes preheating new function instances on the target platform, gradually transferring traffic from the source platform to the target platform, ensuring that all ongoing requests are completed on the source platform, and finally completely switching to the target platform and cleaning up resources on the source platform.

[0143] To support the migration of stateless functions, the system utilizes the service discovery mechanism described in Example 4. Through dynamic service binding, functions can be connected to equivalent services on the new platform immediately after migration. For stateful functions, the system implements a distributed state synchronization mechanism. Fig.11 As shown in Figure 1, the mechanism uses a centralized state storage service and incremental synchronization protocol to ensure that the function state remains consistent across multiple cloud platforms. State synchronization uses version control and conflict resolution strategies, similar to the working principle of distributed version control systems.

[0144] Multi-cloud deployment and dynamic switching mechanisms also integrate intelligent fault detection and automatic recovery functions. The system continuously monitors the health status of functions on each cloud platform, including execution success rate, response time, error rate and other indicators. When an anomaly is detected, the system automatically triggers the failover process and redirects traffic to the healthy platform.

[0145] Another innovation of this embodiment is its support for edge computing. By extending the multi-cloud configuration manager and load balancer, the system can treat edge nodes as additional execution platforms. This allows functions to be dynamically migrated between the cloud and the edge as needed, achieving true cloud-edge collaborative computing.

[0146] In order to evaluate the effectiveness of multi-cloud deployment and dynamic switching mechanisms, performance indicators such as cross-platform load balancing efficiency, dynamic switching response time, state synchronization delay, and cost optimization effect can be considered. These indicators can fully reflect the performance and efficiency of the system in a multi-cloud environment.

[0147] It is worth noting that although this embodiment mainly discusses the multi-cloud deployment of Serverless functions, the technology described here is also applicable to other types of cloud-native applications. For example, this method can be extended to support multi-cloud deployment and dynamic migration of containerized microservices, or used to build hybrid cloud applications across multiple public and private clouds.

[0148] In summary, the multi-cloud deployment and dynamic switching mechanism described in this embodiment provides powerful multi-cloud support for the cross-platform Serverless function execution system. It not only improves the availability and performance of applications, but also provides enterprises with more flexible cloud resource utilization strategies. This technology will play an increasingly important role in building highly reliable and scalable cloud native applications, and promote the entire cloud computing ecosystem to develop in a more open and flexible direction.

Claims

1. A system for implementing cross-platform Serverless function execution, characterized in that: include: (a) Dynamic adapter module, used to convert API calls and service interactions between different cloud platforms when the function is running; (b) a configuration parsing engine for parsing a declarative configuration file describing the mapping relationship between functions and cloud services; (c) Service discovery mechanism, used to locate and bind equivalent cloud services between different platforms; (d) Execution environment initializer, used to configure the runtime environment of the function according to the target platform.

2. The system according to claim 1, characterized in that The dynamic adapter module comprises: (a) Multiple platform-specific adapters, each of which contains the API mapping rules and service call conversion logic of the corresponding cloud platform; (b) A dynamic proxy component that intercepts the API calls of the original function and converts them into equivalent calls of the target platform in real time.

3. The system according to claim 1, characterized in that Also includes: (a) Context converter, which is used to handle the differences in execution contexts between different platforms, including environment variables, event structures, etc.; (b) A unified asynchronous operation interface, used to encapsulate asynchronous operation models of different platforms.

4. The system according to claim 1, characterized in that The configuration parsing engine includes: (a) Configuration validator, which checks the syntax correctness and version compatibility of configuration files; (b) Execution plan generator, which is used to dynamically generate the execution plan of the function based on the configuration and target platform.

5. The system according to claim 1, characterized in that Also includes: (a) Error handling module, which is used to unify the error types of different platforms and implement configurable retry strategies; (b) Performance optimization components, including a cache mechanism based on the LRU algorithm to store frequently used transformation results.

6. The system according to claim 1, characterized in that The service discovery mechanism includes: (a) Service registry, used to store the mapping relationship between equivalent services on different platforms; (b) Dynamic service binder, used to connect to required cloud services in real time during function execution.

7. A method for implementing cross-platform Serverless function execution, characterized in that: The following steps are involved: (a) receiving a deployment request including function code and a declarative configuration file; (b) parsing the configuration file to determine the target platform and required cloud services; (c) initializing the corresponding dynamic adapter module according to the parsing result; (d) during function execution, using the dynamic adapter module to convert API calls and service interactions in real time; (e) Process the execution results and return a response in a unified format.

8. The method according to claim 7, characterized in that Also includes: (a) Before the function is executed, the context switch is used to adjust the execution environment to adapt to the characteristics of the target platform; (b) Use a unified asynchronous operation interface to encapsulate platform-specific asynchronous calls.

9. The method according to claim 7, characterized in that: Also includes: (a) During execution, the required cloud services are dynamically located and bound using the service discovery mechanism; (b) Use the error handling module to uniformly handle exceptions on different platforms and perform retries according to predefined strategies.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 7 to 9 is implemented.

Images