A cloud-edge collaborative distributed API calling method and system

Abstract

The application relates to the field of data processing and discloses a cloud-edge cooperative distributed API calling method and system, which are used for improving API calling efficiency and reliability. The method comprises the following steps: deploying API services in the cloud and edge devices respectively, and generating API service clusters; performing dynamic load balancing processing on the API service clusters, obtaining a target load state, and calling an optimal API service node from the API service clusters according to the target load state to obtain a first API service node; performing fault detection on the first API service node to obtain a fault detection result, and calling a second API service node with a normal node from the API service clusters according to the fault detection result; obtaining an API calling request according to the second API service node, and performing identity authentication and permission control on the API calling request to obtain a security authentication result; and calling an API gateway system to perform communication on the API service clusters according to the security authentication result to obtain a target API service.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to a cloud-edge collaborative distributed API calling method and system. Background Technology

[0002] In today's digital age, APIs (Application Programming Interfaces) have become the standard interface for interaction between various software and systems. With the development of technologies such as the Internet of Things and edge computing, more and more devices and terminal nodes need to exchange data and collaborate with cloud platforms. Therefore, how to efficiently manage and schedule distributed API services has become an important technical issue.

[0003] The traditional approach to deploying API services is to deploy all API services on cloud servers. This allows for centralized handling of large numbers of requests and unified management and monitoring. However, this approach has the following problems: High latency: Because data needs to be transmitted over the network, even with a small number of requests, there will be some latency, affecting user experience. Inability to meet low-latency requirements: For applications requiring real-time or near-real-time responses, such as industrial automation and autonomous driving, traditional centralized deployment of API services cannot meet their low-latency requirements. Network bandwidth limitations: When API services are centralized in the cloud, edge devices need to frequently send / receive data to and from the cloud, consuming a large amount of network bandwidth and increasing operating costs. Summary of the Invention

[0004] This invention provides a cloud-edge collaborative distributed API calling method and system to improve API calling efficiency and reliability.

[0005] The first aspect of this invention provides a cloud-edge collaborative distributed API invocation method, the cloud-edge collaborative distributed API invocation method comprising:

[0006] Deploy API services in pre-built cloud and edge devices to generate an API service cluster;

[0007] Dynamic load balancing is performed on the API service cluster to obtain the target load status, and the optimal API service node is called from the API service cluster according to the target load status to obtain the first API service node.

[0008] Fault detection is performed on the first API service node to obtain the fault detection result, and the second API service node with normal operation is called from the API service cluster according to the fault detection result.

[0009] The corresponding API call request is obtained from the second API service node, and the API call request is authenticated and access controlled to obtain a security authentication result.

[0010] Based on the security authentication result, a pre-configured API gateway system is invoked to communicate with the API service cluster in the cloud and the edge device to obtain the target API service.

[0011] In conjunction with the first aspect, in a first embodiment of the first aspect of the present invention, the step of deploying API services in pre-configured cloud and edge devices to generate an API service cluster includes:

[0012] Obtain different business requirements and resource constraints, and determine cloud-edge deployment strategies based on the business requirements and resource constraints;

[0013] Based on the cloud-edge deployment strategy, API services are deployed on the pre-configured cloud and edge devices respectively, resulting in multiple deployed API services;

[0014] The multiple deployed API services are processed in a cluster to generate an API service cluster.

[0015] In conjunction with the first aspect, in the second embodiment of the first aspect of the present invention, the step of performing dynamic load balancing processing on the API service cluster to obtain a target load state, and calling the optimal API service node from the API service cluster according to the target load state to obtain a first API service node, includes:

[0016] Based on the aforementioned business requirements, a corresponding load balancing algorithm is matched;

[0017] According to the load balancing algorithm, dynamic load balancing is performed on the API service cluster, and the target load status of the API service cluster is obtained.

[0018] Based on the target load status, the optimal API service node is called from the API service cluster to obtain the first API service node.

[0019] In conjunction with the first aspect, in a third embodiment of the first aspect of the present invention, the step of performing fault detection on the first API service node, obtaining a fault detection result, and calling a normal second API service node from the API service cluster based on the fault detection result includes:

[0020] Fault detection is performed on the first API service node to obtain fault detection results, wherein the fault detection results include: the presence of a fault and the absence of a fault;

[0021] If a fault occurs, the first API service node will be switched based on the pre-configured failover mechanism.

[0022] The second API service node, which is functioning normally, is invoked from the API service cluster.

[0023] In conjunction with the first aspect, in the fourth embodiment of the first aspect of the present invention, the step of obtaining the corresponding API call request according to the second API service node, and performing authentication and access control on the API call request to obtain a security authentication result includes:

[0024] Based on the second API service node, obtain the corresponding API call request;

[0025] Query the identity information corresponding to the API call request, verify the identity information, and obtain the verification result;

[0026] Access control is applied to the API call request to obtain the access control result;

[0027] Based on the authentication result and the access control result, a security authentication result is generated, wherein the security authentication result includes: security authentication passed and security authentication failed.

[0028] In conjunction with the first aspect, in the fifth embodiment of the first aspect of the present invention, the step of invoking a pre-set API gateway system to communicate with the API service cluster in the cloud and the edge device based on the security authentication result to obtain the target API service includes:

[0029] If the security authentication result is that the security authentication is successful, then the preset API gateway system is invoked to respond to the API call request;

[0030] The API service cluster in the cloud and the edge device communicates with the API call request to query the corresponding target API service.

[0031] A second aspect of the present invention provides a cloud-edge collaborative distributed API calling system, the cloud-edge collaborative distributed API calling system comprising:

[0032] The deployment module is used to deploy API services in pre-built cloud and edge devices to generate API service clusters.

[0033] The processing module is used to perform dynamic load balancing on the API service cluster, obtain the target load status, and, based on the target load status, call the optimal API service node from the API service cluster to obtain the first API service node.

[0034] The detection module is used to perform fault detection on the first API service node, obtain the fault detection result, and call the second API service node with normal node from the API service cluster according to the fault detection result.

[0035] The control module is used to obtain the corresponding API call request based on the second API service node, and to perform authentication and access control on the API call request to obtain a security authentication result;

[0036] The communication module is used to call a pre-set API gateway system to communicate with the API service cluster in the cloud and the edge device based on the security authentication result, so as to obtain the target API service.

[0037] A third aspect of the present invention provides a cloud-edge collaborative distributed API calling device, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor calls the instructions in the memory to cause the cloud-edge collaborative distributed API calling device to execute the cloud-edge collaborative distributed API calling method described above.

[0038] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the cloud-edge collaborative distributed API call method described above.

[0039] The technical solution provided by this invention involves deploying API services in the cloud and edge devices respectively to generate an API service cluster; performing dynamic load balancing on the API service cluster to obtain the target load status, and calling the optimal API service node from the API service cluster based on the target load status to obtain the first API service node; performing fault detection on the first API service node to obtain the fault detection result, and calling the normal second API service node from the API service cluster based on the fault detection result; obtaining the API call request from the second API service node, and performing authentication and access control on the API call request to obtain the security authentication result; and calling the API gateway system to communicate with the API service cluster based on the security authentication result to obtain the target API service. This invention achieves efficient and reliable API calls by deploying API services in the cloud and edge devices and combining dynamic load balancing, failover, and security authentication mechanisms. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of an embodiment of the cloud-edge collaborative distributed API call method in this invention;

[0041] Figure 2This is a flowchart of the dynamic load balancing process in an embodiment of the present invention;

[0042] Figure 3 This is a flowchart of fault detection in an embodiment of the present invention;

[0043] Figure 4 This is a flowchart of the security authentication process in an embodiment of the present invention;

[0044] Figure 5 This is a schematic diagram of an embodiment of the cloud-edge collaborative distributed API call system in this invention.

[0045] Figure 6 This is a schematic diagram of an embodiment of a cloud-edge collaborative distributed API call device according to the present invention. Detailed Implementation

[0046] This invention provides a cloud-edge collaborative distributed API call method and system to improve API call efficiency and reliability. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0047] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 One embodiment of the cloud-edge collaborative distributed API call method in this invention includes:

[0048] S101. Deploy API services in pre-configured cloud and edge devices to generate an API service cluster;

[0049] It is understood that the executing entity of this invention can be a cloud-edge collaborative distributed API call system, or it can be a terminal or a server; the specific implementation is not limited here. This embodiment of the invention will be described using a server as an example.

[0050] It's important to note that API services are deployed across various locations, including the cloud and edge devices. The cloud typically refers to data centers or servers on the internet, providing high-performance storage, computing, and network resources. Edge devices, on the other hand, refer to IoT terminal devices located closest to the user, such as smartphones, sensors, and routers. Deploying API services on edge devices reduces network latency and bandwidth consumption, improving response speed and data security. By deploying API services in both the cloud and edge devices, an API service cluster can be formed. This cluster can allocate tasks according to different needs and can implement load balancing, disaster recovery, and backup functions. Furthermore, the API service cluster can be monitored, managed, and tuned using automated tools to ensure efficient and stable operation when handling a large number of concurrent requests.

[0051] S102. Perform dynamic load balancing on the API service cluster to obtain the target load status, and based on the target load status, call the optimal API service node from the API service cluster to obtain the first API service node.

[0052] Specifically, in this architecture, API services with different geographical locations and device types are deployed on cloud and edge devices and managed through a dynamic load balancing mechanism. This dynamic load balancing mechanism intelligently selects the optimal API service node for invocation based on the current load. For example, when a node is overloaded, requests are automatically forwarded to other nodes to avoid overload, while ensuring high performance and reliability. This process is handled by the load balancer, which uses various algorithms to calculate which API service node is best suited to handle the current request. To implement this dynamic load balancing mechanism, the following aspects need to be considered: 1. Data collection and monitoring: It is necessary to collect data such as the running status and resource utilization of each API service node and monitor the node load in real time. 2. Load balancing algorithms: Different load balancing algorithms, such as round-robin, random, and weighted round-robin, can be used for different application scenarios to balance the load of each API service node. 3. Fast routing and scheduling: An efficient routing and scheduling strategy needs to be designed to quickly distribute requests to the optimal API service node. 4. Fault Tolerance and Recovery: Even if some nodes fail or malfunction, it is necessary to ensure that the system can still operate normally. This can be achieved through methods such as multiple replica backups. In this embodiment, the server provides multiple service interfaces and can intelligently select the optimal node based on the load, thereby meeting the needs of various application scenarios.

[0053] S103. Perform fault detection on the first API service node, obtain the fault detection result, and call the normal second API service node from the API service cluster according to the fault detection result.

[0054] Specifically, to achieve high availability for API services, a failover mechanism needs to be considered in the architecture design. This means that when an API service node fails, it needs to automatically switch to another healthy node for invocation. Below is a specific implementation plan: Heartbeat Detection: Each API service node periodically sends a heartbeat signal to the load balancer to indicate that the node is in a normal state. If a node fails to send a heartbeat signal, it is considered to have failed. Failure Detection: The load balancer monitors the status of each API service node in real time through heartbeat detection and other methods. When a node fails, it promptly notifies other nodes and clients. Automatic Switching: When a node fails, the load balancer automatically routes requests to other healthy nodes to ensure high service availability. Fault Tolerance and Recovery: Fault-tolerant and recovery measures are also needed for failed nodes. For example, backups and multiple replicas can be used to improve the system's fault tolerance, and the node can be rejoined to the cluster after recovery. Testing and Verification: In practical applications, the effectiveness of the failover mechanism needs to be tested and verified periodically. For example, a node can be disabled or its service stopped, and the load balancer can be observed to automatically switch to another healthy node. In summary, "implementing a failover mechanism—automatically switching to other healthy nodes when an API service node fails to ensure high availability of the API service"—is an important system architecture design that provides a more stable and reliable service. The above implementation plan effectively guarantees the high availability of API services, avoiding single points of failure and data loss.

[0055] S104. Obtain the corresponding API call request from the second API service node, and perform authentication and access control on the API call request to obtain the security authentication result;

[0056] Specifically, this embodiment introduces a security authentication mechanism to authenticate and control access to API call requests, a crucial step in ensuring API service security. This mechanism can prevent unauthorized access, avoid data leaks, and deter malicious attacks. Implementing this mechanism requires the following steps: Authentication: First, authentication is needed to confirm the API caller's identity. Common authentication methods include username / password, tokens, and digital certificates. For example, a user can log in to the system by providing a username and password to gain access to the API service. Access Control: After authentication, further access control is required. This process involves identifying the API caller's role or group and controlling which resources or operations the API caller can access based on the permissions of that role or group. For example, administrators can access all API resources and operations, while ordinary users can only access some resources and operations. Secure Transmission: To ensure the security of API requests and responses during transmission, secure transmission protocols such as HTTPS / SSL are required. Using these protocols encrypts transmitted data, preventing hackers from eavesdropping on, forging, or tampering with API requests and responses. Monitoring and Logging: During operation, the usage of the API service needs to be monitored regularly, and corresponding log information needs to be recorded. This information can be used to track faults, debug problems, discover security vulnerabilities, and serve as audit evidence. Updates and Maintenance: The security authentication mechanism is an ongoing task that requires continuous updates and maintenance. For example, with technological changes and the emergence of new threat patterns, encryption algorithms need to be updated promptly, and vulnerabilities patched to ensure the security of the API service.

[0057] S105. Based on the security authentication result, call the pre-configured API gateway system to communicate with the API service cluster in the cloud and edge devices to obtain the target API service.

[0058] Specifically, the server-side cloud-edge collaborative API gateway system serves as the entry point for API services. It handles requests from clients and communicates with API service clusters on the cloud and edge devices to achieve unified management and scheduling, improving API call efficiency and reliability. An API gateway system typically includes the following components: Client: Clients of the API gateway system are usually various applications or terminal devices that send requests to backend API services through the API gateway and receive response data. API Gateway Server: The cloud-based API gateway server receives requests, authenticates and controls permissions, and then forwards the requests to the appropriate API service nodes. It also supports load balancing, fault tolerance, and other functions. Edge Gateway: Edge gateways located on edge devices perform similar tasks, but their main role is to reduce network latency and bandwidth consumption, bringing API services as close to the user as possible. Backend API Service Cluster: A cluster of multiple API service nodes handles API requests and responses, providing various API interfaces and services. In this architecture, the API gateway system acts as a bridge connecting clients and backend API services. On the one hand, it can control and monitor the security, stability and reliability of API calls; on the other hand, it can coordinate the work of different API service nodes on cloud and edge devices to achieve unified management and scheduling, thereby improving the efficiency and reliability of API calls.

[0059] In this embodiment of the invention, API services are deployed in the cloud and edge devices respectively to generate an API service cluster. Dynamic load balancing is performed on the API service cluster to obtain the target load status. Based on the target load status, the optimal API service node is called from the API service cluster to obtain the first API service node. Fault detection is performed on the first API service node to obtain the fault detection result. Based on the fault detection result, a normal second API service node is called from the API service cluster. API call requests are obtained from the second API service node, and authentication and access control are performed on the API call requests to obtain a security authentication result. Based on the security authentication result, the API gateway system is invoked to communicate with the API service cluster to obtain the target API service. This invention achieves efficient and reliable API calls by deploying API services in the cloud and edge devices and combining dynamic load balancing, failover, and security authentication mechanisms.

[0060] In one specific embodiment, the process of performing step S101 may specifically include the following steps:

[0061] (1) Obtain different business requirements and resource constraints, and determine the cloud-edge deployment strategy based on business requirements and resource constraints;

[0062] (2) Based on the cloud-edge deployment strategy, API services are deployed on the pre-built cloud and edge devices respectively to obtain multiple deployment API services;

[0063] (3) Perform cluster processing on multiple deployed API services to generate an API service cluster.

[0064] Specifically, the API service is deployed on cloud servers. Different types of cloud computing platforms, such as public, private, or hybrid clouds, can be chosen. Deploying API services in the cloud fully leverages the high performance and reliability of cloud computing platforms to meet the processing needs of large-scale concurrent requests. On edge devices, the API service is deployed on edge devices, such as smart streetlights and smart locks. By deploying API services closer to users, data transmission time and network bandwidth usage are reduced, thereby improving the user experience. Furthermore, deploying API services on edge devices reduces reliance on cloud resources, improving system robustness and reliability. An API service cluster is formed after deploying API services in the cloud and on edge devices. This cluster can employ various technologies to achieve load balancing, failover, and other functions to improve the reliability, stability, and throughput of the API service. Specifically, regarding load balancing within the cluster, this technology can employ a dynamic load balancing mechanism to dynamically select the optimal API service node for invocation based on the current load. Furthermore, this technology can also introduce a failover mechanism, automatically switching to other normal nodes when an API service node fails, ensuring high availability of the API service. In this embodiment, by deploying API services on both cloud and edge devices, a distributed API service cluster is formed. This technology can fully leverage the advantages of cloud computing and edge computing to improve the performance and reliability of API services, and can adapt to the needs of different scenarios.

[0065] In one specific embodiment, such as Figure 2 As shown, the process of executing step S102 can specifically include the following steps:

[0066] S201. Match the corresponding load balancing algorithm according to business needs;

[0067] S202. Based on the load balancing algorithm, perform dynamic load balancing on the API service cluster and obtain the target load status of the API service cluster.

[0068] S203. Based on the target load status, call the optimal API service node from the API service cluster to obtain the first API service node.

[0069] Specifically, the server implementation plan is as follows: Define a load balancing strategy: First, a load balancing strategy needs to be defined. Based on different business scenarios and requirements, a suitable load balancing algorithm should be selected. Commonly used load balancing algorithms include round-robin, weighted round-robin, random, and least connections. Collect load information: To achieve dynamic load balancing, load information of API service nodes needs to be collected, including CPU utilization, memory utilization, and network bandwidth utilization. This can be collected through monitoring software, system commands, or other methods. Real-time calculation of load status: After collecting the load information of API service nodes, real-time calculation is needed according to the load balancing strategy to obtain the load status of each API service node. For example, the load index of each node can be calculated based on the weighted average of CPU utilization and memory utilization. Intelligent selection of the optimal node: Based on the calculated load status of the API service nodes, the optimal node is selected for API calls. The load balancing strategy can be used to select API service nodes with lighter loads to avoid performance degradation due to excessive requests. Dynamically adjust the load balancing strategy: The load balancing strategy needs to be dynamically adjusted according to the actual situation. For example, when an API service node fails, it needs to be immediately excluded from the load balancing scope; when an API service node is added or deleted, the load balancing strategy also needs to be modified accordingly. Ensuring high availability: Since load balancing is one of the core mechanisms of the entire API service cluster, its high availability must be ensured. A master-slave mode or a cluster mode can be adopted to ensure that the load balancer itself does not become a single point of failure and provides a highly available interface to the outside world. In this embodiment, the cloud-edge collaborative dynamic load balancing mechanism is a complex system that needs to consider many factors, including performance, reliability, and security. Through reasonable design and implementation, the performance and reliability of API services can be significantly improved, thereby meeting the needs of different scenarios.

[0070] In one specific embodiment, such as Figure 3 As shown, the process of executing step S103 can specifically include the following steps:

[0071] S301. Perform fault detection on the first API service node and obtain the fault detection results, including: whether a fault exists or not.

[0072] S302. If a fault exists, the first API service node will be switched based on the preset fault transfer mechanism.

[0073] S303, Call the second API service node that is functioning normally from the API service cluster.

[0074] It's important to note the following steps: Monitoring node status: To promptly detect faulty nodes, the status of all API service nodes in the cluster needs to be monitored. Methods such as heartbeat detection can be used to periodically send requests to nodes and determine their responsiveness. Detecting faulty nodes: When an API service node fails to respond to requests, it is considered a faulty node. At this point, it needs to be promptly identified and marked as "unavailable." Electing a new worker node: Once a faulty API service node is detected, a new worker node needs to be elected to take over its tasks. Various algorithms can be used, such as weighted election or random election, to select the node with the lightest load to take over. Synchronizing data: After the new node takes over, it needs to synchronize the data and status information of the original node to ensure business continuity. Data synchronization can be achieved using technologies such as data backup and data synchronization. Restoring services: Once the new node completes data synchronization, it can receive and process business requests normally. The entire failover process typically needs to be completed within seconds or tens of seconds to ensure high availability of the API service. Compared to load balancing mechanisms, failover mechanisms are more complex and require consideration of more factors, such as node status monitoring frequency, fault determination strategies, and fault recovery time. To ensure system stability and reliability, the failover mechanism needs thorough testing, and a comprehensive monitoring and alarm system needs to be established to promptly detect and resolve faults. In this embodiment, the failover mechanism is crucial for ensuring the high availability of the API service. Through proper design and implementation, the entire API service cluster can achieve high stability and availability, thereby meeting the needs of different scenarios.

[0075] In one specific embodiment, such as Figure 4 As shown, the process of executing step S104 can specifically include the following steps:

[0076] S401. Obtain the corresponding API call request based on the second API service node;

[0077] S402. Query the identity information corresponding to the API call request, verify the identity information, and obtain the authentication result;

[0078] S403. Perform access control on API call requests and obtain the access control results;

[0079] S404. Based on the authentication result and access control result, generate a security authentication result, which includes: security authentication passed and security authentication failed.

[0080] Specifically, in a distributed API service cluster, to ensure the security of API services, a security authentication mechanism needs to be introduced to authenticate API call requests and control access, preventing unauthorized access and attacks. The security authentication mechanism mainly includes the following aspects: Authentication: Used to verify the identity information of the API caller, preventing forged requests and impersonation. Various authentication methods can be used, such as HTTP Basic Authentication, OAuth 2.0 authentication, and Token authentication. Access Control: Used to control the access permissions of API callers, preventing malicious access and unauthorized operations. Access control can be implemented through multi-dimensional authorization methods such as roles, permissions, and resources. Data Encryption: Used to protect confidential information during data transmission from being stolen or tampered with. Data encryption can be performed using protocols such as SSL / TLS, and a robust secure channel can be established. Log Monitoring: Used to monitor API call activity, promptly detect anomalies, and respond accordingly. API call logs can be recorded and regularly audited and analyzed to avoid potential security risks. Attack Prevention: Appropriate defense strategies need to be adopted against common network attack methods, such as DDoS attacks, SQL injection, and XSS attacks, to ensure the security of API services. It's important to note that the security authentication mechanism needs to be flexibly configured based on actual circumstances to avoid over-protection leading to performance degradation or API service malfunction. Simultaneously, it needs to cooperate with other mechanisms in the API service cluster (such as load balancing and failover) to form a complete security system. In this embodiment, the security authentication mechanism is crucial for ensuring the security of the API service. Through proper design and implementation, the security and reliability of the API service can be significantly improved, thereby meeting the needs of different scenarios.

[0081] In one specific embodiment, the process of executing step S105 may specifically include the following steps:

[0082] (1) If the security authentication result is that the security authentication is successful, the pre-set API gateway system is invoked to respond to the API call request;

[0083] (2) Through the API service cluster in the cloud and edge devices, API call requests are communicated via API service to query the corresponding target API service.

[0084] Specifically, in a distributed API service cluster, to achieve unified management and scheduling, and to improve API call efficiency and reliability, a cloud-edge collaborative API gateway system needs to be developed as the entry point for API services. The API gateway system mainly includes the following functions: Request Processing: As the entry point for API services, the API gateway system needs to process requests from clients and classify and forward them based on request characteristics. Request processing can be performed using reverse proxy, routing, or other methods. Unified Management: The API gateway system needs to uniformly manage all API service nodes, including node status, load, access permissions, and other information. A registry of API service nodes can be established using technologies such as a registry center to achieve unified management. Load Balancing: When multiple API service nodes respond to the same request, the API gateway system needs to select appropriate nodes for load balancing to ensure the efficiency and reliability of the API service. Different load balancing strategies can be selected, such as round-robin, weighted round-robin, and random. Security Authentication: As the entry point for API services, the API gateway system also needs to implement a security authentication mechanism to authenticate and control the permissions of API callers before processing API call requests. Security authentication can be performed using methods such as token authentication and OAuth 2.0 authentication. Edge Computing Support: To meet the API call requirements in edge computing scenarios, the API gateway system needs to support communication with API service clusters on edge devices to achieve lower latency and higher efficiency API calls. Monitoring and Alerting: To promptly identify and resolve issues, the API gateway system needs to establish a robust monitoring and alerting mechanism, regularly checking the operational status and load of API service nodes to promptly identify potential problems and respond accordingly. It should be noted that developing an API gateway system requires consideration of multiple factors, such as performance, reliability, and security. To ensure system stability and availability, the API gateway system needs thorough testing and a flexible, scalable architecture. In this embodiment, the API gateway system is a complex system that requires comprehensive consideration of various factors. Through proper design and implementation, the efficiency and reliability of API services can be significantly improved, thereby meeting the needs of different scenarios.

[0085] The cloud-edge collaborative distributed API call method in this embodiment of the invention has been described above. The cloud-edge collaborative distributed API call system in this embodiment of the invention is described below. Please refer to [link / reference]. Figure 5 One embodiment of the cloud-edge collaborative distributed API call system in this invention includes:

[0086] Deployment module 501 is used to deploy API services in pre-built cloud and edge devices to generate API service clusters;

[0087] The processing module 502 is used to perform dynamic load balancing processing on the API service cluster, obtain the target load status, and call the optimal API service node from the API service cluster according to the target load status to obtain the first API service node.

[0088] The detection module 503 is used to perform fault detection on the first API service node, obtain the fault detection result, and call the second API service node with normal node from the API service cluster according to the fault detection result.

[0089] The control module 504 is used to obtain the corresponding API call request according to the second API service node, and to perform authentication and access control on the API call request to obtain a security authentication result;

[0090] The communication module 505 is used to call a pre-set API gateway system to communicate with the API service cluster in the cloud and the edge device based on the security authentication result, so as to obtain the target API service.

[0091] Through the collaborative efforts of the aforementioned components, API services are deployed in both the cloud and edge devices to generate an API service cluster. Dynamic load balancing is applied to the API service cluster to obtain the target load status. Based on this target load status, the optimal API service node is selected from the cluster to obtain the first API service node. Fault detection is performed on the first API service node to obtain the fault detection result. Based on this result, a healthy second API service node is selected from the cluster. API call requests are obtained from the second API service node, and authentication and access control are performed on these requests to obtain a security authentication result. Based on the security authentication result, the API gateway system is invoked to communicate with the API service cluster to obtain the target API service. This invention achieves efficient and reliable API calls by deploying API services in the cloud and edge devices, combined with dynamic load balancing, failover, and security authentication mechanisms.

[0092] above Figure 5 The cloud-edge collaborative distributed API calling system in this embodiment of the invention is described in detail from the perspective of modular functional entities. The cloud-edge collaborative distributed API calling device in this embodiment of the invention is described in detail from the perspective of hardware processing.

[0093] Figure 6This is a schematic diagram of the structure of a cloud-edge collaborative distributed API calling device 600 provided in an embodiment of the present invention. The cloud-edge collaborative distributed API calling device 600 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 610 (e.g., one or more processors) and a memory 620, and one or more storage media 630 (e.g., one or more mass storage devices) for storing application programs 633 or data 632. The memory 620 and storage media 630 can be temporary or persistent storage. The program stored in the storage media 630 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the cloud-edge collaborative distributed API calling device 600. Furthermore, the processor 610 may be configured to communicate with the storage media 630 and execute the series of instruction operations in the storage media 630 on the cloud-edge collaborative distributed API calling device 600.

[0094] The cloud-edge collaborative distributed API call device 600 may also include one or more power supplies 640, one or more wired or wireless network interfaces 650, one or more input / output interfaces 660, and / or one or more operating systems 631, such as Windows Server, Mac OSX, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 6 The cloud-edge collaborative distributed API call device structure shown does not constitute a limitation on the cloud-edge collaborative distributed API call device. It may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0095] The present invention also provides a cloud-edge collaborative distributed API calling device, which includes a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor performs the steps of the cloud-edge collaborative distributed API calling method in the above embodiments.

[0096] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the cloud-edge collaborative distributed API call method.

[0097] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0098] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0099] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cloud-edge collaborative distributed API calling method, characterized in that, The cloud-edge collaborative distributed API calling method comprises: API services are respectively deployed in a preset cloud and an edge device to generate an API service cluster; Dynamic load balancing is performed on the API service cluster to obtain a target load state, and an optimal API service node is called from the API service cluster according to the target load state to obtain a first API service node; Fault detection is performed on the first API service node to obtain a fault detection result, and a second API service node with a normal node is called from the API service cluster according to the fault detection result; According to the second API service node, a corresponding API calling request is obtained, and identity authentication and permission control are performed on the API calling request to obtain a security authentication result; According to the security authentication result, an API gateway system is called to perform communication on the API service cluster in the cloud and the edge device to obtain a target API service. 2.The cloud-edge collaboration distributed API calling method of claim 1, wherein, The API services are respectively deployed in the preset cloud and the edge device to generate the API service cluster, comprising: Different business requirements and resource constraints are obtained, and a cloud-edge deployment strategy is determined according to the business requirements and the resource constraints; According to the cloud-edge deployment strategy, API services are respectively deployed in the preset cloud and the edge device to obtain a plurality of deployed API services; The plurality of deployed API services are clustered to generate an API service cluster.

3. The cloud-edge collaboration distributed API invocation method of claim 2, wherein, The API service cluster is subjected to dynamic load balancing to obtain a target load state, and an optimal API service node is called from the API service cluster according to the target load state to obtain a first API service node, comprising: According to the business requirements, a corresponding load balancing algorithm is matched; According to the load balancing algorithm, the API service cluster is subjected to dynamic load balancing, and a target load state of the API service cluster is obtained; According to the target load state, an optimal API service node is called from the API service cluster to obtain a first API service node.

4. The cloud-edge collaboration distributed API invocation method of claim 1, wherein, The first API service node is subjected to fault detection to obtain a fault detection result, and a second API service node with a normal node is called from the API service cluster according to the fault detection result, comprising: The first API service node is subjected to fault detection to obtain a fault detection result, wherein the fault detection result comprises: existence of fault and non-existence of fault; If there is a fault, node switching is performed on the first API service node based on a preset fault transfer mechanism; A second API service node with a normal node is called from the API service cluster.

5. The cloud-edge collaboration distributed API invocation method of claim 1, wherein, According to the second API service node, a corresponding API calling request is obtained, and identity authentication and permission control are performed on the API calling request to obtain a security authentication result, comprising: According to the second API service node, a corresponding API calling request is obtained; Identity information corresponding to the API calling request is queried, and identity authentication is performed on the identity information to obtain an identity authentication result; The API calling request is subjected to access control, and an access control result is obtained; According to the identity authentication result and the access control result, a security authentication result is generated, wherein the security authentication result includes security authentication pass and security authentication fail.

6. The cloud-edge collaboration distributed API invocation method of claim 1, wherein, According to the security authentication result, the API gateway system is called to communicate with the API service cluster in the cloud and the edge device to obtain a target API service, including: If the security authentication result is security authentication pass, the API gateway system is called to respond to the API calling request; The API service cluster in the cloud and the edge device is subjected to API service communication to query the corresponding target API service.

7. A cloud-edge collaborative distributed API invocation system, characterized in that, The cloud-edge collaborative distributed API calling system includes: A deployment module is configured to deploy API services in the preset cloud and edge device to generate an API service cluster; A processing module is configured to perform dynamic load balancing processing on the API service cluster to obtain a target load state, and call an optimal API service node from the API service cluster according to the target load state to obtain a first API service node; A detection module is configured to perform fault detection on the first API service node to obtain a fault detection result, and call a second API service node with normal node from the API service cluster according to the fault detection result; A control module is configured to obtain a corresponding API calling request according to the second API service node, and perform identity authentication and access control on the API calling request to obtain a security authentication result; A communication module is configured to call the API gateway system to communicate with the API service cluster in the cloud and the edge device according to the security authentication result to obtain a target API service.

8. The cloud-edge collaboration distributed API invocation system of claim 7, wherein, The deployment module is specifically configured to: Obtain different business requirements and resource constraints, and determine a cloud-edge deployment strategy according to the business requirements and the resource constraints; According to the cloud-edge deployment strategy, API services are deployed in the preset cloud and edge device respectively to obtain a plurality of deployed API services; The plurality of deployed API services are subjected to cluster processing to generate an API service cluster. 9.A cloud-edge collaborative distributed API calling device, characterized in that, The cloud-edge collaborative distributed API calling device includes a memory and at least one processor, and the memory stores instructions; The at least one processor calls the instructions in the memory to enable the cloud-edge collaborative distributed API calling device to perform the cloud-edge collaborative distributed API calling method according to any one of claims 1-6.

10. A computer-readable storage medium having stored thereon instructions, the instructions comprising, The instructions are executed by the processor to implement the cloud-edge collaborative distributed API calling method according to any one of claims 1-6.

Images