Cloud-native product order management method and system

Abstract

The present invention belongs to the technical field of software development, and specifically relates to a cloud-native product order management method and system. The method comprises: S1, acquiring a unified ordering entry, which supports multi-channel ordering, wherein whether the channel is a public cloud can be determined on the basis of a channel type; S2, if the channel is a public cloud, connecting to a BSS in the public cloud, so as to complete an order message and issue same to an orderproxy_consumer order consumption service to undergo processing; and S3, receiving, from an orderproxy order service, the order message sent by the orderproxy_consumer order consumption service and an order message of a non-public-cloud channel, and on the basis of the types of input parameters, implementing different business processing flows, wherein during the business processing flows, multiple threads are used to implement Kafka message pushing and consumption. The cloud-native product order management method and system can be used in various cloud-native product order management scenarios on cloud platforms, and can also be used in scenarios such as cloud platform component ordering, order cancellation, suspension, resumption, renewal and scaling, and connection scenarios involving cloud platform orders, work orders and component consoles.

Description

A cloud-native product order management method and system

[0001] This application claims priority to Chinese patent application number CN202311718236.4, filed on December 14, 2023, entitled “A Cloud Native Product Order Management Method and System,” the entire text of which is hereby incorporated by reference. Technical Field

[0002] The present invention belongs to the field of software development technology, and specifically relates to a cloud-native product order management method and system. Background Art

[0003] Cloud-native applications are applications designed for the cloud. By leveraging cloud-native technologies, developers no longer need to worry about underlying technical implementations, leveraging the elasticity and distributed nature of cloud platforms to achieve rapid deployment, on-demand scaling, and seamless delivery. In the e-commerce sector, cloud-native technologies are particularly applicable across all aspects of the business, including product management, order processing, and payment settlement. Containerization enables rapid deployment and elastic scaling, improving system reliability and stability. Furthermore, cloud-native technologies enable multi-channel sales, supporting seamless switching between mobile and PC platforms, and enhancing the user experience.

[0004] In actual use, the types and sources of cloud-native products that need to be loaded on the cloud platform continue to increase, and the business handled becomes more and more complex. Therefore, this patent provides a stable and reliable cloud-native order management technical solution. Summary of the Invention

[0005] The purpose of the present invention is to provide a cloud-native product order management method and system, which can be used in various cloud platform cloud-native product order management scenarios, and can also be used in cloud platform component subscription, cancellation, shutdown, resumption, renewal, expansion and other scenarios as well as cloud platform order, work order, and component console docking scenarios.

[0006] The technical solutions adopted by the present invention are as follows:

[0007] A cloud-native product order management method, comprising:

[0008] S1. Obtain a unified ordering portal that supports multi-channel ordering and can determine whether the channel is a public cloud based on the channel type;

[0009] S2. If it is a public cloud, then in the public cloud, connect to the BSS system to complete the order message and send it to the orderproxy_consumer order consumption service for processing;

[0010] S3 and the orderproxy order service receive order messages from the orderproxy_consumer order consumption service and order messages from non-public cloud channels, and implement different business processing flows based on the type of input parameters.

[0011] Among them, in the business processing flow, multi-threading is used to implement Kafka message push and consumption.

[0012] In a preferred solution, the step of determining whether the channel is a public cloud based on the channel type includes:

[0013] Receive parameters: channel type busiChannel, resource pool identifier regionUuid, tenant identifier tenantId, and product information vo;

[0014] Formulate a channel strategy and determine whether the current system supports the channel based on the channel type busiChannel. If it does, continue with the following steps; otherwise, return an error message.

[0015] Formulate a resource pool strategy and determine whether it is a public cloud based on the resource pool identifier regionUuid and the tenant identifier tenantId; if it is a public cloud, jump to step S2, otherwise jump to step S3.

[0016] In a preferred solution, the steps of connecting to the BSS system in the public cloud to complete the order message and issue the orderproxy_consumer order consumption service include:

[0017] Obtain the consumption BSS order message, perform preliminary analysis on the order message, and determine whether the consumption and analysis are successful;

[0018] If consumption and parsing are successful, the preliminarily parsed order data will be pushed to the local message queue; otherwise, the message will be discarded and an error log will be printed;

[0019] Obtain and consume local order messages and determine whether consumption and parsing are successful. If consumption is successful, call the orderproxy service; otherwise, log the error message and discard the message.

[0020] In a preferred solution, the process of obtaining the consumer BSS order message and performing preliminary analysis on the order message includes:

[0021] According to the product information vo, based on the BSS system openproxy service protocol, use http to remotely call the BSS order interface. If successful, the order message will be sent to RabbitMq;

[0022] In the orderproxy_consumer service, a "secondary consumption" mechanism is used to achieve smooth consumption of order messages;

[0023] The consumer class BssOrderConsumer listens to the BSS order message queue Q0, consumes the original message data S0, and performs preliminary analysis.

[0024] In a preferred solution, the acquisition and consumption of local order messages uses the consumer class consumeRetryQueue to monitor the local order message queue Q1 to realize the consumption of order data S1.

[0025] In a preferred solution, the process of implementing different business processing flows according to the type of input parameters includes:

[0026] Get the business type actionType in the order information prodReqVO, and call different business implementation classes according to actionType;

[0027] Get the product prodType in prodReqVO and call different component business implementation classes according to prodType;

[0028] For business data processing, except for adding new data, all other actions must ensure atomicity;

[0029] After business data processing, obtain the work order information operationDO, call the work order service according to operationDO, and complete the construction process;

[0030] After the construction process is completed, the completed receipt data S2 is pushed to the local receipt message queue Q2;

[0031] NofityConsumer monitors the receipt message queue Q2. If the consumption is successful, the business status is updated to complete the business process closed loop.

[0032] In a preferred embodiment, the business data processing includes the following steps:

[0033] Based on the business type, call the component implementation class to assemble the business data and determine whether the business is pre-occupied;

[0034] If there is no pre-occupancy, a distributed lock key is set and an attempt is made to lock it. If the lock is successful, a pre-occupancy is added to the order. If the lock is unsuccessful, a prompt is given that an order is already in transit.

[0035] After an order is added or reserved, business data is stored in the database, and order data and instance numbers are added, deleted, and modified. After success, the distributed lock is closed.

[0036] Enable multi-threaded sending of Kafka, and multi-threaded consumer listens to it. After successful consumption, it determines whether the call is successful and performs different operations.

[0037] In a preferred solution, the steps of calling the component implementation class to assemble the business data according to the business type and determining whether the business is pre-occupied include:

[0038] Call the component implementation class group to fill in the order business data according to the business type actionType, and obtain the filled order data orderDatailVo;

[0039] Use ThreadLocalUtil as a pre-occupied tool class, where the pre-occupancy is a custom lock;

[0040] Get the tenant ID based on orderDatailVo, and set the pre-occupied key K1 based on the tenant ID;

[0041] Use orderDatailVo as the pre-occupied content value, i.e. V1;

[0042] Check whether there is pre-occupancy information. If so, directly enter the business data into the database. Otherwise, continue with the following steps.

[0043] Set the distributed lock key (K2) based on K1 and attempt to perform distributed lock tryLock. If the lock is successful, add a pre-emption message with K1 and V1. Otherwise, indicate that there is an order in progress.

[0044] Enter business data into the database.

[0045] In a preferred solution, the process of enabling multi-threaded sending of Kafka and being monitored by multi-threaded consumer classes, determining whether the call is successful after successful consumption, and performing different operations is as follows:

[0046] Enable multi-threaded AsyncCallable to push order messages after batch business processing to Kafka queue Q2;

[0047] The multi-threaded consumer listens to queue Q2. After successful consumption, it directly calls the work order service. If the call is successful, the process ends.

[0048] Otherwise, after setting the cooling time, the queue message is put into the delayed consumption queue Q3. The data in the delayed consumption queue can be consumed multiple times until the set number of times is exceeded.

[0049] The present invention also provides a cloud-native product order management system, which is applied to the above-mentioned cloud-native product order management method, and the system includes:

[0050] The ordering module is used to provide users with a unified ordering portal, support multi-channel ordering, and perform different processing according to the channel type;

[0051] The channel determination module can determine whether the channel is a public cloud based on the channel type;

[0052] An order processing module, which is used to process the order message after judgment;

[0053] A work order processing module is used to provide work order services for processed orders.

[0054] The technical effects achieved by the present invention are: providing a full life cycle management solution for cloud product order management, and proposing a "secondary consumption" mechanism for smooth consumption. At the same time, it adopts pre-occupancy + distributed locks to implement atomic operations, making the analysis of orders more accurate. Based on this, the present invention provides a high-reliability technical solution for multi-threaded message push and message consumption.

[0055] The present invention can be used in various cloud platform cloud-native product order management scenarios, and can also be used in cloud platform component subscription, cancellation, shutdown, resumption, renewal, expansion and other scenarios as well as cloud platform order, work order, and component console docking scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] FIG1 is a system flow chart of the present invention;

[0057] FIG2 is a system flow chart of the present invention;

[0058] FIG3 is a flow chart of the public cloud docking BSS system in the present invention;

[0059] FIG4 is a flow chart of BSS order message consumption in the present invention;

[0060] FIG5 is a flowchart of business data processing in the present invention;

[0061] FIG6 is a system framework diagram of the present invention. DETAILED DESCRIPTION

[0062] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0063] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0064] Secondly, the term "one embodiment" or "embodiment" herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in a preferred embodiment" appearing in various places throughout this specification does not necessarily refer to the same embodiment, nor does it constitute a separate or selective embodiment that is mutually exclusive of other embodiments.

[0065] 1 and 2 , which illustrate a first embodiment of the present invention, providing a cloud-native product order management method, including S1: obtaining a unified ordering portal, the ordering portal supporting multi-channel ordering and determining whether the channel is a public cloud based on the channel type;

[0066] S2. If it is a public cloud, then in the public cloud, connect to the BSS system to complete the order message and send it to the orderproxy_consumer order consumption service for processing;

[0067] S3 and the orderproxy order service receive order messages from the orderproxy_consumer order consumption service and order messages from non-public cloud channels, and implement different business processing flows based on the type of input parameters.

[0068] Among them, in the business processing flow, multi-threading is used to implement Kafka message push and consumption.

[0069] In the above approach, by determining the channel type, separate processing is performed through public and private clouds, and the processed order messages and non-public cloud order messages are processed for business purposes, ultimately implementing solutions for different processes. Based on this, this solution provides a unified order portal and supports solutions for different business processes, including subscriptions, cancellations, shutdowns, resumptions, renewals, and expansions. It also provides solutions for processing orders from different sources, including public and private clouds. It also supports loading new products, SaaS products, and Pass products.

[0070] Among them, the multiple channels mentioned above include but are not limited to operation platforms, cloud computer APP, Tianyi Cloud Portal, component console, OpenAPI and other channels. Other channels that meet the requirements can be applied and will not be described in detail here.

[0071] Secondly, the steps to determine whether the channel is a public cloud include:

[0072] Receive parameters: channel type busiChannel, resource pool identifier regionUuid, tenant identifier tenantId, and product information vo;

[0073] Formulate a channel strategy and determine whether the current system supports the channel based on the channel type busiChannel. If it does, continue with the following steps; otherwise, return an error message.

[0074] Formulate a resource pool strategy and determine whether it is a public cloud based on the resource pool identifier regionUuid and the tenant identifier tenantId; if it is a public cloud, jump to step S2, otherwise jump to step S3.

[0075] In the above method, by receiving various parameters and formulating channel strategies to determine whether the system supports the channel, and based on the judgment results to determine whether to execute the next step, if supported, the resource pool strategy is used to determine whether it is a public cloud, which can be quickly determined.

[0076] Specifically, as shown in Figures 3 and 4, when it is determined to be a public cloud, the BSS system is connected in the public cloud to complete the order message and send it to the orderproxy_consumer order consumption service for processing. The specific steps include:

[0077] Obtain the consumption BSS order message, perform preliminary analysis on the order message, and determine whether the consumption and analysis are successful;

[0078] If consumption and parsing are successful, the preliminarily parsed order data will be pushed to the local message queue; otherwise, the message will be discarded and an error log will be printed;

[0079] Obtain and consume local order messages and determine whether consumption and parsing are successful. If consumption is successful, call the orderproxy service; otherwise, log the error message and discard the message.

[0080] In a preferred embodiment, the process of obtaining a consumer BSS order message and performing preliminary parsing on the order message is shown in FIG3 , and specifically includes:

[0081] According to the product information vo, based on the BSS system openproxy service protocol, use http to remotely call the BSS order interface. If successful, the order message will be sent to RabbitMq;

[0082] In the orderproxy_consumer service, a "secondary consumption" mechanism is used to achieve smooth consumption of order messages;

[0083] The consumer class BssOrderConsumer listens to the BSS order message queue Q0, consumes the original message data S0, and performs preliminary analysis.

[0084] The acquisition and consumption of local order messages uses the consumer class consumeRetryQueue to monitor the local order message queue Q1 to realize the consumption of order data S1.

[0085] In a preferred embodiment, the process of implementing different business processing flows according to the type of input parameters includes:

[0086] Get the business type actionType in the order information prodReqVO, and call different business implementation classes according to actionType;

[0087] Get the product prodType in prodReqVO and call different component business implementation classes according to prodType;

[0088] For business data processing, except for adding new data, all other actions must ensure atomicity;

[0089] After business data processing, obtain the work order information operationDO, call the work order service according to operationDO, and complete the construction process;

[0090] After the construction process is completed, the completed receipt data S2 is pushed to the local receipt message queue Q2;

[0091] NofityConsumer monitors the receipt message queue Q2. If the consumption is successful, the business status is updated to complete the business process closed loop.

[0092] In the above, referring to FIG5 , the business data processing includes the following steps:

[0093] Based on the business type, call the component implementation class to assemble the business data and determine whether the business is pre-occupied;

[0094] If there is no pre-occupancy, a distributed lock key is set and an attempt is made to lock it. If the lock is successful, a pre-occupancy is added to the order. If the lock is unsuccessful, a prompt is given that an order is already in transit.

[0095] After an order is added or reserved, business data is stored in the database, and order data and instance numbers are added, deleted, and modified. After success, the distributed lock is closed.

[0096] Enable multi-threaded sending of Kafka, and multi-threaded consumer listens to it. After successful consumption, it determines whether the call is successful and performs different operations.

[0097] The steps of calling the component implementation class to assemble business data according to the business type and determining whether the business is pre-occupied include:

[0098] Call the component implementation class group to fill in the order business data according to the business type actionType, and obtain the filled order data orderDatailVo;

[0099] Use ThreadLocalUtil as a pre-occupied tool class, where the pre-occupancy is a custom lock;

[0100] Get the tenant ID based on orderDatailVo, and set the pre-occupied key K1 based on the tenant ID;

[0101] Use orderDatailVo as the pre-occupied content value, i.e. V1;

[0102] Check whether there is pre-occupancy information. If so, directly enter the business data into the database. Otherwise, continue with the following steps.

[0103] Set the distributed lock key (K2) based on K1 and attempt to perform distributed lock tryLock. If the lock is successful, add a pre-emption message with K1 and V1. Otherwise, indicate that there is an order in progress.

[0104] Enter business data into the database.

[0105] Specifically, enable multi-threaded sending of Kafka, and have multi-threaded consumer listen to it. After consumption is successful, determine whether the call is successful and perform different operations as follows:

[0106] Enable multi-threaded AsyncCallable to push order messages after batch business processing to Kafka queue Q2;

[0107] The multi-threaded consumer listens to queue Q2. After successful consumption, it directly calls the work order service. If the call is successful, the process ends.

[0108] Otherwise, after setting the cooling time, the queue message is put into the delayed consumption queue Q3. The data in the delayed consumption queue can be consumed multiple times until the set number of times is exceeded.

[0109] As shown in FIG6 , the present invention further provides a cloud-native product order management system, which includes:

[0110] The ordering module is used to provide users with a unified ordering portal, support multi-channel ordering, and perform different processing according to the channel type;

[0111] The channel determination module can determine whether the channel is a public cloud based on the channel type;

[0112] An order processing module, which is used to process the order message after judgment;

[0113] A work order processing module is used to provide work order services for processed orders.

[0114] The present invention provides a full life cycle management solution for cloud product order management. By providing a unified order portal, it supports processing solutions for different business processes, including ordering, cancellation, shutdown, resumption, renewal, expansion, etc., and provides processing solutions for orders from different sources, including public cloud, private cloud, etc., as well as solutions that support loading new products, SaaS products and Pass products.

[0115] The foregoing is merely a preferred embodiment of the present invention. It should be noted that those skilled in the art may make various improvements and modifications without departing from the principles of the present invention, and such improvements and modifications are also within the scope of protection of the present invention. Structures, devices, and operating methods not specifically described or explained herein shall, unless otherwise specified or limited, be implemented in accordance with conventional means in the art.

Claims

1. A cloud-native product order management method, characterized in that: include: S1. Obtain a unified ordering portal, which supports multi-channel ordering and can determine whether the channel is a public cloud based on the channel type; S2. If it is a public cloud, in the public cloud, connect to the BSS system to complete the order message and send it to the orderproxy_consumer order consumption service for processing; S3, orderproxy order service receives order messages from orderproxy_consumer order consumption service and order messages from non-public cloud channels, and implements different business processing flows according to the type of input parameters; Among them, in the business processing flow, multi-threading is used to implement Kafka message push and consumption.

2. The cloud-native product order management method according to claim 1, characterized in that: The step of determining whether the channel is a public cloud according to the channel type includes: Receive parameters: channel type busiChannel, resource pool identifier regionUuid, tenant identifier tenantId, and product information vo; Formulate a channel strategy and determine whether the current system supports the channel based on the channel type busiChannel. If it does, continue with the following steps. Otherwise, return an error message. Formulate a resource pool strategy and determine whether it is a public cloud based on the resource pool identifier regionUuid and the tenant identifier tenantId; if it is a public cloud, jump to step S2, otherwise jump to step S3.

3. The cloud-native product order management method according to claim 1, characterized in that: The steps of connecting to the BSS system to complete the order message and send the orderproxy_consumer order consumption service in the public cloud include: Obtain the BSS order message for consumption, perform preliminary analysis on the order message, and determine whether the consumption and analysis are successful; If the consumption and parsing are successful, the order data after preliminary parsing will be pushed to the local message queue, otherwise the message will be discarded and the error log will be printed; Get the local order message and determine whether it is consumed and parsed successfully. If it is consumed successfully, call the orderproxy service. Otherwise, record the error message and discard the message.

4. The cloud native product order management method according to claim 3, characterized in that: The process of obtaining the consumption BSS order message and performing preliminary analysis on the order message includes: According to the product information vo, based on the BSS system openproxy service protocol, use http to remotely call the BSS order interface. After success, the order message will be sent to RabbitMq; In the orderproxy_consumer service, the "secondary consumption" mechanism is adopted to achieve smooth consumption of order messages; The consumer class BssOrderConsumer listens to the order message queue Q0 of BSS, consumes the original message data S0, and performs preliminary analysis.

5. The cloud-native product order management method according to claim 3, characterized in that: The acquisition and consumption of local order messages uses the consumer class consumeRetryQueue to monitor the local order message queue Q1 to realize the consumption of order data S1.

6. The cloud native product order management method according to claim 1, characterized in that: The process of implementing different business processing flows according to the type of input parameters includes: Get the business type actionType in the order information prodReqVO, and call different business implementation classes according to actionType; Get the product prodType in prodReqVO, and call different component business implementation classes according to prodType; For business data processing, except for adding new data, all other actions must ensure atomicity; After business data processing, obtain the work order information operationDO, call the work order service according to operationDO, and complete the construction process; After the construction process is completed, the completed receipt data S2 is pushed to the local receipt message queue Q2; NofityConsumer monitors the receipt message queue Q2. If the consumption is successful, the business status is updated to complete the business process closed loop.

7. The cloud-native product order management method according to claim 6, characterized in that: The business data processing comprises the following steps: According to the business type, call the component implementation class to assemble the business data and determine whether the business is pre-occupied; If there is no pre-occupancy, set the distributed lock key and try to lock it. If the lock is successful, add a pre-occupancy to the order. If the lock is unsuccessful, it will prompt that there is an order in transit. After an order is added or reserved, business data is stored in the database, and order data and instance numbers are added, deleted, and modified. After success, the distributed lock is closed. Enable multi-threaded sending of Kafka, and listen to it by multi-threaded consumers. After successful consumption, determine whether the call is successful and perform different operations.

8. The cloud-native product order management method according to claim 7, characterized in that: The steps of calling the component implementation class to assemble business data according to the business type and determining whether the business is pre-occupied include: Call the component implementation class group to fill in the order business data according to the business type actionType, and obtain the filled order data orderDatailVo; Use ThreadLocalUtil as a pre-occupied tool class, where the pre-occupancy is a custom lock; Get the tenant id according to orderDatailVo, and set the reserved key K1 according to the tenant id; Use orderDatailVo as the pre-occupied content value, i.e. V1; Check whether there is pre-occupancy information. If so, directly perform the business data storage operation. Otherwise, continue with the following steps; Set the distributed lock key according to K1, that is, K2, and try to perform distributed lock tryLock. If the lock is successful, add a pre-occupied message with K1 and V1. Otherwise, it prompts that there is an order being processed. Enter business data into the database.

9. The cloud-native product order management method according to claim 7, characterized in that: The process of enabling multi-threaded sending of Kafka and being monitored by multi-threaded consumers, determining whether the call is successful after successful consumption, and performing different operations is as follows: Enable multi-threaded AsyncCallable to push order messages after batch business processing to Kafka to queue Q2; The multi-threaded consumer listens to queue Q2. After consumption is successful, the work order service is directly called. If the call is successful, the process ends. Otherwise, after setting the cooling time, the queue message is put into the delayed consumption queue Q3; the data in the delayed consumption queue can be consumed multiple times until the set number is exceeded.

10. A cloud-native product order management system, characterized in that: The cloud-native product order management method applied to any one of claims 1 to 9 above, the system comprising: An ordering module, which is used to provide users with a unified ordering portal, supports multi-channel ordering, and performs different processing according to the channel type; The channel determination module can determine whether the channel is a public cloud based on the channel type; An order processing module, which is used to process the determined order message; A work order processing module, wherein the work order processing module is used to provide work order services for processed orders.

Images