A multi-cloud network automation delivery and billing method, device, medium and product

Abstract

A method, apparatus, medium, and product for automated delivery and billing of multi-cloud networks are disclosed, relating to the field of data processing. In this method, in response to a product definition request, a network service product model is created; an order containing service parameters selected for the network service product model is received, and the service instance corresponding to the order is determined, generating a service instance identifier; based on the order, underlying resources are orchestrated and configured in multiple cloud network environments, and resource tags associated with the service instance identifier are deployed on each underlying resource; multi-dimensional target metering data corresponding to the underlying resources are collected from multiple cloud network environments; based on the service instance identifier, the target metering data is aggregated to obtain consumption data corresponding to the service instance; according to the pricing rules in the network service product model, the consumption data is calculated to generate a service instance cost breakdown. Implementing the technical solution provided in this application improves billing accuracy.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data processing, in particular to a multi-cloud network automated delivery and billing method, device, medium and product. BACKGROUND

[0002] With the rapid development of cloud computing and network technology, enterprises' demand for network services is growing, especially efficient network connection and resource delivery in a multi-cloud environment. However, the existing network service delivery and billing mode has obvious limitations. For example, in the traditional mode, customers usually need to submit network service requirements (such as opening a cross-country private line) through email or work order, and the service provider needs to intervene through multiple teams such as sales, pre-sales, network operation, etc. to complete the complex processes of requirement confirmation, scheme design, manual configuration, testing and acceptance, etc. The delivery cycle is long, often taking weeks or even months. This mode is inefficient and difficult to meet the agility needs of business.

[0003] At present, thanks to the popularity of cloud platforms, some service providers try to use the native billing tools provided by cloud platforms (such as AWS Cost Explorer) to optimize resource cost management. However, these tools can only provide cost perspective bills based on single public cloud computing resources, and it is difficult to meet the current needs of hybrid multi-cloud or complex network services. For example, when the service involves multiple cloud platforms, private lines or self-owned devices, the cost data is scattered and difficult to be unified and allocated, resulting in low accuracy of the final billing result. SUMMARY

[0004] The present application provides a multi-cloud network automated delivery and billing method, device, medium and product, which improves the billing accuracy.

[0005] In a first aspect of the present application, a multi-cloud network automated delivery and billing method is provided, which comprises: creating a network service product model in response to a product definition request, the network service product model comprising at least one set of configurable service parameters and pricing rules associated with the service parameters; receiving an order containing selected service parameters for the network service product model, and determining a service instance corresponding to the order, and generating a service instance identifier corresponding to the service instance; based on the order, orchestrating and configuring underlying resources in multiple cloud network environments, and deploying resource tags associated with the service instance identifier on each of the underlying resources; collecting multi-dimensional target metering data corresponding to the underlying resources from multiple cloud network environments; based on the service instance identifier, aggregating the target metering data to obtain consumption data corresponding to the service instance; and calculating the consumption data according to the pricing rules in the network service product model to generate a fee breakdown of the service instance.

[0006] By adopting the above technical solutions, a network service product model is created in response to product definition requests. This abstracts network services into standardized, salable units containing configurable service parameters and pricing rules, facilitating the product-oriented management of network services. By receiving orders and generating service instance identifiers, a precise correspondence between customer order requests and service instances is achieved, providing a unique basis for subsequent resource management and billing. By orchestrating and configuring underlying resources and deploying resource tags across multiple cloud network environments, automated resource deployment across cloud network environments is achieved, while establishing a traceable relationship between service instances and underlying resources. By collecting multi-dimensional target metering data and aggregating it based on service instance identifiers, unified collection of resource consumption data scattered across multiple cloud network environments is achieved. By calculating and generating detailed cost breakdowns based on pricing rules, accurate billing based on actual resource consumption is achieved, closely linking costs to service usage. The automated delivery and billing method for multi-cloud networks provided in this application achieves flexible configuration of service parameters and scalable definition of pricing rules by creating a standardized network service product model; it significantly shortens the service delivery cycle and improves resource allocation efficiency by utilizing automated orchestration and resource tagging management technologies; it solves the problem of scattered and difficult-to-trace cost data in hybrid multi-cloud environments by accurately collecting and uniformly associating multi-dimensional metering data; and it achieves transparent and refined cost management by aggregating consumption data based on service instance identifiers and calculating pricing rules. This greatly improves the delivery efficiency, billing accuracy, and operational automation level of network services, ultimately providing service providers with the ability to productize and scale operations, while bringing customers an on-demand, cost-transparent consumption experience.

[0007] Optionally, the step of creating a network service product model in response to a product definition request specifically includes: assigning a product inventory unit identifier to the network service product to be created based on the product definition request; configuring a set of configurable parameters corresponding to the product inventory unit identifier, the set of configurable parameters including bandwidth specification parameters, service region parameters, and service level parameters; configuring a set of pricing rules corresponding to the product inventory unit identifier, the set of pricing rules including fixed fee rules, traffic billing rules, bandwidth billing rules, and API call billing rules; establishing an association between the set of configurable parameters and the set of pricing rules; and encapsulating the product inventory unit identifier, the set of configurable parameters, the set of pricing rules, and the association into the network service product model.

[0008] By adopting the above technical solutions, product inventory unit identifiers are assigned to network service products to be created, achieving unique identification and management of network service products within the system. By configuring a set of configurable parameters, including bandwidth specifications, service region parameters, and service level parameters, flexible definitions of network service technical specifications are achieved, meeting the differentiated needs of various customers. By configuring a set of pricing rules, including fixed-fee rules, traffic billing rules, bandwidth billing rules, and API call billing rules, support for multiple billing models is achieved. By establishing the association between the set of configurable parameters and the set of pricing rules, the linkage between service parameter values ​​and fee calculation logic is realized, ensuring that different configuration combinations correspond to different billing methods. By encapsulating the above content into a network service product model, a structured product definition of network services is achieved.

[0009] Optionally, the step of collecting multi-dimensional target metering data corresponding to the underlying resources from multiple cloud network environments specifically includes: deploying metering collector instances adapted to each cloud network environment, wherein the metering collector instances are configured as at least one of cloud platform interface collectors, network device collectors, or virtual probe collectors according to the data source type; acquiring the raw metering data collected by each metering collector instance; labeling the raw metering data with metering dimensions according to preset metering dimension rules, wherein the metering dimensions include network traffic dimension, peak bandwidth dimension, connection duration dimension, interface call count dimension, and specific function usage dimension; and cleaning the raw metering data after metering dimension labeling to obtain the target metering data.

[0010] By adopting the above technical solution and deploying metering data acquisition instances adapted to each cloud network environment, compatible data acquisition of different types of data sources is achieved. Cloud platform interface data acquisition devices, network device data acquisition devices, and virtual probe data acquisition devices are adapted to different data acquisition scenarios. By acquiring the raw metering data collected by each metering data acquisition instance, centralized aggregation of resource consumption data in a multi-cloud network environment is realized. By labeling the raw metering data according to preset metering dimension rules, the raw metering data is classified and managed according to network traffic, peak bandwidth, connection duration, number of interface calls, and usage of specific functions, facilitating subsequent billing processing by dimension. Data cleaning of the raw metering data after metering dimension labeling eliminates anomalies and noise, improving the accuracy and reliability of the target metering data.

[0011] Optionally, obtaining the raw metering data collected by each of the metering collector instances specifically includes: establishing an authentication connection between the cloud platform interface collector and the corresponding cloud network environment, and obtaining cloud platform monitoring indicator data associated with the underlying resources based on the authentication connection. The cloud platform monitoring indicator data includes the inbound traffic count value, outbound traffic count value, and cross-border traffic count value of the virtual gateway; connecting the network device collector to the network device in the backbone network through a preset device management protocol; reading the interface traffic statistics register associated with the service instance on the network device, and calculating the incremental traffic value and instantaneous bandwidth sampling value based on the read register value; and receiving probe observation messages pushed by software probes deployed on the data plane nodes of each of the cloud network environments through the virtual probe collector. The probe observation messages contain traffic sampling data passing through the underlying resources.

[0012] By adopting the above technical solutions, an authenticated connection is established between the cloud platform interface collector and the cloud network environment to obtain cloud platform monitoring indicator data. This enables the collection of inbound, outbound, and cross-border traffic counts for virtual gateways, thus acquiring resource consumption indicators at the cloud platform level. By using a preset device management protocol, the network device collector is connected to network devices in the backbone network, enabling data collection capabilities from physical network devices. By reading the interface traffic statistics register and calculating incremental traffic values ​​and instantaneous bandwidth sampling values, accurate measurement of backbone network traffic data is achieved. By receiving probe observation messages pushed by software probes through a virtual probe collector, real-time acquisition of traffic sampling data on data plane nodes is achieved, supplementing the fine-grained traffic data that cannot be covered by the cloud platform monitoring interface and network device management interface.

[0013] Optionally, the step of cleaning and compensating the raw measurement data after labeling the measurement dimensions to obtain the target measurement data specifically includes: calculating the statistical mean of each of the raw measurement data within a preset sliding time window; replacing the outlier data points in the raw measurement data with the statistical mean to obtain the target measurement data, wherein the deviation between the outlier data points and the statistical mean is greater than or equal to a preset standard deviation threshold; detecting whether the register value has a counter zeroing feature; if the counter zeroing feature is determined to exist, determining that the network device has experienced a restart event, and compensating and estimating the measurement data during the restart event based on historical measurement data before the restart event to obtain the target measurement data; detecting whether the sequence number in the probe observation message is discontinuous; if the sequence number in the probe observation message is determined to be discontinuous, determining that a message loss has occurred, and using the measurement data in the valid messages adjacent to the lost message to perform linear interpolation compensation for the missing measurement data of the lost message to obtain the target measurement data.

[0014] By employing the above technical solutions, the statistical mean of the original metering data within a preset sliding time window is calculated and abnormal data points are replaced, thus filtering out abnormal spikes in data caused by network jitter or acquisition errors and avoiding the impact of abnormal data on billing results. By detecting the counter zeroing characteristic of register values ​​and compensating for metering data during restart events, the continuity of metering data is ensured in network device restart scenarios, avoiding data loss due to device restarts. By detecting discontinuities in probe-observed packet sequence numbers and performing linear interpolation compensation for missing metering data in lost packets, the integrity of metering data is restored in probe packet loss scenarios, ensuring the accuracy and integrity of the target metering data.

[0015] Optionally, the step of calculating the consumption data and generating the cost details of the service instance based on the pricing rules in the network service product model specifically includes: obtaining the product inventory unit identifier and pricing rule set corresponding to the service instance from the network service product model; performing classified billing processing on the consumption data according to the pricing component types included in the pricing rule set, wherein the pricing component types include fixed cost components, traffic billing components, bandwidth billing components, and interface call billing components; and summarizing the costs calculated by each of the pricing component types to generate the cost details of the service instance.

[0016] By adopting the above technical solution, the product inventory unit identifiers and pricing rule sets corresponding to service instances are obtained from the network service product model, achieving precise matching between service instances and billing rules. By performing categorized billing processing on consumption data according to pricing component types, independent calculations are achieved for fixed-fee components, traffic billing components, bandwidth billing components, and API call billing components, supporting parallel processing of multiple billing modes. By summarizing the fees calculated by each pricing component type to generate a detailed fee statement, a complete presentation of service instance fees is achieved. The fee statement includes the itemized fees for each billing item and the total fee, facilitating customer understanding of the fee structure.

[0017] Optionally, the method further includes an idempotency processing step for the cost details. Specifically, the idempotency processing of the cost details includes: storing the target metering data in an immutable mode in the original metering event storage area; assigning a rule version identifier to each pricing rule in the pricing rule set, and generating a new rule version identifier when the pricing rule changes; recording the rule version identifier and billing time window corresponding to the cost details when generating the cost details; and, in response to a billing recalculation request, retrieving the corresponding target metering data from the original metering event storage area according to the rule version identifier and billing time window specified in the billing recalculation request, and recalculating the cost details using the pricing rule of the specified rule version.

[0018] By adopting the above technical solutions, target metering data is stored in an immutable mode in the original metering event storage area, ensuring the complete preservation of metering data as billing vouchers and guaranteeing the immutability of the billing basis. Version management of pricing rules is achieved by assigning rule version identifiers to pricing rules and generating new rule version identifiers when rules change, supporting the traceability of historical rule versions. Recording the rule version identifier and billing time window when generating cost details ensures the traceability of the association between cost details and the billing basis. Retrieving target metering data from the original metering event storage area and recalculating cost details using the specified rule version in response to billing recalculation requests enables repeatable cost calculation, supporting scenarios for billing dispute resolution and audit verification.

[0019] In a second aspect, embodiments of this application provide a multi-cloud network automated delivery and billing apparatus, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the multi-cloud network automated delivery and billing apparatus to perform the method described in the first aspect and any possible implementation thereof.

[0020] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a multi-cloud network automated delivery and billing device, cause the multi-cloud network automated delivery and billing device to perform the method described in the first aspect and any possible implementation thereof.

[0021] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a multi-cloud network automated delivery and billing device, cause the multi-cloud network automated delivery and billing device to perform the method described in the first aspect and any possible implementation thereof.

[0022] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: 1. By creating a network service product model that includes configurable service parameters and pricing rules, and by automatically orchestrating and configuring underlying resources based on orders, the delivery cycle of network services has been significantly shortened. At the same time, by deploying unified resource tags for underlying resources, end-to-end tracking and efficient management from service instances to physical resources have been achieved, solving the problems of low efficiency and chaotic resource management in the traditional manual delivery model.

[0023] 2. By leveraging metering data acquisition devices adapted to various cloud network environments, the raw metering data is collected, labeled, cleaned, and compensated from multiple dimensions, ensuring the accuracy and integrity of the metering data. This solution effectively addresses the challenges posed by data dispersion, single metering dimensions, and erroneous data in multi-cloud environments, providing a reliable data foundation for subsequent billing.

[0024] 3. By classifying and billing aggregated consumption data based on a set of pricing rules, the system supports multiple billing modes, including fixed fees, traffic-based billing, bandwidth billing, and API call billing, meeting the needs of complex service scenarios. Meanwhile, the idempotent processing mechanism for fee details ensures the traceability of billing results and the ability to recalculate after rule changes, further enhancing the flexibility, transparency, and reliability of billing, and providing customers and service providers with a better consumption experience and profit analysis capabilities. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating an automated delivery and billing method for multi-cloud networks disclosed in an embodiment of this application; Figure 2 This is another flowchart illustrating an automated delivery and billing method for multi-cloud networks disclosed in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a multi-cloud network automated delivery and billing device provided in an embodiment of this application.

[0026] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0028] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0029] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple system devices refer to two or more system devices, and multiple screen terminals refer to two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0030] This application provides a method for automated delivery and billing of multi-cloud networks, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an automated delivery and billing method for multi-cloud networks provided in an embodiment of this application. The method is applied to a server, and the device can execute the automated delivery and billing procedure for multi-cloud networks. The method includes steps S101 to S106, as follows: Step S101: In response to the product definition request, create a network service product model, which includes at least one set of configurable service parameters and pricing rules associated with the service parameters.

[0031] In step S101, a product definition request refers to an instruction initiated by the service provider's product management personnel to create a sellable network service product. A network service product model refers to a data structure that abstracts and encapsulates network services to form a standardized, sellable unit. Service parameters refer to configurable attributes describing the technical specifications and service levels of the network service, including bandwidth specifications, service region parameters, and service level parameters. Pricing rules define the billing logic for how network service products calculate costs based on resource consumption, including fixed-fee rules, traffic-based billing rules, bandwidth-based billing rules, and API call billing rules.

[0032] Specifically, in response to a received product definition request, the server first assigns a unique product inventory unit identifier to the network service product to be created. Based on the parameter configuration information carried in the product definition request, the server constructs a service parameter set. The bandwidth specification parameter defines the range of bandwidth values ​​and bandwidth adjustment steps available to the customer; the service region parameter defines the list of cloud network environment regions and cross-border interconnection combinations available to the customer; and the service level parameter defines the service quality assurance level available to the customer and the corresponding performance indicator commitment values. Based on the pricing configuration information carried in the product definition request, the server constructs a pricing rule set. The fixed fee rule defines a fixed amount charged per billing cycle; the traffic billing rule defines the unit price and unit of measurement for charges calculated based on actual traffic consumption; the bandwidth billing rule defines the unit price for charges calculated based on the 95th percentile bandwidth peak or the maximum bandwidth peak; and the interface call billing rule defines the unit price for charges calculated based on the number of interface calls and the free call allowance. The server establishes a relationship between the service parameter set and the pricing rule set, defining the applicable conditions and price coefficients for different combinations of service parameter values. The server encapsulates the product inventory unit identifier, service parameter set, pricing rule set, and association relationship into a network service product model, and stores the network service product model in the product catalog library.

[0033] In one possible implementation, in response to a product definition request, a network service product model is created, specifically including: assigning a product inventory unit identifier to the network service product to be created based on the product definition request; configuring a set of configurable parameters corresponding to the product inventory unit identifier, the set of configurable parameters including bandwidth specification parameters, service region parameters, and service level parameters; configuring a set of pricing rules corresponding to the product inventory unit identifier, the set of pricing rules including fixed fee rules, traffic billing rules, bandwidth billing rules, and API call billing rules; establishing an association between the set of configurable parameters and the set of pricing rules; and encapsulating the product inventory unit identifier, the set of configurable parameters, the set of pricing rules, and the association into a network service product model.

[0034] Specifically, in response to a received product definition request, the server first parses the basic product information carried in the request, including the product name, product category, and product description. Based on the product category, the server determines the encoding rules for the product inventory unit identifier and assigns a globally unique product inventory unit identifier to the network service product to be created according to these rules. The product inventory unit identifier uses a combined encoding format that includes a product category code, a region code, and a serial number, ensuring that each network service product has a unique and identifiable identifier throughout the system.

[0035] The server configures a set of configurable parameters corresponding to the product inventory unit identifier. This set defines the technical specifications that customers can choose and adjust when ordering network service products. The server configures bandwidth specifications, which define the range of bandwidth values ​​that customers can select, the bandwidth adjustment step size, and the bandwidth unit. The server writes the lower limit, upper limit, and adjustment step size of the bandwidth range into the bandwidth specification configuration item. For example, if the server configures the bandwidth range to 100Mbps to 10Gbps with an adjustment step size of 100Mbps, it means that the customer can select the desired bandwidth specification in 100Mbps units within the 100Mbps to 10Gbps range. The server configures service region parameters, which define the list of cloud network environment regions that the network service can cover and the supported cross-border interconnection combinations. The server writes the list of selectable source regions, the list of target regions, and the allowed region combination rules into the service region parameter configuration item. For example, the server configures the source regions as Alibaba Cloud Shanghai, Alibaba Cloud Beijing, and Tencent Cloud Guangzhou, and the target regions as AWS US East, AWS Europe, and Azure Southeast Asia, and defines the combinable rules between each source region and target region. The server is configured with service level parameters, which define the service quality assurance levels that customers can choose and the performance metric commitments for each level. The server writes the selectable service level types, the latency commitments, availability commitments, and packet loss rate commitments for each level into the service level parameter configuration items. For example, the server can be configured with three service levels: gold, silver, and bronze. Gold corresponds to a latency of less than 50 milliseconds and availability of no less than 99.99%, silver corresponds to a latency of less than 100 milliseconds and availability of no less than 99.9%, and bronze corresponds to a latency of less than 200 milliseconds and availability of no less than 99%.

[0036] The server configures the pricing rule set corresponding to the product inventory unit identifier. This set defines how network service products calculate fees based on customer resource consumption. The server configures fixed-fee rules, which define a fixed amount charged per billing cycle. The server writes the billing cycle type, fixed fee amount, and billing start conditions into the fixed-fee rule's configuration items. For example, configuring the billing cycle as monthly and the fixed fee amount as $500 means the customer will pay a fixed service fee of $500 per month. The server also configures traffic-based billing rules, which define the billing logic based on actual traffic consumption. The server writes the traffic unit price, unit of measurement, traffic direction, and billing granularity into the traffic-based billing rule's configuration items. For example, configuring the traffic unit price as $0.05 per GB and the traffic direction as cross-border outbound traffic means the customer will pay $0.05 per GB of cross-border outbound traffic. The server configures bandwidth billing rules, which define the billing logic for calculating charges based on peak bandwidth. The server writes the bandwidth billing mode, bandwidth unit price, and sampling period into the configuration items of the bandwidth billing rules. Bandwidth billing modes include 95th-th bandwidth billing mode and maximum bandwidth billing mode. For example, if the server configures the bandwidth billing mode to 95th-th bandwidth billing mode, the bandwidth unit price to $10 per Mbps, and the sampling period to 5 minutes, the system calculates the customer's monthly bandwidth charges according to the 95th-th bandwidth billing mode. The server also configures API call billing rules, which define the billing logic for calculating charges based on the number of API calls. The server writes the call unit price, free call quota, and billed API range into the configuration items of the API call billing rules. For example, if the server configures the call unit price to $0.1 per 10,000 calls and the free call quota to 1 million calls per month, the customer's first 1 million API calls per month are free, and subsequent calls are charged at $0.1 per 10,000 calls.

[0037] The server establishes a relationship between a set of configurable parameters and a set of pricing rules. This relationship defines the applicable conditions and price coefficients for different combinations of parameter values. The server creates a mapping configuration table between parameters and rules, recording how each service parameter value affects the pricing rules. For example, the server configures the price coefficient for the fixed fee rule to be 1.5 when the customer selects the Gold service level, 1.2 when the customer selects the Silver service level, and 1.0 when the customer selects the Bronze service level, indicating that different service levels correspond to different fixed fee amounts. The server also configures a relationship between service region parameters and traffic billing rules. For example, when the source and destination regions selected by the customer involve cross-border transmission, a cross-border traffic unit price applies; when the source and destination regions are located within the same geographical region, a domestic traffic unit price applies.

[0038] The server encapsulates the product inventory unit identifier, configurable parameter set, pricing rule set, and relationships into a network service product model. The server serializes the network service product model into a structured data format and stores it in the product catalog library. At the same time, the server marks the status of the network service product model as available for sale, so that customers can browse and order the network service product through the online ordering portal.

[0039] Step S102: Receive an order containing the service parameters selected for the network service product model, determine the service instance corresponding to the order, and generate a service instance identifier corresponding to the service instance.

[0040] In step S102, an order refers to a purchase request submitted by a customer through the online ordering portal, which includes the selected network service product and configuration parameters. A service instance refers to the running entity of the network service actually activated according to the customer's order. A service instance identifier is a globally unique identifier assigned by the system to each activated service instance.

[0041] Specifically, the server receives orders submitted by customers through an online ordering portal. Each order contains the product inventory unit identifier corresponding to the selected network service product model and the specific parameter values ​​chosen by the customer for the service parameters. The server verifies the order's validity, checking whether the selected parameter values ​​are within the range defined by the network service product model and whether the customer's account status meets the ordering conditions. After successful order verification, the server matches the corresponding predefined automated workflow template based on the network service product model specified in the order. The server instantiates the automated workflow template to generate a service activation workflow instance and creates a corresponding service instance for that instance. The server assigns a globally unique service instance identifier to each service instance, using a combined encoding format including the customer identifier, product type identifier, and serial number. The server associates the service instance identifier with order information and customer information, storing this association in the order management database.

[0042] Step S103: Based on the order, orchestrate and configure the underlying resources in multiple cloud network environments, and deploy resource tags associated with service instance identifiers on each underlying resource.

[0043] In step S103, the cloud network environment refers to public or private cloud platforms operated by different cloud service providers. Underlying resources refer to the infrastructure resources created and configured in the cloud network environment to implement network service functions; these resources include virtual gateways, virtual private network connections, load balancers, and routing policies. Resource tags are key-value pairs of information appended to the metadata attributes of underlying resources to identify resource ownership.

[0044] Specifically, the server executes a service activation workflow instance, determining which cloud network environments need to create underlying resources based on the service parameters selected by the customer in the order. The server calls the resource orchestration interfaces provided by each cloud network environment to automatically create the underlying resources required for the network service in the corresponding cloud network environment. The creation process of underlying resources includes the instantiation of virtual gateways, the establishment of virtual private network connections, the configuration of routing policies, and the setting of security policies. The server generates a unified resource tag containing customer identifier, service instance identifier, and service product type fields. Through the resource management interfaces of each cloud network environment, the server writes the unified resource tag into the metadata attributes of all created underlying resources, ensuring that each underlying resource carries a resource tag associated with the service instance identifier. The server establishes and maintains a mapping table between service instance identifiers and underlying resource identifiers in the control plane. This mapping table records all underlying resource identifiers corresponding to each service instance identifier for subsequent metering data verification and aggregation.

[0045] Step S104: Collect multi-dimensional target measurement data corresponding to the underlying resources from multiple cloud network environments.

[0046] In step S104, the target measurement data refers to multi-dimensional quantitative data reflecting the consumption of underlying resources, which is collected from various cloud network environments and cleaned.

[0047] Specifically, the server deploys a metering collector instance adapted to each cloud network environment. These metering collector instances are configured as cloud platform interface collectors, network device collectors, or virtual probe collectors, depending on the data source type. The server establishes an authenticated connection with the corresponding cloud network environment through the cloud platform interface collector and obtains cloud platform monitoring indicator data associated with the underlying resources based on this connection. This data includes inbound traffic counts, outbound traffic counts, and cross-border traffic counts for the virtual gateway. The server connects to network devices in the backbone network through the network device collector, reads the interface traffic statistics registers associated with the service instances on these devices, and calculates incremental traffic values ​​and instantaneous bandwidth sampling values ​​based on the read register values. The server receives probe observation messages pushed by software probes deployed on data plane nodes in each cloud network environment through the virtual probe collector. These messages contain traffic sampling data passing through the underlying resources. The server annotates the collected raw metering data according to preset metering dimension rules. These metering dimensions include network traffic, peak bandwidth, connection duration, number of interface calls, and usage of specific functions. The server performs data cleaning on the raw measurement data after the measurement dimensions are labeled. The data cleaning process includes abnormal spike filtering, equipment restart compensation, and probe packet loss compensation. After the data cleaning process, the target measurement data is obtained.

[0048] In one possible implementation, multi-dimensional target metering data corresponding to underlying resources is collected from multiple cloud network environments, specifically including steps S1041-S1044, as follows: Step S1041: Deploy a metering collector instance adapted to each cloud network environment. The metering collector instance is configured as at least one of cloud platform interface collector, network device collector, or virtual probe collector according to the data source type.

[0049] In step S1041, a metering data collector instance refers to a software program that is actually deployed and running, responsible for collecting metering information from a specific data source. The data source type refers to the classification of the system from which the metering data originates, such as the monitoring interface of a public cloud platform, the management interface of a physical network device, or the measurement results of a software probe. A cloud platform interface collector refers to a metering data collector instance specifically designed to interact with monitoring services provided by cloud service providers via APIs to obtain resource metering data. A network device collector refers to a metering data collector instance specifically designed to communicate with hardware devices such as routers and switches via network management protocols such as SNMP, NetFlow, or SSH to obtain data such as port traffic. A virtual probe collector refers to a metering data collector instance specifically designed to collect performance indicator data, such as latency, jitter, and packet loss rate, generated by virtualized software probes deployed in the network.

[0050] Specifically, the server deploys different types of metering collector instances based on the composition of the multi-cloud network environment to be metered. For example, a service instance spans both the AWS public cloud and the customer's on-premises data center. For the AWS cloud network environment, the server deploys a cloud platform interface collector instance and configures it to programmatically call the AWS CloudWatch service API using the customer-authorized access key to obtain traffic metrics from the virtual private gateway. For the border router in the customer's on-premises data center, the server deploys a network device collector instance and configures it to periodically poll the router's specific interface information management library (MIB) object using a pre-defined SNMP community string via the SNMP protocol to obtain the number of incoming and outgoing bytes for the interface. If the service also needs to bill for network quality, the server may also deploy a virtual machine as a probe in each of the two environments and deploy a virtual probe collector instance to collect latency data generated by the network probe commands executed between the two probes.

[0051] Step S1042: Obtain the raw metering data collected by each metering data acquisition instance.

[0052] In step S1042, raw measurement data refers to the initial data obtained directly from the respective data sources by each metering acquisition instance, without any processing or standardization. This data typically retains the original format, units, and data structure of the data source.

[0053] Specifically, the server's central data processing unit receives data from all deployed metering collector instances. Cloud platform interface collector instances deployed in the AWS environment receive a JSON response after calling the API, containing a timestamp, metric name (e.g., NetworkIn), and a numerical value in bytes. This collector instance then sends this raw JSON data packet to the server. Network device collector instances deployed in the customer's data center, after querying via the SNMP protocol, receive an unsigned 64-bit integer representing the total number of bytes since the interface started. This collector instance sends this integer value along with the device identifier and interface index to the server. Virtual probe collector instances, after executing a ping command, parse the round-trip time in milliseconds and send this value to the server. The server obtains this raw metering data from different sources and in various formats, and aggregates it into a temporary storage area, such as a message queue, for subsequent unified processing.

[0054] In one possible implementation, acquiring the raw metering data collected by each metering collector instance specifically includes: establishing an authentication connection between the cloud platform interface collector and the corresponding cloud network environment, and acquiring cloud platform monitoring indicator data associated with the underlying resources based on the authentication connection. The cloud platform monitoring indicator data includes the inbound traffic count value, outbound traffic count value, and cross-border traffic count value of the virtual gateway; connecting the network device collector to the network device in the backbone network through a preset device management protocol; reading the interface traffic statistics register associated with the service instance on the network device, and calculating the incremental traffic value and instantaneous bandwidth sampling value based on the read register value; and receiving probe observation messages pushed by software probes deployed on the data plane nodes of each cloud network environment through a virtual probe collector. The probe observation messages contain traffic sampling data passing through the underlying resources.

[0055] Specifically, the server establishes an authentication connection with the corresponding cloud network environment through the cloud platform interface collector. The server uses pre-configured interface access credentials to initiate an authentication request to the authentication service of the cloud network environment, and establishes an authentication connection after successful authentication. Based on the authentication connection, the server calls the monitoring data query interface provided by the cloud network environment, specifies the underlying resource identifier to be queried in the interface request parameters, and obtains the cloud platform monitoring indicator data associated with the underlying resource. The cloud platform monitoring indicator data includes the inbound traffic count value, outbound traffic count value, and cross-border traffic count value of the virtual gateway.

[0056] The server connects the network device collector to network devices in the backbone network through a preset device management protocol, which includes a simple network management protocol and a network configuration protocol. The server reads the interface traffic statistics register associated with the service instance on the network device through the established management connection. The server records the currently read register value and the read timestamp, calculates the incremental traffic value by calculating the difference between two adjacent read register values, and calculates the instantaneous bandwidth sampling value based on the ratio of the incremental traffic value to the time interval.

[0057] The server receives probe observation messages pushed by software probes deployed on data plane nodes in various cloud network environments via a virtual probe collector. The software probes sample network traffic passing through the data plane nodes and generate probe observation messages. These messages contain traffic sampling data passing through underlying resources and a sequence number field used to detect message loss. The server then categorizes and summarizes the traffic sampling data from the received probe observation messages according to the underlying resource identifier.

[0058] Step S1043: Label the original measurement data with measurement dimensions according to the preset measurement dimension rules. The measurement dimensions include network traffic dimension, peak bandwidth dimension, connection duration dimension, number of interface calls dimension, and usage of specific functions dimension.

[0059] In step S1043, the preset measurement dimension rules refer to a set of mapping logic predefined in the server, used to identify and classify specific indicators in raw measurement data from different sources onto a unified measurement dimension with business meaning. A measurement dimension is a standardized label used to classify and price resource consumption. For example, network traffic dimension represents data transmission volume, peak bandwidth dimension represents the highest data transmission rate, connection duration dimension represents the continuous online time of a service or connection, API call count dimension represents the frequency of API and other resource calls, and specific function usage dimension measures the usage of specific value-added functions such as the number of NAT gateways or security policy entries.

[0060] Specifically, the server's data processing pipeline consumes raw metering data from temporary storage. For each data piece, the server applies preset metering dimension rules for analysis and labeling. For example, one rule might be defined as: if the raw metering data originates from a cloud platform interface collector and the metric name is NetworkIn or NetworkOut, then label it with the network traffic dimension. Another rule might be defined as: if the raw metering data originates from a network device collector and is derived by calculating the difference between the interface byte count counters of two consecutive collections, then also label it with the network traffic dimension. Yet another rule might be defined as: if the raw metering data originates from a virtual probe collector and is round-trip latency, then label it with a custom dimension, such as the duration of network quality SLA compliance.

[0061] Step S1044: Clean the raw measurement data after the measurement dimensions are labeled to obtain the target measurement data.

[0062] In step S1044, data cleaning refers to a series of verification, correction, and formatting operations performed on the raw measurement data that has already been labeled with measurement dimensions, to ensure the accuracy, consistency, and integrity of the data, thereby generating final data that can be used for billing. Target measurement data refers to the high-quality, standardized set of measurement data obtained after the data cleaning process.

[0063] Specifically, after completing dimension labeling, the server's data processing pipeline immediately performs data cleaning. First, the server performs deduplication, checking for duplicate records with identical timestamps, resource identifiers, and values. If found, only one record is retained, preventing duplicate billing due to collector retries. Second, the server performs outlier detection. For example, if a record for the bandwidth peak dimension shows 0 or a value far exceeding physical link limits, the server will determine it as an anomaly and remove it, avoiding billing errors due to incorrect data sources. Next, the server performs unit standardization, converting all network traffic data, regardless of whether the original unit is bytes, KB, or MB, to GB. Finally, the cleaned data, i.e., the target metering data, is assigned a unique record ID and loaded into a dedicated time-series database for persistent storage.

[0064] In one possible implementation, the raw metrological data after being labeled with metrological dimensions is cleaned and compensated to obtain target metrological data. Specifically, this includes: calculating the statistical mean of each raw metrological data within a preset sliding time window; replacing outlier data points in the raw metrological data with the statistical mean to obtain target metrological data, where the deviation between the outlier data points and the statistical mean is greater than or equal to a preset standard deviation threshold; detecting whether the register value has a counter zeroing characteristic; if the counter zeroing characteristic is determined to exist, a network device restart event is determined, and the metrological data during the restart event period is compensated and estimated based on historical metrological data before the restart event to obtain target metrological data; detecting whether the sequence number in the probe observation message is discontinuous; if the sequence number in the probe observation message is determined to be discontinuous, a message loss is determined, and the missing metrological data of the lost message is compensated by linear interpolation using the metrological data in the valid messages adjacent to the lost message to obtain target metrological data.

[0065] The server performs anomaly filtering on the raw metering data after metering dimension annotation. The server sets a preset sliding time window span and slides this window along the time axis, acquiring each raw metering data point falling within it. The server calculates the statistical mean and standard deviation of the metering values ​​for each raw metering data point within the preset sliding time window. The server then checks the metering value of each raw metering data point within the preset sliding time window, calculating the deviation of each value from the statistical mean. The server determines if the deviation is greater than or equal to a preset standard deviation threshold, typically set as the boundary between the statistical mean and three times the standard deviation. The server marks raw metering data points with deviations greater than or equal to the preset standard deviation threshold as outlier data points. These outlier data points are usually caused by instantaneous anomalies due to network jitter, equipment failure, or acquisition errors. The server replaces the metering values ​​of the outlier data points with the statistical mean, eliminating the impact of these anomalies on subsequent billing calculations.

[0066] The server performs device restart compensation processing on the raw metering data after abnormal spike filtering. The server checks if the register values ​​obtained from the network device collector exhibit a counter zeroing characteristic. A counter zeroing characteristic is indicated by the register value in the current sampling period being significantly smaller than the register value in the previous sampling period and close to zero or a small positive integer. If the server detects a counter zeroing characteristic in the register values, it determines that a network device restart event has occurred. During the network device restart process, the interface traffic statistics register is cleared, causing a gap in the metering data. The server acquires historical metering data within a preset time range before the restart event, analyzes the changing trends and periodic patterns of the historical metering data, and performs compensation estimation on the metering data during the restart event period based on the trend characteristics of the historical metering data. The compensation estimation uses the historical average method or linear trend extrapolation method to calculate the estimated metering values ​​during the restart period. The server then fills the estimated metering values ​​into the corresponding time points during the restart event period.

[0067] The server performs probe packet loss compensation processing on the raw metering data after device restart compensation. The server checks for discontinuities in the sequence numbers of probe observation packets received from the virtual probe collector. The server arranges all probe observation packets in chronological order of reception time and compares the sequence number differences between adjacent packets. If the difference is greater than one, it indicates a discontinuity. If the server determines a discontinuity, it identifies packet loss, typically caused by network congestion, transmission link failure, or insufficient probe processing capacity. The server locates the sequence number range of the lost packet and retrieves adjacent valid packets. Metering data is extracted from these adjacent valid packets, and linear interpolation is used to compensate for the missing metering data in the lost packet. This linear interpolation calculates an estimated metering value for the corresponding time point of the lost packet based on the metering values ​​of the preceding and following valid packets, proportionally to the time. The server outputs the raw metering data, after all the above data cleaning and compensation processing, as the target metering data.

[0068] Step S105: Aggregate the target metering data based on the service instance identifier to obtain the consumption data corresponding to the service instance.

[0069] In step S105, the consumption data refers to the comprehensive resource consumption statistics formed by aggregating the target metering data scattered in multiple cloud network environments according to the service instance dimension.

[0070] Specifically, the server extracts resource tag information and data source resource identifiers from the target metering data. Based on the service instance identifier field in the resource tag information, the server queries the mapping table to verify the attribution of the target metering data. The server determines whether the service instance identifier in the resource tag information matches the record in the mapping table, and whether the data source resource identifier exists in the underlying resource identifier set corresponding to the service instance identifier in the mapping table. For the verified target metering data, the server groups and aggregates it according to the service instance identifier. For the target metering data corresponding to each service instance identifier, the server calculates the aggregated value for each metering dimension: for network traffic, it calculates the cumulative total traffic; for peak bandwidth, it calculates the maximum value or 95th percentile value within the sampling period; for connection duration, it calculates the cumulative connection time; and for interface call count, it calculates the cumulative number of calls. The server combines the aggregated values ​​of each metering dimension to form the consumption data corresponding to the service instance.

[0071] Step S106: Calculate the consumption data according to the pricing rules in the network service product model and generate a service instance cost breakdown.

[0072] In step S106, the expense details refer to the bill data that includes each expense item and the total expense, generated after calculating the consumption data according to the pricing rules.

[0073] Specifically, the server retrieves the product inventory unit identifier and associated pricing rule set corresponding to the service instance from the network service product model. Based on the pricing component types included in the pricing rule set, the server performs categorized billing processing on the consumption data. For the fixed-fee component, the server calculates the fixed fee based on the service period of the service instance and the corresponding fixed fee amount, proportionally to the number of service days. For the traffic billing component, the server extracts the cumulative traffic value from the network traffic dimension of the consumption data and multiplies the cumulative traffic value by the corresponding traffic unit price to calculate the traffic fee. For the bandwidth billing component, the server extracts the 95th bandwidth value or maximum bandwidth value from the bandwidth peak dimension of the consumption data and multiplies the bandwidth value by the corresponding bandwidth unit price to calculate the bandwidth fee. For the API call billing component, the server extracts the cumulative number of API calls from the API call count dimension of the consumption data and multiplies the number of calls exceeding the free quota by the corresponding call unit price to calculate the API call fee. For the tiered pricing rules or consumption commitment rules included in the pricing rule set, the server calculates the corresponding fees according to the corresponding billing logic. The server summarizes the fees calculated by each pricing component type, generates a service instance fee detail, and associates and stores the fee detail with the service instance identifier and customer account.

[0074] In one possible implementation, the consumption data is calculated according to the pricing rules in the network service product model to generate a service instance cost detail. Specifically, this includes: obtaining the product inventory unit identifier and pricing rule set corresponding to the service instance from the network service product model; performing classified billing processing on the consumption data according to the pricing component types included in the pricing rule set, where the pricing component types include fixed cost components, traffic billing components, bandwidth billing components, and API call billing components; and summarizing the costs calculated by each pricing component type to generate a service instance cost detail.

[0075] Specifically, based on the product information associated with the service instance, the server retrieves the product inventory unit identifier and pricing rule set corresponding to the service instance from the network service product model. The server determines the network service product ordered by the service instance by querying the association record between the service instance and the product inventory unit identifier, and loads the complete pricing rule set corresponding to the product inventory unit identifier from the product catalog library.

[0076] The server parses the pricing component types contained in the pricing rule set and performs categorized billing processing on the consumption data according to each pricing component type. For fixed-fee components, the server performs billing processing by reading the billing period and fixed fee amount defined for the fixed-fee component from the pricing rule set. The server calculates the fixed fee based on the ratio of the actual number of service days in the current billing period to the total number of days in the billing period. For example, if a service instance has a fixed fee of $500 per month and 15 service days in the current month, the server calculates the fixed fee as $500 multiplied by 15 days and divided by 30 days, which equals $250.

[0077] The server performs billing processing for the traffic billing component. The server reads the traffic unit price and billed traffic type defined by the traffic billing component from the pricing rule set. The server extracts the cumulative traffic value of the network traffic dimension from the consumption data, and multiplies the cumulative traffic value by the traffic unit price to calculate the traffic cost. For example, if a service instance generates 15,000 GB of cross-border traffic in a month and the traffic unit price is $0.05 per GB, the server calculates the traffic cost as 15,000 GB multiplied by $0.05, which equals $750.

[0078] The server performs billing processing for the bandwidth billing component. It reads the bandwidth billing mode and bandwidth unit price defined by the component from the pricing rule set. The bandwidth billing modes include the 95th-bit bandwidth billing mode and the maximum bandwidth billing mode. If the server uses the 95th-bit bandwidth billing mode, it extracts all bandwidth sample values ​​from the peak bandwidth dimension of the consumption data. All bandwidth sample values ​​are sorted in descending order of value, and the top 5% of sample values ​​are removed. The maximum value among the remaining sample values ​​is determined as the 95th-bit bandwidth value. The server multiplies the 95th-bit bandwidth value by the bandwidth unit price to calculate the bandwidth cost. For example, if a service instance's 95th-bit bandwidth value for the current month is 650 Mbps and the bandwidth unit price is $10 per Mbps, the server calculates the bandwidth cost as 650 Mbps multiplied by $10, which equals $6500.

[0079] The server performs billing processing for the API call billing component. The server reads the call unit price and free call quota defined by the API call billing component from the pricing rule set. The server extracts the cumulative call count dimension of the API call count from the consumption data and determines whether the cumulative call count exceeds the free call quota. If the cumulative call count exceeds the free call quota, the excess call count is multiplied by the call unit price to calculate the API call cost. For example, if a service instance has a cumulative call count of 1.5 million times in a month, a free call quota of 1 million times, and a call unit price of $0.1 per 10,000 times, the server calculates the API call cost as 500,000 times multiplied by $0.1 per 10,000 times, which equals $5.

[0080] The server summarizes the various costs calculated by the fixed-cost component, traffic billing component, bandwidth billing component, and API call billing component to generate a service instance cost detail. The cost detail includes the cost items and total cost corresponding to each pricing component type. The server associates and stores the cost detail with the service instance identifier and customer account.

[0081] refer to Figure 2 In one possible implementation, the method further includes an idempotency processing step for the cost details. This idempotency processing specifically includes steps S201-S204, as follows: Step S201: Store the target measurement data in an immutable mode to the original measurement event storage area.

[0082] In step S201, the immutable mode refers to a storage method where data cannot be modified or deleted once it is written to the storage area. The original metering event storage area refers to a dedicated data storage area used for persistently storing the target metering data.

[0083] Specifically, the server writes the cleaned target metering data into the original metering event storage area. During the writing process, the server assigns a globally unique metering event identifier to each piece of target metering data and records the event generation timestamp and event entry timestamp. The server configures the original metering event storage area in immutable mode. The immutable mode is implemented through the write protection mechanism of the storage system, which prohibits updating or deleting the stored target metering data, ensuring that the target metering data, as the original voucher for billing, is completely preserved.

[0084] Step S202: Assign a rule version identifier to each pricing rule in the pricing rule set, and generate a new rule version identifier when the pricing rule changes.

[0085] In step S202, the rule version identifier refers to a unique code used to identify a specific version of the pricing rule.

[0086] Specifically, the server assigns a rule version identifier to each pricing rule in the pricing rule set. The rule version identifier uses a combination format including the rule code and a version number. The server monitors changes to the pricing rule set. When a pricing rule is changed, the server retains the original version of the pricing rule record and generates a new rule version identifier for the changed pricing rule. The server also records the effective start time of the rule corresponding to the new rule version identifier. The server uses rule version identifiers to achieve versioned management of pricing rules, enabling the system to trace the content of pricing rules that took effect at any point in time.

[0087] Step S203: When generating the cost details, record the rule version identifier and billing time window corresponding to the cost details.

[0088] In step S203, the billing time window refers to the start and end time range of the billing cycle covered by the fee details.

[0089] Specifically, when generating fee details, the server writes the rule version identifier used to generate the fee details into the metadata field of the fee details. The server also records the billing time window corresponding to the fee details, which includes the start and end timestamps of the billing period. The server establishes a relationship between fee details, rule version identifiers, and billing time windows, so that each fee detail can be traced back to the pricing rule version and billing time range on which it was generated.

[0090] Step S204: In response to the billing recalculation request, retrieve the corresponding target metering data from the original metering event storage area according to the rule version identifier and billing time window specified in the billing recalculation request, and recalculate the cost details using the pricing rules of the specified rule version.

[0091] In step S204, a billing recalculation request refers to an instruction initiated by an operator or system to recalculate the cost details for a specified time period.

[0092] Specifically, in response to a received billing recalculation request, the server parses the rule version identifier and billing time window specified in the request. Based on the start and end timestamps within the billing time window, the server retrieves all target metering data from the original metering event storage area whose event timestamps fall within the billing time window range. Based on the rule version identifier specified in the billing recalculation request, the server loads the corresponding version of the pricing rule content from the pricing rule version library. The server re-executes the billing calculation process on the retrieved target metering data using the specified rule version, generating a recalculated cost breakdown. The server compares the recalculated cost breakdown with the original cost breakdown, records the cost differences, and decides whether to update the cost breakdown or generate an adjustment order based on business rules.

[0093] The following describes a multi-cloud network automated delivery and billing device according to an embodiment of the present invention from the perspective of hardware processing. Please refer to [link to relevant documentation]. Figure 3 This is a schematic diagram of the structure of a multi-cloud network automated delivery and billing device in an embodiment of this application.

[0094] It should be noted that, Figure 3 The structure of the multi-cloud network automated delivery and billing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0095] like Figure 3 As shown, a multi-cloud network automated delivery and billing device includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 302 or a program loaded from storage portion 308 into random access memory (RAM) 303, such as performing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for device operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0096] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0097] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0098] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0099] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0100] Specifically, the multi-cloud network automated delivery and billing device of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the multi-cloud network automated delivery and billing method provided in the above embodiment.

[0101] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the multi-cloud network automated delivery and billing apparatus described in the above embodiments; or it may exist independently and not assembled into the multi-cloud network automated delivery and billing apparatus. The storage medium carries one or more computer programs, which, when executed by a processor of the multi-cloud network automated delivery and billing apparatus, cause the multi-cloud network automated delivery and billing apparatus to implement the multi-cloud network automated delivery and billing method provided in the above embodiments.

Claims

1. A method for automated delivery and billing of multi-cloud networks, characterized in that, The method includes: In response to a product definition request, a network service product model is created, the network service product model including at least one set of configurable service parameters and pricing rules associated with the service parameters; Receive an order containing service parameters selected for the network service product model, determine the service instance corresponding to the order, and generate a service instance identifier corresponding to the service instance; Based on the order, underlying resources are orchestrated and configured in multiple cloud network environments, and resource tags associated with the service instance identifier are deployed on each underlying resource; Collect multi-dimensional target measurement data corresponding to the underlying resources from multiple cloud network environments; Based on the service instance identifier, the target metering data is aggregated to obtain the consumption data corresponding to the service instance; Based on the pricing rules in the network service product model, the consumption data is calculated to generate the cost details of the service instance.

2. The method according to claim 1, characterized in that, The process of creating a network service product model in response to a product definition request specifically includes: Based on the product definition request, assign a product inventory unit identifier to the network service product to be created; Configure the set of configurable parameters corresponding to the product inventory unit identifier, including bandwidth specification parameters, service area parameters, and service level parameters; Configure the pricing rule set corresponding to the product inventory unit identifier. The pricing rule set includes fixed fee rules, traffic billing rules, bandwidth billing rules, and interface call billing rules. Establish the association between the set of configurable parameters and the set of pricing rules; The product inventory unit identifier, the set of configurable parameters, the set of pricing rules, and the relationship are encapsulated into the network service product model.

3. The method according to claim 1, characterized in that, The collection of multi-dimensional target measurement data corresponding to the underlying resources from multiple cloud network environments specifically includes: Deploy a metering collector instance adapted to each of the cloud network environments, wherein the metering collector instance is configured as at least one of a cloud platform interface collector, a network device collector, or a virtual probe collector, depending on the data source type; Obtain the raw metering data collected by each of the metering data acquisition instances; The original measurement data is labeled with measurement dimensions according to preset measurement dimension rules. The measurement dimensions include network traffic dimension, peak bandwidth dimension, connection duration dimension, number of interface calls dimension, and usage of specific functions dimension. The original measurement data after the measurement dimensions are labeled is cleaned and compensated to obtain the target measurement data.

4. The method according to claim 3, characterized in that, The acquisition of the raw metering data collected by each of the metering data acquisition instances specifically includes: Establish an authentication connection between the cloud platform interface collector and the corresponding cloud network environment, and obtain cloud platform monitoring indicator data associated with the underlying resources based on the authentication connection. The cloud platform monitoring indicator data includes the inbound traffic count value, outbound traffic count value, and cross-border traffic count value of the virtual gateway. The network device collector is connected to network devices in the backbone network through a preset device management protocol; Read the interface traffic statistics register associated with the service instance on the network device, and calculate the incremental traffic value and instantaneous bandwidth sampling value based on the read register value; The virtual probe collector receives probe observation messages pushed by software probes deployed on data plane nodes in each of the cloud network environments. The probe observation messages contain traffic sampling data passing through the underlying resources.

5. The method according to claim 4, characterized in that, The process of cleaning and compensating the raw measurement data after labeling the measurement dimensions to obtain the target measurement data specifically includes: Calculate the statistical mean of each of the original measurement data within a preset sliding time window; The outlier data points in the original measurement data are replaced with the statistical mean to obtain the target measurement data, wherein the deviation between the outlier data points and the statistical mean is greater than or equal to a preset standard deviation threshold. Detect whether the register value exhibits a counter zeroing characteristic; If the counter zeroing feature is determined to exist, then a network device restart event is determined to have occurred, and the metering data during the restart event is compensated and estimated based on the historical metering data before the restart event to obtain the target metering data; Detect whether there are any discontinuities in the sequence numbers in the probe observation message; If it is determined that there is a discontinuity in the sequence number in the probe observation message, then it is determined that a message loss has occurred. The missing measurement data of the lost message is compensated by linear interpolation using the measurement data in the valid messages adjacent to the lost message, so as to obtain the target measurement data.

6. The method according to claim 1, characterized in that, The step of calculating the consumption data based on the pricing rules in the network service product model to generate the cost details of the service instance specifically includes: Obtain the product inventory unit identifier and pricing rule set corresponding to the service instance from the network service product model; According to the pricing component types included in the pricing rule set, the consumption data is subjected to classified billing processing, and the pricing component types include fixed cost components, traffic billing components, bandwidth billing components and interface call billing components; The costs calculated for each of the aforementioned pricing component types are summarized to generate a cost breakdown for the service instance.

7. The method according to claim 6, characterized in that, The method further includes an idempotency processing step for the expense details, wherein the idempotency processing of the expense details specifically includes: The target measurement data is stored in an immutable mode in the original measurement event storage area; Assign a rule version identifier to each pricing rule in the pricing rule set, and generate a new rule version identifier when the pricing rule is changed; When generating the fee details, the rule version identifier and billing time window corresponding to the fee details are recorded; In response to a billing recalculation request, the corresponding target metering data is retrieved from the original metering event storage area according to the rule version identifier and billing time window specified in the billing recalculation request, and the fee details are recalculated using the pricing rules of the specified rule version.

8. A multi-cloud network automated delivery and billing device, characterized in that, The multi-cloud network automated delivery and billing apparatus includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors invoke the computer instructions to cause the multi-cloud network automated delivery and billing apparatus to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the multi-cloud network automated delivery and billing device, the multi-cloud network automated delivery and billing device performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on a multi-cloud network automated delivery and billing device, the multi-cloud network automated delivery and billing device performs the method as described in any one of claims 1-7.

Images