Mass terminal access and data management method based on hyper-converged architecture

Abstract

The invention relates to the technical field of Internet of Things, provides a mass terminal access and data management method based on a hyper-converged architecture, and particularly realizes efficient and stable access and intelligent data management of mass heterogeneous terminals by constructing the hyper-converged architecture based on cloud native and micro-servitization. By adopting containerization and Kubernetes arrangement, elastic expansion and high-concurrency processing capability of resources are realized, and the problem of standardized access of multiple terminals and multiple protocols is solved through a unified API gateway and a multi-protocol adaptation layer; a cross-platform framework and native adaptation are utilized to guarantee consistent experience and rapid expansion capability of cross-operating systems, operation and maintenance transparency and personalized data processing flexibility are remarkably improved through full-process visual monitoring and a customizable rule engine, and the operation and maintenance efficiency is improved through unified authentication, end-to-end encryption, real-time anomaly detection and high-availability clustering. And a depth safety protection system is constructed.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and more specifically, to a method for massive terminal access and data management based on a hyper-converged architecture. Background Technology

[0002] With the rapid development of the Internet of Things (IoT), mobile internet, and edge computing, the number of terminal devices connected to networks has exploded. These devices are diverse, including smartphones, industrial sensors, and smart wearables, typically running on different operating systems and using various communication protocols for data transmission. Simultaneously, the diversification of business scenarios places stringent demands on data processing in terms of real-time performance, personalization, and high security. This trend presents unprecedented challenges to traditional centralized, monolithic data access and management platforms.

[0003] Currently, the industry commonly uses multiple independent middleware or customized gateways to handle access from terminals using different protocols. While this approach solves compatibility issues to some extent, it leads to complex system architecture, high maintenance costs, and the formation of "data silos" between systems, making it difficult to achieve unified resource scheduling and collaborative data management. Furthermore, traditional resource allocation models are rigid and cannot dynamically scale computing, storage, and network resources according to fluctuations in terminal access volume. This can easily lead to service performance bottlenecks or even outages when dealing with sudden high-concurrency access scenarios.

[0004] At the terminal adaptation level, developing separate native applications for different operating systems, while ensuring performance and user experience, leads to significant duplication of development and maintenance investment, slow version iteration, and difficulty in achieving rapid synchronization and unified management of features. Regarding operation and maintenance monitoring, existing solutions often lack end-to-end visual monitoring capabilities throughout the entire lifecycle of terminal access. Problem localization relies on analyzing scattered logs, which is inefficient and fails to provide early warnings and intelligent control. At the security level, security measures such as authentication, encryption, and anomaly detection are often scattered across different stages, lacking a systematic and coordinated design. This makes it difficult to cope with increasingly complex network attacks, and the system's high availability design is insufficient, posing a single point of failure risk.

[0005] In summary, existing technologies have significant shortcomings in areas such as unified management of massive heterogeneous terminal access, intelligent elastic scaling of resources, rapid cross-platform adaptation, transparent operation and maintenance processes, and systematic security protection. There is an urgent need for a solution that can integrate resources, adapt flexibly, and is secure and reliable. Summary of the Invention

[0006] In view of this, the present invention proposes a method for massive terminal access and data management based on hyperconverged architecture to solve the problems existing in the prior art.

[0007] To achieve the above objectives, this invention proposes a method for massive terminal access and data management based on a hyperconverged architecture, comprising: Step S1: Adopting a cloud-native and microservice architecture, the access management function is modularly split into multiple independent microservice units, and containerized and deployed. The service is declaratively managed and automatically operated and maintained by relying on the Kubernetes container orchestration platform. Step S2: Based on the Kubernetes platform's automatic scaling mechanism, the number of replicas and resource quotas of each microservice instance are dynamically adjusted according to the real-time business load to achieve elastic scaling of computing resources to support concurrent access from millions of terminals. Step S3: Build a unified API gateway as the external access point, and deploy a multi-protocol adaptation layer consisting of multiple independent microservices behind the gateway to simultaneously support the standardized access and conversion of multiple communication protocols such as MQTT, CoAP, HTTP and HTTPS. Step S4: Build a unified terminal client using a cross-platform development framework, and perform platform-specific adaptation and optimization for iOS, Android and HarmonyOS to ensure functional consistency and native experience. Step S5: Embed telemetry agents in key microservices to collect logs and indicator data of the entire terminal access process. Build an observability system through real-time stream processing and data storage, and use visualization tools to achieve global monitoring of access status and process traceability. Step S6: Deploy a customizable rule engine microservice in the data access layer. The standardized access data is matched in real time through a predefined rule set, and personalized processing logic including data cleaning, format conversion and routing distribution is executed. Step S7: Establish a unified identity authentication and end-to-end encrypted transmission mechanism, and combine it with real-time anomaly detection and high-availability clusters deployed across availability zones to build a multi-layered security protection and reliability assurance system.

[0008] Furthermore, in step S1, the microservice unit includes at least an authentication and authorization service responsible for terminal authentication and permission management, a protocol adaptation service responsible for multi-protocol parsing and conversion, a connection management service responsible for maintaining terminal sessions, and a data routing service responsible for data distribution; each microservice communicates for service discovery and load balancing through the Kubernetes Service mechanism.

[0009] Further, in step S2, the automatic scaling mechanism includes a Horizontal Pod Autoscaler, which dynamically calculates the desired number of Pod replicas based on the target metric value; the formula for calculating the desired number of replicas is: Expected number of copies .

[0010] Furthermore, in step S3, the multi-protocol adaptation layer includes independent protocol adapter microservices, including at least an MQTT adapter, a CoAP adapter, and an HTTP / HTTPS adapter; each protocol adapter service can be horizontally scaled independently, and the number of its replicas can be elastically scaled according to the access traffic pressure of the corresponding protocol.

[0011] Furthermore, in step S4, the cross-platform development framework is React Native, which calls the native capability modules of various operating systems through the platform channel mechanism, including using iOS's Keychain service, Android's ForegroundService, and HarmonyOS's distributed capability framework.

[0012] Furthermore, in step S5, the construction of the observability system specifically involves: buffering the collected log and metric data through the Kafka message queue, performing real-time cleaning and correlation processing using Spark Streaming, and persisting the result data to the InfluxDB time-series database and the Elasticsearch search engine, respectively.

[0013] Furthermore, in step S6, the rule engine matches the data feature vector with the rule set using a pattern matching algorithm. The rule consists of triggering conditions and execution actions and is stored in the configuration database. The rule engine service is stateless, ensuring consistency through a shared rule cache and achieving horizontal scaling and load balancing with the help of a message queue.

[0014] Further, in step S7, the real-time anomaly detection is implemented through a security monitoring microservice. This service analyzes authentication logs and network traffic from the gateway, calculates the Z-score of key security indicators using a statistical model, and combines it with machine learning algorithms to identify attack patterns. The formula for calculating the Z-score is: Z = (X - μ) / σ Where X is the measured value, μ is the historical mean, and σ is the standard.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention achieves efficient and stable access and intelligent data management for massive heterogeneous terminals by constructing a hyper-converged architecture based on cloud-native and microservices; it realizes elastic scaling and high-concurrency processing capabilities by adopting containerization and Kubernetes orchestration; it solves the problem of standardized access for multiple terminals and protocols by using a unified API gateway and multi-protocol adaptation layer; it ensures a consistent experience and rapid expansion capabilities across operating systems by utilizing a cross-platform framework and native adaptation; it significantly improves operational transparency and personalized data processing flexibility through full-process visual monitoring and a customizable rule engine; and it builds a deep security protection system through unified authentication, end-to-end encryption, real-time anomaly detection, and high-availability clusters, thereby achieving a comprehensive improvement in access capabilities, operational efficiency, adaptation flexibility, and system reliability. Attached Figure Description

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. In the drawings: Figure 1 This is a schematic diagram of the framework of a massive terminal access and data management method based on a hyperconverged architecture in an embodiment of the present invention. Detailed Implementation

[0017] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0018] This embodiment proposes a method for massive terminal access and data management based on a hyper-converged architecture, such as... Figure 1 As shown, it includes: Step S1: Based on cloud-native and distributed architecture design as the foundation for the overall implementation, the access management function is modularized and decomposed using microservice architecture and containerized deployment. The detailed steps are as follows: Based on cloud-native and distributed architecture, and using microservice architecture and containerized deployment, the access management functions are modularly decomposed; A detailed analysis of the business and functional domains of the unified access tasks undertaken by the hyperconverged access management service is conducted. Based on the principle of high cohesion and low coupling, the overall system is divided into a series of microservice units with single responsibilities and independent deployment. Specifically, the authentication and authorization service is responsible for terminal authentication and permission management, the protocol adaptation service is dedicated to handling the parsing and conversion of different protocols such as MQTT and CoAP, the connection management service maintains the terminal session state and lifecycle, and the data routing service is responsible for directing the access data to the backend processing system. Each microservice encapsulates its specific business logic and data model and interacts through the gRPC communication mechanism to achieve functional decoupling and independent evolution.

[0019] In terms of containerized deployment, each microservice and its dependent runtime environment are packaged into a standardized Docker image. The image contains application code, runtime libraries, system tools, and configuration files to ensure consistent behavior across different computing environments. These container images are then deployed to a Kubernetes-based container orchestration platform.

[0020] As a core component of cloud-native architecture, Kubernetes is responsible for the scheduling, deployment, scaling, and lifecycle management of containers. It defines the expected state of microservices through declarative configuration, including the number of replicas, resource requirements, health check policies, and service discovery mechanisms, and continuously monitors the consistency between the actual state and the expected state.

[0021] In addition, Kubernetes automatically performs corrective actions. When a service instance terminates due to a failure, Kubernetes will immediately restart the container on a new node to maintain service availability. By leveraging the elasticity and automation capabilities of distributed systems, traditional monolithic applications can be decomposed into a collection of independently scalable microservices, thereby significantly improving the maintainability, scalability, and deployment flexibility of the system.

[0022] At the resource scheduling level, Kubernetes distributes container instances optimally across cluster nodes based on node resource utilization and service priority, static allocation of resources based on requests and limits, and dynamic rebalancing of real-time load.

[0023] Specifically, when deciding to schedule a container to a specific node, the remaining CPU, memory, and storage resources of the node are used to determine whether the container's needs are met. This problem is formalized as a bin packing problem under multi-dimensional resource constraints. The objective function is set to minimize resource fragmentation or maximize the overall utilization of the cluster, while ensuring service quality.

[0024] For communication and load balancing between microservices, the Kubernetes Service mechanism provides a single, stable access endpoint for a group of identical container instances and distributes requests to healthy backend instances through a built-in load balancer. It employs a response time-based algorithm to optimize traffic distribution and improve overall processing capacity.

[0025] Step S2: Implement dynamic scheduling and elastic scaling of resources through Kubernetes to ensure that the system can maintain stable operation and horizontal scaling capabilities even when facing millions of concurrent terminal accesses. Specifically: First, based on the containerized deployment of microservices built in step S1, each microservice in the Kubernetes cluster is defined as one or more Pod replicas, and corresponding resource requests and limits are configured.

[0026] To ensure the connectivity management service requires 0.5 CPU cores and 1GB of memory per Pod instance, the Kubernetes scheduler sets its resource usage limit to 1 CPU core and 2GB of memory. Based on these settings and the real-time resource capacity of the cluster nodes, the Pods are allocated to the optimal worker nodes.

[0027] The above scheduling process can be abstracted into a constrained multidimensional resource binning optimization problem. The optimization objective is to maximize cluster resource utilization while satisfying service quality constraints. When the business load increases, leading to a surge in terminal access requests, the pre-deployed Horizontal Pod Autoscaler (HPA) comes into play. HPA continuously monitors specific metrics provided by the Metrics Server or PrometheusAdapter. When the average CPU utilization or custom metric of each Pod exceeds the preset target threshold, the HPA controller calculates the desired number of replicas based on the ratio of the current metric value to the target value, combined with the number of currently running Pod replicas, using a built-in algorithm. The calculation method is as follows: Expected number of copies

[0028] HPA then triggers a coordination process in the Kubernetes control plane by adjusting the replica count field of the corresponding Deployment or StatefulSet, automatically creating new Pod instances to distribute the load. When the load decreases, the replica count is reduced using the same calculation method to shrink resources and prevent frequent fluctuations in the replica count due to short-term metric fluctuations.

[0029] In terms of vertical resource adjustment, the Vertical Pod Autoscaler analyzes the historical resources and usage patterns of Pods and dynamically adjusts their configured resource requests and limits to better meet actual needs and reduce resource waste.

[0030] When a Pending state occurs due to insufficient resources, or when the node resource utilization rate is too low for an extended period, CA will automatically request the cloud platform to create new virtual machine nodes to join the cluster, or remove idle nodes, thereby achieving elastic scaling of computing resources at the infrastructure level. Its decision-making logic is also based on the resource supply and demand model, aiming to maintain a node scale that balances cost and performance.

[0031] In scenarios dealing with sudden surges in concurrent access, a multi-layered elastic scaling mechanism works together. First, HPA rapidly increases the number of replicas of the business Pods to handle the influx of connection requests. If node resources are insufficient, CA supplements new node resources, thereby ensuring that the Pods can be successfully scheduled. At the same time, through Kubernetes Service and Ingress resources in conjunction with a load balancer, the newly added terminal access traffic is intelligently distributed to the newly expanded Pod instances. The entire process requires no manual intervention, achieving coordinated elastic scaling from the application layer to the infrastructure layer.

[0032] Step S3: By building a unified API gateway, a standardized access interface is provided to the outside world. Internally, a multi-protocol adaptation layer is set up to support multiple communication protocols such as MQTT, CoAP, HTTP and HTTPS, and an extension interface is reserved to ensure that different terminal devices can access in a consistent and flexible manner, effectively reducing the integration complexity and maintenance costs caused by protocol differences.

[0033] Specifically, this embodiment first deploys a highly available API gateway component at the edge of the Kubernetes cluster. This gateway serves as the sole entry point for all external terminal access requests, providing a unified access point for different types of terminal devices.

[0034] Furthermore, unified security authentication is implemented within the gateway, token bucket or leaky bucket algorithms are used to prevent system overload, and data verification and access logging are performed to ensure the security and controllability of incoming traffic. Subsequently, pre-processed requests are forwarded by the gateway's routing engine to the corresponding backend microservice cluster based on their path, header information, or payload content. This forwarding process relies on a pre-configured routing rule table and combines negative consistency hashing to distribute requests to healthy service instances, optimizing resource utilization and ensuring high availability.

[0035] This adaptation layer consists of independent protocol adapter microservices. The MQTT adapter handles lightweight message passing from IoT devices by implementing the MQTT broker subscription and publish mechanism; the CoAP adapter handles UDP-based request-response interactions for restricted network environments; and the HTTP / HTTPS adapter handles standard web requests.

[0036] To achieve high concurrency processing, each protocol adapter service is also a horizontally scalable microservice, and the number of its replicas is dynamically adjusted by Kubernetes HPA based on the pressure of the protocol access traffic.

[0037] Step S4: In terms of cross-platform and multi-terminal adaptation, this embodiment adopts a cross-platform development framework to perform differentiated adaptation and optimization for iOS, Android and HarmonyOS, ensuring functional consistency, performance efficiency and user-friendliness on each platform, while reserving the ability to quickly access new operating systems and new hardware terminals to meet the needs of future technology evolution and business expansion.

[0038] Specifically, this embodiment uses the React Native framework and develops a unified client core code library using Dart or JavaScript / TypeScript. This code library implements all the basic functions required for terminal access, including secure communication with the unified API gateway in the cloud, user authentication, encrypted data transmission, access status management, and basic user interface components.

[0039] However, due to the fundamental differences between different operating systems in terms of underlying system APIs, UI rendering mechanisms, performance characteristics, and security policies, this embodiment has made targeted platform-specific adaptations. It uses the platform channel mechanism provided by the framework to enable scenarios that require calling the native capabilities of the operating system. Specifically, this embodiment uses iOS's Keychain service for storing sensitive information, calls Android's Foreground Service to maintain the stability of the background connection, and integrates the distributed capability framework of HarmonyOS, allowing developers to write platform-specific native code modules. These modules can communicate bidirectionally with cross-platform code through predefined interfaces, forming a bridge layer that encapsulates platform-related details, making them transparent to the upper-layer business logic.

[0040] In terms of user interface adaptation, this embodiment follows the navigation pattern of Human Interface Guidelines on iOS, conforms to Material Design control feedback on Android, and uses the atomic service concept to fine-tune the touch feedback, font rendering, and animation curves of components on HarmonyOS to ensure that the application presents a native visual and operating experience on each platform.

[0041] Step S5: At the access process management level, this embodiment introduces intelligent visualization tools to realize the status display and tracking of the entire terminal access process. It supports the visualization monitoring and traceability of each link from access application, authentication and authorization to data transmission, which greatly improves the transparency of operation and maintenance and management efficiency.

[0042] Specifically, this embodiment embeds a lightweight telemetry agent into key microservices such as access gateway, protocol adapter, authentication service, and data routing to collect logs and indicator data generated at each stage of each terminal access event in real time. The data types include, but are not limited to, the terminal's unique identifier, access timestamp, protocol type, authentication result, connection status, data throughput, and error code. The above data stream is buffered and asynchronously transmitted through a Kafka queue, and then connected to Spark Streaming for cleaning, aggregation, and correlation processing.

[0043] The aforementioned data is written to the InfluxDB database to support high-performance time-series queries, and indexed into Elasticsearch to support complex multidimensional retrieval and tracing. Building upon this, this embodiment introduces a Grafana-based intelligent visualization tool. This tool displays the overall status of the entire access process from multiple dimensions. Specifically, it uses a dashboard to dynamically display the trends of real-time access request volume and success rate through line charts; a topology diagram to intuitively present the real-time connection relationships between terminals, gateways, and backend services; a Sankey diagram to show the flow path of access traffic across different protocols and states; and a detailed list to provide traceable details of each access session, including all service nodes it passes through and any abnormal states and time consumption. Alarms are triggered and highlighted in the visualization interface based on pre-defined threshold rules.

[0044] Step S6: To address personalized data processing needs, a customizable rule engine is designed at the data access layer to support data cleaning, format conversion, and processing logic across different industries and application scenarios. This enables the system to flexibly adapt to diverse business requirements, specifically including: Rule definition and modeling phase The design incorporates a structured rule description language and provides a visual configuration interface, allowing business personnel or system administrators to define data processing rules based on specific scenarios. Each rule consists of two parts: a trigger condition and an execution action. The trigger condition is based on matching the metadata or content of the accessed data. The metadata includes the terminal type, protocol tag, data format, or the value of a specific field in the payload of the data source. The execution action defines the processing operations to be performed after the condition is met, including data cleaning, format conversion, content desensitization, numerical unit conversion, simple aggregation calculation, or routing the data to a specific downstream topic or storage system.

[0045] The rules mentioned above are stored in the configuration database in the form of structured documents. The rule engine itself is deployed as an independent microservice. Its core loads and parses the stored rule definitions and compiles them into an internally executable data structure.

[0046] After the data is transformed and standardized through the protocol adaptation layer, it does not directly enter the core business flow, but is sent to the rule engine service engine. In this process, the feature vector of the data is first extracted, and then it is quickly matched with the preloaded rule set. This matching process aims to find the rule that meets all conditions. Its principle is similar to the efficient pattern matching algorithm to optimize the evaluation performance under multiple rules, avoid linear scanning of the entire rule set for each piece of data, and thus improve throughput.

[0047] For a successfully matched rule engine, the associated action sequence is executed sequentially according to its predefined priority or order. To support high-concurrency data processing rules, the rule engine service is designed as multiple stateless and horizontally scalable engine instances. The consistency of the rule set is ensured through a shared rule cache and a distributed lock mechanism, and a message queue is used to handle massive data streams from upstream, achieving load balancing and elastic scaling.

[0048] Simultaneously, the execution logs, rule hit rates, and processing delays of the rule engine are collected in real time and integrated into the observability system described in step S5, providing a basis for rule optimization and performance evaluation. Finally, through the rule engine data access layer, it transforms from a passive data pipeline into an intelligent data preprocessing and distribution center, enabling the system to flexibly adapt to different data cleaning, transformation, and routing logics without modifying the core code for each differentiated business scenario, simply by adding, deleting, or modifying rule configurations.

[0049] Step S7: In terms of security and reliability, this embodiment establishes a unified identity authentication mechanism and an end-to-end encrypted transmission channel, combines real-time anomaly detection and high-availability cluster deployment to build a multi-layered security protection system, and ensures the continuous and stable operation of the system under extreme conditions through a disaster recovery mechanism.

[0050] Specifically, the unified identity authentication mechanism constructed in this embodiment includes: when all terminals initiate an access request, they must first submit credentials to the distributed authentication microservice. This service adopts a token-based protocol, and after the terminal identity is verified, a time-limited digital token is issued as a unified credential for all subsequent interactions. The authentication service itself is integrated with a lightweight directory access protocol or an external identity provider to support rapid verification and permission management of massive numbers of terminals.

[0051] After the connection is established, the system enforces the use of transport layer security protocols to build an end-to-end encrypted transmission channel. During the handshake phase, the terminal and the server exchange session keys using an asymmetric encryption algorithm. Subsequently, all communication data is encrypted using a symmetric encryption algorithm to ensure the confidentiality and integrity of data transmission.

[0052] At the runtime security level, the real-time anomaly detection is implemented through a separate security monitoring microservice. Specifically, this service continuously receives authentication logs and network traffic data streams from the gateway, uses a stream processing framework to calculate key security metrics in real time, including the number of authentication failures per unit time, the standard deviation of packet size, and sudden changes in connection frequency. It also uses a statistical model to calculate the Z-score of these key security metrics and combines this with machine learning algorithms to identify attack patterns. The formula for calculating the Z-score is as follows: Z = (X - μ) / σ Where X is the measured value, μ is the historical mean, and σ is the standard.

[0053] If the calculated Z-score exceeds the threshold, it indicates that an anomaly has been detected, and the system will automatically trigger an alarm and execute a predefined mitigation strategy.

[0054] In terms of high availability, the key services in this embodiment include an authentication gateway and an encryption proxy, both of which are deployed in a Kubernetes cluster across availability zones in the form of multiple replicas. A load balancer is used to distribute access traffic to healthy instances, and the status of instances is continuously monitored through ready probes and liveness probes. When an instance fails, the orchestration platform automatically reroutes traffic to other instances and restarts or replaces the failed container to ensure service continuity and availability.

[0055] This ratio is increased to over 99.9% through redundant design and automatic failover mechanisms. Ultimately, unified identity authentication ensures the trustworthiness of access subjects, encrypted transmission guarantees data security on the link, real-time anomaly detection provides dynamic threat awareness and high availability, and the cluster eliminates single points of failure at the infrastructure level.

[0056] In summary, this method achieves dynamic allocation of computing, storage, and network resources through resource pooling and elastic scaling capabilities. This enables the entire platform to automatically scale resources according to peak and off-peak traffic patterns, ensuring high availability of services during peak periods and achieving optimal resource utilization efficiency. As a result, a complete implementation plan for massive terminal access and data management is formed, encompassing terminal access, protocol adaptation, cross-platform support, process visualization management, and security and reliability assurance.

[0057] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A method for massive terminal access and data management based on hyperconverged architecture, characterized in that, include: Step S1: Adopt cloud-native and microservice architecture, modularize the access management function into multiple independent microservice units, and containerize and deploy them. Use the Kubernetes container orchestration platform for declarative management and automated operation and maintenance of services. Step S2: Based on the Kubernetes platform's automatic scaling mechanism, the number of replicas and resource quotas of each microservice instance are dynamically adjusted according to the real-time business load to achieve elastic scaling of computing resources to support concurrent access from millions of terminals. Step S3: Build a unified API gateway as the external access point, and deploy a multi-protocol adaptation layer consisting of multiple independent microservices behind the gateway to simultaneously support the standardized access and conversion of multiple communication protocols such as MQTT, CoAP, HTTP and HTTPS. Step S4: Build a unified terminal client using a cross-platform development framework, and perform platform-specific adaptation and optimization for iOS, Android and HarmonyOS to ensure functional consistency and native experience. Step S5: Embed telemetry agents in key microservices to collect logs and indicator data of the entire terminal access process. Build an observability system through real-time stream processing and data storage, and use visualization tools to achieve global monitoring of access status and process traceability. Step S6: Deploy a customizable rule engine microservice in the data access layer. The standardized access data is matched in real time through a predefined rule set, and personalized processing logic including data cleaning, format conversion and routing distribution is executed. Step S7: Establish a unified identity authentication and end-to-end encrypted transmission mechanism, and combine it with real-time anomaly detection and high-availability clusters deployed across availability zones to build a multi-layered security protection and reliability assurance system.

2. The method according to claim 1, characterized in that, In step S1, the microservice unit includes at least an authentication and authorization service responsible for terminal authentication and permission management, a protocol adaptation service responsible for multi-protocol parsing and conversion, a connection management service responsible for maintaining terminal sessions, and a data routing service responsible for data distribution; each microservice communicates for service discovery and load balancing through the Kubernetes Service mechanism.

3. The method according to claim 1, characterized in that, In step S2, the automatic scaling mechanism includes a Horizontal Pod Autoscaler, which dynamically calculates the desired number of Pod replicas based on the target metric value; the formula for calculating the desired number of replicas is: Desired number of sub-units .

4. The method according to claim 1, characterized in that, In step S3, the multi-protocol adaptation layer includes independent protocol adapter microservices, including at least an MQTT adapter, a CoAP adapter, and an HTTP / HTTPS adapter; Each protocol adapter service can be scaled horizontally independently, and the number of its replicas can be elastically adjusted based on the access traffic pressure of the corresponding protocol.

5. The method according to claim 1, characterized in that, In step S4, the cross-platform development framework is ReactNative, which calls the native capability modules of various operating systems through the platform channel mechanism, including using iOS's Keychain service, Android's Foreground Service, and HarmonyOS's distributed capability framework.

6. The method according to claim 1, characterized in that, In step S5, the construction of the observability system specifically involves: buffering the collected log and metric data through the Kafka message queue, performing real-time cleaning and correlation processing using Spark Streaming, and persisting the result data to the InfluxDB time-series database and the Elasticsearch search engine, respectively.

7. The method according to claim 1, characterized in that, In step S6, the rule engine matches the data feature vector with the rule set using a pattern matching algorithm. The rule consists of triggering conditions and execution actions and is stored in the configuration database. The rule engine service is stateless, ensuring consistency through a shared rule cache and achieving horizontal scaling and load balancing with the help of a message queue.

8. The method according to claim 1, characterized in that, In step S7, the real-time anomaly detection is implemented through a security monitoring microservice. This service analyzes authentication logs and network traffic from the gateway, calculates the Z-score of key security indicators using a statistical model, and combines it with machine learning algorithms to identify attack patterns. The formula for calculating the Z-score is: Z = (X - μ) / σ Where X is the measured value, μ is the historical mean, and σ is the standard.

Images