Service management method, platform, equipment and program product under server-free architecture

Abstract

The embodiment of the invention provides a service management method, platform, device and program product under a server-free architecture, and the service management method under the server-free architecture comprises the steps: receiving a service deployment request sent by a front-end user, the service deployment request comprising service description information and a user identifier; calling cloud resources under a server-free architecture based on the service description information to construct a target service; and deploying the target service in a cloud room corresponding to the front-end user based on the user identifier. According to the method, a full-automatic solution required by a quick-access server-free developer is combined, and an application view of managing cloud resources is provided for the developer from codes to the cloud. According to the method, personalized service deployment is realized, elastic resources of a server-free architecture are fully utilized, the reliability and stability of service deployment are ensured, and convenient and efficient use experience is brought to developers and users.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of cloud service technology, and in particular to a service management method, platform, device and program product under a serverless architecture. Background Art

[0002] Serverless technology is the main form of next-generation cloud computing. Its core advantages include availability redundancy, geographically distributed redundant copies, and automatic system expansion capabilities, so that a single machine failure will not cause service interruption, while maintaining service load balancing and request routing in disaster events, and effectively utilizing resources. Serverless architecture eliminates the need for traditional server maintenance, allowing developers to focus on application development and operation, significantly reducing operation and maintenance costs.

[0003] However, with the widespread application of serverless technology, some technical challenges have also been brought about. In the development and operation and maintenance process of the serverless architecture, the traditional way of interacting with specific equipment and facilities has become ineffective, requiring developers to relearn serverless architecture technology, which is inconvenient to manage.

[0004] Therefore, a service management method under a serverless architecture is continued to enable developers to focus on application development and operation and improve the convenience of service management under a serverless architecture. Summary of the invention

[0005] In view of this, an embodiment of this specification provides a service management method under a serverless architecture. One or more embodiments of this specification also relate to a service management platform under a serverless architecture, a service management device under a serverless architecture, a computing device, a computer-readable storage medium, and a computer program product to solve the technical defects existing in the prior art.

[0006] According to a first aspect of an embodiment of this specification, a service management method in a serverless architecture is provided, including:

[0007] Receiving a service deployment request sent by a front-end user, wherein the service deployment request includes service description information and a user identifier;

[0008] Based on the service description information, cloud resources in the serverless architecture are called to build the target service;

[0009] The target service is deployed in the cloud room corresponding to the front-end user based on the user identity.

[0010] According to a second aspect of an embodiment of this specification, a service management platform under a serverless architecture is provided, including:

[0011] The front-end interaction module is used to receive a service deployment request sent by a front-end user, wherein the service deployment request includes service description information;

[0012] The back-end processing module is used to call the cloud resources under the serverless architecture to build the target service based on the service description information; and deploy the target service in the user cloud room corresponding to the front-end user.

[0013] According to a third aspect of an embodiment of this specification, a service management device in a serverless architecture is provided, including:

[0014] A receiving module is configured to receive a service deployment request sent by a front-end user, wherein the service deployment request includes service description information and a user identifier;

[0015] A calling module is configured to call cloud resources in a serverless architecture to build a target service based on the service description information;

[0016] The deployment module is configured to deploy the target service in the cloud room corresponding to the front-end user based on the user identifier.

[0017] According to a fourth aspect of an embodiment of this specification, a computing device is provided, including:

[0018] Memory and processor;

[0019] The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor, the steps of the service management method under the above-mentioned serverless architecture are implemented.

[0020] According to the fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of the service management method under the above-mentioned serverless architecture are implemented.

[0021] According to the sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instruction, which, when executed by a processor, implements the steps of the service management method under the above-mentioned serverless architecture.

[0022] An embodiment of this specification implements receiving a service deployment request sent by a front-end user, wherein the service deployment request includes service description information and a user identifier, calling cloud resources under a serverless architecture based on the service description information to build a target service, and deploying the target service in a cloud room corresponding to the front-end user based on the user identifier. It combines the fully automatic solution required for quick-start serverless developers, and provides developers with an application perspective for managing cloud resources from code to the cloud. It implements personalized service deployment, fully utilizes the elastic resources of the serverless architecture, ensures the reliability and stability of the deployed service, and brings a convenient and efficient user experience to developers and users. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a flow chart of a service management method under a serverless architecture provided by an embodiment of this specification;

[0024] Figure 2 This is a service deployment interaction diagram of a service management platform under a serverless architecture provided by an embodiment of this specification;

[0025] Figure 3 This is a service application interaction diagram of a service management platform under a serverless architecture provided by an embodiment of this specification;

[0026] Figure 4 This is a schematic diagram of an interface of a service management platform under a first serverless architecture provided by an embodiment of this specification;

[0027] Figure 5 It is a schematic diagram of an interface of a service management platform under a second serverless architecture provided by an embodiment of this specification;

[0028] Figure 6 It is a schematic diagram of the interface of a service management platform under a third serverless architecture provided by an embodiment of this specification;

[0029] Figure 7 It is a schematic diagram of an interface of a service management platform under a fourth serverless architecture provided by an embodiment of this specification;

[0030] Figure 8 It is a schematic diagram of an interface of a fifth service management platform under a serverless architecture provided by an embodiment of this specification;

[0031] Fig. 9 It is a schematic diagram of an interface of a service management platform under a sixth serverless architecture provided by an embodiment of this specification;

[0032] Fig.10 It is a schematic diagram of an interface of a service management platform under a seventh serverless architecture provided by an embodiment of this specification;

[0033] Fig.11 It is a schematic diagram of an interface of an eighth service management platform under a serverless architecture provided by an embodiment of this specification;

[0034] Fig.12 It is a structural diagram of a service management device under a serverless architecture provided by an embodiment of this specification;

[0035] Fig.13 It is a structural block diagram of a computing device provided by an embodiment of this specification. DETAILED DESCRIPTION

[0036] Many specific details are described in the following description to facilitate a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of this specification, so this specification is not limited to the specific implementation disclosed below.

[0037] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0038] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0039] In addition, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0040] First, the terms involved in one or more embodiments of this specification are explained.

[0041] Severe less: Serverless is a cloud computing service architecture whose core concept is that developers do not need to worry about server management and maintenance. In a serverless architecture, developers do not need to provision or manage server instances. Instead, they deploy code to the cloud platform, and the cloud service provider automatically manages and allocates resources, dynamically allocating and releasing resources based on request requirements. This model enables developers to focus on application development and function implementation without having to worry about the details at the hardware or infrastructure level.

[0042] SAE: Serverless Application Engine. A platform service that provides a serverless computing environment. It is mainly used to support developers to quickly build, deploy, and run applications in a cloud environment without having to worry about the underlying server management. SAE allows developers to focus on writing the business logic of the application without having to worry about the configuration, expansion, and maintenance of the server.

[0043] Sample Code: Sample code is a pre-written program or functional code, usually provided by cloud service providers or development communities. They are designed to show how to use a specific service or solve a specific problem. Sample code is very useful for developers and can serve as a starting point for learning and quick start, helping them understand and apply the functions of cloud services.

[0044] WebIDE: Web Integrated Development Environment is an integrated development environment accessed through a web browser for developing and editing application code. It allows developers to code, debug, and deploy without installing a local development environment. WebIDE usually integrates code editors, debugging tools, version control functions, etc., allowing developers to easily develop on any device.

[0045] CI / CD: Continuous Integration / Continuous Deployment, which integrates code changes into a shared trunk frequently through automated processes and automatically deploys them to the production environment. Specifically, continuous integration (CI) focuses on the frequent integration, building, and testing of code by the development team to ensure code quality and stability. Continuous deployment (CD) involves automatically deploying code that has passed the CI phase verification to the production environment in order to quickly respond to business needs and fix problems.

[0046] Cloud room: A cloud room is a specific virtual space or folder used to store files and data in a cloud storage service. Users can upload files to this cloud storage space and share or collaborate on editing these files with others.

[0047] With the development of cloud computing, serverless technology has gradually become one of the important means of digital transformation for enterprises. However, there are still some challenges and pain points in the current serverless technology, mainly including: Faced with numerous cloud products and services, developers often face a dilemma of choice and do not know which product is suitable for their application scenarios. Serverless technology itself has certain technical difficulties, especially for those developers who have no relevant experience. The lack of a comprehensive perspective to manage and monitor the entire application ecosystem makes operation and maintenance work cumbersome. Traditional methods cannot effectively reduce the operational burden, so that developers cannot focus on core business functions.

[0048] In response to the above problems, the present invention provides a service management method under a serverless architecture to help developers choose suitable cloud service providers and cloud products, while obtaining professional consulting services. Simplify deployment parameter settings, provide unified CI / CD capabilities, and integrate the ATC tool chain. Support functions such as automatic scaling, network configuration, domain name integration, and certificate management. Provide a unified observability view, cost optimization suggestions, and realize intelligent management of cloud resources. By implementing this method, the selection and deployment process of cloud products is simplified, making it easier for developers to understand and master serverless technology. Providing a unified governance view reduces operation and maintenance pressure and enhances cross-platform compatibility. Help enterprises save expenses by optimizing resource usage and providing cost optimization suggestions. Reduce the workload of daily operations, allowing developers to focus more on innovation and business development.

[0049] In this specification, a service management method under a serverless architecture is provided. This specification also involves a service management platform under a serverless architecture, a service management device under a serverless architecture, a computing device, and a computer-readable storage medium, which are described in detail one by one in the following embodiments.

[0050] See also Figure 1 , Figure 1 It is a flowchart of a service management method under a serverless architecture provided by an embodiment of this specification, which specifically includes the following steps.

[0051] Step 102: Receive a service deployment request sent by a front-end user, wherein the service deployment request includes service description information and a user identifier.

[0052] Front-end users refer to users who use the service management platform under the serverless architecture. Front-end users initiate service deployment requests or other requests in the operation interface of the service management platform under the serverless architecture.

[0053] Service deployment requests request that a specific service be deployed to one or more environments. Deployment requests typically contain the necessary service description information so that the platform can accurately understand and execute these requests.

[0054] Service description information refers to a detailed description of the service to be deployed, including the service name, version number, configuration requirements, dependencies, and other technical and functional characteristics.

[0055] A user identity is information used to uniquely identify a user or entity requesting a service deployment. A user identity can typically be a username, email address, user ID, or other type of unique identifier used to determine the source and authority of a request.

[0056] In actual applications, under the serverless architecture, the service management platform is responsible for handling various operations initiated by users, including the deployment of services. When the front-end user decides to deploy a service, a deployment request is initiated to the service management platform through the user interface or application program interface. This request is a data packet containing two key pieces of information: service description information and the user ID of the service deployer. The service description information covers all the technical details and configuration parameters required to deploy the service, such as the programming language used by the service, the version of the dependent library, the environment variable configuration, the resource requirements (such as memory, CPU), and the entry point for the service to run. This information ensures that the platform knows exactly how to configure and run the service. The user ID refers to the unique identity proof of the user who initiated this deployment request, which is used for permission control and audit tracking. The platform will verify whether the user has the authority to deploy the service based on the user ID, and determine the user or team to which the service belongs after deployment, so as to facilitate subsequent resource management and access control.

[0057] The entire process does not involve direct server management in the traditional sense, but relies on the concept of serverless architecture, such as AWS Lambda (a serverless architecture name), Azure Functions (a serverless architecture name) or Google Cloud Functions (a serverless architecture name). After the platform receives a request, it will automatically trigger a series of backend functions, including but not limited to:

[0058] Authentication and authorization: Check the validity of user identification and corresponding permissions.

[0059] Parse service description: parse the service configuration in the request and prepare the deployment environment.

[0060] Resource provisioning: Automatically allocating computing resources based on service demand, although in serverless architectures this is often more dynamic and on-demand.

[0061] Service deployment: build or pull service images, configure network, storage and other resources, and start services.

[0062] Health check and monitoring: Perform a preliminary health check after deployment and continuously monitor the service operation status to ensure its stability and availability.

[0063] Logs and Notifications: Record the deployment process and service operation logs, and send deployment status notifications to users when necessary.

[0064] Step 104: Based on the service description information, cloud resources in the serverless architecture are called to build the target service.

[0065] Cloud resources refer to the various on-demand, scalable computing, storage, network, security, database, analysis and application services provided by the cloud computing platform. These resources are delivered through the Internet, and users can obtain, configure and manage these services according to actual needs without building and maintaining physical data centers or server hardware. The core advantages of cloud resources are elastic scaling, high availability, cost-effectiveness and convenient management capabilities. The main categories include: computing resources: such as virtual machine instances, containers, and serverless functions. These resources provide an operating environment for applications. Storage resources: including object storage (suitable for storing large amounts of unstructured data), block storage (providing hard disk-like storage space for virtual machines), file storage (shared access file system), etc., for data storage and backup. Database services: provide various types of database solutions, such as relational database services, non-relational databases), data warehouses, cache services, etc., to meet different data processing needs. Network resources: such as virtual private clouds, load balancers, content distribution networks, dedicated network connections, etc., help build a flexible and secure network architecture. Security management resources: including identity and access management, firewalls, security groups, key management services, etc., to ensure the security of the cloud environment. Monitoring and management tools: log analysis, performance monitoring, resource automation management, cost optimization tools, etc., to help users efficiently operate cloud resources. Analysis and artificial intelligence services: big data processing, machine learning platform, speech recognition, image recognition and other advanced services to support enterprises in data analysis and intelligent transformation.

[0066] In actual applications, first, the platform parses the service description information and extracts key parameters such as runtime environment (such as Node.js, Python version), dependency library list, environment variable settings, memory and CPU requirements, etc. Then, based on these parameters, the platform can automatically perform the following steps:

[0067] Choose the right cloud function service: Based on the programming language and technology stack used by the service, the platform will select the corresponding serverless cloud service provider and its services, such as AWS Lambda, Azure Functions, or Google Cloud Functions.

[0068] Configure the execution environment: On the selected cloud function service, configure the execution environment according to the service description information. This includes installing the necessary runtime environment, dependent libraries, and setting environment variables to ensure that the service can run smoothly in the environment.

[0069] Code upload and packaging: If the service code is not hosted in the code repository provided by the cloud service provider, the code must be uploaded from the user-submitted or specified source to the cloud platform and packaged to form a deployable executable package.

[0070] Set triggers and events: Define events that trigger service execution based on service requirements, such as HTTP requests, scheduled tasks, or event triggers from other cloud services. In a serverless architecture, services are usually driven by specific events.

[0071] Resource allocation and optimization: Although resource allocation is relatively automated and on-demand in a serverless architecture, the platform still needs to intelligently pre-configure or dynamically adjust the amount of resources based on the resource requirements in the service description to ensure service performance and cost-effectiveness.

[0072] Deployment and initialization: After completing the above configuration, the platform deploys the service to the cloud and performs initialization for the first run, including database connection, external service authentication, etc., to ensure that the service is ready to provide functions to the outside world as soon as it is started.

[0073] Health check and monitoring start: After deployment, the platform automatically performs health checks to confirm that the service is running properly and starts continuous monitoring to promptly detect and address any runtime issues.

[0074] Furthermore, the service description information includes a target service environment; before calling cloud resources under a serverless architecture to build a target service based on the service description information, it includes: creating a corresponding cloud room according to at least one service environment set by a front-end user; deploying the target service in the cloud room corresponding to the front-end user, including: deploying the target service in the cloud room corresponding to the target service environment.

[0075] The service environment, also known as the operating environment or deployment environment, refers to the sum of all configurations and conditions necessary to support the operation of a specific software or service. It covers many factors such as hardware, operating system, middleware, programming language version, library files, dependencies, configuration files, network settings, etc.

[0076] In actual applications, under the serverless architecture, the process of building the target service is closely centered around the service description information to ensure the accuracy of environment matching and resource allocation. The service description information carries detailed information for building the target service, covering the operating environment configuration required for the service. After the front-end user submits a deployment request, in which at least one service environment (such as development, test, and production environments) is specified, the platform responds immediately: the platform parses the service environment information in the user's request, and based on this information, automatically creates or specifies a "cloud room" that matches the environment for the user on the cloud platform. This "cloud room" is essentially a collection of logically isolated resources, including computing, storage, and network configuration, to ensure environmental consistency and resource exclusivity. In the newly created or existing "cloud room", the system further configures the necessary cloud resources based on the service description information, such as selecting a suitable runtime environment, installing dependencies, setting environment variables, and configuring storage and network services to set the stage for deploying the target service. Subsequently, the platform directly deploys the target service code or packaged application to the corresponding "cloud room" environment. This step involves uploading service code, setting triggers, configuring automatic expansion rules, etc., to ensure that the service can respond to expected events and run on demand. Finally, ensure that the target service is tightly bound to the "cloud room" environment in which it runs, which means that all running configurations and resource usage of the service strictly follow the environmental standards defined in the service description information to achieve environmental consistency and deployment automation.

[0077] Based on this, according to the service environment set by the front-end user, the corresponding cloud resource space is created, and the process of deploying the target service in the space is implemented. This method allows cloud resources to be dynamically created and configured according to user needs, effectively supports multi-environment deployment requirements, improves flexibility and resource utilization efficiency, and thus optimizes the process of service deployment and management.

[0078] Furthermore, the cloud resources are code resources in a code repository under a serverless architecture; based on the service description information, the cloud resources under the serverless architecture are called to build a target service, including: based on the service description information, obtaining the target service code in the code repository under the serverless architecture; scheduling the code encapsulation service under the serverless architecture to encapsulate the target service code into a target service.

[0079] Code resources refer to the collection of all source code files, library files, configuration files, and related documentation used to implement specific functions or services during the software development process. In the context of serverless architecture, code resources are particularly important because they directly determine the behavior and functionality of the service. These resources are usually stored in code repositories in version control systems, such as GitHub, GitLab, or private code repositories provided by cloud service providers, to facilitate version control, collaboration, and automated deployment.

[0080] The role of the code packaging service is to convert the original code resources into a form that can be directly run on the serverless platform. The specific steps include: Analyze all dependencies declared in the code, including libraries, frameworks, and other external services. Prepare the corresponding execution environment according to the runtime environment (such as Node.js, Python version), environment variables, and other settings in the service description information. This includes installing the necessary runtime, setting environment variable values, configuration file paths, etc. For languages ​​that require compilation (such as C#, Go), the packaging service will perform the compilation process. For all languages, the service will be packaged into one or more deployable units, such as AWS Lambda ZIP files or Docker images, so that it can be run on the serverless platform. Determine the main entry file or function of the service to ensure that the serverless platform knows where to start executing the service logic. In order to increase loading speed and reduce operating costs, the packaging service can optimize the code, such as removing useless code and compressing files. Generate specific deployment configurations based on the service description information, such as memory size, timeout, error handling strategy, etc., so that it can be correctly deployed and run on the serverless platform.

[0081] In actual applications, in the scenario of serverless architecture, after receiving the request, the platform first parses the instructions about the target service environment and code resources, and uses the path or identifier specified in the service description information to interact directly with the code repository under the serverless architecture. The code repository is a cloud service that centrally stores, manages and version-controls code, such as GitHub, GitLab or the code storage service provided by the cloud service provider. The platform accurately locates the code storage location of the target service according to the instructions in the description. After locating the target service code, the platform extracts the required code and dependent files from the code repository. This process can involve the specification of specific branches, tags or commit hashes to ensure that the exact code version that the user intends to deploy is obtained. After extracting the code, the platform further calls the code packaging service under the serverless architecture. This service is responsible for converting the original code into a format that can run on the serverless platform, such as creating or updating Lambda functions, Azure Functions, Google Cloud Functions, etc. The packaging process involves compilation (if the code is not an interpreted language), packaging, configuring the dependent environment, optimization, and setting the execution entry point, etc., to ensure that the code can adapt to the serverless execution environment. The packaged code has essentially become a target service that can be deployed in a serverless architecture. Based on other configurations in the service description information (such as memory, CPU limits, environment variables, triggers, etc.), the platform deploys the packaged service to the corresponding "cloud room" in the cloud environment to complete the entire process of service construction.

[0082] Based on this, code resources can be dynamically managed and deployed according to service description information to achieve efficient service construction and deployment, thereby supporting rapid development and flexible resource configuration management.

[0083] Step 106: Deploy the target service in the cloud room corresponding to the front-end user based on the user identifier.

[0084] The target service includes but is not limited to the following forms: Application: An application is a collection of software that users interact directly with or run in the background to complete specific tasks. It can be a desktop software, a mobile application, or a web-based application. Applications are usually composed of multiple functional components that work together to provide users with a complete functional experience. For example, an email client is an application that includes multiple functional components such as writing emails, sending emails, receiving emails, and managing contacts. Microservices: Microservices is a method of splitting a large application into a set of small, independently deployable services. Each service runs in its own process and communicates with each other through lightweight communication mechanisms. Each microservice focuses on implementing a specific function of the application, such as user authentication service, order processing service, etc. This architecture makes the system easier to expand and maintain because each service can be developed, deployed, and expanded independently without affecting other services. Web Pages: Web pages are documents on the Internet used to display information or provide interactive interfaces. They form the basis of web applications that users access through browsers. Although the "web page" itself refers more to the user interface level, the functions behind it are also composed of a series of services and applications. For example, the homepage of an online shopping website not only displays a list of products, but also integrates microservices such as search, filter, and add to cart, which together provide users with a complete shopping experience.

[0085] In modern software development, whether building applications or microservices, modular design ideas are often used. Functional components are software modules that implement specific business functions. They encapsulate relevant business logic and data processing processes, making the code clearer and easier to maintain. Functional components are built from smaller execution units - functions. Functions are blocks of code that perform specific tasks, such as calculating the sum of two numbers or querying records in a database. By combining these basic functions, complex functional components are built to form complete applications or microservices.

[0086] In actual applications, in a serverless service management platform, the process of "deploying the target service in the cloud room corresponding to the front-end user based on the user identity" essentially means that the platform ensures that the service is deployed within the exclusive cloud resource range that the user has the right to access and manage based on the identity of the user who initiated the service deployment request. This is similar to providing an isolated "cloud room" for each user. The specific implementation steps include:

[0087] User identity authentication and permission check: The platform first verifies the user ID in the request sent by the front-end user to confirm its legitimacy. Then, based on the user's role and permissions, it checks whether the user has the right to deploy services in his "cloud room".

[0088] Resource mapping and isolation: After determining the user's permissions, the platform associates the user's request with the resource quota and the allocated "cloud room" on the cloud platform. This "cloud room" is essentially a logically isolated environment that ensures that the user's services and data are independent of other users and meet security and resource management requirements.

[0089] Configure target services: Using the service description information extracted from the user request, the platform configures the necessary cloud resources in the user's corresponding "cloud room", such as creating or updating serverless functions, setting the execution environment, configuring storage and network resources, etc. All operations are limited to the resource permissions of this user.

[0090] Deploy and initialize services: After configuring all necessary resources, the platform deploys the user's service code or application package to the specified location of the "cloud room", executes the initialization script, and establishes dependencies between services such as database connection and API gateway integration to ensure that the service can be started smoothly and provide functions to the outside world.

[0091] Permission control and auditing: After deployment, the platform will also set access control policies based on user identification to ensure that only authorized users can manage or access this service. At the same time, deployment activity logs are recorded for auditing and tracing to enhance security and compliance.

[0092] Furthermore, the target service includes at least one functional component, and the cloud resources are functional components under the serverless architecture; the target service is deployed in the cloud room corresponding to the front-end user based on the user identifier, including: sending at least one functional component to the cloud room corresponding to the front-end user based on the user identifier, wherein at least one functional component is obtained under the serverless architecture based on the service description information, and at least one functional component is used to implement a sub-function of the target service.

[0093] In the context of software development and architecture design, functional components (Building Blocks) refer to independent, reusable software modules or service units that can implement specific functions or sub-functions. They serve as the cornerstones for building complex applications or platforms. By combining and configuring these pre-designed and tested components, developers can quickly build solutions that meet specific business needs without having to write all the code from scratch.

[0094] In actual applications, users initiate service deployment requests through unique identifiers. The request carries a detailed description of the target service, including its constituent functional components. These functional components, as the basic units for implementing various sub-functions of the target service, have been prepared in advance in the code repository or service market of the serverless architecture. Each component encapsulates specific logic, such as data processing, interface calls, etc. After the platform captures the request, it first verifies the user identity to ensure the legality and security of the operation. Based on the user identity, the platform accesses and confirms the user's resource permissions on the cloud platform and the corresponding "cloud room" configuration. This "cloud room" is a collection of resources isolated and prepared for the user, aiming to maintain the independence and security of service operation. Next, the platform intelligently identifies and extracts the necessary functional components based on the service description information. These components can involve different business logic fragments, such as user authentication, data encryption, API calls, etc., and they are accurately selected according to service requirements. The platform uses the characteristics of the serverless architecture to efficiently obtain these functional components from the cloud resource pool without the need for users to manually configure the underlying infrastructure. Subsequently, the platform automatically deploys these functional components to the user's corresponding "cloud room". This process includes but is not limited to configuring the execution environment, setting permission control, establishing communication links between components, and adjusting resource allocation according to the parameters in the service description information. Each functional component is properly placed and configured in the cloud environment to ensure that they can work together to support the overall functionality of the target service. Finally, all components are integrated in the "cloud room", and the target service is successfully deployed and ready to respond to user requests or be triggered by preset events. In this way, the serverless architecture not only accelerates the deployment and iteration of services, but also ensures efficient use of resources and simplified operation and maintenance, allowing users to focus on business logic rather than infrastructure management.

[0095] Based on this, functional components can be dynamically managed and deployed according to user identification, and target services that meet user needs can be built, thereby realizing personalized service deployment and management.

[0096] Furthermore, before obtaining at least one target functional component in a serverless architecture based on the service description information, it also includes: creating a service function in response to function description information sent by a front-end user, wherein the function description information includes a function name; receiving component description information sent by the front-end user, wherein the component description information includes a function name and a construction method of at least one service function; determining a function to be constructed based on the function name of at least one service function; and constructing the function to be constructed as a functional component based on the construction method, wherein the construction method is a triggering method of at least one service function in the functional component.

[0097] The build method refers to the specific method of defining how to organize and package elements such as code, dependencies, and configuration to form executable services or functional components. The build method not only includes the steps of code compilation or interpretation, but also involves how to design the service trigger mechanism, resource allocation, and environment configuration based on business logic and architecture requirements. Different build methods are suitable for different application scenarios to meet the requirements of efficiency, maintainability, and scalability.

[0098] In actual applications, users first submit the description information of functions and components to the platform through the front-end interface or API. Among these information, the function description information at least contains the name of the function and defines the specific operation to be performed; while the component description information, based on the listing of at least one service function name, further explains how these functions are combined and their triggering methods, that is, how to respond to specific events or requests to execute service logic. The specific process includes: the platform first parses the function description information, verifies its legitimacy based on the provided function name, and prepares to create a service function. At the same time, the component description information is analyzed to understand the user's expected functional component structure and the interaction mode of the internal service function. According to the function name, the platform creates the corresponding service function on the serverless architecture platform. This includes configuring the execution environment, defining input and output parameters, setting the runtime language and dependencies, etc., laying the foundation for the subsequent construction of functional components. According to the construction method in the component description information, the platform determines how to organize and service functions and sets the corresponding trigger mechanism. The triggering method can include HTTP requests, scheduled tasks, message queue events, etc., to ensure that the service function can be activated at the appropriate time or under the appropriate conditions. Using the created service functions and the specified construction method, the platform integrates these service functions into one or more functional components. This involves configuring dependencies between functions, data flow, and error handling logic so that the component can work as a whole and perform predetermined tasks based on preset events or request patterns.

[0099] Based on this, functional components can be dynamically created and configured according to user needs, enabling flexible service construction and deployment to support diverse service functions and triggering methods.

[0100] Furthermore, after the target service is deployed in the cloud room corresponding to the front-end user, it also includes: receiving a task processing request for the target service, wherein the specific task processing request includes a task type identifier, a service identifier of the target service and task description information; based on the task type identifier, determining the task function module under the serverless architecture, wherein the task function module is designed to perform logical and data interaction with the service in the cloud room; scheduling the task function module, and executing the task for the target service based on the task description information and the service identifier.

[0101] In actual applications, under the serverless architecture, users initiate requests through the front-end application. This request contains detailed information about a specific task, such as the task type identifier, the service identifier of the target service, and the specific description information of the task. For example, a request can indicate that the data of a specific user needs to be analyzed and processed. After receiving the request, the cloud room first parses the task type identifier to determine which task function module to call to process the task. According to the task type identifier, the platform automatically matches the corresponding task function module. For example, if the task type is "data processing", it can match the module that specializes in processing data processing logic; if it is "application update", it can schedule the APP life cycle management module. The advantage of the serverless architecture is that it can quickly and on-demand schedule resources. The platform dynamically starts or allocates appropriate computing resources to the corresponding task function module according to the task requirements without manual intervention. The selected task function module interacts with the target service in the cloud room logically and data based on the task description information and service identifier. For example, if the task is to check the health of the service through the monitoring module, the module will access the relevant service status and logs and execute the health check logic.

[0102] Examples of task module functions are as follows: APP lifecycle management module: responsible for application deployment, update, rollback and other operations. Cloud resource management module: automatically adjusts resource allocation to ensure sufficient computing and storage resources when executing tasks. Monitoring module: collects performance indicators of target services, monitors task execution status, and promptly detects and reports anomalies. Billing module: records resources consumed during task execution for billing and cost analysis. Log module: collects task execution logs for troubleshooting and auditing. Certificate management module: ensures the security of all services and data transmission involved in task execution, and manages SSL / TLS certificates. Development module: provides APIs or SDKs to support developers in writing task processing logic. Network policy module: configures network access control to ensure that secure network policies are followed during task execution.

[0103] After the task is completed, the relevant results or status information will be fed back to the front-end application or user through the cloud room, completing the closed loop of the user's request. Detailed records of all task executions will be saved for subsequent performance analysis, troubleshooting and optimization.

[0104] Based on this, the corresponding task function modules can be dynamically scheduled and executed according to the user's task request, realizing flexible processing and management of target services. This architecture can effectively support multiple task types and complex business logic requirements, while ensuring the efficiency and scalability of the platform in a serverless environment.

[0105] Furthermore, the task type identifier includes a resource management identifier, the task function module includes a resource management module, the resource management module includes a management sub-module for managing different resources; the task function module is scheduled, and based on the task description information and the service identifier, tasks for the target service are executed, including: determining the resource type based on the resource management identifier; determining the corresponding management sub-module based on the resource type; determining the current target resource of the target service based on the service identifier and the resource type; and scheduling the management sub-module to execute resource management tasks for the target resource.

[0106] In actual applications, under the serverless architecture, a request is first received from the frontend, which contains a task type identifier, which specifically indicates that it is a resource management-related task, as well as a service identifier and detailed task description information about the target service. For example, a task may be to request an increase in memory resources for a specific service. The platform parses the task type identifier, identifies that this is a resource management task, and further refines it to specific resource types, such as the adjustment of computing resources, storage resources, or network resources. Based on the determined resource type, the platform automatically matches and selects the corresponding management submodule under the resource management module. For example, if the task involves increasing computing resources (CPU or memory), the corresponding computing resource management submodule will be selected. Next, the platform uses the service identifier and resource type to accurately locate the specific resources currently being used by the target service. This includes identifying the specific cloud room where the service is located, the service instance, and the resource configuration. The resource management submodule is scheduled for execution and manages the target resources according to the specific instructions in the task description information. For example, if the task is to increase memory, the submodule will automatically adjust the memory configuration of the target service instance to ensure that the service can obtain more resources to cope with higher load requirements. After the operation is completed, the resource management submodule will confirm the results of the resource adjustment and feedback to the original requester through the platform. The feedback results include the new resource configuration details; if there are any exceptions or failures in the task, the corresponding error information will also be provided. The entire resource management task execution process, including request information, operation steps, result status, etc., will be recorded for auditing and troubleshooting. At the same time, resource changes will also be captured by the monitoring platform to ensure the stable operation of the service after resource adjustment.

[0107] Based on this, the resource management module can be dynamically managed and scheduled according to the task type identifier and service identifier, so as to realize the flexible management and optimization of the resources required for the target service. This method ensures the effective utilization and efficient operation of resources in the serverless architecture.

[0108] Furthermore, the task type identifier includes an operation and maintenance monitoring identifier, and the task function module includes an operation and maintenance module; a task function module is scheduled, and based on the task description information and the service identifier, tasks for the target service are executed, including: a scheduling operation and maintenance module, and execution of operation and maintenance tasks for the target service based on the task description information, wherein the operation and maintenance task is a task for editing the target service logic.

[0109] In actual applications, under the serverless architecture, the platform receives an operation and maintenance monitoring task request sent by the front-end or back-end, which contains an operation and maintenance monitoring identifier, indicating that this is an operation and maintenance task related to service logic editing. The request also includes the service identifier of the target service and detailed description information of the service, such as the current status of the service, the specific logic that needs to be modified, etc. The platform parses the operation and maintenance monitoring identifier in the task and identifies the nature of the operation and maintenance task. At the same time, the task description information is carefully analyzed to understand the specific requirements of the operation and maintenance task, such as whether it is necessary to add new functional logic, fix existing logic vulnerabilities, or optimize performance. Based on the nature of the task, the platform automatically schedules the operation and maintenance module to intervene. In the serverless architecture, the operation and maintenance module can integrate a set of Web integrated development environment (WebIDE), allowing users to directly access and edit the code logic of the target service through the Web interface without the need for local development environment configuration. The operation and maintenance module ensures that the current operating user has the permission to edit the target service based on the service identifier. After the permission verification is passed, the user securely accesses the cloud environment where the target service is located through WebIDE to view and edit the service code. The user directly edits the logic code of the target service in WebIDE to add, modify, or delete operations. WebIDE provides development assistance functions such as code highlighting, syntax checking, and version control to ensure that the editing process is efficient and accurate. After editing is completed, the operation and maintenance module provides a preview function, allowing users to view the effects of logic changes before deployment, and even test in a sandbox environment to ensure that the modifications are correct and will not affect the stability of existing services. After confirmation, the user submits the changes through WebIDE. The operation and maintenance module automatically performs code checking, building, packaging and other processes, and based on the characteristics of the serverless architecture, quickly deploys the updated service logic to the target cloud environment. The entire process does not require manual configuration of the server or environment. After deployment is complete, the operation and maintenance module and the monitoring platform automatically monitor the service operation status to ensure the normal operation of the service after the logic update. Any abnormalities or performance changes will be fed back immediately, facilitating rapid response and adjustment.

[0110] Based on this, the operation and maintenance modules can be dynamically scheduled and executed according to user requests, and the target service logic can be flexibly edited and managed. This architecture helps maintain the stability and performance of the service, while supporting the operation and maintenance team to effectively manage the running status and logical configuration of the service in a serverless environment.

[0111] Furthermore, after the target service is deployed in the cloud room corresponding to the front-end user, it also includes: receiving a service call request sent by the front-end user, wherein the service call request includes a service identifier; and calling the service corresponding to the service identifier in the cloud room of the front-end user.

[0112] In actual applications, under the serverless architecture, the front-end user sends a service call request to the service management platform under the serverless architecture through the front-end interaction module. The platform first verifies the legitimacy of the request, including checking the source of the request, the user identity, and the validity of the access token to ensure that the request comes from an authorized front-end user and that the user has the right to call the specified service. After the request is verified, the platform parses the service identifier to determine the specific service and its version requested by the user. This step is key to the subsequent call process because it guides the platform to find the correct service instance. Based on the identity of the front-end user, the platform identifies and enters the "cloud room" corresponding to the user. This "cloud room" is the user's exclusive resource space on the cloud platform, which contains all the services deployed by the user and their configurations. In the "cloud room", the platform finds the corresponding service instance based on the service identifier. In the serverless architecture, this usually means triggering one or more serverless functions (such as AWS Lambda functions, Azure Functions, etc.), which directly respond to specific events or API calls. After the service instance is triggered, the platform executes the logic of the service, which can involve data processing, API calls, interactions with other services, etc. The execution environment of the service logic has been configured in advance according to the service description information, ensuring the resources and environment required for the service to run. After the service processes the request, it returns the processing results to the front-end user through the platform. This can include data, status code, error information, etc. The platform ensures the security and efficiency of data transmission, such as using encrypted transmission. During the entire service call process, the platform automatically records operation logs, monitors the status and performance indicators of service execution, and provides data support for subsequent troubleshooting, performance optimization and auditing.

[0113] Based on this, the target service can be dynamically called according to the user's service call request, realizing flexible calling and management of services. This method can support front-end users to interact with various services in the cloud environment and meet the service needs in different business scenarios.

[0114] An embodiment of this specification implements receiving a service deployment request sent by a front-end user, wherein the service deployment request includes service description information and a user identifier, calling cloud resources under a serverless architecture based on the service description information to build a target service, and deploying the target service in a cloud room corresponding to the front-end user based on the user identifier. It combines the fully automatic solution required for quick-start serverless developers, and provides developers with an application perspective for managing cloud resources from code to the cloud. It implements personalized service deployment, fully utilizes the elastic resources of the serverless architecture, ensures the reliability and stability of the deployed service, and brings a convenient and efficient user experience to developers and users.

[0115] See also Figure 2 , Figure 2 This is a service deployment interaction diagram of a service management platform under a serverless architecture provided by an embodiment of the present specification. The service management platform under the serverless architecture includes: a front-end interaction module for receiving a service deployment request sent by a front-end user, wherein the service deployment request includes service description information; a back-end processing module for invoking cloud resources under the serverless architecture based on the service description information to build a target service; and deploying the target service in a cloud room corresponding to the front-end user.

[0116] Specifically, the front-end interaction module is responsible for receiving the service deployment request sent by the front-end user, where the service deployment request includes service description information, and sending the service description information to the back-end processing module. The back-end processing module includes multiple functional modules: APP lifecycle management module, cloud resource management module, monitoring module, billing module, log module, certificate management module, development module and network policy module. After the back-end processing module information, the corresponding functional module can be scheduled according to the specific content of the service description information, and the corresponding code can be extracted from the pre-integrated code repository. The application is packaged and deployed through the integrated packaging service, or the front-end interaction module interacts with the back-end processing module to obtain the functional components that respond to the service description information and send them to the user's cloud room.

[0117] See also Figure 3 , Figure 3This is a service application interaction diagram of a service management platform under a serverless architecture provided by an embodiment of the present specification, which specifically includes three service application methods: ① The front-end interaction module receives the code information input by the user through the development interface and forwards it to the back-end processing module. The back-end processing module triggers the corresponding function calculation according to the code information input by the user; ② The front-end interaction module receives the data processing request input by the user through the front-end interaction interface and forwards it to the back-end processing module. The back-end processing module calls the serverless application engine to perform the corresponding data processing task. The data processing task may specifically include: calling the function calculation unit for calculation, accessing the relational database for data query, or calling the function calculation unit to encrypt the data and then store it in a database such as an object storage service; ③ The front-end interaction module receives the service call request input by the user through the front-end interaction interface and forwards it to the back-end processing module. The back-end processing module calls the services deployed by the shared cloud according to the service identifier, such as container image service, log service, application monitoring service, etc.

[0118] See also Figure 4 , Figure 4 is a schematic diagram of an interface of a service management platform under a first serverless architecture provided by an embodiment of this specification. Figure 4 The following is the user interface for creating a new cloud APP on the service management platform under the serverless architecture, including: the management selection area of ​​the management platform, Figure 4 The cloud APP control under serverless management is selected in the management platform; the cloud APP display area includes the created first cloud APP, second cloud APP, third cloud APP, fourth cloud APP and create cloud APP control; the edit cloud APP area covering the cloud APP display area includes basic information such as the name of the cloud APP, the associated management platform, cloud service provider, function description, and corresponding input bars and selection bars for users to enter or select, and also includes the cloud room selection bar of the cloud APP in the development environment, test environment, acceptance environment, and production environment.

[0119] See also Figure 5 , Figure 5 is a schematic diagram of an interface of a service management platform under a second serverless architecture provided by an embodiment of this specification. Figure 5 The following is a user interface for editing an existing cloud APP on a service management platform under a serverless architecture, including: Figure 4 The management selection area and cloud APP display area of ​​the same management platform, where you click the "..." control of any cloud APP in the cloud APP display area ( Figure 5 Taking the First Cloud app as an example), the edit control and delete control will be displayed. If you select the edit control, the Figure 4 In the Edit Cloud App area, if you select Delete control, the cloud app will be deleted.

[0120] See also Figure 6 , Figure 6 is a schematic diagram of an interface of a service management platform under a third serverless architecture provided by an embodiment of this specification. Figure 6 Shown is the details interface of the First Cloud APP, specifically including: the basic information area of ​​the First Cloud APP, including the name of the First Cloud APP, the cloud room, cloud service provider, associated management platform, creation user, creation time, description and other basic information; the function list area of ​​the First Cloud APP, including creation function controls, import function controls, and a list of function information including function name, function type, creation user, creation time, function description behavior records and other function information.

[0121] See also Figure 7 , Figure 7 is a schematic diagram of an interface of a service management platform under a fourth serverless architecture provided by an embodiment of this specification. Figure 7 For selection Figure 6 The user interface displayed after selecting a function and then selecting Create Function Control specifically includes: a basic information area, including an input field for the function name, an input field for the function description, and optional controls for the trigger type, including an event trigger control and a web page trigger control.

[0122] See also Figure 8 , Figure 8 is a schematic diagram of an interface of a fifth service management platform under a serverless architecture provided by an embodiment of this specification. Figure 7 For selection Figure 6 Select a function and then select Create Function Control to display the user interface. Generally, Figure 8 and Figure 7 The interface can be the same interface, specifically including: code information area, including the selection bar of code running environment, the selection bar of code repository type, such as selecting to create a new code repository or import an existing code repository, and the selection bar of trigger. It can be understood that if you select Create a new code repository as the code repository type, Figure 8 The "..." area in the code repository creation window will display specific information about the creation of the code repository. If you choose to import an existing code repository as the code repository type, Figure 8 The "..." area in the code repository import window will display specific information related to the code repository import.

[0123] See also Fig. 9 , Fig. 9 It is an interface diagram of the service management platform under the sixth serverless architecture provided by an embodiment of this specification, specifically including: the first cloud APP is not a historical display area, including the time of each deployment, the deployer and the corresponding code repository.

[0124] See also Fig.10 , Fig.10 is a schematic diagram of an interface of a service management platform under a seventh serverless architecture provided by an embodiment of this specification, Fig.10 The following is the configuration interface of the service management platform under the serverless architecture, which includes: certificate management control and permission management control. Fig.10 The Credential Management control is selected, showing the current user's username and personal access token.

[0125] See also Fig.11 , Fig.11 is a schematic diagram of an interface of an eighth service management platform under a serverless architecture provided by an embodiment of this specification, Fig.11 The following is the configuration interface of the service management platform under the serverless architecture, which includes: certificate management control and permission management control. Fig.10 The permission management control is in the selected state, and the selection bar of the cloud APP is displayed. After selecting a specific cloud APP in the selection bar, the users who currently have permission to use and edit the cloud APP will be displayed. Click the "⊕ Add permission" control to choose to add permission users.

[0126] Corresponding to the above method embodiment, this specification also provides a service management device embodiment under a serverless architecture. Fig.12 Schematic diagram of a service management device in a serverless architecture provided by an embodiment of this specification. Fig.12 As shown, the device comprises:

[0127] The receiving module 1220 is configured to receive a service deployment request sent by a front-end user, wherein the service deployment request includes service description information and a user identifier.

[0128] The calling module 1240 is configured to call the cloud resources in the serverless architecture to build the target service based on the service description information.

[0129] The deployment module 1260 is configured to deploy the target service in the cloud room corresponding to the front-end user based on the user identifier.

[0130] Optionally, the device also includes a management module, configured to receive a task processing request for a target service, wherein the specific task processing request includes a task type identifier, a service identifier of the target service, and task description information; based on the task type identifier, determine the task function module under the serverless architecture, wherein the task function module is designed to perform logical and data interaction with the service in the cloud room; schedule the task function module, and execute the task for the target service based on the task description information and the service identifier.

[0131] Optionally, the task type identifier includes a resource management identifier, the task function module includes a resource management module, the resource management module includes a management sub-module for managing different resources, and the management module is further configured to determine the resource type based on the resource management identifier; determine the corresponding management sub-module based on the resource type; determine the current target resource of the target service based on the service identifier and the resource type; and schedule the management sub-module to execute resource management tasks for the target resources.

[0132] Optionally, the task type identifier includes an operation and maintenance monitoring identifier, and the task function module includes an operation and maintenance module; the management module is further configured to schedule the operation and maintenance module to execute the operation and maintenance task for the target service based on the task description information, wherein the operation and maintenance task is a task of editing the target service logic.

[0133] Optionally, the service description information includes a target service environment; the device also includes a creation module configured to create a corresponding cloud room based on at least one service environment set by a front-end user; accordingly, the deployment module 1260 is further configured to deploy the target service in the cloud room corresponding to the target service environment.

[0134] Optionally, the cloud resources are code resources in a code repository under a serverless architecture, and the calling module 1240 is further configured to obtain the target service code in the code repository under the serverless architecture based on the service description information; and schedule the code encapsulation service under the serverless architecture to encapsulate the target service code into a target service.

[0135] Optionally, the target service includes at least one functional component, the cloud resources are functional components under the serverless architecture, and the deployment module 1260 is further configured to send at least one functional component to the cloud room corresponding to the front-end user based on the user identifier, wherein at least one functional component is obtained under the serverless architecture based on the service description information, and at least one functional component is used to implement a sub-function of the target service.

[0136] Optionally, the deployment module 1260 is further configured to create a service function in response to function description information sent by a front-end user, wherein the function description information includes a function name; receive component description information sent by the front-end user, wherein the component description information includes a function name and a construction method of at least one service function; determine a function to be constructed based on the function name of at least one service function; and construct the function to be constructed into a functional component based on the construction method, wherein the construction method is a triggering method of at least one service function in the functional component.

[0137] Optionally, the device also includes an application module, which is configured to receive a service call request sent by a front-end user, wherein the service call request includes a service identifier; and call a service corresponding to the service identifier in the cloud room of the front-end user.

[0138] Through the service management device under the serverless architecture, it is possible to receive service deployment requests sent by front-end users, wherein the service deployment requests include service description information and user identification, call cloud resources under the serverless architecture based on the service description information to build the target service, and deploy the target service in the cloud room corresponding to the front-end user based on the user identification. It combines the fully automatic solution required for quick-start serverless developers, and provides developers with an application perspective for managing cloud resources from code to the cloud. It realizes personalized service deployment, fully utilizes the elastic resources of the serverless architecture, ensures the reliability and stability of the deployed service, and brings convenient and efficient use experience to developers and users.

[0139] The above is a schematic scheme of a service management device under a serverless architecture of this embodiment. It should be noted that the technical scheme of the service management device under the serverless architecture and the technical scheme of the service management method under the serverless architecture belong to the same concept, and the details not described in detail in the technical scheme of the service management device under the serverless architecture can be referred to the description of the technical scheme of the service management method under the serverless architecture.

[0140] Fig.13 The block diagram of a computing device 1300 according to one embodiment of the present specification is shown. The components of the computing device 1300 include but are not limited to a memory 1310 and a processor 1320. The processor 1320 is connected to the memory 1310 via a bus 1330, and the database 1350 is used to store data.

[0141] The computing device 1300 also includes an access device 1340, which enables the computing device 1300 to communicate via one or more networks 1360. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 1340 may include one or more of any type of network interface (e.g., a network interface card (NIC)) of wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a world-wide interoperability for microwave access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, and a near field communication (NFC).

[0142] In one embodiment of the present specification, the above components of the computing device 1300 and Fig.13 Other components not shown in the figure may also be connected to each other, for example, via a bus. It should be understood that Fig.13 The computing device structure block diagram shown is only for the purpose of illustration, and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0143] The computing device 1300 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smart phone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or a personal computer (PC). The computing device 1300 may also be a mobile or stationary server.

[0144] Among them, the processor 1320 is used to execute the following computer program / instructions, which, when executed by the processor, implement the steps of the service management method under the above-mentioned serverless architecture.

[0145] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the computing device embodiment, since it is basically similar to the service management method embodiment under the serverless architecture, the description is relatively simple, and the relevant parts can be referred to the partial description of the service management method embodiment under the serverless architecture.

[0146] An embodiment of the present specification also provides a computer-readable storage medium storing a computer program / instruction, which implements the steps of the service management method under the above-mentioned serverless architecture when executed by a processor.

[0147] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the computer-readable storage medium embodiment, since it is basically similar to the service management method embodiment under the serverless architecture, the description is relatively simple, and the relevant parts can be referred to the partial description of the service management method embodiment under the serverless architecture.

[0148] An embodiment of the present specification also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the service management method under the above-mentioned serverless architecture.

[0149] The above is a schematic scheme of a computer program product of this embodiment. It should be noted that the technical scheme of the computer program product and the technical scheme of the service management method under the serverless architecture described above belong to the same concept, and the details not described in detail in the technical scheme of the computer program product can be found in the description of the technical scheme of the service management method under the serverless architecture described above.

[0150] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0151] The computer instructions include computer program codes, which may be in source code form, object code form, executable files or some intermediate forms, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0152] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0153] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0154] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The optional embodiments do not describe all the details in detail, nor do they limit the invention to only the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that technicians in the relevant technical field can well understand and use this specification. This specification is only limited by the claims and their full scope and equivalents.

Claims

1. A service management method under a serverless architecture, characterized in that: include: Receiving a service deployment request sent by a front-end user, wherein the service deployment request includes service description information and a user identifier; Based on the service description information, cloud resources in a serverless architecture are called to build a target service; The target service is deployed in the cloud room corresponding to the front-end user based on the user identifier.

2. The method according to claim 1, characterized in that After the target service is deployed in the cloud room corresponding to the front-end user, the method further includes: Receiving a task processing request for the target service, wherein the specific task processing request includes a task type identifier, a service identifier of the target service, and task description information; Based on the task type identifier, determining a task function module under the serverless architecture, wherein the task function module is designed to perform logic and data interaction with the service in the cloud room; The task function module is scheduled, and the task for the target service is executed based on the task description information and the service identifier.

3. The method according to claim 2, characterized in that The task type identifier includes a resource management identifier, the task function module includes a resource management module, and the resource management module includes a management submodule for managing different resources; the scheduling of the task function module and executing the task for the target service based on the task description information and the service identifier includes: Determining a resource type based on the resource management identifier; Determine a corresponding management submodule based on the resource type; Determining a current target resource of the target service based on the service identifier and the resource type; The management submodule is scheduled to execute a resource management task for the target resource.

4. The method according to claim 2, characterized in that: The task type identifier includes an operation and maintenance monitoring identifier, and the task function module includes an operation and maintenance module; the scheduling of the task function module and executing the task for the target service based on the task description information and the service identifier include: The operation and maintenance module is scheduled to perform an operation and maintenance task for the target service based on the task description information, wherein the operation and maintenance task is a task of editing the logic of the target service.

5. The method according to claim 1, characterized in that The service description information includes a target service environment; Before calling the cloud resources in the serverless architecture to build the target service based on the service description information, the method includes: Creating a corresponding cloud room according to at least one service environment set by the front-end user; The step of deploying the target service in the cloud room corresponding to the front-end user includes: The target service is deployed in a cloud room corresponding to the target service environment.

6. The method according to claim 1, characterized in that The cloud resources are code resources in a code repository under a serverless architecture; The calling of cloud resources in a serverless architecture to build a target service based on the service description information includes: Based on the service description information, obtain the target service code in the code repository under the serverless architecture; The code encapsulation service under the serverless architecture is scheduled to encapsulate the target service code into a target service.

7. The method according to claim 1, characterized in that The target service includes at least one functional component, and the cloud resource is a functional component under a serverless architecture; and deploying the target service in a cloud room corresponding to the front-end user based on the user identifier includes: Based on the user identifier, the at least one functional component is sent to the cloud room corresponding to the front-end user, wherein the at least one functional component is obtained under a serverless architecture based on the service description information, and the at least one functional component is used to implement the sub-function of the target service.

8. The method according to claim 7, characterized in that Before acquiring at least one target functional component in a serverless architecture based on the service description information, the method further includes: In response to the function description information sent by the front-end user, creating a service function, wherein the function description information includes a function name; Receiving component description information sent by the front-end user, wherein the component description information includes a function name and a construction method of at least one service function; Determining a function to be constructed based on a function name of the at least one service function; The function to be constructed is constructed as a functional component based on the construction method, wherein the construction method is a triggering method of the at least one service function in the functional component.

9. The method according to claim 1, characterized in that: After the target service is deployed in the cloud room corresponding to the front-end user, the method further includes: Receiving a service call request sent by the front-end user, wherein the service call request includes a service identifier; The service corresponding to the service identifier is called in the cloud room of the front-end user.

10. A service management platform under a serverless architecture, characterized in that: include: The front-end interaction module is used to receive a service deployment request sent by a front-end user, wherein the service deployment request includes service description information; The back-end processing module is used to call the cloud resources under the server-less architecture to build a target service based on the service description information; and deploy the target service in the user cloud room corresponding to the front-end user.

11. A computing device, characterized in that: include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer program / instructions are executed by the processor, the steps of the service management method under the serverless architecture described in any one of claims 1-9 are implemented.

12. A computer-readable storage medium, characterized in that: It stores computer programs / instructions, which, when executed by a processor, implement the steps of the service management method under the serverless architecture described in any one of claims 1-9.

13. A computer program product, characterized in that It includes a computer program / instruction, which, when executed by a processor, implements the steps of the service management method under the serverless architecture described in any one of claims 1-9.

Images