A method for orderly billing of multiple cloud products

Abstract

The present invention belongs to the field of cloud technology, specifically, a method for orderly billing of multiple cloud products, comprising the following steps: step one, determining the relationship between products purchased by a user, step two, establishing a product relationship diagram according to the relationship between the purchased products, step three, generating a billing event message according to the user's behavior of changing the product status, step four, packaging usage sampling data into a billing event message at a fixed time node, step five, binding the billing event message to the product relationship diagram, step six, performing cyclic billing on the product relationship diagram, and step seven, storing the bill; the present invention not only enables the billing of basic cloud computing products to be executed first and run first when arrears are incurred by establishing a product relationship diagram; but also enables the billing sequence to be established by adding associations between previous and subsequent bills in the bill, so that the reconciliation can accurately locate the wrong account position and help analyze the cause of the wrong account.

Description

Technical Field

[0001] The present invention belongs to the field of cloud technology, and in particular, relates to a method for orderly billing of multiple cloud products. Background Art

[0002] In recent years, the market demand for cloud computing has become increasingly diverse. Therefore, cloud computing service providers have provided products and corresponding billing models at all levels, from networks, storage, servers to operating systems and software.

[0003] Most existing cloud computing products are charged in parallel at fixed time nodes, for example, multiple threads are opened for all products at every hour or every midnight to generate bills. Although this method reduces the difficulty of development, if there are wrong accounts in the bills generated at these time nodes, it is difficult to locate the wrong accounts based on the balance and order of the bills. At the same time, the trend of cloud computing products gradually developing towards customer customization has led to the segmentation of products and their billing models, and more complex service relationships have emerged between products. For example, a NAT gateway deployed on the edge of a computing cluster composed of multiple elastic servers (ECS) needs to serve the elastic servers. The existing billing method cannot give priority to the operation of products involved in important businesses when some products are in arrears, and cannot enable users to obtain better services. Summary of the invention

[0004] In view of the shortcomings of the prior art, the present invention discloses a method for orderly billing of multiple cloud products. By establishing a product relationship diagram, the billing of basic cloud computing products can be prioritized and priority can be given to operations when there is arrears.

[0005] The specific technical solution adopted by the present invention is as follows:

[0006] A method for orderly billing of multiple cloud products includes the following steps:

[0007] Step 1: Determine the relationship between the products purchased by the user.

[0008] Step 2: Create a product relationship diagram based on the relationship between the purchased products.

[0009] Step 3: Generate a billing event message based on the user's behavior of changing the product status.

[0010] Step 4: Pack the usage sampling data into billing event messages at fixed time nodes.

[0011] Step 5: Bind the billing event message to the product relationship diagram.

[0012] Step 6: Perform recurring billing on the product relationship diagram.

[0013] Step 7. Save the bill.

[0014] A further improvement of the present invention is that in the step one, determining the relationship between the products purchased by the user refers to determining the architecture diagram or deployment status of the service cluster composed of the products purchased by the user, taking each instance of each type of product as a product, and all products forming a product set, making a Cartesian product of the product set with itself, excluding tuples in which two products are the same, and judging whether the following binary relationship exists between each remaining group of two products: one product A is started and the other product B is not started, at which time the minimum operating indicators of the service cluster are not met or certain requirements of the customer are not met, and distinguishing the symmetry of the binary relationship.

[0015] Furthermore, the symmetry of distinguishing binary relations means that if the binary relation between two products in a tuple is symmetric, then the two products are defined as a cooperative relation, denoted as A&B; if the binary relation between two products in a tuple is antisymmetric, then the two products are defined as a priority relation, denoted as<A,B> , indicating that B takes precedence over A in startup.

[0016] In a further improvement of the present invention, in step 2, establishing a product relationship graph based on the relationship between the purchased products means that, from the relationships of all tuples, for the same products in the cooperative relationship, such as A&B and B&C, all products A, B, and C in the relationship are aggregated into the vertices of a directed graph, and for the priority relationship, such as<A,B> , then establish a directed arc from the vertex containing product A to the vertex containing product B. Finally, each product that has not yet been included in the graph is regarded as a vertex of a directed graph, thus forming a product relationship graph.

[0017] A further improvement of the present invention is that in step three, generating a billing event message based on the user's behavior of changing the product status means that when the user makes behaviors such as purchasing a product, using a product, and ending the use of a product, the vertex containing the target product is found in the product relationship graph, and starting from the vertex, all reachable vertices are found, and the information of all products in the found vertices are packaged into billing event messages respectively.

[0018] Furthermore, packaging the information of all products in the found vertices into billing event messages means obtaining the user id, obtaining the product id, obtaining the usage of the product since the last billing event or time node, obtaining the product unit price, obtaining the billing event type, obtaining the time when the user changes the product status and the last billing event or time node time as the billing start time and billing end time, and combining the above information into a billing event message for a product of the user.

[0019] A further improvement of the present invention, in the step four, packaging the usage sampling data into a billing event message at a fixed time node means sampling the usage of all purchased products of the user since the last billing event or time node at a fixed time node, and packaging the usage of each product into a billing event message respectively.

[0020] Furthermore, packaging the usage of each product into a billing event message means obtaining the user ID, obtaining the product ID, obtaining the product usage, obtaining the product unit price, obtaining the billing event type, obtaining the sampling time and the previous billing event or time node time as the billing start time and billing end time, and combining the above information into a billing event message for a product of the user.

[0021] A further improvement of the present invention, in step five, the binding of the billing event message with the product relationship graph means that after obtaining the billing event message, the billing system finds the user's product relationship graph according to the user ID, establishes tuples between the billing event message and the vertices in the product relationship graph with the same product ID, and arranges the tuples of each vertex in chronological order.

[0022] A further improvement of the present invention, in step six, the cyclic billing of the product relationship graph means that the billing system cyclically reads each vertex in the product relationship graph of each user in parallel, and for each vertex, reads all billing event messages in all tuples that are not marked as "billing completed" from the current moment forward, which is called set P, and then reads all billing event messages in all predecessor vertex tuples of the vertex that are not marked as "billing completed", which is called set Q. If a billing event message X in P contains a time period from the billing start time to the billing end time, but all billing event messages in Q do not contain this time period, then billing event message X is executed for billing and marked as "billing completed", otherwise billing event message X is temporarily skipped.

[0023] Furthermore, the execution of billing on the billing event message X refers to determining which billing rule applies to the billing event message X according to the billing event type, calculating the consumption amount, the balance after consumption, the billing start time, the billing end time, and the billing completion time according to the billing rule and the data in the billing event message, obtaining the pre_exchange_id, i.e., the id of the previously completed bill, and generating the exchange_id, i.e., the id of the current bill.

[0024] A further improvement of the present invention is that in step seven, storing the bill means storing the bill consisting of pre_exchange_id, exchange_id, user id, product id, billing event type, billing start time, billing end time, billing completion time, balance, balance after consumption, consumption amount, etc. in a database, and the previous and subsequent bills reflect the time sequence through pre_exchange_id and exchange_id.

[0025] Beneficial effects of the present invention: The present invention can not only prioritize the billing of basic cloud computing products by establishing a product relationship diagram, and prioritize operation when fees are in arrears; but also establish a billing sequence by adding associations between previous and subsequent bills in the bill, so that reconciliation can accurately locate the location of the wrong account and help analyze the cause of the wrong account. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a schematic diagram of the process of the present invention.

[0027] Figure 2 It is a schematic diagram of a cloud computing cluster architecture in the present invention.

[0028] Figure 3 It is a user-product relationship diagram in the present invention.

[0029] Figure 4 It is a schematic diagram of binding a product relationship diagram and a billing event message in the present invention.

[0030] Figure 5 It is a schematic diagram of the structure of a billing system in the present invention. DETAILED DESCRIPTION

[0031] In order to deepen the understanding of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. The embodiments are only used to explain the present invention and do not limit the protection scope of the present invention.

[0032] Example: Figure 1 As shown, a method for orderly billing of multiple cloud products includes the following steps:

[0033] Step 1: Determine the relationship between the products purchased by the user.

[0034] Step 2: Create a product relationship diagram based on the relationship between the purchased products.

[0035] Step 3: Generate a billing event message based on the user's behavior of changing the product status.

[0036] Step 4: Pack the usage sampling data into billing event messages at fixed time nodes.

[0037] Step 5: Bind the billing event message to the product relationship diagram.

[0038] Step 6: Perform recurring billing on the product relationship diagram.

[0039] Step 7. Save the bill.

[0040] like Figure 2 As shown, the user can determine to adopt the cloud computing cluster architecture by self-service or by communicating with the cloud computing service provider's salesperson, which includes six cloud product instances: VPC gateway (201), elastic server A (202), elastic server B (203), elastic server C (204), elastic file service (205), and object storage (206). 202, 203, 205, and 206 can complete the main tasks delivered by the user by starting them. The VPC gateway (201) is responsible for isolating the computing cluster composed of 201, 202, 203, 204, and 205 from the public cloud, and the elastic server C (204) is used for non-main tasks of the user. All products form a set {201, 202, 203, 204, 205, 206}. Taking the Cartesian product with itself and excluding tuples where two products are the same, we get: {(201, 202), (201, 203), (201, 204), (201, 205), (201, 206), (202, 203), (202, 204), (202, 205), (202, 206), (203, 204), (203, 205), (203, 206), (204, 205), (204, 206), (205, 206)}. Determine whether the following binary relationship exists between the remaining two products in each group: one product is started and the other is not started, and the minimum operating index of the service cluster is not met or some customer requirements are not met. For example, when 201 is started and 202 is not started, other products are running normally by default, and the main tasks delivered by the user cannot be met; when 202 is started and 201 is not started, the main tasks delivered by the user are met, so 202 is started before 201, and there is a priority relationship <201, 202>. Finally, all tuples contain the relationship: <201, 202>, <201, 203>, <201, 205>, <201, 206>, 202&203, 202&205, 202&206, 203&205, 203&206, 205&206.

[0041] In step 1, all tuples obtained contain the following relations: <201, 202>, <201, 203>, <201, 205>, <201, 206>, 202&203, 202&205, 202&206, 203&205, 203&206, 205&206. First, for the same products in the cooperative relationship, aggregate all products in the relationship into the vertices of a directed graph, such as 202&203, 202&205, 202&206, 203&205, 203&206, 205&206, to form Figure 3 301 in the example includes products 202, 203, 205, and 206. Then, a directed arc is established for the precedence relationship, for example, <201, 202>. Figure 3 302 points to Figure 3 Finally, each product that has not been included in the graph is regarded as a vertex of the directed graph. For example, product 204 is not included in the graph, so it is regarded as a vertex of the directed graph. Figure 3 303 in China.

[0042] In step three, a billing event message is generated according to the user's behavior of changing the product status.

[0043] In this embodiment, when the user ends the use of product VPC gateway 201, Figure 3 Find vertex 302 in the user-product relationship graph, and find vertex 301 reached from 302. Then, for VPC gateway 201, elastic server A 202, elastic server B 203, elastic file service 205, and object storage 206, obtain the user ID, obtain each product ID, obtain the usage of the product since the last billing event or time node from the metering system, obtain the product unit price, and obtain the billing event type, generally in a coded manner, such as the integer "3" can be used to indicate that the user ends the use, obtain the time when the user ends the use and the time of the last billing event or time node as the billing start time and billing end time, and combine the above information into a billing event message for a product of the user.

[0044] Step 4: Pack the usage sampling data into a billing event message at a fixed time node.

[0045] When the time reaches 13:00, the usage of all purchased products of the user since the last billing event or time node is obtained from the metering system, the user ID is obtained, each product ID is obtained, the product usage is obtained, the product unit price is obtained, and the billing event type is obtained, generally in a coded manner. For example, the integer "4" can be used to represent system billing. The sampling time and the last billing event or time node time are obtained as the billing start time and billing end time, and the above information is combined into a billing event message for a product of the user.

[0046] Step 5: Bind the billing event message to the product relationship diagram.

[0047] exist Figure 4 In the illustrated embodiment, after obtaining the billing event message, the billing system finds the user's product relationship graph according to the user ID, and creates a tuple (402) of the billing event message with the same product ID and the vertex in the product relationship graph. The billing event ID and the vertex ID can be used to create the tuple, such as "JF033" representing the billing event ID and "V401" representing the vertex ID. At the same time, the tuples of each vertex are arranged in time sequence, 402 is added to the queue (403), and sorted in reverse order according to the billing start time and billing end time (404) in the billing event message.

[0048] Step six is ​​to perform recurring billing on the product relationship diagram.

[0049] exist Figure 4 In the illustrated embodiment, the billing system reads each vertex in the product relationship graph of each user in parallel and cyclically. For vertex (401), the billing event messages not marked as "billing completed" in all tuples are read from the queue (403). The set consisting of these billing event messages is called set P. Then, the billing event messages not marked as "billing completed" in all predecessor vertex tuples of 401 are read, which is called set Q. Set Q is an empty set. A billing event message X in P includes a time period from the billing start time to the billing end time. Q is an empty set and does not include the time period X. Then, which billing rule is applicable to the billing event message X according to the billing event type, the current balance is obtained according to the user id, the consumption amount is calculated using the product usage and the product unit price, the post-consumption balance is calculated using the current balance and the consumption amount, the billing start time, the billing end time and the billing completion time are obtained, the pre_exchange_id, i.e., the id of the previous completed bill, is obtained, the exchange_id, i.e., the id of the current bill, is generated, and X is marked as "billing completed".

[0050] Step 7: Save the bill.

[0051] The bill is composed of pre_exchange_id, exchange_id, user id, product id, billing event type, billing start time, billing end time, billing completion time, balance, balance after consumption, consumption amount, etc. and stored in the database. The previous and subsequent bills reflect the time sequence through pre_exchange_id and exchange_id.

[0052] like Figure 5 As shown, a schematic diagram of the structure of a billing system in this embodiment includes:

[0053] The product determination relationship determination module 501 is used to determine the relationship between the products purchased by the user; the product relationship diagram establishment module 502 is used to establish a product relationship diagram based on the relationship between the purchased products; the user behavior response module 503 is used to generate a billing event message based on the user's behavior of changing the product status; the sampling module 504 is used to package the usage sampling data into a billing event message at a fixed time node; the billing event message receiving module 505 and the binding relationship module 506 are used to bind the billing event message to the product relationship diagram; the billing module 507 is used to perform cyclic billing on the product relationship diagram; the bill storage module 508 is used to store bills

[0054] The above shows and describes the basic principles, main features and advantages of the present invention. It should be understood by those skilled in the art that the present invention is not limited to the above embodiments. The above embodiments and descriptions are only for explaining the principles of the present invention. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, which fall within the scope of the present invention to be protected. The scope of protection of the present invention is defined by the attached claims and their equivalents.

Claims

1. A method for orderly billing of multiple cloud products, characterized in that: The following steps are involved: Step 1: Determine the relationship between the products purchased by the user. Step 2: Create a product relationship diagram based on the relationship between the purchased products. Step 3: Generate a billing event message based on the user's behavior of changing the product status. Step 4: Pack the usage sampling data into billing event messages at fixed time nodes. Step 5: Bind the billing event message to the product relationship diagram. Step 6: Perform recurring billing on the product relationship diagram. Step 7: Store the bill; The step 1 determines the architecture diagram or deployment of the service cluster composed of the products purchased by the user, takes each instance of each type of product as a product, and all products form a product set. The product set is subjected to a Cartesian product with itself, and tuples in which two products are the same are excluded, and it is determined whether there is a binary relationship between the two products in each remaining group: if the binary relationship between the two products in the tuple is symmetrical, the two products are defined as a cooperative relationship; if the binary relationship between the two products in the tuple is antisymmetric, the two products are defined as a priority relationship; In step 2, from the relationships of all tuples, the same products in the cooperation relationship are aggregated into the vertices of a directed graph. For the priority relationship, a directed arc is established from the vertex containing the product to the vertex containing another product. Finally, each product that has not yet been included in the graph is used as a vertex of a directed graph to form a product relationship graph. When the user purchases, uses, and ends the use of a product, the vertex containing the target product is found in the product relationship graph. Starting from the vertex, all reachable vertices are found, and the information of all products in the found vertices are packaged into billing event messages. The step 3 obtains the user ID, obtains the product ID, obtains the usage of the product since the last billing event or time node, obtains the product unit price, obtains the billing event type, obtains the time when the user changes the product status and the last billing event or time node time as the billing start time and billing end time, and combines the above information into a billing event message for a product of the user; The fourth step is to sample the usage of all the products purchased by the user since the last billing event or time node at a fixed time node, package the usage of each product into a billing event message, obtain the user ID, obtain the product ID, obtain the product usage, obtain the product unit price, obtain the billing event type, obtain the sampling time and the last billing event or time node time as the billing start time and billing end time, and combine the above information into a billing event message for a product of the user; In step 5, after obtaining the billing event message, the billing system finds the user's product relationship graph according to the user ID, creates tuples of the billing event messages with the same product ID and the vertices in the product relationship graph, and arranges the tuples of each vertex in chronological order.

2. The method for orderly billing of multiple cloud products according to claim 1, characterized in that: In step six, the billing system cyclically reads each vertex in the product relationship graph of each user in parallel. For each vertex, all billing event messages not marked as "billing completed" in the binary tuples starting from the current moment are read forward, which is called set P. Then, all billing event messages not marked as "billing completed" in the binary tuples of all predecessor vertices of the vertex are read, which is called set Q. If a billing event message X in P contains a time period from the billing start time to the billing end time, but all billing event messages in Q do not contain this time period, then billing is performed on the billing event message X and marked as "billing completed". Otherwise, the billing event message X is temporarily skipped. According to the billing event type, it is determined which billing rule is applicable to the billing event message X. According to the billing rule and the data in the billing event message, the consumption amount, the balance after consumption, the billing start time, the billing end time, and the billing completion time are calculated. The pre_exchange_id, i.e., the id of the previous completed bill, is obtained, and the exchange_id, i.e., the id of this bill, is generated.

3. The method for orderly billing of multiple cloud products according to claim 2, characterized in that: In step seven, the pre_exchange_id, exchange_id, user id, product id, billing event type, billing start time, billing end time, billing completion time, balance, balance after consumption, and consumption amount are combined into a bill and stored in the database. The previous and subsequent bills reflect the time sequence through pre_exchange_id and exchange_id.

Images