CN116319803A - Cloud edge cooperative distributed API calling method and system - Google Patents
Cloud edge cooperative distributed API calling method and system Download PDFInfo
- Publication number
- CN116319803A CN116319803A CN202310355364.0A CN202310355364A CN116319803A CN 116319803 A CN116319803 A CN 116319803A CN 202310355364 A CN202310355364 A CN 202310355364A CN 116319803 A CN116319803 A CN 116319803A
- Authority
- CN
- China
- Prior art keywords
- api
- api service
- cloud
- calling
- edge
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 50
- 238000001514 detection method Methods 0.000 claims abstract description 53
- 238000012545 processing Methods 0.000 claims abstract description 32
- 238000012795 verification Methods 0.000 claims abstract description 24
- 230000007246 mechanism Effects 0.000 claims description 29
- 238000012546 transfer Methods 0.000 claims description 8
- 238000004891 communication Methods 0.000 claims description 7
- 230000008569 process Effects 0.000 description 14
- 238000012544 monitoring process Methods 0.000 description 11
- 238000011084 recovery Methods 0.000 description 7
- 238000013461 design Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 6
- 230000004044 response Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 239000000243 solution Substances 0.000 description 4
- 238000012360 testing method Methods 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005242 forging Methods 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention relates to the field of data processing, and discloses a cloud edge cooperative distributed API calling method and a cloud edge cooperative distributed API calling system, which are used for improving API calling efficiency and reliability. The method comprises the following steps: respectively deploying API services in the cloud and the edge equipment to generate an API service cluster; carrying out dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster 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 cluster according to the fault detection result; acquiring an API call request according to the second API service node, and performing identity verification and authority control on the API call request to obtain a security authentication result; and calling an API gateway system to communicate with the API service cluster according to the security authentication result to obtain the target API service.
Description
Technical Field
The invention relates to the field of data processing, in particular to a cloud edge cooperative distributed API calling method and a cloud edge cooperative distributed API calling system.
Background
In the present digital age, API (ApplicationProgramming Interface) has become a 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 cooperatively operate with a cloud platform, so how to efficiently manage and schedule distributed API services becomes an important technical problem.
For the deployment mode of the API service, the conventional method is to deploy all the API services on a cloud server, so that a large number of requests can be processed in a centralized manner, and unified management and monitoring can be realized. However, this approach has the following problems: the delay is high: because the data needs to be transmitted through the network, even if the request amount is not large, a certain delay is caused, and the user experience is affected. The low latency requirement cannot be met: for application scenarios that require response in real-time or near real-time situations, such as industrial automation, intelligent driving, etc., conventional API service centralized deployment cannot meet its low-latency requirements. Network bandwidth limitation: when the API service is concentrated in the cloud, the edge device needs to frequently send/receive data to the cloud, which consumes a large amount of network bandwidth and increases the operation cost.
Disclosure of Invention
The invention provides a cloud edge cooperative distributed API calling method and a cloud edge cooperative distributed API calling system, which are used for improving API calling efficiency and reliability.
The first aspect of the present invention provides a cloud edge cooperative distributed API call method, where the cloud edge cooperative distributed API call method includes:
respectively deploying API services in a preset cloud and edge equipment to generate an API service cluster;
carrying out dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster 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 cluster according to the fault detection result;
acquiring a corresponding API call request according to the second API service node, and performing identity verification and authority control on the API call request to obtain a security authentication result;
and calling a preset API gateway system to communicate the cloud end with the API service cluster in the edge equipment according to the security authentication result to obtain a target API service.
With reference to the first aspect, in a first implementation manner of the first aspect of the present invention, the deploying API services in a preset cloud end and an edge device respectively, to generate an API service cluster includes:
different service demands and resource constraints are obtained, and cloud edge deployment strategies are determined according to the service demands and the resource constraints;
according to the cloud side deployment strategy, respectively deploying API services on a preset cloud side and edge equipment to obtain a plurality of deployment API services;
and carrying out cluster processing on the plurality of deployment API services to generate an API service cluster.
With reference to the first aspect, in a second implementation manner of the first aspect of the present invention, performing dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster according to the target load state to obtain a first API service node, where the method includes:
matching a corresponding load balancing algorithm according to the service demand;
according to the load balancing algorithm, carrying out dynamic load balancing processing on the API service cluster, and acquiring a target load state of the API service cluster;
and calling an optimal API service node from the API service cluster according to the target load state to obtain a first API service node.
With reference to the first aspect, in a third implementation manner of the first aspect of the present invention, the performing fault detection on the first API service node to obtain a fault detection result, and calling, from the API service cluster, a second API service node with a normal node according to the fault detection result, includes:
performing fault detection on the first API service node to obtain a fault detection result, wherein the fault detection result comprises: the presence of a fault and the absence of a fault;
if a fault exists, switching nodes of the first API service node based on a preset fault transfer mechanism;
and calling a second API service node with normal nodes from the API service cluster.
With reference to the first aspect, in a fourth implementation manner of the first aspect of the present invention, the obtaining, according to the second API service node, a corresponding API call request, and performing identity verification and authority control on the API call request, to obtain a security authentication result, includes:
acquiring a corresponding API call request according to the second API service node;
inquiring identity information corresponding to the API call request, and carrying out identity verification on the identity information to obtain an identity verification result;
Performing access right control on the API call request to obtain an access right control result;
generating a security authentication result according to the identity verification result and the access right control result, wherein the security authentication result comprises: the security authentication passes and the security authentication does not pass.
With reference to the first aspect, in a fifth implementation manner of the first aspect of the present invention, according to the security authentication result, the calling a preset API gateway system to communicate the cloud end with the API service cluster in the edge device to obtain a target API service includes:
if the security authentication result is that the security authentication passes, calling a preset API gateway system to respond to the API calling request;
and carrying out API service communication on the API call request through the cloud and the API service clusters in the edge equipment, and inquiring the corresponding target API service.
The second aspect of the present invention provides a cloud edge cooperative distributed API call system, the cloud edge cooperative distributed API call system comprising:
the deployment module is used for respectively deploying the API service in the preset cloud and edge equipment to generate an API service cluster;
the processing module is used for carrying out dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster according to the target load state to obtain a first API service node;
The detection module is used for carrying out 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 cluster according to the fault detection result;
the control module is used for acquiring a corresponding API call request according to the second API service node, and carrying out identity verification and authority control on the API call request to obtain a security authentication result;
and the communication module is used for calling a preset API gateway system to communicate the cloud end with the API service cluster in the edge equipment according to the security authentication result to obtain a target API service.
A third aspect of the present invention provides a cloud-edge collaborative distributed API call apparatus, including: a memory and at least one processor, the memory having instructions stored therein; and the at least one processor calls the instructions in the memory so that the cloud edge cooperative distributed API call device executes the cloud edge cooperative distributed API call method.
A fourth aspect of the present invention provides a computer readable storage medium having instructions stored therein that, when executed on a computer, cause the computer to perform the cloud-edge collaborative distributed API call method described above.
According to the technical scheme provided by the invention, API services are deployed in the cloud and the edge equipment respectively, and an API service cluster is generated; carrying out dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster 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 cluster according to the fault detection result; acquiring an API call request according to the second API service node, and performing identity verification and authority control on the API call request to obtain a security authentication result; according to the safety authentication result, calling an API gateway system to communicate with an API service cluster to obtain a target API service.
Drawings
FIG. 1 is a schematic diagram of an embodiment of a cloud-edge collaborative distributed API call method according to an embodiment of the present invention;
FIG. 2 is a flow chart of a dynamic load balancing process in an embodiment of the invention;
FIG. 3 is a flow chart of fault detection in an embodiment of the present invention;
FIG. 4 is a flow chart of security authentication in an embodiment of the invention;
FIG. 5 is a schematic diagram of an embodiment of a cloud-edge collaborative distributed API call system according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of an embodiment of a cloud-edge collaborative distributed API call device according to an embodiment of the present invention.
Detailed Description
The embodiment of the invention provides a cloud edge cooperative distributed API calling method and a cloud edge cooperative distributed API calling system, which are used for improving the API calling efficiency and the API calling reliability. The terms "first," "second," "third," "fourth" and the like in the description and in the claims and in the above drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus.
For ease of understanding, the following describes a specific flow of an embodiment of the present invention, referring to fig. 1, and one embodiment of a cloud edge collaborative distributed API call method in an embodiment of the present invention includes:
s101, respectively deploying API services in a preset cloud and edge equipment to generate an API service cluster;
it can be understood that the execution body of the present invention may be a cloud-edge cooperative distributed API call system, and may also be a terminal or a server, which is not limited herein. The embodiment of the invention is described by taking a server as an execution main body as an example.
It should be noted that the API service is distributed and deployed at different locations, including on the cloud and the edge devices. Cloud end generally refers to a data center or server on the internet that can provide high performance storage, computing, and network resources. The edge device refers to a location of the terminal device of the internet of things, such as a smart phone, a sensor, a router, etc., which is closest to the user. The API service is deployed on the edge equipment, so that network delay and bandwidth consumption can be reduced, and response speed and data security are improved. By deploying API services on the cloud and edge devices, respectively, an API service cluster may be formed. The cluster can distribute tasks according to different requirements and can realize functions of load balancing, disaster recovery, backup and the like. Meanwhile, the API service cluster can also use automation tools to monitor, manage and adjust, and ensure high-efficiency and stable operation when processing a large number of concurrent requests.
S102, carrying out dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster according to the target load state to obtain a first API service node;
specifically, in this architecture, API services of different geographic locations and device types are deployed on cloud and edge devices and managed through a dynamic load balancing mechanism. The dynamic load balancing mechanism can intelligently select the optimal API service node to call according to the current load condition. For example, when the load of one node is too high, the request is automatically forwarded to the other node to avoid overload while ensuring high performance and reliability of the request. This is done by the load balancer, which can calculate by various algorithms which API service node is most suitable for handling the current request. To implement such a dynamic load balancing mechanism, the following considerations are required: 1. data acquisition and monitoring: data such as the running state and the resource utilization rate of each API service node are required to be collected, and the load condition of the nodes is required to be monitored in real time. 2. Load balancing algorithm: different load balancing algorithms, such as polling, random, weighted polling, etc., may be used for different application scenarios to balance the load of the API service nodes. 3. Fast route scheduling: an efficient routing strategy needs to be designed to quickly distribute requests to optimal API service nodes. 4. Fault tolerance and recovery: even if some nodes fail or fail, the system still needs to be ensured to be able to operate normally, and the system can be realized by a multi-copy backup mode and the like. In the embodiment, the server provides a plurality of service interfaces, and can intelligently select the optimal node according to the load condition, so that the requirements under various application scenes are met.
S103, 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 cluster according to the fault detection result;
specifically, in order to achieve high availability of API services, a failover mechanism needs to be considered in architecture design, that is, when a certain API service node fails, it needs to be automatically switched to other normal nodes to make a call. The following is a specific embodiment: 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 cannot send a heartbeat signal, the node is considered to be faulty. And (3) fault detection: the load balancer monitors the states of all API service nodes in real time through heartbeat detection and other modes, and when a certain node fails, other nodes and clients are notified in time. Automatic switching: when a node fails, the load balancer automatically routes requests to other normal nodes to ensure high availability of services. Fault tolerance and recovery: at the same time, fault tolerance and recovery processing is also required for the failed node. For example, backup, multiple copies, etc. may be employed to increase the fault tolerance of the system and rejoin the cluster after recovery. And (3) testing and verifying: in practical applications, it is necessary to periodically test and verify whether the failover mechanism is effective, for example, to destroy a certain node or stop the service of a certain node, and to observe whether the load balancer will automatically switch to other normal nodes. In a word, the "realizing the fault transfer mechanism", when a certain API service node fails, it automatically switches to other normal nodes to call, and ensures the high availability of API service "is an important system architecture design, and can provide more stable and reliable service. Through the implementation scheme, the high availability of the API service can be effectively ensured, and the problems of single-point failure, data loss and the like are avoided.
S104, acquiring a corresponding API call request according to the second API service node, and performing identity verification and authority control on the API call request to obtain a security authentication result;
specifically, the embodiment introduces a security authentication mechanism, performs identity verification and authority control on the API call request, and is a key step for ensuring the security of the API service. The mechanism can prevent illegal access, avoid data leakage, prevent malicious attack and other problems. In implementing this mechanism, the following steps are required: and (3) identity authentication: first, identity information of an API caller needs to be confirmed through authentication. Common authentication means include user name passwords, tokens, digital certificates, and the like. For example, a user may log into the system by providing a user name and password to gain access to the API service. And (3) authority control: after authentication, further rights control is required. In this process, it is necessary to identify a role or group to which the API caller belongs and control which resources the API caller can access or which operations are performed according to the authority of the role or group. For example, an administrator may access all API resources and operations, while a typical user may only access some of the resources and operations. And (3) safe transmission: to ensure the security of API requests and responses during transmission, secure transmission protocols, such as HTTPS/SSL, etc., need to be used. The use of these protocols can encrypt the transmitted data, preventing hackers from eavesdropping, forging, or tampering with API requests and responses. Monitoring and logging: in the running process, the use condition of the API service needs to be monitored regularly, and corresponding log information is recorded. This information may be used to track faults, debug problems, discover security vulnerabilities, etc., as well as audit evidence. Updating and maintaining: the security authentication mechanism is a long-term operation that requires constant updating and maintenance. For example, with technology changes and new threat patterns, encryption algorithms, fix vulnerabilities, etc. need to be updated in time to ensure the security of API services.
S105, calling a preset API gateway system to communicate the cloud end with the API service cluster in the edge equipment according to the security authentication result, and obtaining the target API service.
Specifically, the server develops the cloud-edge collaborative API gateway system as an API service inlet, can process requests from clients and communicate with the cloud and the API service clusters on the edge equipment, so that unified management and scheduling are realized, and the API calling efficiency and reliability are improved. An API gateway system typically includes several components: client side: the clients of the API gateway system are typically various applications or terminal devices that send requests to the backend API service through the API gateway while also receiving response data. API gateway server: the API gateway server located at the cloud end is responsible for receiving the request, carrying out identity verification and authority control on the request, and then forwarding the request to the corresponding API service node. It can also support functions such as load balancing, fault tolerance recovery, etc. Edge gateway: edge gateways located on edge devices are also responsible for similar tasks, but their main role is to reduce network latency and bandwidth consumption, bringing the API services as close as possible to the user. Back-end API service cluster: the cluster formed by a plurality of API service nodes is responsible for processing requests and responses of the APIs and providing various API interfaces and services. In this architecture, the API gateway system acts as a bridge between the connection client and the backend API service. On one hand, the method can control and monitor the safety, stability and reliability in the API calling process; on the other hand, the cloud end and the edge equipment can coordinate the work of different API service nodes, so that unified management and scheduling are realized, and the API calling efficiency and reliability are improved.
In the embodiment of the invention, API services are respectively deployed in the cloud and the edge equipment to generate an API service cluster; carrying out dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster 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 cluster according to the fault detection result; acquiring an API call request according to the second API service node, and performing identity verification and authority control on the API call request to obtain a security authentication result; according to the safety authentication result, calling an API gateway system to communicate with an API service cluster to obtain a target API service.
In a specific embodiment, the process of executing step S101 may specifically include the following steps:
(1) Different business requirements and resource constraints are obtained, and cloud edge deployment strategies are determined according to the business requirements and the resource constraints;
(2) According to cloud side deployment strategies, respectively carrying out API service deployment on a preset cloud side and edge equipment to obtain a plurality of deployment API services;
(3) And carrying out cluster processing on the plurality of deployment API services to generate an API service cluster.
Specifically, the server is at the cloud: the API service is deployed on a server on the cloud. Different types of cloud computing platforms, such as public cloud, private cloud, or hybrid cloud, may be selected. The API service can be deployed at the cloud end, so that the advantages of high performance, high reliability and the like of the cloud computing platform can be fully utilized, and the processing requirement of large-scale concurrent requests can be met. On the edge device: the API service is deployed on edge devices, such as intelligent street lamps, intelligent door locks, etc. By deploying the API service closer to the user, the transmission time of the data and the network bandwidth usage can be reduced, thereby improving the user experience. In addition, the API service is deployed on the edge equipment, so that the dependence on cloud resources can be reduced, and the robustness and reliability of the system are improved. Forming an API service cluster: after the API services are deployed on the cloud and edge devices, they are organized to form a distributed API service cluster. The cluster can adopt various technical means to realize the functions of load balancing, fault transfer and the like so as to improve the reliability, stability and throughput of the API service. Aiming at the problem of load balancing of the API service in the cluster, the technology can adopt a dynamic load balancing mechanism to dynamically select the optimal API service node for calling according to the current load condition. Meanwhile, the technology can also introduce a fault transfer mechanism, and when a certain API service node fails, the node is automatically switched to other normal nodes to call, so that the high availability of the API service is ensured. In this embodiment, by respectively deploying API services on the cloud and the edge devices, a distributed API service cluster is formed, which can fully utilize the advantages of cloud computing and edge computing, improve the performance and reliability of the API service, and adapt to the requirements of different scenes.
In a specific embodiment, as shown in fig. 2, the process of executing step S102 may specifically include the following steps:
s201, matching a corresponding load balancing algorithm according to service requirements;
s202, carrying out dynamic load balancing processing on the API service cluster according to a load balancing algorithm, and acquiring a target load state of the API service cluster;
s203, calling an optimal API service node from the API service cluster according to the target load state to obtain a first API service node.
Specifically, the server embodiments are as follows: defining a load balancing strategy: firstly, a set of load balancing strategies needs to be defined, and a proper load balancing algorithm is selected according to different service scenes and requirements. Common load balancing algorithms include polling, weighted polling, random, minimum connection, etc. Load information is collected: in order to realize dynamic load balancing, load information of the API service node needs to be collected, including CPU utilization, memory utilization, network bandwidth utilization and the like. The collection may be by monitoring software, system commands, or other means. Calculating the load state in real time: after the load information of the API service nodes is collected, real-time calculation is needed according to a load balancing strategy, and the load state of each API service node is obtained. For example, the load index of each node may be calculated from a weighted average of CPU utilization and memory utilization. Intelligent selection of optimal nodes: and selecting an optimal node to call the API according to the calculated load state of the API service node. According to the load balancing strategy, the API service node with lighter load can be selected, and performance degradation caused by excessive requests is avoided. Dynamically adjusting a load balancing strategy: the load balancing strategy needs to be dynamically adjusted according to actual conditions. For example, when a certain API service node fails, it needs to be immediately excluded from the load balancing range; when API service nodes are added or deleted, the load balancing policy also needs to be modified accordingly. Ensuring high availability: since load balancing is one of the core mechanisms of the entire API service cluster, it is necessary to ensure its high availability. A master-slave mode or cluster mode may be employed to ensure that the load balancer itself does not become a single point of failure and to provide a highly available interface to the outside. In this embodiment, the cloud-edge cooperative dynamic load balancing mechanism is a complex system, and needs to consider various factors including performance, reliability, security, and the like. Through reasonable design and implementation, the performance and reliability of the API service can be greatly improved, so that the requirements under different scenes are met.
In a specific embodiment, as shown in fig. 3, the process of executing step S103 may specifically include the following steps:
s301, performing fault detection on the first API service node to obtain a fault detection result, wherein the fault detection result comprises: the presence of a fault and the absence of a fault;
s302, if a fault exists, switching nodes of the first API service node based on a preset fault transfer mechanism;
s303, calling a second API service node with normal node from the API service cluster.
Note that, the monitoring node state: in order to discover a failed node in time, state monitoring needs to be performed on all API service nodes in the cluster. The method such as heartbeat detection can be used for periodically sending requests to the nodes to judge whether the nodes respond or not. Finding out a fault node: an API service node is considered a failed node when it cannot respond to a request. At this point, the node needs to be found and marked as "unavailable" in time. Electing a new working node: once a failure of an API service node is found, a new working node needs to be elected to take over its tasks. Various algorithms may be employed, such as weight-based elections, random elections, etc., to elect the least loaded node to take over the work. Synchronizing data: when the new node takes over the work, the data and state information of the original node need to be synchronized so as to ensure the service continuity. The data synchronization can be realized by using technical means such as data backup, data synchronization and the like. Restoration service: after the new node completes the data synchronization, the service request can be normally received and processed. The entire failover process typically needs to be completed in seconds or tens of seconds to ensure high availability of API services. Compared with a load balancing mechanism, the fault transfer mechanism is more complex, and more factors such as node state monitoring frequency, fault determination strategy, fault recovery time and the like need to be considered. In order to ensure the stability and reliability of the system, the failover mechanism needs to be fully tested, and a perfect monitoring and alarming mechanism is established to discover and remove faults in time. In this embodiment, the failover mechanism is critical to guarantee high availability of API services. Through reasonable design and implementation, the whole API service cluster has higher stability and availability, thereby meeting the requirements in different scenes.
In a specific embodiment, as shown in fig. 4, the process of executing step S104 may specifically include the following steps:
s401, acquiring a corresponding API call request according to a second API service node;
s402, inquiring identity information corresponding to the API call request, and carrying out identity verification on the identity information to obtain an identity verification result;
s403, performing access right control on the API call request to obtain an access right control result;
s404, generating a security authentication result according to the identity verification result and the access right control result, wherein the security authentication result comprises: the security authentication passes and the security authentication does not pass.
Specifically, in the distributed API service cluster, in order to ensure the security of the API service, the server needs to introduce a security authentication mechanism to perform identity verification and authority control on the API call request, so as to prevent illegal access and attack. The security authentication mechanism mainly comprises the following aspects: and (3) identity authentication: the method is used for verifying the identity information of the API caller and preventing fake requests and impersonation of identities. Authentication may be performed in a variety of ways, such as HTTP basic authentication, oauth2.0 authentication, token authentication, etc. And (3) authority control: the method is used for controlling the access authority of the API caller and preventing malicious access and unauthorized operation. The authority control can be performed in a multidimensional authorization mode such as roles, authorities, resources and the like. Data encryption: for protecting confidential information during data transmission from theft or tampering. Protocols such as SSL/TLS and the like can be adopted for data encryption, and a perfect security channel is established. And (3) log monitoring: the method is used for monitoring the API call condition, finding out abnormal conditions in time and responding. The API call log can be recorded and audited and analyzed regularly, so that potential safety risks are avoided. And (3) preventing attack: aiming at common network attack means such as DDoS attack, SQL injection, XSS attack and the like, corresponding defending strategies are needed to ensure the safety of API service. It should be noted that, the security authentication mechanism needs to be flexibly configured according to actual situations, so as to avoid performance degradation or abnormal operation of API service caused by excessive protection. Meanwhile, the system also needs to be matched with other mechanisms (such as load balancing, fault transfer and the like) of the API service cluster to form a complete security system. In this embodiment, the security authentication mechanism is critical to ensure the security of the API service. Through reasonable design and implementation, the safety and reliability of the API service can be greatly improved, so that the requirements under different scenes are met.
In a specific embodiment, the process of executing step S105 may specifically include the following steps:
(1) If the security authentication result is that the security authentication passes, calling a preset API gateway system to respond to the API calling request;
(2) And carrying out API service communication on the API call request through the cloud and the API service clusters in the edge equipment, and inquiring the corresponding target API service.
Specifically, in the distributed API service cluster, in order to implement unified management and scheduling and improve the efficiency and reliability of API call, a cloud-edge collaborative API gateway system needs to be developed as an API service entry. The API gateway system mainly comprises the following functions: request processing: as a portal to the API service, the API gateway system needs to process requests from clients and classify and forward according to the characteristics of the requests. The request processing may be performed by reverse proxy, route distribution, etc. And (3) unified management: the API gateway system needs to uniformly manage all API service nodes, including information such as state, load condition, access right, etc. of the nodes. The registry of the API service nodes can be established by using technical means such as a registry, and unified management is realized. Load balancing: when a plurality of API service nodes respond to the same request, the API gateway system needs to select a proper node for load balancing so as to ensure the efficiency and the reliability of the API service. The selection may be made according to different load balancing strategies such as polling, weighted polling, random, etc. And (3) safety authentication: as an entrance to the API service, the API gateway system also needs to implement a security authentication mechanism to authenticate and control the rights of the API caller before processing the API call request. The security authentication can be performed by means of token authentication, oauth2.0 authentication and the like. Edge computing support: aiming at the API call requirement in the edge computing scene, the API gateway system needs to support communication with an API service cluster on the edge device so as to realize lower-delay and high-efficiency API call. Monitoring and alarming: in order to discover and solve the problems in time, the API gateway system needs to establish a perfect monitoring and alarming mechanism, periodically check the running state and the load condition of the API service node, discover the potential problems in time and respond. It should be noted that, various factors, such as performance, reliability, security, etc., need to be considered in developing the API gateway system. In order to ensure the stability and usability of the system, it is necessary to fully test the API gateway system and build a flexible and extensible architecture. In this embodiment, the API gateway system is a complex system, and multiple factors need to be comprehensively considered. Through reasonable design and implementation, the efficiency and reliability of the API service can be greatly improved, so that the requirements under different scenes are met.
The cloud side cooperative distributed API call method in the embodiment of the present invention is described above, and the cloud side cooperative distributed API call system in the embodiment of the present invention is described below, referring to fig. 5, where an embodiment of the cloud side cooperative distributed API call system in the embodiment of the present invention includes:
the deployment module 501 is configured to deploy API services in a preset cloud end and an edge device respectively, and generate an API service cluster;
the processing module 502 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 503, 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 a normal node from the API service cluster according to the fault detection result;
the control module 504 is configured to obtain a corresponding API call request according to the second API service node, and perform identity verification and authority control on the API call request to obtain a security authentication result;
and the communication module 505 is configured to call a preset API gateway system to communicate the cloud end with the API service cluster in the edge device according to the security authentication result, so as to obtain a target API service.
Through the cooperation of the components, respectively deploying API services in the cloud and the edge equipment to generate an API service cluster; carrying out dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster 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 cluster according to the fault detection result; acquiring an API call request according to the second API service node, and performing identity verification and authority control on the API call request to obtain a security authentication result; according to the safety authentication result, calling an API gateway system to communicate with an API service cluster to obtain a target API service.
The cloud side cooperative distributed API call system in the embodiment of the present invention is described in detail in fig. 5 from the perspective of a modularized functional entity, and the cloud side cooperative distributed API call device in the embodiment of the present invention is described in detail in the perspective of hardware processing.
Fig. 6 is a schematic structural diagram of a cloud-edge cooperative distributed API call device according to an embodiment of the present invention, where the cloud-edge cooperative distributed API call device 600 may generate relatively large differences according to different configurations or performances, and may include one or more processors (central processing units, CPU) 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) storing application programs 633 or data 632. Wherein the memory 620 and the storage medium 630 may be transitory or persistent storage. The program stored on the storage medium 630 may include one or more modules (not shown), each of which may include a series of instruction operations in the cloud-edge collaborative distributed API-calling device 600. Still further, the processor 610 may be configured to communicate with the storage medium 630 to execute a series of instruction operations in the storage medium 630 on the cloud-side co-distributed API-calling device 600.
The cloud-edge co-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 Serves, mac OSX, unix, linux, freeBSD, and the like. Those skilled in the art will appreciate that the cloud-edge co-distributed API-calling device structure shown in fig. 6 does not constitute a limitation of the cloud-edge co-distributed API-calling device, and may include more or fewer components than shown, or may combine certain components, or may be a different arrangement of components.
The invention also provides cloud edge cooperative distributed API calling equipment, which comprises a memory and a processor, wherein the memory stores computer readable instructions, and when the computer readable instructions are executed by the processor, the processor executes the steps of the cloud edge cooperative distributed API calling method in the embodiments.
The invention also provides a computer readable storage medium, which can be a nonvolatile computer readable storage medium, and can also be a volatile computer readable storage medium, wherein the computer readable storage medium stores instructions, and when the instructions run on a computer, the instructions cause the computer to execute the steps of the cloud edge collaborative distributed API calling method.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (randomacceS memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
The above embodiments are only for illustrating the technical solution of the present invention, and not for limiting the same; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims (10)
1. The cloud edge cooperative distributed API calling method is characterized by comprising the following steps of:
respectively deploying API services in a preset cloud and edge equipment to generate an API service cluster;
carrying out dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster 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 cluster according to the fault detection result;
Acquiring a corresponding API call request according to the second API service node, and performing identity verification and authority control on the API call request to obtain a security authentication result;
and calling a preset API gateway system to communicate the cloud end with the API service cluster in the edge equipment according to the security authentication result to obtain a target API service.
2. The cloud-edge collaborative distributed API call method according to claim 1, wherein the deploying API services in the preset cloud and edge devices respectively, generating an API service cluster, includes:
different service demands and resource constraints are obtained, and cloud edge deployment strategies are determined according to the service demands and the resource constraints;
according to the cloud side deployment strategy, respectively deploying API services on a preset cloud side and edge equipment to obtain a plurality of deployment API services;
and carrying out cluster processing on the plurality of deployment API services to generate an API service cluster.
3. The cloud-edge collaborative distributed API call method according to claim 2, wherein said dynamically load balancing the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster according to the target load state to obtain a first API service node, comprising:
Matching a corresponding load balancing algorithm according to the service demand;
according to the load balancing algorithm, carrying out dynamic load balancing processing on the API service cluster, and acquiring a target load state of the API service cluster;
and calling an optimal API service node from the API service cluster according to the target load state to obtain a first API service node.
4. The cloud edge cooperative distributed API call method as claimed in claim 1, wherein said performing fault detection on said first API service node to obtain a fault detection result, and calling a second API service node with a normal node from said API service cluster according to said fault detection result, includes:
performing fault detection on the first API service node to obtain a fault detection result, wherein the fault detection result comprises: the presence of a fault and the absence of a fault;
if a fault exists, switching nodes of the first API service node based on a preset fault transfer mechanism;
and calling a second API service node with normal nodes from the API service cluster.
5. The cloud-edge collaborative distributed API call method according to claim 1, wherein said obtaining, according to the second API service node, a corresponding API call request, and performing identity verification and authority control on the API call request, to obtain a security authentication result, includes:
Acquiring a corresponding API call request according to the second API service node;
inquiring identity information corresponding to the API call request, and carrying out identity verification on the identity information to obtain an identity verification result;
performing access right control on the API call request to obtain an access right control result;
generating a security authentication result according to the identity verification result and the access right control result, wherein the security authentication result comprises: the security authentication passes and the security authentication does not pass.
6. The cloud-edge collaborative distributed API call method according to claim 1, wherein the calling a preset API gateway system to communicate the cloud and the API service cluster in the edge device according to the security authentication result to obtain a target API service includes:
if the security authentication result is that the security authentication passes, calling a preset API gateway system to respond to the API calling request;
and carrying out API service communication on the API call request through the cloud and the API service clusters in the edge equipment, and inquiring the corresponding target API service.
7. The cloud edge cooperative distributed API calling system is characterized by comprising:
The deployment module is used for respectively deploying the API service in the preset cloud and edge equipment to generate an API service cluster;
the processing module is used for carrying out dynamic load balancing processing on the API service cluster to obtain a target load state, and calling an optimal API service node from the API service cluster according to the target load state to obtain a first API service node;
the detection module is used for carrying out 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 cluster according to the fault detection result;
the control module is used for acquiring a corresponding API call request according to the second API service node, and carrying out identity verification and authority control on the API call request to obtain a security authentication result;
and the communication module is used for calling a preset API gateway system to communicate the cloud end with the API service cluster in the edge equipment according to the security authentication result to obtain a target API service.
8. The cloud-edge collaborative distributed API call system of claim 7, wherein the deployment module is specifically configured to:
different service demands and resource constraints are obtained, and cloud edge deployment strategies are determined according to the service demands and the resource constraints;
According to the cloud side deployment strategy, respectively deploying API services on a preset cloud side and edge equipment to obtain a plurality of deployment API services;
and carrying out cluster processing on the plurality of deployment API services to generate an API service cluster.
9. A cloud-edge collaborative distributed API call device, the cloud-edge collaborative distributed API call device comprising: a memory and at least one processor, the memory having instructions stored therein;
the at least one processor invoking the instructions in the memory to cause the cloud-edge co-distributed API-invoking device to perform the cloud-edge co-distributed API-invoking method of any of claims 1-6.
10. A computer readable storage medium having instructions stored thereon, which when executed by a processor implement the cloud-edge collaborative distributed API-call method of any of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310355364.0A CN116319803A (en) | 2023-04-06 | 2023-04-06 | Cloud edge cooperative distributed API calling method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310355364.0A CN116319803A (en) | 2023-04-06 | 2023-04-06 | Cloud edge cooperative distributed API calling method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116319803A true CN116319803A (en) | 2023-06-23 |
Family
ID=86778043
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310355364.0A Pending CN116319803A (en) | 2023-04-06 | 2023-04-06 | Cloud edge cooperative distributed API calling method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116319803A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116566865A (en) * | 2023-07-11 | 2023-08-08 | 湖南星汉数智科技有限公司 | Bag grabbing system and method |
-
2023
- 2023-04-06 CN CN202310355364.0A patent/CN116319803A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116566865A (en) * | 2023-07-11 | 2023-08-08 | 湖南星汉数智科技有限公司 | Bag grabbing system and method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7076801B2 (en) | Intrusion tolerant server system | |
| US9769170B2 (en) | Synchronizing credential hashes between directory services | |
| Zhou et al. | SDN-RDCD: A real-time and reliable method for detecting compromised SDN devices | |
| US20050027862A1 (en) | System and methods of cooperatively load-balancing clustered servers | |
| JP2007507760A (en) | Secure cluster configuration dataset transfer protocol | |
| CN106911648B (en) | Environment isolation method and equipment | |
| CN112149105A (en) | Data processing system, method, related device and storage medium | |
| Babay et al. | Network-attack-resilient intrusion-tolerant SCADA for the power grid | |
| Shao et al. | Blockchain-based SDN security guaranteeing algorithm and analysis model | |
| CN113645213A (en) | Multi-terminal network management monitoring system based on VPN technology | |
| CN116319803A (en) | Cloud edge cooperative distributed API calling method and system | |
| CN114422201A (en) | Network target range large-scale user remote access method and system | |
| Kim | Securing the Internet of Things via locally centralized, globally distributed authentication and authorization | |
| Khelil et al. | Protection of SCADA communication channels | |
| CN108600156B (en) | Server and security authentication method | |
| Costan et al. | A fault tolerance approach for distributed systems using monitoring based replication | |
| Khosravifar et al. | An experience improving intrusion detection systems false alarm ratio by using honeypot | |
| CN117131493A (en) | Authority management system construction method, device, equipment and storage medium | |
| Latah et al. | When SDN and blockchain shake hands | |
| CN112583951B (en) | Application layer double-live method, device, equipment and storage medium | |
| Meling et al. | When you don't trust clients: Byzantine proposer fast paxos | |
| CN114584344A (en) | Network access control method and system | |
| Alturfi et al. | An advanced classification of cloud computing security techniques: A survey | |
| Ayaburi et al. | Securing supervisory control and data acquisition systems: Factors and research direction | |
| CN114124459B (en) | Cluster server security protection method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |