Digital product online leasing system based on cloud native micro-service architecture and construction method thereof

Abstract

The invention discloses a digital product online leasing system based on a cloud native micro-service architecture and a construction method thereof, and the method specifically comprises the steps: firstly, carrying out containerized deployment and micro-service hierarchical design, including a plurality of business modules of user service, product management, leasing order, payment settlement, credit evaluation and recommendation, and enabling each module to operate in an independent service form; efficient cooperation is realized through service registration and discovery; a cloud native platform is utilized to realize elastic expansion and automatic operation and maintenance of the system, lease life cycle management is realized through an event-driven mechanism, links of ordering, payment, delivery, lease renewal, return and maintenance are covered, and a credit determination and risk control mechanism is introduced to support multiple lease modes such as detention-free lease and the like. The digital product leasing platform supports multi-terminal access and unified entrance management, has good system expansibility and leasing service flexibility, improves the concurrent processing capability, deployment efficiency and user experience of the digital product leasing platform, and has wide commercial application prospects.

Description

Technical Field

[0001] The present invention relates to the technical field of digital product rental, and in particular to an online digital product rental system based on a cloud-native microservice architecture and a construction method thereof. Background Art

[0002] With the rapid development of the consumer electronics market, digital product prices have been rising year by year, leading consumers to place higher demands on device lifecycle flexibility and capital expenditure flexibility. At the same time, the "renting instead of buying" consumption concept is gaining acceptance among users, giving rise to digital product rental platforms. However, existing online rental platforms generally utilize monolithic application architectures or traditional centralized systems, which present complex deployment, poor scalability, high module coupling, and difficulty meeting high concurrent access requirements. These platforms struggle to support diverse rental business logic and continuously growing user demand.

[0003] Furthermore, the digital product rental business itself involves multiple key processes, including user registration and authentication, product management, inventory tracking, rental order creation and follow-up, payment and settlement, equipment return and maintenance, and extensive cross-module data interaction. In traditional architectures, these processes are often centralized in single applications or limited service nodes, resulting in insufficient system stability and fault tolerance. Failure of some modules can render the entire service unavailable. Furthermore, as the business scales, the platform's demand for operational and maintenance capabilities, such as elastic scaling, independent module upgrades, and phased releases, is increasing. Traditional systems are no longer able to meet the needs of business development.

[0004] In recent years, cloud-native technologies have rapidly developed, with concepts such as containerized deployment, microservices architecture, service mesh, and DevOps being widely applied in large-scale distributed systems. This cloud-native microservices architecture can decompose complex systems into multiple loosely coupled, independently deployable service units based on functionality. This architecture, enabled by container orchestration platforms such as Kubernetes, enables elastic management and automatic scaling, significantly improving system flexibility and stability. Introducing this architecture into a digital product rental platform enables dynamic resource scheduling, service fault-tolerant isolation, modular operations, and continuous delivery in high-concurrency scenarios, significantly improving user experience and platform operational efficiency.

[0005] Therefore, there is an urgent need to build an online digital product rental system that integrates a cloud-native microservice architecture to solve the technical bottlenecks of the existing platform in terms of scalability, flexibility, stability and intelligent services, and meet the increasingly complex business scenarios and diversified user needs. Summary of the Invention

[0006] The purpose of the present invention is to provide an online digital product rental system based on a cloud-native microservice architecture and a construction method thereof, which has strong scalability, strong flexibility, simple system maintenance, high service reliability, high rental process efficiency, good user experience, and strong platform operation capabilities.

[0007] The technical solution to achieve the purpose of the present invention is: a method for constructing an online digital product rental system based on a cloud-native microservice architecture, comprising the following steps:

[0008] Step 1: Deploy the cloud-native operating environment, initialize the system, and complete the construction and configuration of the containerized platform;

[0009] Step 2: Design a leasing business process management module. Through event-driven architecture and microservice-oriented decoupling design, achieve full-process support for users in the digital product leasing process, and introduce credit judgment and risk control mechanisms to support multiple leasing models.

[0010] Furthermore, the cloud-native operating environment described in step 1 is deployed, the system is initialized, and the containerized platform is built and configured as follows:

[0011] Step 1.1: Deploy a cloud-native operating environment, including container platform and Kubernetes cluster deployment, as well as GitOps toolchain and configuration center access.

[0012] Step 1.2: Initialize the microservice module, including service startup and configuration loading, service registration and interconnection mechanism, and core module initialization behavior;

[0013] Step 1.3: Initialize data services and caches, including data source connection and structure verification, cache warming and synchronization mechanisms, multi-data source support, and sharding strategies.

[0014] Step 1.4: Initialize the gateway and unified access services, including routing rule loading and reverse proxy configuration, authentication control and traffic management, multi-terminal access, and security policy loading.

[0015] Step 1.5: Initialize the message queue and event bus, including middleware startup and topic configuration, consumer logic registration and processing mechanism;

[0016] Step 1.6: Configure health check probes and monitoring core components to perform health checks and generate system status reports.

[0017] Furthermore, the deployment of the cloud-native operating environment described in step 1.1 is as follows:

[0018] Step 1.1.1: Deploy the container platform and Kubernetes cluster.

[0019] Use Docker as the running container, build each microservice unit into an independent image, and upload it to a private image repository;

[0020] Start the Kubernetes container orchestration platform, configure the master node and multiple worker nodes, divide the namespaces to isolate different service groups, and install network plug-ins to support intra-cluster service communication;

[0021] Step 1.1.2: Connect the GitOps toolchain to the configuration center.

[0022] Deploy the GitOps toolchain and use ArgoCD or Flux to connect the code repository with the Kubernetes API to automatically pull configurations and synchronize versions, enabling continuous integration and deployment of services.

[0023] Build a configuration center and use Nacos or Spring Cloud Config to centrally manage the configuration parameters of each service to ensure that each service can obtain environment variables, database configuration, and current limiting parameter information in real time when it starts.

[0024] Furthermore, the initialization microservice module described in step 1.2 is as follows:

[0025] Step 1.2.1, service startup and configuration loading, as follows:

[0026] The business logic is divided into several core microservice units, including user services, product management, order services, payment services, credit services, and recommendation services. When each microservice starts, it first connects to the configuration center to obtain the dynamic configuration required for operation, including database address, cache parameters, and message queue topics. It then establishes a database connection pool and initializes the index structure, common data cache, and local state machine.

[0027] Step 1.2.2, service registration and interconnection mechanism, as follows:

[0028] Start the service registration mechanism. Each microservice registers its network address and health status with the service registration center Eureka or Consul to support dynamic discovery and calling between services. After the service is successfully registered, the microservice starts the local thread pool and prepares to receive external API calls or internal message queue instructions.

[0029] Step 1.2.3: Initialization of the core module is as follows:

[0030] The user service module loads the authentication mechanism and connects to the external identity authentication system; the product management module synchronizes inventory and SKU metadata to the cache; the order service module builds a state machine for the rental status flow and starts the status synchronization thread; the payment service module connects to multiple payment channels and listens for asynchronous callback events; the credit service module and the recommendation service module load model parameters, start the credit scoring and personalized recommendation engines respectively.

[0031] Furthermore, the initialization of data services and cache described in step 1.3 is as follows:

[0032] Step 1.3.1: Data source connection and structure verification, as follows:

[0033] The system connects relational and non-relational databases and manages data access requests between services through the connection pool component. After establishing the connection pool, the system performs a database pre-check, including version verification, table structure detection, and master-slave status confirmation, to ensure that the data layer is operating normally.

[0034] Step 1.3.2, cache preheating and synchronization mechanism, as follows:

[0035] The system loads Redis as a cache to preheat hot data. Cache preheating is completed through asynchronous threads, batch reading data from the database and writing it to the cache, setting expiration time and update policy. The cache service deployment adopts a master-slave structure with fault switching and data persistence capabilities.

[0036] Step 1.3.3, multiple data source support and sharding strategy, as follows:

[0037] The system supports dividing data sources by business modules and presetting data sharding or database partitioning strategies to provide a capacity expansion basis for subsequent business growth.

[0038] Furthermore, the initialization of the gateway and unified access service described in step 1.4 is as follows:

[0039] Step 1.4.1, routing rule loading and reverse proxy configuration, as follows:

[0040] During the initialization phase, the system starts the API gateway service and serves as the entry point for all terminal requests to implement unified access control and traffic scheduling at the platform level. After the API gateway is started, it loads all routing rules, service mapping relationships, and authentication policies from the configuration center and establishes a routing table based on the dynamic service list of the service registration center.

[0041] Step 1.4.2, authentication control and traffic management, are as follows:

[0042] The gateway identifies the target service based on the request path and finds the corresponding service instance through the service discovery mechanism to complete the reverse proxy forwarding. The gateway has built-in flow control and circuit breaker mechanisms to control the flow of high-frequency requests and avoid overloading the backend service. The unified authentication module verifies the user identity through token verification or third-party login and intercepts illegal requests.

[0043] Step 1.4.3, multi-terminal access and security policy loading, is as follows:

[0044] Load security policies, including blacklist and whitelist policies, anti-spam interface settings, and log recording templates, to ensure the stability and security of the system entrance; the gateway itself is also deployed as a container, and the number of instances is dynamically expanded according to traffic. It supports web, mobile, mini-programs, and open platform access methods to achieve unified multi-terminal access capabilities.

[0045] Furthermore, the initialization of the message queue and event bus described in step 1.5 is as follows:

[0046] Step 1.5.1, middleware startup and theme configuration, as follows:

[0047] The system introduces an event-driven architecture to achieve asynchronous decoupling and process linkage between microservices. During the initialization phase, Kafka or RabbitMQ message queue services are started, various business topics are predefined, and corresponding producer and consumer roles are assigned to each service.

[0048] Step 1.5.2, consumption logic registration and processing mechanism, as follows:

[0049] Each service registers an event listener at startup, binds the topic of interest, and initializes the processing logic; when the event bus receives a message, the system automatically calls the listening method of the corresponding service to complete the response processing; the event queue also supports message persistence and multiple retry mechanisms to ensure that key business processes are not interrupted by temporary failures.

[0050] Furthermore, the health check probes and monitoring core components described in step 1.6 are configured to perform health checks and generate system status reports, as follows:

[0051] Step 1.6.1: All service containers are configured with health check probes during deployment, including Liveness Probe and Readiness Probe. Kubernetes periodically checks the liveness and readiness of services and automatically restarts or removes traffic for abnormal instances.

[0052] Step 1.6.2: Deploy Prometheus as the core monitoring component. Use Exporter to collect performance metrics for each service, including response time, error rate, CPU usage, and memory usage. Then, transmit the data to the Grafana panel for visualization.

[0053] Step 1.6.3: The logging system collects and aggregates standard output and error logs through Fluentd or Loki, providing centralized query and tracing capabilities.

[0054] Step 1.6.4: Generate a startup report for the initialization process, including the startup time, abnormal alarms, and configuration loading status of all services. This report provides O&M personnel with a basis for auditing the startup status and serves as a foundation for fault location and performance optimization.

[0055] Furthermore, the leasing business process management module described in step 2 is designed to provide full-process support for users in the digital product leasing process through an event-driven architecture and a decoupled microservice-oriented design. It also introduces a credit assessment and risk control mechanism to support various leasing models, as follows:

[0056] Step 2.1: Design the user authentication and credit assessment interaction module as follows:

[0057] Step 2.1.1: When a user first accesses the rental system and registers or logs in, the request is first intercepted by the API Gateway and forwarded to the user service module. The user service module verifies the user's identity through the OAuth2.0 authentication service, completes token issuance and session initialization, and records the device identifier and source platform metadata for subsequent behavior analysis.

[0058] Step 2.1.2: The user service initiates a preliminary credit rating request to the credit risk control service through a synchronous REST interface. The credit service module uses a rule engine to call a third-party credit reporting platform or load a local credit scoring model to extract the user profile, historical performance records, and scoring dimensions to generate a preliminary credit score.

[0059] Step 2.1.3: The preliminary credit score is pushed to the credit_score topic of Kafka as an asynchronous event. The user service asynchronously consumes the score to update the local cache and reads the current deposit exemption policy from the configuration center to determine whether the user has deposit exemption permission.

[0060] Step 2.2: Design the product browsing and order creation collaboration module as follows:

[0061] Step 2.2.1: After the user enters the product list page, the API gateway at the access layer forwards the request to the product management service module. The product management service module is responsible for querying the cache for available product SKUs, inventory status, and rental price information, and returning the results to the front end.

[0062] Step 2.2.2: When a user clicks on a specific product, the system queries the user's historical behavior and profile through the recommendation and pricing service module, dynamically adjusts the displayed price, or pushes similar products and promotions;

[0063] Step 2.2.3: When a user initiates a rental intention, the front-end will send an order creation request to the order service module with the product information and user ID. The order service will encapsulate the current request as a rental intention event and trigger a pre-rental verification, including inventory locking, credit check result confirmation, and rental period compliance verification. Once the verification is passed, the system officially creates the rental order, generates a unique order number and status record, and sets the initial status of the order to "pending deposit processing";

[0064] Step 2.2.4: Order information is sent to the payment service and risk control service via the Kafka message queue.

[0065] Step 2.3: Design the deposit processing and payment settlement linkage module, as follows:

[0066] Step 2.3.1: During the deposit processing phase, the system automatically determines whether a deposit is required based on the user's credit rating. If the user meets the deposit-free requirements, the order will proceed directly to the next stage. If a deposit is required, the front-end page will guide the user into the payment process.

[0067] Step 2.3.2: After receiving the "deposit freeze" request, the payment service module calls the third-party payment platform interface to complete the fund freezing operation and monitor the callback result;

[0068] Step 2.3.3: After payment is completed, the payment service sends a "deposit successful" event to the order service and credit service. The former is used to update the order status to "pending shipment", and the latter synchronously updates the user's fulfillment record.

[0069] Step 2.3.4: If the payment fails, the system will roll back the deposit freeze status and prompt the user to re-submit the request;

[0070] Step 2.4: Design the module for linking delivery scheduling and lease start-up, as follows:

[0071] Step 2.4.1: After the deposit is successfully processed, the order service sends a "shipping notification" event to the logistics scheduling system through the event queue. After receiving the message, the logistics service module assigns a courier and waybill number, writes the logistics information into the order extended information table, and sends a notification to the user.

[0072] Step 2.4.2: When the platform detects the courier receipt confirmation, the system will trigger the "Lease Start" event. The order service will update the order status to "Lease in Progress" and start the lease countdown management mechanism.

[0073] Step 2.4.3: Synchronize the order status to the operation and maintenance monitoring service to start the equipment usage monitoring and maintenance plan management process;

[0074] Step 2.5: Design the usage period management and renewal reminder interaction module as follows:

[0075] Step 2.5.1: During the user's rental period, the Order Service periodically sends user behavior data, including device usage frequency and number of abnormal requests, to the Recommendation Service and Credit Service based on the recorded rental start and end times to assess current usage status and risk level.

[0076] Step 2.5.2: The system starts the scheduled task engine and sends a "lease expiration" reminder message to the user based on the lease contract rules;

[0077] Step 2.5.3: When the user chooses to renew the lease, the system initiates the order modification process, including lease extension, fee supplement, and payment confirmation, which is handled jointly by the order service and the payment service;

[0078] Step 2.5.4: If the user does not renew the lease and the lease is nearing its end, the system will automatically mark the device as "pending return" and push a return instruction to the user and operation and maintenance end to arrange for the device to be recycled;

[0079] Step 2.6: Design the return process and equipment acceptance module, as follows:

[0080] Step 2.6.1: After the user actively returns the device or the system pushes a return instruction, the logistics service assigns a door-to-door pickup or courier return task, and the device is put into storage by scanning the QR code on the device.

[0081] Step 2.6.2: After receiving the equipment, the operation and maintenance service module will perform a status check and functional test on the equipment. If there are no obvious faults or damage, the equipment will be marked as "reusable" and the order status will be updated to "pending settlement." If a problem is detected, the equipment will be marked as "unreusable" and the order status will be updated to "pending maintenance." A maintenance work order will be generated and the maintenance team will be notified.

[0082] Step 2.6.3: Synchronously push the device status to the order service and credit service, which will serve as the basis for subsequent deposit release and credit score update.

[0083] Step 2.7: Design the deposit release and order archiving modules as follows:

[0084] Step 2.7.1: After the acceptance is completed, the payment service module decides whether to release the deposit based on the operation and maintenance feedback. If the device is intact, the system will call the third-party payment interface to unfreeze the funds and send a payment notification to the user. The order service will update the order status to "Completed" and seal all related records of the order.

[0085] Step 2.7.2: If the device is damaged, the system will generate a compensation bill and guide the user to complete the additional payment. The remaining deposit will be released only after the payment is successful;

[0086] Step 2.7.3: The operation and maintenance service will classify the equipment into the warehouse, and the credit service will adjust the user's credit rating based on the performance of this lease.

[0087] A digital product online rental system based on a cloud-native microservices architecture, constructed using the aforementioned construction method, is deployed in a container cloud environment and includes an access layer, a business service layer, a data service layer, and an operation and maintenance support layer;

[0088] The access layer is the component directly connected to the end user. As the interface layer between the user equipment and the network system, it is responsible for user access authentication, service distribution and local information processing.

[0089] The business service layer is used to provide the system's business configuration, parse the configuration information into database entities, establish a mapping relationship between the business model and the database entity, and provide business model parsing services for the access layer;

[0090] The data service layer manages data access requests between services through a connection pool component;

[0091] The operation and maintenance support layer establishes a service infrastructure framework based on cloud native technology and microservice architecture, so that each business module has the ability of decoupled communication, expansion, automatic recovery and dynamic configuration during subsequent operation.

[0092] Compared with the existing technology, the present invention has the following significant advantages: (1) Based on cloud native technology and microservice architecture, it solves the bottlenecks of traditional leasing platforms in scalability, flexibility, service availability, system maintenance and business collaboration, improves the flexibility and scalability of the digital product online leasing system, reduces system maintenance costs, and improves system work efficiency; (2) By introducing cloud native technology and microservice architecture, it realizes modularization, elasticity, intelligence and automated management and control of the entire process of digital product leasing, improves the platform's concurrent processing capability, service reliability and leasing process efficiency, and improves user experience and platform operation capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0093] Figure 1This is a structural diagram of a digital product online rental system based on a cloud-native microservice architecture of the present invention.

[0094] Figure 2 It is a flow chart of the online rental business of digital products in the present invention. DETAILED DESCRIPTION

[0095] This invention aims to provide a method and system for online digital product rentals based on a cloud-native microservices architecture, addressing bottlenecks in traditional rental platforms, including scalability, flexibility, service availability, system maintenance, and business collaboration. By introducing cloud-native technologies and a microservices architecture, the system achieves modular, flexible, intelligent, and automated management and control of the entire digital product rental process, enhancing the platform's concurrent processing capabilities, service reliability, and rental process efficiency, ultimately improving user experience and platform operational capabilities.

[0096] Combine Figure 1 , the present invention provides a digital product online rental system based on cloud native microservice architecture, which is deployed in a container cloud environment and includes an access layer, a business service layer, a data service layer and an operation and maintenance support layer;

[0097] The access layer is the component directly connected to the end user. As the interface layer between the user equipment and the network system, it is responsible for user access authentication, service distribution and local information processing.

[0098] The business service layer is used to provide the system's business configuration, parse the configuration information into database entities, establish a mapping relationship between the business model and the database entity, and provide business model parsing services for the access layer;

[0099] The data service layer manages data access requests between services through a connection pool component;

[0100] The operation and maintenance support layer establishes a highly available and elastically scalable service infrastructure framework based on cloud native technology and microservice architecture, enabling each business module to have decoupled communication, rapid expansion, automatic recovery and dynamic configuration capabilities during subsequent operation.

[0101] The present invention provides a method for constructing an online digital product rental system based on a cloud-native microservice architecture, comprising the following steps:

[0102] Step 1: Build an online digital product rental system based on a cloud-native microservices architecture, deploy a cloud-native operating environment, initialize the system, and complete the construction and configuration of the containerized platform. The details are as follows:

[0103] The system initialization of this invention is the primary step in ensuring the proper operation of the online digital product rental platform based on a cloud-native microservices architecture. It encompasses everything from preparing the cloud infrastructure and launching the microservices modules to initializing and configuring various middleware, gateways, caches, and event systems. During this phase, the system establishes a highly available and elastically scalable service infrastructure, enabling each business module to utilize decoupled communication, rapid expansion, automatic recovery, and dynamic configuration capabilities during subsequent operation. By rationally planning the system initialization process, platform deployment efficiency, operational stability, and ease of maintenance can be effectively improved.

[0104] Step 1.1: Deploy the cloud-native operating environment, including the container platform and Kubernetes cluster deployment, as well as the GitOps toolchain and configuration center access. Detailed instructions are as follows:

[0105] Step 1.1.1: Deploy the container platform and Kubernetes cluster.

[0106] Deploy a cloud-native operating environment and complete the construction and configuration of a containerized platform. The system uses Docker as the operating container, builds each microservice unit into an independent image, and uploads it to a private image repository.

[0107] Start the Kubernetes container orchestration platform, configure the master node and multiple worker nodes, divide the namespaces to isolate different service groups, and install network plug-ins to support intra-cluster service communication;

[0108] Step 1.1.2: Connect the GitOps toolchain to the configuration center.

[0109] Deploy the GitOps toolchain and use ArgoCD or Flux to connect the code repository with the Kubernetes API to automatically pull configurations and synchronize versions, enabling continuous integration and deployment of services.

[0110] In addition, the system initialization phase also includes building a configuration center and using Nacos or Spring Cloud Config to centrally manage the configuration parameters of each service, ensuring that each service can obtain key information such as environment variables, database configuration, and current limiting parameters in real time when it starts.

[0111] Step 1.2: Initialize the microservice module, including service startup and configuration loading, service registration and interconnection mechanism, and the initialization behavior of the core module, as follows:

[0112] Step 1.2.1, service startup and configuration loading, as follows:

[0113] The business logic is divided into several core microservice units, including user services, product management, order services, payment services, credit services, and recommendation services. When each microservice starts, it first connects to the configuration center to obtain the dynamic configuration required for its operation, including the database address, cache parameters, and message queue topics. It then establishes a database connection pool and initializes the index structure, common data cache, and local state machine.

[0114] Step 1.2.2, service registration and interconnection mechanism, as follows:

[0115] Start the service registration mechanism. Each microservice registers its network address and health status with the service registration center (such as Eureka or Consul) to support dynamic discovery and calling between services. After the service is successfully registered, the microservice starts the local thread pool and prepares to receive external API calls or internal message queue instructions.

[0116] Step 1.2.3: Initialization of the core module is as follows:

[0117] The user service module loads the authentication mechanism and connects to the external identity authentication system. The product management module synchronizes inventory and SKU metadata to the cache. The order service module builds a state machine for rental status flow and starts the status synchronization thread. The payment service module connects to multiple payment channels and listens for asynchronous callback events. The credit service module and recommendation service module load model parameters respectively and start the credit scoring and personalized recommendation engines.

[0118] Step 1.3: Initialize data services and caches, including data source connection and structure verification, cache warming and synchronization mechanism, multi-data source support, and sharding strategy. Details are as follows:

[0119] Step 1.3.1: Data source connection and structure verification, as follows:

[0120] The data support layer plays a connecting role during system initialization and is key to ensuring efficient read and write operations and state consistency for microservices. During the initialization phase, the system first connects to relational databases (such as MySQL) and non-relational databases (such as MongoDB), and manages data access requests between services through the connection pool component. After establishing the connection pool, the system performs a database pre-check, including version verification, table structure detection, and master-slave status confirmation, to ensure the normal operation of the data layer.

[0121] Step 1.3.2, cache preheating and synchronization mechanism, as follows:

[0122] The system loads Redis as a high-performance cache to preheat hot data such as popular products, rental configurations, and user profiles to reduce database access pressure and speed up response time. Cache preheating is completed through asynchronous threads, batch reading data from the database and writing it to the cache, with reasonable expiration time and update policies set. The cache service deployment adopts a master-slave structure, with fault switching and data persistence capabilities.

[0123] Step 1.3.3, multiple data source support and sharding strategy, as follows:

[0124] To support high availability and scalability of data, the system supports dividing data sources by business modules and presetting data sharding or database partitioning strategies to provide a capacity expansion basis for subsequent business growth.

[0125] Step 1.4: Initialize the gateway and unified access services, including routing rule loading and reverse proxy configuration, authentication control and traffic management, multi-terminal access, and security policy loading. Details are as follows:

[0126] Step 1.4.1, routing rule loading and reverse proxy configuration, as follows:

[0127] During the initialization phase, the system starts the API gateway service and uses it as the entry point for all terminal requests to achieve unified access control and traffic scheduling at the platform level. After the API gateway is started, it loads all routing rules, service mapping relationships, and authentication policies from the configuration center and establishes a routing table based on the dynamic service list of the service registration center.

[0128] Step 1.4.2, authentication control and traffic management, are as follows:

[0129] The gateway identifies the target service based on the request path and finds the corresponding service instance through the service discovery mechanism to complete the reverse proxy forwarding. The gateway has built-in flow control and circuit breaker mechanisms to control the flow of high-frequency requests and avoid overloading the backend service. The unified authentication module verifies the user identity through token verification or third-party login and intercepts illegal requests.

[0130] Step 1.4.3, multi-terminal access and security policy loading, is as follows:

[0131] Load security policies, including blacklist and whitelist policies, anti-spam interface settings, and log recording templates, to ensure the stability and security of the system entrance; the gateway itself is also deployed as a container, and the number of instances can be dynamically expanded according to traffic. It supports Web, mobile, mini-programs, and open platform access methods to achieve true multi-terminal unified access capabilities.

[0132] Step 1.5: Initialize the message queue and event bus, including middleware startup and topic configuration, consumer logic registration and processing mechanism, as follows:

[0133] Step 1.5.1, middleware startup and theme configuration, as follows:

[0134] The system introduces an event-driven architecture to achieve asynchronous decoupling and process linkage between microservices. During the initialization phase, Kafka or RabbitMQ message queue services are started, and various business topics are predefined, such as "order creation event", "payment completion event", "device return event", etc., and corresponding producer and consumer roles are assigned to each service.

[0135] Step 1.5.2, consumption logic registration and processing mechanism, as follows:

[0136] At startup, each service registers an event listener, binds its topic of interest, and initializes its processing logic. When the event bus receives a message, the system automatically calls the corresponding service's listener method to complete the response, such as generating a rental voucher, updating inventory status, or triggering a recommendation algorithm. The event queue also supports message persistence and multiple retry mechanisms to ensure that critical business processes are not interrupted by temporary failures.

[0137] 1.5.3. Asynchronous decoupling and system fault tolerance, as follows:

[0138] The introduction of the event mechanism has greatly reduced the coupling between services, making the platform more fault-tolerant and scalable, and enabling it to operate efficiently and stably in complex business scenarios.

[0139] Step 1.6: Configure the health check probe and monitoring core components to perform health checks and generate system status reports, as follows:

[0140] Step 1.6.1, container probe mechanism and fault self-recovery, are as follows:

[0141] All service containers are configured with health check probes during deployment, including Liveness Probe and Readiness Probe. Kubernetes periodically checks the liveness and readiness of services and automatically restarts or removes traffic for abnormal instances.

[0142] Step 1.6.2, Performance Monitoring and Visualization Dashboard, as follows:

[0143] The system deploys Prometheus as the core monitoring component, and uses Exporter to collect performance indicators of each service, including response time, error rate, CPU usage, and memory usage, and transmits the data to the Grafana panel for visualization.

[0144] Step 1.6.3, log collection and initiation of audit report, is as follows:

[0145] The logging system collects and aggregates standard output and error logs through Fluentd or Loki, providing centralized query and tracing capabilities;

[0146] The initialization process generates a startup report, including the startup time, abnormal alarms, and configuration loading status of all services, providing operation and maintenance personnel with a basis for startup status audit and serving as the basis for fault location and performance optimization.

[0147] Step 2: Design a leasing business process management module. Through an event-driven architecture and microservice-oriented decoupling design, this module provides full support for users during the digital product leasing process.

[0148] The leasing business process management module proposed in the present invention realizes the full-process support for users in the process of renting digital products through the event-driven architecture (EDA) and the decoupling design for microservices. The service modules communicate with each other mainly through the Kafka asynchronous event stream, supplemented by gRPC or REST interfaces for key path communication, to ensure that the system has scalable, observable, recoverable and highly consistent business process processing capabilities in high-concurrency scenarios. The core process of the system is composed of a ternary mechanism of "user behavior triggering-microservice collaboration-state-driven advancement". Each stage is completed by the collaboration of at least two services, and the linkage of the service link of the next stage is driven by state transfer. Combined with Figure 2 , as follows:

[0149] Step 2.1: Design the user authentication and credit assessment interaction module as follows:

[0150] Step 2.1.1: When a user first accesses the rental system and registers or logs in, the request is first intercepted by the API Gateway and forwarded to the user service module. The user service module verifies the user's identity through the OAuth2.0 authentication service, completes token issuance and session initialization, and records the device identifier and source platform metadata for subsequent behavior analysis.

[0151] Step 2.1.2: The user service initiates a preliminary credit rating request to the credit risk control service through a synchronous REST interface. The credit service module uses the rule engine to call a third-party credit reporting platform, such as the Sesame Credit API, or loads a local credit scoring model (TensorFlow Lite / ONNX) and deploys it in the inference engine. It extracts the user profile, historical performance records, and scoring dimensions to generate a preliminary credit score.

[0152] Step 2.1.3: The preliminary credit score is pushed to the credit_score topic of Kafka as an asynchronous event. The user service asynchronously consumes the score to update the local cache and reads the current deposit exemption policy from the configuration center to determine whether the user has deposit exemption permission.

[0153] The core technology of this stage is that the credit module uses a dual-stack judgment of reasoning services and rule strategies, and improves the response speed under concurrency through the event-writeback separation mechanism.

[0154] Step 2.2: Design the product browsing and order creation collaboration module as follows:

[0155] Step 2.2.1: After the user enters the product list page, the request is forwarded to the product management service module through the API gateway of the access layer. This module is responsible for querying the cache for available rental product SKUs, inventory status, and rental price information. The product service reads the product data from the Redis cache and returns the results to the front end. It also sets a local cache with a 2-second expiration time to alleviate the pressure of hot product queries.

[0156] Step 2.2.2: After the user clicks on the product details, the system loads the user's personalized recommendation results by synchronously calling the recommendation service interface. The recommendation service uses features such as user profile, rental history, and geographic location to construct collaborative filtering results and complete page rendering;

[0157] Step 2.2.3: After the user clicks "Rent Now," the front-end encapsulates parameters such as the product ID, lease period, and address and submits them to the order service module. The order service first establishes the initial order state as "pending deposit" based on a state machine framework, such as StateMachineEngine, and calls the product service's "inventory reservation" interface to lock inventory. The inventory locking operation is implemented through MySQL transactions combined with atomic modifications to the Redis inventory field to prevent overselling.

[0158] Step 2.2.4: The order service then sends an event to the order_created topic in Kafka, prompting the payment service and credit service to initiate pre-lease assessment and risk control calculations.

[0159] The key points of this stage are to ensure the idempotence of inventory locking and the atomicity of order status initialization. Distributed locks and Redis transaction Lua scripts are used to prevent status confusion under concurrency, and order creation events are distributed through the event bus to decouple downstream modules.

[0160] Step 2.3: Design the deposit processing and payment settlement linkage module, as follows:

[0161] Step 2.3.1: During the deposit processing phase, the system automatically determines whether a deposit is required based on the user's credit rating. If the user meets the deposit-free requirements, the order will proceed directly to the next stage. If a deposit is required, a freeze request is initiated through the REST interface using a third-party payment platform, such as the Alipay face-to-face payment API or WeChat Pay V3.

[0162] Step 2.3.2: After receiving the "deposit freeze" request, the payment service module calls the third-party payment platform interface, writes the payment callback information to the Kafka payment_status topic, and updates the payment status table using idempotent logic;

[0163] Step 2.3.3: Once payment is complete, Kafka pushes "Payment Completed" and "Fulfillment Record Added" events to the Order Service and Credit Service, respectively. The former is used to switch the order status to "Pending Shipment" in the Order Service and simultaneously update the local order table and the order index in ElasticSearch. The latter is used to record the payment status in the user credit log table and serve as a sample for subsequent credit rating updates.

[0164] Step 2.3.4: If the payment fails, the system will roll back the deposit freeze status and prompt the user to re-submit the request;

[0165] The core of the payment stage lies in ensuring the eventual consistency of the funds status. The system adopts an idempotent consumption mechanism for payment services, such as an idempotent key + status bit check to avoid duplicate deductions, and achieves cross-service transaction consistency through three-dimensional binding of payment status → order status → credit status.

[0166] Step 2.4: Design the module for linking delivery scheduling and lease start-up, as follows:

[0167] Step 2.4.1: After the deposit is successfully processed, the order enters the "pending shipment" state. The order service will construct a "dispatch_request" event and publish it to the logistics_dispatch topic of Kafka, which will be consumed asynchronously by the logistics service module. The logistics service module calls a third-party express delivery interface, such as the SF Express API, to create an order, generate a waybill, and write the result back to the order extension information table. At the same time, it pushes a "logistics notification" message to the user service.

[0168] Step 2.4.2: The logistics system monitors the courier company's webhook interface and writes the receipt status to the Kafka topic "delivery_status". After the order service consumes this topic, the status is switched to "renting".

[0169] Step 2.4.3: Synchronously transmit the order status to the operation and maintenance monitoring service, and call the operation and maintenance service interface to start device monitoring tasks, such as installation status perception and power consumption detection;

[0170] This stage uses a logistics-driven lease start mechanism to avoid users manually confirming the start of the lease and improve the degree of process automation.

[0171] Step 2.5: Design the usage period management and renewal reminder interaction module as follows:

[0172] Step 2.5.1: During the user's rental period, the Order Service periodically sends user behavior data, including device usage frequency and number of abnormal requests, to the Recommendation Service and Credit Service based on the recorded rental start and end times to assess current usage status and risk level.

[0173] Step 2.5.2: The system starts the scheduled task engine and sends a "lease expiration" reminder message to the user based on the lease contract rules;

[0174] Step 2.5.3: When the user chooses to renew the lease, the system initiates the order modification process, including lease extension, fee supplement, and payment confirmation, which is handled jointly by the order service and the payment service;

[0175] Step 2.5.4: If the user does not renew the lease and the lease is nearing its end, the system will automatically mark the device as "pending return" and push a return instruction to the user and operation and maintenance end to arrange for the device to be recycled;

[0176] At this stage, the system introduces a state extrapolation mechanism to predict whether users will renew their leases based on their behavior, and controls the push frequency through a delay queue to prevent repeated reminders, reflecting intelligent scheduling capabilities.

[0177] Step 2.6: Design the return process and equipment acceptance module, as follows:

[0178] Step 2.6.1: When the rental period ends or the user initiates a return, the Order Service updates the order status to "Returning" and publishes a "return_request" event to Kafka. After receiving the return instruction, the Logistics Service reallocates the waybill, records the pickup time and estimated delivery time, assigns a door-to-door pickup or courier return task, and completes the device storage by scanning the QR code on the device.

[0179] Step 2.6.2: After receiving the equipment, the operation and maintenance service module will perform a status check and functional test on the equipment. If there are no obvious faults or damage, the equipment will be marked as "reusable" and the order status will be updated to "pending settlement." If a problem is detected, the equipment will be marked as "unreusable" and the order status will be updated to "pending maintenance." A maintenance work order will be generated and the maintenance team will be notified.

[0180] Step 2.6.3: Synchronously push the device status to the order service and credit service, which will serve as the basis for subsequent deposit release and credit score update.

[0181] The key technology in the equipment return process is the automatic alignment of the return inspection form data with the rental data, matching orders and hardware through key values ​​such as rental ID and equipment SN number to avoid data mismatch; in addition, the system supports mobile terminal scanning operations for operation and maintenance to realize automatic flow of operation and maintenance in the scene.

[0182] Step 2.7: Design the deposit release and order archiving modules as follows:

[0183] Step 2.7.1: After acceptance, the payment service module decides whether to release the deposit based on the operation and maintenance feedback. If the device is intact, the payment service initiates the deposit release process, calls the payment platform to unfreeze the device, and publishes a deposit_release event in Kafka. The order service and user service complete the order archiving and notification push, respectively.

[0184] Step 2.7.2: If the device is damaged, a compensation work order will be generated and the amount to be paid will be generated through the "Breach of Contract Handling Strategy" in the Configuration Center and sent to the user for confirmation of payment;

[0185] Step 2.7.3: The operation and maintenance service will classify the equipment into the warehouse, and the credit service will adjust the user's credit rating based on the performance of this lease.

[0186] This stage emphasizes the linkage between the release of deposit funds and the status of performance evaluation to form a complete leasing closed loop, ensure the complete archiving of post-lease data, and provide a basis for subsequent service recommendations and credit control.

[0187] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0188] Example

[0189] This embodiment provides a method for using a digital product online rental system based on a cloud-native microservices architecture, which includes the following stages:

[0190] (1) User authentication and credit assessment interaction stage

[0191] When a user first accesses the rental system and registers or logs in, the request is first intercepted by the API Gateway and forwarded to the user service module. The user service module verifies the user's identity through the OAuth2.0 authentication service, issues a token, initializes the session, and records metadata such as the device identifier and source platform for subsequent behavioral analysis. The user service then initiates a preliminary credit assessment request to the credit risk control service via a synchronous REST interface. The credit service module uses a rules engine to invoke a third-party credit reporting platform (such as the Sesame Credit API) or loads a local credit scoring model (TensorFlowLite / ONNX deployed within the inference engine). This model extracts the user's profile, historical performance history, and scoring dimensions to generate a preliminary credit score. This score is pushed asynchronously to the credit_score topic in Kafka. The user service consumes this asynchronously, updates the local cache, and reads the current deposit exemption policy from the configuration center to determine whether the user is eligible for deposit exemption. The key technical aspect of this phase lies in the credit module's dual-stack decision-making using both the inference service and the rules policy, coupled with an event-writeback decoupling mechanism to improve response speed under concurrent conditions.

[0192] (2) Product browsing and order creation collaboration stage

[0193] When a user browses a product, the frontend calls the REST interface exposed by the product service module to retrieve information such as the product SKU, rental price, and inventory. The product service caches the product data from Redis and sets a local cache with a 2-second expiration time to alleviate the pressure of querying popular products. When a user clicks on a product detail, the system synchronously calls the recommendation service interface to load the user's personalized recommendations. The recommendation service uses features such as user profile, rental history, and location to construct collaborative filtering results and complete page rendering.

[0194] After a user clicks "Rent Now," the front-end encapsulates parameters such as the product ID, lease period, and address and submits them to the order service module. The order service first establishes the initial order state as "Awaiting Deposit" using a state machine framework (such as StateMachineEngine) and calls the product service's "Inventory Pre-Occupation" API to lock inventory. This inventory lock operation is implemented using a MySQL transaction coupled with atomic modifications to the Redis inventory field to prevent overselling. The order service then sends an event to the Kafka topic "order_created," prompting the payment and credit services to initiate pre-rental assessments and risk control calculations.

[0195] The key points of this stage are to ensure the idempotence of inventory locking and the atomicity of order status initialization. Distributed locks and Redis transaction Lua scripts are used to prevent status confusion under concurrency, and order creation events are distributed through the event bus to decouple downstream modules.

[0196] (3) Deposit processing and payment settlement linkage stage

[0197] After the order is created, the payment service obtains the new order data by listening for the order_created event and reads the credit score to determine whether a deposit is required. If a deposit is required, it initiates a freeze request via the REST interface to a third-party payment platform (such as the Alipay face-to-face payment API or WeChat Pay V3). The payment service writes the payment callback information to the Kafka payment_status topic and updates the payment status table using idempotent logic. If the payment is successful, it pushes a "Payment Completed" and "Fulfillment Record Added" event to the Order and Credit services, respectively, via Kafka. Upon receiving the confirmation event, the Order service switches the order status to "Pending Shipment" and simultaneously updates the local order table and the order index in ElasticSearch. The Credit service records the payment status in the user's credit log table, which serves as a sample for subsequent credit rating updates.

[0198] The core of the payment stage lies in ensuring the eventual consistency of the funds status. The system uses the payment service idempotent consumption mechanism (such as idempotent key + status bit check) to avoid duplicate deductions, and achieves cross-service transaction consistency through three-dimensional binding of payment status → order status → credit status.

[0199] (4) Delivery scheduling and lease start linkage stage

[0200] When an order enters the "pending shipment" state, the order service constructs a "dispatch_request" event and publishes it to the logistics_dispatch topic in Kafka. This event is then asynchronously consumed by the logistics service module. The logistics service module then calls a third-party express delivery interface (such as the SF Express API) to create the order, generate a waybill, and write the result back to the order's extended information table. Simultaneously, it pushes a "logistics notification" message to the user service.

[0201] The system triggers the lease start based on the logistics receipt event. The specific process is as follows: the logistics system monitors the courier company's webhook interface and writes the receipt status to the Kafka topic "delivery_status". After the order service consumes this topic, it switches the status to "Leased" and calls the operation and maintenance service interface to initiate device monitoring tasks (such as installation status detection and power consumption detection). This stage uses a logistics-driven lease start mechanism, eliminating manual user confirmation of the lease start and improving process automation.

[0202] (5) Interaction stage of usage period management and renewal reminder

[0203] During the lease period, the order service maintains a scheduled task (based on Quartz or Kubernetes CronJob) to regularly check the remaining lease period and call the recommendation service to query whether there is a renewal intention signal. When the lease period enters the reminder period, the system publishes an "expiring soon" event to the user service, which notifies the user via SMS, app push, etc. If the user clicks to renew, the system will simultaneously update the order table, generate a renewal bill, and push it to the payment service for additional payment processing. The entire renewal chain reuses the initial order process, but creates a derived lease period node based on the original order as the anchor point, retaining the main order number to ensure the continuity of historical behavior.

[0204] At this stage, the system introduces a state extrapolation mechanism to predict whether users will renew their leases based on their behavior, and controls the push frequency through a delay queue to prevent repeated reminders, reflecting intelligent scheduling capabilities.

[0205] (6) Return process and equipment acceptance stage

[0206] At the end of the rental period or when the user initiates a return, the order service updates the order status to "returning" and publishes a "return_request" event to Kafka. Upon receiving the return instruction, the logistics service reallocates the waybill and records the pickup time and estimated delivery time. After the device is returned to the platform, the operation and maintenance service calls the QR code registration interface to confirm the device's ownership and rental number. It then performs a quick inspection of the device, including screen detection, battery performance, and system integrity. The inspection results are synchronized to the order service via the REST interface, which determines whether the device enters the "settlement in progress" or "maintenance processing" status.

[0207] The key technology in the equipment return process is the automatic alignment of the return inspection form data with the rental data, matching orders and hardware through key values ​​such as rental ID and equipment SN number to avoid data mismatch; in addition, the system supports mobile terminal scanning operations for operation and maintenance to realize automatic flow of operation and maintenance in the scene.

[0208] (7) Deposit release and order archiving stage

[0209] Once acceptance is passed, the payment service initiates the deposit release process, calls the payment platform to unfreeze the deposit, and publishes a deposit_release event to Kafka. The order service and user service complete the order archiving and push notifications, respectively. If acceptance fails, a compensation ticket is generated and the "default handling strategy" in the configuration center is used to calculate the outstanding payment amount, which is then sent to the user for payment confirmation. The system uses idempotent tokens to prevent duplicate calls to the deposit release interface, and all status changes are recorded in the audit log and asynchronous archiving storage.

[0210] After archiving is completed, the system will trigger a "credit score update" event, call the credit service to re-model the user's performance behavior, adjust the credit level and record the performance history.

[0211] This stage emphasizes the linkage between the release of deposit funds and the status of performance evaluation to form a complete leasing closed loop, ensure the complete archiving of post-lease data, and provide a basis for subsequent service recommendations and credit control.

[0212] The above are only preferred embodiments of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for constructing an online digital product rental system based on a cloud-native microservice architecture, characterized in that: The following steps are involved: Step 1: Deploy the cloud-native operating environment, initialize the system, and complete the construction and configuration of the containerized platform; Step 2: Design a leasing business process management module. Through event-driven architecture and microservice-oriented decoupling design, achieve full-process support for users in the digital product leasing process, and introduce credit judgment and risk control mechanisms to support multiple leasing models.

2. The method for constructing a digital product online rental system based on a cloud-native microservice architecture according to claim 1 is characterized in that: Deploy the cloud-native operating environment described in step 1, initialize the system, and complete the construction and configuration of the containerized platform as follows: Step 1.1: Deploy a cloud-native operating environment, including container platform and Kubernetes cluster deployment, as well as GitOps toolchain and configuration center access. Step 1.2: Initialize the microservice module, including service startup and configuration loading, service registration and interconnection mechanism, and core module initialization behavior; Step 1.3: Initialize data services and caches, including data source connection and structure verification, cache warming and synchronization mechanisms, multi-data source support, and sharding strategies. Step 1.4: Initialize the gateway and unified access services, including routing rule loading and reverse proxy configuration, authentication control and traffic management, multi-terminal access, and security policy loading. Step 1.5: Initialize the message queue and event bus, including middleware startup and topic configuration, consumer logic registration and processing mechanism; Step 1.6: Configure health check probes and monitoring core components to perform health checks and generate system status reports.

3. The method for constructing a digital product online rental system based on a cloud-native microservice architecture according to claim 2 is characterized in that: Deploy the cloud-native runtime environment described in step 1.1 as follows: Step 1.1.1: Deploy the container platform and Kubernetes cluster. Use Docker as the running container, build each microservice unit into an independent image, and upload it to a private image repository; Start the Kubernetes container orchestration platform, configure the master node and multiple worker nodes, divide the namespaces to isolate different service groups, and install network plug-ins to support intra-cluster service communication; Step 1.1.2: Connect the GitOps toolchain to the configuration center. Deploy the GitOps toolchain and use ArgoCD or Flux to connect the code repository with the Kubernetes API to automatically pull configurations and synchronize versions, enabling continuous integration and deployment of services. Build a configuration center and use Nacos or Spring Cloud Config to centrally manage the configuration parameters of each service to ensure that each service can obtain environment variables, database configuration, and current limiting parameter information in real time when it starts.

4. The method for constructing a digital product online rental system based on a cloud-native microservice architecture according to claim 2 is characterized in that: Initialize the microservice module described in step 1.2 as follows: Step 1.2.1, service startup and configuration loading, as follows: The business logic is divided into several core microservice units, including user services, product management, order services, payment services, credit services, and recommendation services. When each microservice starts, it first connects to the configuration center to obtain the dynamic configuration required for operation, including database address, cache parameters, and message queue topics. It then establishes a database connection pool and initializes the index structure, common data cache, and local state machine. Step 1.2.2, service registration and interconnection mechanism, as follows: Start the service registration mechanism. Each microservice registers its network address and health status with the service registration center Eureka or Consul to support dynamic discovery and calling between services. After the service is successfully registered, the microservice starts the local thread pool and prepares to receive external API calls or internal message queue instructions. Step 1.2.3: Initialization of the core module is as follows: The user service module loads the authentication mechanism and connects to the external identity authentication system; the product management module synchronizes inventory and SKU metadata to the cache; the order service module builds a state machine for the rental status flow and starts the status synchronization thread; the payment service module connects to multiple payment channels and listens for asynchronous callback events; the credit service module and the recommendation service module load model parameters, start the credit scoring and personalized recommendation engines respectively.

5. The method for constructing a digital product online rental system based on a cloud-native microservice architecture according to claim 2 is characterized in that: Initialize the data service and cache as described in step 1.3, as follows: Step 1.3.1: Data source connection and structure verification, as follows: The system connects relational and non-relational databases and manages data access requests between services through the connection pool component. After establishing the connection pool, the system performs a database pre-check, including version verification, table structure detection, and master-slave status confirmation, to ensure that the data layer is operating normally. Step 1.3.2, cache preheating and synchronization mechanism, as follows: The system loads Redis as a cache to preheat hot data. Cache preheating is completed through asynchronous threads, batch reading data from the database and writing it to the cache, setting expiration time and update policy. The cache service deployment adopts a master-slave structure with fault switching and data persistence capabilities. Step 1.3.3, multiple data source support and sharding strategy, as follows: The system supports dividing data sources by business modules and presetting data sharding or database partitioning strategies to provide a basis for expansion for subsequent business growth.

6. The method for constructing a digital product online rental system based on a cloud-native microservice architecture according to claim 2 is characterized in that: Initialize the gateway and unified access service as described in step 1.4 as follows: Step 1.4.1, routing rule loading and reverse proxy configuration, as follows: The system starts the API gateway service during the initialization phase and serves as the entry point for all terminal requests to achieve unified access control and traffic scheduling at the platform level; After the API gateway is started, it loads all routing rules, service mapping relationships, and authentication policies from the configuration center, and creates a routing table based on the dynamic service list of the service registration center; Step 1.4.2, authentication control and traffic management, are as follows: The gateway identifies the target service based on the request path and finds the corresponding service instance through the service discovery mechanism to complete the reverse proxy forwarding. The gateway has built-in flow control and circuit breaker mechanisms to control the flow of high-frequency requests and avoid overloading the backend service. The unified authentication module verifies the user identity through token verification or third-party login and intercepts illegal requests. Step 1.4.3, multi-terminal access and security policy loading, is as follows: Load security policies, including blacklist and whitelist policies, anti-spam interface settings, and log recording templates to ensure the stability and security of the system entrance; the gateway itself is also deployed as a container, and the number of instances is dynamically expanded according to traffic. It supports web, mobile, mini-programs, and open platform access methods to achieve unified multi-terminal access capabilities.

7. The method for constructing a digital product online rental system based on a cloud-native microservice architecture according to claim 2 is characterized in that: Initialize the message queue and event bus as described in step 1.5, as follows: Step 1.5.1, middleware startup and theme configuration, as follows: The system introduces an event-driven architecture to achieve asynchronous decoupling and process linkage between microservices. During the initialization phase, Kafka or RabbitMQ message queue services are started, various business topics are predefined, and corresponding producer and consumer roles are assigned to each service. Step 1.5.2, consumption logic registration and processing mechanism, as follows: Each service registers an event listener at startup, binds the topic of interest, and initializes the processing logic; when the event bus receives a message, the system automatically calls the listening method of the corresponding service to complete the response processing; The event queue also supports message persistence and multiple retry mechanisms to ensure that key business processes are not interrupted by temporary failures.

8. The method for constructing a digital product online rental system based on a cloud-native microservice architecture according to claim 2 is characterized in that: Configure the health check probes and monitoring core components described in step 1.6 to perform health checks and generate system status reports, as follows: Step 1.6.1: All service containers are configured with health check probes during deployment, including Liveness Probe and Readiness Probe. Kubernetes periodically checks the liveness and readiness of services and automatically restarts or removes traffic for abnormal instances. Step 1.6.2: Deploy Prometheus as the core monitoring component. Use Exporter to collect performance metrics for each service, including response time, error rate, CPU usage, and memory usage. Then, transmit the data to the Grafana panel for visualization. Step 1.6.3: The logging system collects and aggregates standard output and error logs through Fluentd or Loki, providing centralized query and tracing capabilities. Step 1.6.4: Generate a startup report for the initialization process, including the startup time, abnormal alarms, and configuration loading status of all services. This report provides O&M personnel with a basis for auditing the startup status and serves as a foundation for fault location and performance optimization.

9. The method for constructing a digital product online rental system based on a cloud-native microservice architecture according to claim 1, characterized in that: The leasing business process management module described in step 2 is designed. Through an event-driven architecture and a decoupled microservice-oriented design, it provides full-process support for users in the digital product leasing process. It also introduces credit determination and risk control mechanisms to support various leasing models. The details are as follows: Step 2.1: Design the user authentication and credit assessment interaction module as follows: Step 2.1.1: When a user first accesses the rental system and registers or logs in, the request is first intercepted by the API Gateway and forwarded to the user service module. The user service module verifies the user's identity through the OAuth2.0 authentication service, completes token issuance and session initialization, and records the device identifier and source platform metadata for subsequent behavior analysis. Step 2.1.2: The user service initiates a preliminary credit rating request to the credit risk control service through a synchronous REST interface. The credit service module uses a rule engine to call a third-party credit reporting platform or load a local credit scoring model to extract the user profile, historical performance records, and scoring dimensions to generate a preliminary credit score. Step 2.1.3: The preliminary credit score is pushed to the credit_score topic of Kafka as an asynchronous event. The user service asynchronously consumes the score to update the local cache and reads the current deposit exemption policy from the configuration center to determine whether the user has deposit exemption permission. Step 2.2: Design the product browsing and order creation collaboration module as follows: Step 2.2.1: After the user enters the product list page, the API gateway at the access layer forwards the request to the product management service module. The product management service module is responsible for querying the cache for available product SKUs, inventory status, and rental price information, and returning the results to the front end. Step 2.2.2: When a user clicks on a specific product, the system queries the user's historical behavior and profile through the recommendation and pricing service module, dynamically adjusts the displayed price, or pushes similar products and promotions; Step 2.2.3: When a user initiates a rental intent, the frontend sends an order creation request to the order service module with the product information and user ID. The order service encapsulates the current request as a rental intent event and triggers a pre-rental verification process, including inventory locking, credit check confirmation, and lease term compliance verification. Once verification passes, the system officially creates the rental order, generates a unique order number and status record, and sets the initial order status to "pending deposit processing." Step 2.2.4: Order information is sent to the payment service and risk control service via the Kafka message queue. Step 2.3: Design the deposit processing and payment settlement linkage module, as follows: Step 2.3.1: During the deposit processing phase, the system automatically determines whether a deposit is required based on the user's credit rating. If the user meets the deposit-free requirements, the order will proceed directly to the next stage. If a deposit is required, the front-end page will guide the user into the payment process. Step 2.3.2: After receiving the "deposit freeze" request, the payment service module calls the third-party payment platform interface to complete the fund freezing operation and monitor the callback result; Step 2.3.3: After payment is completed, the payment service sends a "deposit successful" event to the order service and credit service. The former is used to update the order status to "pending shipment", while the latter simultaneously updates the user's fulfillment record. Step 2.3.4: If the payment fails, the system will roll back the deposit freeze status and prompt the user to re-submit the request; Step 2.4: Design the module for linking delivery scheduling and lease start-up, as follows: Step 2.4.1: After the deposit is successfully processed, the order service sends a "shipping notification" event to the logistics scheduling system through the event queue. After receiving the message, the logistics service module assigns a courier and waybill number, writes the logistics information into the order extended information table, and sends a notification to the user. Step 2.4.2: When the platform detects the courier receipt confirmation, the system will trigger the "Lease Start" event. The order service will update the order status to "Lease in Progress" and start the lease countdown management mechanism. Step 2.4.3: Synchronize the order status to the operation and maintenance monitoring service to start the equipment usage monitoring and maintenance plan management process; Step 2.5: Design the usage period management and renewal reminder interaction module as follows: Step 2.5.1: During the user's rental period, the Order Service periodically sends user behavior data, including device usage frequency and number of abnormal requests, to the Recommendation Service and Credit Service based on the recorded rental start and end times to assess current usage status and risk level. Step 2.5.2: The system starts the scheduled task engine and sends a "lease expiration" reminder message to the user based on the lease contract rules; Step 2.5.3: When the user chooses to renew the lease, the system initiates the order modification process, including lease extension, fee supplement, and payment confirmation, which is handled jointly by the order service and the payment service; Step 2.5.4: If the user does not renew the lease and the lease is nearing its end, the system will automatically mark the device as "pending return" and push a return instruction to the user and operation and maintenance end to arrange for the device to be recycled; Step 2.6: Design the return process and equipment acceptance module as follows: Step 2.6.1: After the user actively returns the device or the system pushes a return instruction, the logistics service assigns a door-to-door pickup or courier return task, and the device is put into storage by scanning the QR code on the device. Step 2.6.2: After receiving the equipment, the operation and maintenance service module will perform a status check and functional test on the equipment. If there are no obvious faults or damage, the equipment will be marked as "reusable" and the order status will be updated to "pending settlement." If a problem is detected, the equipment will be marked as "unreusable" and the order status will be updated to "pending maintenance." A maintenance work order will be generated and the maintenance team will be notified. Step 2.6.3: Synchronously push the device status to the order service and credit service, which will serve as the basis for subsequent deposit release and credit score update. Step 2.7: Design the deposit release and order archiving modules as follows: Step 2.7.1: After the acceptance is complete, the payment service module decides whether to release the deposit based on the operation and maintenance feedback. If the device is intact, the system will call the third-party payment interface to unfreeze the funds and send a payment notification to the user. The order service will update the order status to "Completed" and seal all related records of the order. Step 2.7.2: If the device is damaged, the system will generate a compensation bill and guide the user to complete the additional payment. The remaining deposit will be released only after the payment is successful; Step 2.7.3: The operation and maintenance service will classify the equipment into the warehouse, and the credit service will adjust the user's credit rating based on the performance of this lease.

10. A digital product online rental system based on cloud native microservice architecture, characterized by: The system is constructed using the construction method according to any one of claims 1 to 9. The system is deployed in a container cloud environment and includes an access layer, a business service layer, a data service layer, and an operation and maintenance support layer. The access layer is the component directly connected to the end user. As the interface layer between the user equipment and the network system, it is responsible for user access authentication, service distribution and local information processing. The business service layer is used to provide the system's business configuration, parse the configuration information into database entities, establish a mapping relationship between the business model and the database entity, and provide business model parsing services for the access layer; The data service layer manages data access requests between services through a connection pool component; The operation and maintenance support layer establishes a service infrastructure framework based on cloud native technology and microservice architecture, so that each business module has the ability of decoupled communication, expansion, automatic recovery and dynamic configuration during subsequent operation.

Images