Carbon emission calculation system based on server-free architecture technology

Abstract

The invention discloses a carbon emission calculation system based on a server-free architecture technology. The system adopts a three-layer architecture including an access layer, a control platform and an execution platform. The access layer includes an event source processor for monitoring an external event trigger and / or a user's computing request, and sending a carbon emission computing message to a scheduler of the control platform based on the monitored external event trigger and / or the received user's computing request, the message carrying a computing parameter and a computing target. And a scheduler of the control platform selects a target function instance from a plurality of function instances stored in the system according to the calculation target, and transmits the calculation parameters and the target function instance to a function operation container of the execution platform. And the function operation container calculates the carbon emission according to the target function instance and the parameters. According to the server-free architecture, resources can be automatically expanded or reduced according to calculation requirements, the utilization rate of the resources is optimized, and the operation cost is reduced.

Description

Technical Field

[0001] The present application relates to the field of carbon energy emission technology, and in particular to a carbon emission calculation system based on serverless architecture technology. Background Art

[0002] Carbon emission calculation refers to the process of quantitatively calculating and evaluating the greenhouse gases (such as carbon dioxide and methane) released by various activities or products in various industries (such as the energy industry and the steel industry) during production, transportation, consumption, etc. By calculating carbon emissions, we can evaluate the contribution of different activities to climate change and environmental impacts, help companies better understand and manage their carbon footprint, formulate emission reduction strategies, and promote sustainable development.

[0003] Current carbon emission calculation systems usually use Web (WorldWide Web) services or microservices architecture to provide computing services. However, this architecture has a common problem: when there is no computing request, the server continues to occupy resources, causing the resources to be idle. This situation not only wastes resources, but also increases unnecessary operating costs. The server is in operation for a long time, even if there is no actual computing task to be processed, it will continue to consume energy and maintenance costs, thus bringing economic burden to the enterprise.

[0004] Therefore, how to reduce server resource usage when making carbon-free computing requests to avoid resource waste and unnecessary operating costs is a technical problem that technicians in this field urgently need to solve. Summary of the invention

[0005] Based on the above problems, the present application provides a carbon emission calculation system based on serverless architecture technology, which can reduce server resource usage when there is no carbon emission calculation request to avoid resource waste and unnecessary operating costs.

[0006] The embodiments of the present application disclose the following technical solutions:

[0007] A carbon emission calculation system based on serverless architecture technology, the system comprising: an access layer, a control platform and an execution platform; the access layer comprises an event source processor; the control platform comprises a scheduler; the execution platform comprises a function running container;

[0008] The event source processor is connected to the scheduler; the scheduler is connected to the function execution container;

[0009] The event source processor is used to monitor external event triggers and / or receive user calculation requests, and send a carbon emission calculation message to the scheduler based on the monitoring of external event triggers and / or receiving user calculation requests; the carbon emission calculation message carries calculation parameters and calculation targets;

[0010] The scheduler is configured to determine a target function instance from multiple function instances stored in the system based on the calculation target carried in the received carbon emission calculation message, and send the calculation parameters and the target function instance to the function execution container;

[0011] The function running container is used to calculate the carbon emissions based on the calculation parameters on the target function instance to obtain the carbon emissions.

[0012] In a possible implementation, the function runs the container and is further used to:

[0013] Feeding back the carbon emissions to the trigger that triggers the external event, and deleting the carbon emissions from the function running container; or,

[0014] The carbon emissions are fed back to the client that sends the calculation request, and the carbon emissions are deleted in the function running container.

[0015] In a possible implementation, the access layer further includes an application programming interface gateway APIGateway; the API Gateway is connected to the event source processor;

[0016] The API Gateway is used to:

[0017] Authenticating a trigger that triggers the external event and / or authenticating a client that sends the computing request;

[0018] When the identity authentication is passed, the event source processor is triggered to send a carbon emission calculation message to the scheduler based on the monitoring of external event triggers and / or receiving a user's calculation request.

[0019] In a possible implementation, the access layer further includes a command line interface CLI tool; the CLI tool is connected to the event source processor;

[0020] The CLI tool is used to generate the carbon emission calculation message based on the monitoring of external event triggers and / or receiving a calculation request from a user.

[0021] In a possible implementation, the control platform further includes a routing manager; the routing manager is connected to the scheduler;

[0022] The routing manager is used to:

[0023] Analyzing the industry category to which the carbon emission calculation message belongs based on the calculation target of the carbon emission calculation message;

[0024] Determining whether the function instance applied to the industry category to which the carbon emission calculation message belongs is stored in the system;

[0025] If yes, the scheduler is triggered to execute the step of determining a target function instance from multiple function instances based on the calculation target carried in the received carbon emission calculation message.

[0026] In a possible implementation, the system further includes a monitoring unit; the monitoring unit is connected to the function execution container;

[0027] The monitoring unit is used to monitor the running status and key indicators of the function instance running in the function running container; the key indicators include the execution time of the function instance, the running execution error rate of the function instance and the throughput of the function instance.

[0028] In a possible implementation, the control platform further includes a configuration center; the configuration center is connected to the function management component;

[0029] The configuration center is used to manage the function instance and the configuration information of the system.

[0030] In a possible implementation, the system further includes a storage unit; the storage unit is connected to the scheduler;

[0031] The storage unit is used to store the multiple function instances.

[0032] In a possible implementation, the control platform further includes a function management component; the function management component is connected to the storage unit;

[0033] The function management component is used to maintain the life cycle of the function instance; the life cycle of the function instance includes the creation operation, update operation and deletion operation of the function instance.

[0034] In a possible implementation, the execution platform further includes a resource isolation component; the resource isolation component is connected to the function execution container;

[0035] The resource isolation component is used to isolate different function instances in the function execution container.

[0036] Compared with the prior art, this application has the following beneficial effects:

[0037] The present application provides a carbon emission calculation system based on serverless architecture technology, which includes an access layer, a control platform and an execution platform. This structural design is intended to effectively manage the carbon emission calculation process. The access layer covers an event source processor, which is connected to the scheduler of the control platform, and the control platform is connected to the function running container in the execution platform. The function of the event source processor is to monitor external event triggers and user calculation requests, and then send carbon emission calculation messages to the scheduler based on these events, which carry calculation parameters and calculation targets. The task of the scheduler is to select a target function instance from multiple function instances stored in the system according to the calculation target in the received message, and pass the calculation parameters and the target function instance to the function running container. The function running container performs calculation operations on the target function instance and calculates the specific carbon emissions using the input calculation parameters. Therefore, in the carbon emission calculation system based on serverless architecture technology of the present application, computing resources are dynamically allocated and started only when there is a calculation request, which avoids the server from continuously occupying resources when there is no request, and significantly reduces resource idleness and waste. At the same time, the event source processor monitors external event triggers and dynamically schedules corresponding computing resources according to computing requests, making the system more flexible and efficient, and avoiding meaningless preheating and continuous occupation of computing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0039] Figure 1 A structural diagram of a carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application;

[0040] Figure 2 An interactive flow chart of a carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application;

[0041] Figure 3 A structural diagram of another carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application;

[0042] Figure 4 A structural diagram of another carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application;

[0043] Figure 5 A structural diagram of another carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application;

[0044] Figure 6 A structural diagram of another carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0046] Web service is a software system interaction mechanism based on network protocols, mainly Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS). It uses standardized communication interfaces and predefined data exchange formats (such as eXtensible Markup Language (XML) and JavaScript Object Notation (JSON)) to achieve remote communication, resource access and function calls between different software applications. This article refers to function calls.

[0047] Current carbon emission calculation systems usually provide computing services based on Web services or microservices architecture, but this architecture has the problem of idle resources: even if there are no computing requests, the server will continue to run, causing waste of resources and additional operating costs, increasing energy consumption and maintenance costs, and bringing economic burdens to enterprises.

[0048] In order to solve this problem, a carbon emission calculation system based on serverless architecture technology is provided in an embodiment of the present application, which includes a three-layer architecture: an access layer, a control platform and an execution platform. The access layer is mainly responsible for receiving external events and user requests, and the layer includes an event source processor. The control platform is mainly responsible for scheduling calculation tasks, including a scheduler. The execution platform is responsible for the actual execution of calculation tasks, including a function running container. The event source processor is connected to the scheduler, and is used to monitor external event triggers and / or receive user calculation requests, and convert these triggers and / or requests into specific carbon emission calculation messages and send them to the scheduler. Each carbon emission calculation message carries calculation parameters and calculation targets, which determine the specific calculation requirements and purposes. After receiving the carbon emission calculation message, the scheduler will select the most suitable target function instance from multiple function instances stored in the system according to the calculation target, and send the calculation parameters and the selected target function instance to the function running container. The function running container then performs a specific carbon emission calculation task based on the received calculation parameters on the selected target function instance, and finally outputs the carbon emissions. The serverless architecture of the present application can automatically expand or reduce resources according to computing needs, optimize resource utilization and reduce operating costs.

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

[0050] See also Figure 1 , Figure 1 This is a structural diagram of a carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application. Figure 1 The carbon emission calculation system based on serverless architecture technology (i.e., serverless) shown in the figure includes an access layer 100, a control platform 110, an execution platform 120, and a storage unit 130; the access layer 100 includes an event source processor 101; the control platform 110 includes a scheduler 111; and the execution platform 120 includes a function running container 121. The event source processor 101 is connected to the scheduler 111; and the scheduler 111 is connected to the function running container 121 and the storage unit 130, respectively.

[0051] Serverless means serverless architecture. Serverless is based on the cloud-native development model. Serverless does not mean that no server is needed. It just focuses on the development implementation itself, while operation, maintenance, expansion and security are provided by the infrastructure.

[0052] See also Figure 2 , Figure 2 An interactive flow chart of a carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application may include the following steps:

[0053] The event source processor 101 monitors external event triggers and / or receives user calculation requests, and sends a carbon emission calculation message to the scheduler 111 based on the monitoring of external event triggers and / or receiving user calculation requests; the carbon emission calculation message carries calculation parameters and calculation targets.

[0054] Specifically, the function of the event source processor 101 is: on the one hand, it monitors the triggering of external events, such as environmental changes inside and outside the system or the start of specific operations; on the other hand, it is also responsible for receiving carbon emission calculation requests from users. When the event source processor 101 detects an external event or receives a user request, it generates and sends a carbon emission calculation message to the scheduler 111. The message contains the parameters required for the calculation (such as emission sources, calculation scope, etc.) and clear calculation targets (such as the expected carbon emissions or calculation methods). This process ensures that the system can respond to external changes or user needs in a timely manner and calculate carbon emissions.

[0055] It should be noted that calculation parameters refer to the input data or conditions required for carbon emission calculation. These parameters may include:

[0056] Type and quantity of emission sources (e.g. energy consumption, vehicle emissions, etc.);

[0057] Emission factor (carbon emissions per unit of activity);

[0058] The calculation period or time range (for example, a specific year or quarter);

[0059] Relevant physical or economic data (such as energy consumption, output, etc.);

[0060] Calculation objective: This refers to the purpose of the calculation or the desired output. For example, the objective may be to calculate the total carbon emissions over a certain period of time. The objective may be to assess the carbon impact of a specific activity or project. It may also be to optimize carbon emissions and set a goal to reduce carbon emissions.

[0061] The definition of the calculation target helps the scheduler 111 to determine the specific calculation method and the target function instance when receiving the calculation request, so as to calculate the carbon emission in the execution platform 120 .

[0062] The scheduler 111 is used to determine a target function instance from multiple function instances stored in the storage unit 130 based on the calculation target carried in the received carbon emission calculation message, and send the calculation parameters and the target function instance to the function execution container 121.

[0063] In the system, the function of the scheduler 111 is to select a suitable target function instance from multiple available function instances according to the calculation target in the received carbon emission calculation message. Then, the scheduler 111 sends the selected target function instance and the corresponding calculation parameters to the function execution container 121 to perform the actual carbon emission calculation.

[0064] Specifically, the working process of the scheduler 111 can be divided into the following steps:

[0065] Receiving calculation message: The scheduler 111 first receives the carbon emission calculation message from the access layer 100. The message includes the calculation target (ie, the specific task to be calculated) and related calculation parameters (such as the data to be input, calculation rules, etc.).

[0066] Parsing the computing target: The scheduler 111 extracts the computing target from the message and analyzes it according to the characteristics of the target (eg, the type of computing task, the computing method, the required resources, etc.).

[0067] Selecting a target function instance: The scheduler 111 selects the most suitable target function instance from the available multiple function instances stored in the storage unit 130 according to the parsed computing target. The selection criteria may include: the execution efficiency, processing capability, task complexity, resource requirements, etc. of the computing function.

[0068] Passing calculation parameters: Once the target function instance is selected, the scheduler 111 will send the calculation parameters (these parameters may include sensor data, user input, etc.) together with the target function instance to the function running container 121 in the execution platform 120.

[0069] Task allocation and resource scheduling: Scheduler 111 not only needs to select the target function instance, but also needs to perform reasonable resource scheduling. If the computing resources in the system are limited, scheduler 111 may dynamically adjust to ensure that the computing tasks are processed in a timely and effective manner.

[0070] Through such a workflow, the scheduler 111 plays a vital role in the system. It can ensure that the carbon emission calculation task intelligently selects appropriate computing resources for processing according to actual needs and resource conditions. The flexibility and intelligence of the scheduler 111 make the entire system have good scalability and efficiency, and can handle different types of carbon emission calculation tasks.

[0071] The storage unit 130 stores a plurality of function instances.

[0072] In the system, the storage unit 130 is a key component responsible for storing multiple function instances. These function instances are predefined calculation logics in the system, each instance represents a specific carbon emission calculation method or algorithm, and can handle different types of calculation tasks.

[0073] Specifically, the functions and effects of the storage unit 130 are as follows:

[0074] (1) Storing multiple function instances

[0075] The storage unit 130 stores multiple function instances, which are predefined carbon emission calculation logics based on different calculation requirements and scenarios. Each function instance has independent computing and processing capabilities, and can perform relevant calculations of carbon emissions based on input parameters. Function instances may include: mathematical models: such as carbon emission calculation formulas based on energy consumption; data processing algorithms: such as sensor data analysis and conversion algorithms; statistical analysis methods: such as algorithms for carbon emission trend analysis based on historical data.

[0076] (2) Function and task division

[0077] The function instances in the storage unit 130 are usually divided by function or task. For example, there may be function instances that specifically calculate carbon emissions in the fields of industrial production, transportation, energy consumption, etc. Each function instance can perform related calculation tasks based on specific input data and calculation targets. This division ensures that the system can select the most suitable function instance for processing according to different carbon emission calculation requirements.

[0078] (3) Easy access and scheduling

[0079] The function instances in the storage unit 130 are managed and accessed by the system's scheduler 111. The scheduler 111 selects a most suitable target function instance from multiple function instances based on the calculation target in the received carbon emission calculation message. This means that the function instances in the storage unit 130 can be quickly called by the scheduler 111 to meet various calculation requirements.

[0080] The function execution container 121 is used to calculate the carbon emissions based on the calculation parameters on the target function instance to obtain the carbon emissions.

[0081] The function running container 121 is used to receive the target function instance and calculation parameters, and perform carbon emission calculation on the target function instance according to the calculation parameters, and finally output the calculated carbon emission. Specifically, the workflow of the function running container 121 can be broken down into the following steps:

[0082] (1) Receive the target function instance and calculation parameters

[0083] When the scheduler 111 determines the appropriate target function instance, it sends the instance together with the required computing parameters to the function execution container 121.

[0084] (2) Loading the target function instance

[0085] After receiving the target function instance, the function execution container 121 will load the corresponding calculation logic according to the definition of the instance. This target function instance can be regarded as a predefined algorithm or calculation model, which is specially used to process a certain type of carbon emission calculation. It may calculate carbon emissions based on existing mathematical models, statistical models, or other algorithms.

[0086] (3) Perform carbon emission calculation based on calculation parameters

[0087] The function execution container 121 inputs the calculation parameters into the target function instance, and then performs the operation according to the calculation logic of the target function. This step is the actual calculation of carbon emissions. For example:

[0088] If the objective function is to calculate the carbon emissions of a particular activity, the container will calculate the emissions based on the parameters of the activity (such as fuel consumption for transportation, energy usage, etc.).

[0089] If the objective function is to calculate the total carbon emissions over a certain period of time, the container will aggregate multiple data points and combine them with the model for summary calculation.

[0090] The calculations may include some complex math, such as estimating emissions based on data such as energy consumption and carbon intensity.

[0091] (4) Output carbon emissions

[0092] After the calculation is completed, the function execution container 121 returns the calculation result (ie, carbon emissions) to the scheduler 111, or directly passes it to subsequent system components. These output results can be specific values, or reports or analysis results after further processing.

[0093] The final carbon emissions may need to be further summarized, displayed or stored, depending on the needs of the application scenario.

[0094] For example, suppose a certain objective function instance is used to calculate the carbon emissions of a factory within a certain period of time. The scheduler 111 will pass this objective function instance and related parameters (such as time range, product type, energy consumption data, etc.) to the function execution container 121 through a message. The container performs model calculations based on these parameters and outputs the total carbon emissions of the factory within the specified time.

[0095] In a possible implementation, the function execution container 121 is further used for:

[0096] Feedback the carbon emissions to the trigger that triggers the external event, and delete the carbon emissions in the function execution container 121; or,

[0097] The carbon emissions are fed back to the client that sends the calculation request, and the carbon emissions are deleted in the function execution container 121.

[0098] Specifically, in addition to performing carbon emission calculation, the function running container 121 also has the following two important functions:

[0099] Feed the carbon emission back to the trigger and delete the carbon emission in the container.

[0100] Feed the carbon footprint back to the client and delete it in the container.

[0101] These functions can be understood as how to process the calculation results (carbon emissions) and manage the data stored in the system after the function running container 121 completes the calculation task. The following is a detailed description of these two parts:

[0102] (1) Feedback carbon emissions to the trigger and delete carbon emissions

[0103] Background: A trigger may be an event monitoring mechanism in the system, which responds to the occurrence of an external event. For example, when a specific external event (such as the occurrence of a production activity or a transportation event) is triggered, the function running container 121 needs to calculate the carbon emissions of the event and return the result.

[0104] Operation process: After the function running container 121 completes the carbon emission calculation, it will feed back the calculation result (carbon emission) to the trigger. The trigger will perform relevant operations based on the feedback result, such as recording the result, triggering subsequent processing flow, or sending it to other system components for analysis and reporting. Once the carbon emission is fed back to the trigger, the function running container 121 will delete the calculation result from the container. This can avoid data redundancy and ensure that the storage space in the container is released in time, thereby improving the efficiency of the system and the real-time nature of the data.

[0105] (2) Feedback the carbon emissions to the client and delete the carbon emissions

[0106] Background: The client may be an external application or user that sends a calculation request to the system and needs to obtain the calculated carbon emissions results. For example, the client can be an environmental monitoring platform, an enterprise management system, or a data analysis tool. The client requests the system to calculate the carbon emissions of a certain activity and expects to get feedback.

[0107] Operation process: After the calculation is completed, the function running container 121 will send the calculated carbon emissions to the client that initiated the request. This is the interactive part with the client to ensure that the calculation results can be used by the end user or system. Once the carbon emissions are fed back to the client, the container will clear the result. This is also to avoid the accumulation of unnecessary data in the storage and keep the system running efficiently.

[0108] The purpose of these two operations:

[0109] Reduce storage burden: By deleting the carbon emission feedback in time, the function running container 121 can avoid the waste of storage resources and maintain efficient use of system memory;

[0110] Ensure the timeliness of data: By immediately deleting the fed-back calculation results, the function running container 121 can prevent old data from affecting new calculations or operations, thereby ensuring the system's response speed and calculation accuracy.

[0111] See also Figure 3 , Figure 3 This is a structural diagram of another carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application. Figure 3 The access layer 100 in the carbon emission calculation system based on the serverless architecture technology shown in the figure also includes an application programming interface gateway 102 (Application Programming Interface Gateway, APIGateway102) and a command line interface (Command Line Interface, CLI) tool. The API Gateway 102 is connected to the event source processor 101; the CLI tool 103 is connected to the event source processor 101.

[0112] The API Gateway 102 is used for:

[0113] Authenticating a trigger that triggers the external event and / or authenticating a client that sends the computing request;

[0114] When the identity authentication is passed, the event source processor 101 is triggered to send a carbon emission calculation message to the scheduler 111 based on the monitoring of external event triggers and / or receiving a user's calculation request.

[0115] Specifically, the API Gateway 102 plays a crucial role in the system, and is responsible for ensuring the security of the system, the correct transmission of data, and the smooth execution of the carbon emission calculation task.

[0116] According to your description, the main functions of API Gateway 102 can be divided into the following aspects:

[0117] The first is identity verification:

[0118] One of the primary functions of API Gateway 102 is to perform authentication, which includes: verifying the triggers that trigger external events and verifying the clients that send computing requests.

[0119] Verify triggers that trigger external events: When an external event (such as sensor data update, user request, etc.) is triggered, API Gateway 102 will first check the legitimacy of the trigger. The trigger may be a specific device, service, or application. API Gateway 102 needs to ensure that these triggers are authorized to prevent unauthorized triggers from interfering with the system.

[0120] Verify the client sending the calculation request: The carbon emission calculation request sent by the client of the system (such as user-side applications, third-party systems, etc.) also needs to be authenticated. API Gateway 102 needs to check whether the identity of the client is legitimate, which can be achieved through API keys, OAuth authentication or other authentication mechanisms.

[0121] The second is to trigger the event source processor 101:

[0122] Once the identity is authenticated, API Gateway 102 passes the external event trigger or computing request to the event source processor 101. The main functions of the event source processor 101 are: monitoring external events and receiving user computing requests.

[0123] Monitoring external events: The event source processor 101 monitors events from different external systems or sensors in real time. If the triggered event meets the preset conditions (for example, the data related to carbon emissions reaches a certain threshold), the event source processor 101 will trigger further calculations.

[0124] Receiving user calculation requests: When a user initiates a calculation request through a client, the event source processor 101 receives and parses the request to confirm the specific carbon emission calculation task that needs to be performed.

[0125] It should be noted that API is a standardized software interface definition that enables heterogeneous systems to exchange data and share functions through predefined protocols, data structures, and interaction methods. API Gateway is a centralized network proxy service that serves as the unified traffic entry point for the system. It is responsible for request routing, forwarding, load balancing, authentication and authorization, traffic control, and monitoring, and provides a unified management and governance mechanism for backend services at the application layer.

[0126] OAuth is a standard authorization protocol that establishes a secure access control model between resource owners, client applications and resource servers through a token mechanism, so as to securely authorize third-party applications to access protected resources without directly exposing user credentials. The CLI tool 103 is used to generate the carbon emission calculation message based on the monitoring of external event triggers and / or receiving user calculation requests.

[0127] Regardless of whether it is triggered by an external event or a calculation request from a user, the CLI tool 103 will generate a corresponding carbon emission calculation message according to preset rules and / or input data.

[0128] These messages will contain sufficient metadata so that other modules of the system (such as scheduler 111, computing engine) can accurately understand and execute corresponding computing tasks.

[0129] It should be noted that the CLI tool is a text-based user interaction paradigm that enables users to directly interact with computer operating systems, software applications or computer systems by entering command instructions with specific syntax in a terminal or console.

[0130] See also Figure 4 , Figure 4 This is a structural diagram of another carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application. Figure 4 The control platform 110 in the carbon emission calculation system based on the serverless architecture technology further includes a routing manager 112, a configuration center 113 and a function management component 114. The routing manager 112 is connected to the scheduler 111; the configuration center 113 is connected to the function management component 114; and the function management component 114 is connected to the storage unit 130.

[0131] The routing manager 112 is used to:

[0132] Analyzing the industry category to which the carbon emission calculation message belongs based on the calculation target of the carbon emission calculation message;

[0133] Determining whether the function instance applied to the industry category to which the carbon emission calculation message belongs is stored in the system;

[0134] If yes, the scheduler 111 is triggered to execute the step of determining a target function instance from multiple function instances based on the calculation target carried in the received carbon emission calculation message.

[0135] Specifically, the role of the routing manager 112 can be broken down into the following key steps and functions:

[0136] (1) Analyze the industry categories to which carbon emission calculation news belongs

[0137] The routing manager 112 will first receive carbon emission calculation messages, which carry relevant information such as calculation targets and industry categories.

[0138] The analysis of industry categories is the primary task of the routing manager 112. It will analyze and determine which industry (such as electricity, steel, etc.) the calculation task involves based on the data in the carbon emission calculation message. The identification of industry categories is the basis for subsequent operations.

[0139] (2) Determine whether there are function instances related to industry categories

[0140] Once the industry category is identified, the routing manager 112 next needs to determine whether there is a function instance applicable to the industry category stored in the system.

[0141] These function instances are usually predefined calculation methods or algorithms. For different industry categories, the system may store multiple function instances for the industry.

[0142] If a function instance suitable for the industry category has been stored in the system, the routing manager 112 can further perform subsequent steps. If there is no corresponding function instance, other logic may be triggered (for example, returning an error or requesting a new function instance).

[0143] (3) Triggering the scheduler 111 to execute the determination of the target function instance

[0144] Once the target function instance is determined, the routing manager 112 triggers the scheduler 111 to execute the determined computing task.

[0145] The scheduler 111 is responsible for assigning computing tasks to corresponding execution units for processing and ensuring that the computing process can proceed smoothly.

[0146] The configuration center 113 is used to manage the function instance and the configuration information of the system.

[0147] The configuration center 113 is a core component for managing function instances and system configuration information. Specifically, the configuration center 113 is responsible for centrally storing and managing configuration information related to system operation to ensure that the system can operate efficiently and flexibly.

[0148] The following is a detailed explanation of the functions of Configuration Center 113:

[0149] (1)Management function instance

[0150] The configuration center 113 is responsible for managing the function instances used in the system. Function instances usually refer to algorithms or logic modules that implement specific functions in the system. In actual applications, these function instances may be managed, updated, and switched in different versions according to business needs. The role of the configuration center 113 is to ensure that the system can load and execute appropriate function instances on demand.

[0151] Storing and registering function instances: The configuration center 113 stores relevant information of various function instances, including the input and output formats, execution logic, parameters, etc. of the function.

[0152] Version control and updates: Function instances may be updated and optimized as the business develops. The configuration center 113 needs to manage these updates and ensure that the system can smoothly transition to the new version.

[0153] Select and execute function instances: Configuration center 113 helps the system dynamically select appropriate function instances to handle specific requests or tasks at runtime, ensuring that the system can flexibly respond to different needs.

[0154] (2) Management system configuration information

[0155] The configuration center 113 is also responsible for managing various configuration information of the system, which is crucial to the overall operation of the system and may include but is not limited to database configuration, service address, performance tuning parameters, resource configuration, etc.

[0156] Global configuration storage: The configuration center 113 stores all system-level configuration information, such as database connection strings, cache configurations, logging settings, etc., to ensure that each module in the system uses a consistent configuration.

[0157] Dynamic configuration update: When the system needs to adjust certain configuration parameters, the configuration center 113 can support dynamic updates to avoid system downtime or restart. For example, adjusting the concurrency limit of a service or modifying the configuration of a computing algorithm can be done directly in the configuration center 113 and take effect immediately.

[0158] Support for multi-environment configuration: Many systems may have multiple operating environments (such as development, testing, production, etc.). The configuration center 113 usually supports configuration management in different environments to ensure that the system configuration in each environment meets its actual needs.

[0159] (3) Collaborative management of function instances and configuration information

[0160] Configuration center 113 not only manages function instances and configuration information, but they are often closely related. In some cases, the execution of a function may depend on specific configuration parameters, and these configuration parameters may also change as the function instance is updated. Therefore, configuration center 113 needs to ensure that the function instance and the configuration information it depends on can work together to ensure that the system can adjust the relevant configuration in time when updating the function, and vice versa.

[0161] Function-configuration correlation: Some function instances may require specific system configurations to execute correctly. The configuration center 113 can manage such dependencies and ensure that the function can obtain the correct configuration support when it is called.

[0162] Unified management and scheduling: In the system, different function instances and configuration combinations may need to be selected according to different business scenarios. The configuration center 113 can achieve unified management of such configurations and function instances to ensure that the system can be flexibly scheduled according to business needs.

[0163] The function management component 114 is used to maintain the life cycle of the function instance; the life cycle of the function instance includes the creation operation, update operation and deletion operation of the function instance.

[0164] The function management component 114 is responsible for maintaining the entire life cycle of the function instance, including creation, update and deletion operations. It effectively manages the state changes of the function instance, ensures that the functions in the system can be dynamically adjusted according to demand, and improves the flexibility and availability of the system.

[0165] See also Figure 5 , Figure 5 This is a structural diagram of another carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application. Figure 5 The execution platform 120 in the carbon emission calculation system based on the serverless architecture technology further includes a resource isolation component 122. The resource isolation component 122 is connected to the function execution container 121.

[0166] The resource isolation component 122 is used to isolate different function instances in the function running container 121 to ensure that they run independently of each other to avoid interference and conflict. This isolation helps to ensure the stability and security of the system, while improving the reliability and efficiency between function instances.

[0167] See also Figure 6 , Figure 6 This is a structural diagram of another carbon emission calculation system based on serverless architecture technology provided in an embodiment of the present application. Figure 6 The carbon emission calculation system based on the serverless architecture technology shown further includes a monitoring unit 140 ; ​​the monitoring unit 140 is connected to the function running container 121 .

[0168] The monitoring unit 140 is responsible for monitoring the running status and key indicators of the function instance running in the function running container 121 in the system. These indicators include the execution time, running execution error rate and throughput of the function instance. By monitoring these key indicators, the monitoring unit 140 can help the system understand the performance of the function instance in real time, find problems in time and take necessary measures to ensure the stability and reliability of the system.

[0169] It should be noted that the instance execution time refers to the time required for the function instance to complete one run, which reflects the execution efficiency of the function; the running execution error rate refers to the proportion of errors in the function instance during the execution process, which indicates the stability of the system; the throughput represents the number of requests that the function instance can process per unit time, which is an important indicator for measuring system performance. These key indicators are crucial for monitoring and optimizing the operation of the system.

[0170] The present application provides a carbon emission calculation system based on serverless architecture technology, which includes a structural design of an access layer, a control platform and an execution platform, which fully reflects the modular and hierarchical characteristics of the system. In the system, the access layer includes an event source processor, the control platform includes a scheduler, and the execution platform includes a function running container. This hierarchical design helps to improve the scalability and flexibility of the system. The connection between the event source processor and the scheduler and the connection between the scheduler and the function running container constitute an effective communication bridge between the various modules within the system, ensuring the smooth transmission and mutual cooperation of information. As an important component for monitoring external event triggers and receiving user calculation requests, the event source processor forwards relevant information to the scheduler, thereby triggering subsequent carbon emission calculation tasks. The role of the scheduler is to select a target function instance from multiple function instances stored in the system according to the calculation target in the received carbon emission calculation message, and transmit the calculation parameters and the target function instance to the function running container. The function running container is responsible for executing the calculation task on the target function instance, performing carbon emission calculation according to the provided calculation parameters, and finally obtaining the carbon emissions. By adopting a serverless architecture, the present application can dynamically manage and allocate computing resources. When there are no computing requests, the system will not continue to occupy server resources, thus avoiding resource waste and unnecessary operating costs.

[0171] The above is a detailed introduction to a carbon emission calculation system based on serverless architecture technology provided by the present application. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the embodiments can refer to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can refer to the method part description. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

[0172] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0173] It should also be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0174] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A carbon emission calculation system based on serverless architecture technology, characterized in that: The system comprises: an access layer, a control platform and an execution platform; the access layer comprises an event source processor; the control platform comprises a scheduler; the execution platform comprises a function running container; The event source processor is connected to the scheduler; the scheduler is connected to the function execution container; The event source processor is used to monitor external event triggers and / or receive user calculation requests, and send a carbon emission calculation message to the scheduler based on the monitoring of external event triggers and / or receiving user calculation requests; the carbon emission calculation message carries calculation parameters and calculation targets; The scheduler is configured to determine a target function instance from multiple function instances stored in the system based on the calculation target carried in the received carbon emission calculation message, and send the calculation parameters and the target function instance to the function execution container; The function running container is used to calculate the carbon emissions based on the calculation parameters on the target function instance to obtain the carbon emissions.

2. The system according to claim 1, characterized in that The function runs the container and is also used to: Feeding back the carbon emissions to the trigger that triggers the external event, and deleting the carbon emissions from the function running container; or, The carbon emissions are fed back to the client that sends the calculation request, and the carbon emissions are deleted in the function running container.

3. The system according to claim 1, characterized in that The access layer also includes an application programming interface gateway API Gateway; the API Gateway is connected to the event source processor; The API Gateway is used to: Authenticating a trigger that triggers the external event and / or authenticating a client that sends the computing request; When the identity authentication is passed, the event source processor is triggered to send a carbon emission calculation message to the scheduler based on the monitoring of external event triggers and / or receiving a user's calculation request.

4. The system according to claim 1, characterized in that The access layer also includes a command line interface CLI tool; the CLI tool is connected to the event source processor; The CLI tool is used to generate the carbon emission calculation message based on the monitoring of external event triggers and / or receiving a calculation request from a user.

5. The system according to claim 1, characterized in that The control platform also includes a routing manager; the routing manager is connected to the scheduler; The routing manager is used to: Analyzing the industry category to which the carbon emission calculation message belongs based on the calculation target of the carbon emission calculation message; Determining whether the function instance applied to the industry category to which the carbon emission calculation message belongs is stored in the system; If yes, the scheduler is triggered to execute the step of determining a target function instance from multiple function instances based on the calculation target carried in the received carbon emission calculation message.

6. The system according to claim 1, characterized in that The system further includes a monitoring unit; the monitoring unit is connected to the function execution container; The monitoring unit is used to monitor the running status and key indicators of the function instance running in the function running container; the key indicators include the execution time of the function instance, the running execution error rate of the function instance and the throughput of the function instance.

7. The system according to claim 1, characterized in that The control platform also includes a configuration center; the configuration center is connected to the function management component; The configuration center is used to manage the function instance and the configuration information of the system.

8. The system according to claim 1, characterized in that The system further comprises a storage unit; the storage unit is connected to the scheduler; The storage unit is used to store the multiple function instances.

9. The system according to claim 8, characterized in that The control platform further includes a function management component; the function management component is connected to the storage unit; The function management component is used to maintain the life cycle of the function instance; the life cycle of the function instance includes the creation operation, update operation and deletion operation of the function instance.

10. The system according to claim 1, characterized in that The execution platform also includes a resource isolation component; the resource isolation component is connected to the function execution container; The resource isolation component is used to isolate different function instances in the function execution container.

Images