Micro-service security communication method and system, electronic equipment and storage medium

Abstract

The invention discloses a micro-service secure communication method and system, electronic equipment and a storage medium, which are used for realizing communication between a request micro-service and a target micro-service, and the micro-service secure communication method comprises the following steps: generating security information based on the micro-service, the security information comprising identity information and authority information; requesting the micro service to initiate a calling request; generating encrypted data based on the calling request; generating an operation certificate based on the calling request, wherein the operation certificate comprises user identity information and operation content; and the target micro-service obtains the encrypted data and calls the operation basis and the security information to carry out security verification, and when the verification is passed, response data is generated and sent to the request micro-service. According to the invention, a comprehensive security mechanism of identity verification, authority control, data encryption and integrity protection is realized, so that the security risk is effectively reduced, and the security and reliability of communication between micro-services of different domains are ensured.

Description

Technical Field

[0001] The present invention belongs to the field of data transmission technology, and specifically relates to a microservice secure communication method, system, electronic device and storage medium. Background Art

[0002] In complex distributed systems, microservices are usually deployed in different security domains. Although this architecture improves the flexibility and scalability of the system, it also brings many security challenges.

[0003] In related technologies, existing cross-domain call mechanisms lack effective trust and data protection mechanisms. During a cross-domain call, it's difficult to determine the true identity and permissions of the caller, and there's no way to ensure that the transmitted data hasn't been tampered with. For example, an attacker could forge an identity or tamper with data to gain unauthorized access, leading to data leaks or malicious system exploitation. On the other hand, while traditional gatekeeper-based approaches offer some security, they lack flexibility and real-time processing capabilities. Summary of the Invention

[0004] The purpose of the present invention is to ensure data security and system defense functions when data is transmitted between microservices in different domains.

[0005] To achieve the above-mentioned objectives, the present invention proposes a microservice secure communication method for realizing communication between a requesting microservice and a target microservice, the microservice secure communication method comprising: generating security information based on the microservice, the security information including identity information and permission information; the requesting microservice initiating a call request; generating encrypted data based on the call request; generating an operation credential based on the call request, the operation credential including user identity information and operation content; the target microservice obtaining the encrypted data and calling the operation credential and the security information for security verification, and when the verification passes, generating response data and sending it to the requesting microservice.

[0006] In an optional implementation, generating security information based on the microservice specifically includes: building each microservice management node in the alliance chain; and generating the security information based on the microservice management node.

[0007] In an optional embodiment, the call request includes request body data, and generating encrypted data based on the call request specifically includes: encrypting the request body data to obtain request body encrypted data; performing hash calculation on the request body encrypted data to obtain a hash value of an encryption key; signing the request body data to obtain signature data; wherein the encrypted data includes the request body encrypted data, the hash value of the encryption key and the signature data.

[0008] In an optional implementation, the request body data is encrypted to obtain request body encrypted data, specifically including: encrypting the request body data using a symmetric encryption algorithm to obtain a symmetric encryption key; and encrypting the symmetric encryption key using an asymmetric encryption algorithm to obtain request body encrypted data.

[0009] In an optional embodiment, the target microservice calls the operation credential and the security information based on the encrypted data for security verification. When the verification is successful, response data is generated and sent to the requesting microservice, specifically including: calling the security information, verifying the data signature, judging whether the identity is forged and whether it complies with the authority to call the interface, and when the judgment result is no, the verification is successful; calling the operation credential, comparing the received encrypted data signature with the signature in the operation credential, and the hash value of the encrypted data to see if they are consistent, and when the comparison results are consistent, the verification is successful; when all verifications are successful, the response data is generated and sent to the requesting microservice.

[0010] In an optional embodiment, the microservice secure communication method further includes: processing a call request to obtain a request processing result; generating a target protocol code according to a target protocol specification and the request processing result, wherein the target protocol code includes a service definition and a protocol adaptation layer code.

[0011] In an optional embodiment, processing a call request to obtain a request processing result specifically includes: prioritizing the call request according to a pre-assigned weight factor to obtain a request queue sorted by priority; performing source protocol parsing on the request queue to obtain parsed data, the parsed data including an interface definition and a data structure; reorganizing the parsed data according to the grammatical rules of the call request to obtain an abstract syntax tree, wherein each node in the abstract syntax tree represents an element of the protocol; based on the abstract syntax tree, using regular expressions to match abstract syntax tree nodes, and checking the semantic consistency of the protocol conversion through semantic analysis to obtain the request processing result, which is the reorganized request information.

[0012] In an optional embodiment, the call requests are prioritized according to a pre-assigned weight factor to obtain a priority-sorted request queue, specifically including: allocating a weight factor according to the priority requirements of the microservice interface to obtain a weight factor for each microservice interface; obtaining a request in a weighted priority queue based on the call request and the weight factor; dynamically adjusting the priority of the requests in the weighted priority queue based on the Dijkstra algorithm, and re-sorting the queue to obtain the priority-sorted request queue.

[0013] In an optional implementation, the microservice secure communication method further includes: returning a confirmation message to the requesting microservice based on the call request; and allocating a child thread to process the call request.

[0014] In an optional embodiment, the microservice secure communication method further includes: obtaining real-time network status data; obtaining the target microservice information, wherein the target microservice information includes location information and network topology structure of the target microservice; using a dynamic routing algorithm to obtain an optimal transmission path based on the real-time network status data and the target microservice information; and switching to an alternative path when a failure or congestion of the optimal transmission path is detected.

[0015] The present invention also provides a microservice security communication system, comprising: an alliance chain, which is provided with a microservice management node and generates security information based on each microservice, and the security information includes identity information and permission information; a request microservice, which is suitable for initiating a call request and generating encrypted data based on the call request; a request transfer station, which is communicated with the request microservice and the alliance chain respectively, and the request transfer station generates an operation credential based on the call request and stores it in the alliance chain; a data conversion module, which is suitable for transmitting data between microservices in different service domains and obtaining the encrypted data; a target transfer station, which is communicated with the data conversion module, and the target transfer station obtains the encrypted data and calls the operation credential and the security information for security verification. When the verification is passed, response data is generated and sent to the request microservice.

[0016] In an optional implementation, the request transfer station is provided with a target microservice interface.

[0017] In an optional embodiment, the request transfer station includes: a request processing module, which is communicated with the request microservice architecture, and the data processing module is suitable for obtaining and processing the call request to obtain the request processing result; a protocol conversion module, which is communicated with the data processing module, and the protocol conversion module is suitable for generating a target protocol code according to the target protocol specification and the request processing result; a data processing module, which is communicated with the database to store the encrypted data in the database.

[0018] In an optional implementation, the data conversion module is a network gate device, an API gateway or a VPN.

[0019] The present invention also provides an electronic device, comprising: at least one processor; a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any one of the microservice secure communication methods described.

[0020] The present invention also provides a computer storage medium storing a computer program, wherein when the computer program is executed by a processor, the computer program implements any one of the microservice secure communication methods described above.

[0021] The beneficial effects of the present invention are: in cross-domain calls in a distributed system, a comprehensive security mechanism of identity authentication, permission control, data encryption and integrity protection is implemented, thereby effectively reducing security risks and ensuring the security and reliability of communication between microservices in different domains. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 A flowchart of a microservice secure communication method provided for the implementation of the present invention;

[0023] Figure 2 A block diagram of a microservice secure communication system provided in an embodiment of the present invention;

[0024] Figure 3 A block diagram of a request transfer station for a microservice secure communication system provided in an embodiment of the present invention.

[0025] Description of reference numerals:

[0026] 110. Alliance chain; 120. Data conversion device; 130. Request network; 131. Request microservice; 132. Request transfer station; 1321. Request processing module; 1322. Protocol conversion module; 1323. Data processing module; 133. Request database; 140. Target network; 141. Target microservice; 142. Target transfer station; 143. Target database. DETAILED DESCRIPTION

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

[0028] like Figure 1 and Figure 2 As shown, according to an embodiment of the present invention, on the one hand, a microservice secure communication method is provided, comprising the following steps:

[0029] Step S101: Generate security information based on microservices, including identity information and permission information;

[0030] Step S103: Request microservice 131 to initiate a call request;

[0031] Step S105: Generate encrypted data based on the call request;

[0032] Step S107: Generate an operation credential based on the call request, the operation credential including user identity information and operation content;

[0033] Step S109: The target microservice 141 obtains the encrypted data and calls the operation credentials and security information for security verification. When the verification passes, response data is generated and sent to the requesting microservice 131.

[0034] In this embodiment, when microservices in different domains communicate with each other, for ease of description, the domain initiating the request is named the requesting domain or requesting network 130, the requesting network 130 has a requesting microservice 131, and the requested domain is named the target domain or target network 140, the target network 140 has a target microservice 141.

[0035] In a distributed microservice architecture, each microservice can generate its own security information. This microservice's identity uniquely identifies it. A key management system can be used to generate a unique encryption key for this identity, such as a public-private key pair, for enhanced security. This identity information is accompanied by corresponding permissions. These permissions define the microservice's operational permissions for cross-domain calls, such as which other microservices it can call and which data resources it can access. This information can be stored for easy access later.

[0036] When the requesting microservice 131 needs to call the target microservice 141 across domains, a call request will be initiated. Before the call request is sent, in order to further protect the security of the transmitted data, the requesting microservice 131 will encrypt the business parameters and generate encrypted data, and attach the encrypted data to the call request.

[0037] To further enhance the security and traceability of the call, the requesting network 130 generates an operation certificate based on the call request to record the detailed information of the call. The process of generating the operation certificate is as follows:

[0038] Extract user identity information from the call request, including user ID, role, organization, etc.

[0039] Record the specific operation content of this call, including the target microservice 141 called, the called interface name, business parameter summary, etc.

[0040] The user identity information and operation content are combined into an operation credential, which is then stored for subsequent calls.

[0041] To prevent the operation credential from being tampered with, the operation credential can be digitally signed using the private key of the requesting microservice 131 , and the target microservice 141 can verify the validity of the signature using the public key.

[0042] Through the above steps, cross-domain calls in distributed systems can implement security mechanisms such as authentication, permission control, data encryption, and integrity protection, thereby effectively reducing security risks and ensuring the security and reliability of communication between microservices in different domains.

[0043] In step S101, security information is generated based on the microservice, specifically including the following steps:

[0044] Step S1011: Build each microservice management node in the alliance chain 110.

[0045] Step S1013: Generate security information based on the microservice management node.

[0046] Consortium Chain 110 is a semi-decentralized consortium chain architecture, jointly maintained by multiple trusted organizations or entities. Participating nodes in Consortium Chain 110 are limited and authorized, including the management node of each microservice domain. When a management node registers a microservice with Consortium Chain 110, it generates a public-private key pair for its identity and corresponding permissions. In a distributed system, Consortium Chain 110 is used to store and manage microservice identity and permissions information. The immutability of Consortium Chain 110 ensures the security and credibility of this information.

[0047] Furthermore, in step S105, the call request includes request body data, and generating encrypted data based on the call request specifically includes the following steps:

[0048] Step S1051: Encrypt the request body data to obtain encrypted request body data;

[0049] Step S1053: Perform hash calculation on the encrypted data of the request body to obtain the hash value of the encryption key;

[0050] Step S1055: Sign the request body data to obtain signature data;

[0051] The encrypted data includes the request body encrypted data, the hash value of the encryption key, and the signature data.

[0052] In this embodiment, cross-domain calls can be implemented through the HTTP protocol. The HTTP request consists of three parts: a request line, a request header, and a request body. The process of generating encrypted data based on the call request is to ensure the confidentiality, integrity, and non-repudiation of the request body data during cross-domain transmission. Among them, the encrypted request body data can ensure the confidentiality of the data and prevent the request body data from being leaked during transmission. The hash value obtained by hashing the request body encrypted data ensures that the request body data has not been tampered with during transmission and is used to verify the integrity of the data. The signature data obtained by signing the request body data is used to verify that the caller is initiated by a legitimate caller to prevent repudiation.

[0053] Furthermore, based on step S1051, the request body data is encrypted to obtain request body encrypted data, which specifically includes the following steps:

[0054] Step S10511: Encrypt the request body data using a symmetric encryption algorithm to obtain a symmetric encryption key.

[0055] Step S10513: Use an asymmetric encryption algorithm to encrypt the symmetric encryption key to obtain the encrypted data of the request body.

[0056] In this embodiment, a hybrid encryption algorithm is combined. Symmetric encryption processes data quickly, while asymmetric encryption algorithms use public keys for encryption and private keys for decryption. Even if the public key is leaked, the private key remains secure. Asymmetric encryption protects the key. By combining the two, both the efficiency of symmetric encryption and the security of asymmetric encryption are utilized, achieving efficient and secure communication. This balance of efficiency and security ensures that the symmetric key is not leaked or tampered with during transmission, and even if the data is intercepted, the attacker cannot decrypt or tamper with the key, avoiding the high computational overhead of directly using asymmetric encryption to encrypt large amounts of data. The dual encryption mechanism ensures the security of data and keys, and combined with digital signatures, provides high confidentiality for the data.

[0057] Based on step S107, the target microservice 141 performs security verification based on the encrypted data call operation credentials and security information. When the verification passes, response data is generated and sent to the requesting microservice 131. Specifically, the steps include:

[0058] Step S1071: call security information, verify the data signature, determine whether the identity is forged, and whether it complies with the authority to call the interface. If the judgment result is no, the verification is passed.

[0059] Step S1073: Call the operation certificate and compare the received encrypted data signature with the signature in the operation certificate and the hash value of the encrypted data to see if they are consistent. If the comparison results are consistent, the verification is passed;

[0060] Step S1075: When all verifications are passed, response data is generated and sent to the requesting microservice 131.

[0061] In this embodiment, after receiving a call request, the target microservice 141 needs to perform security verification on the call request to ensure the legitimacy of the call and the integrity of the data. First, the encrypted data, operation credentials, and security information are extracted to verify the legitimacy of the identity information, including the service name, instance ID, etc. The target microservice 131 is then checked for permission to call the target microservice 141 interface based on its permission information. If the permission is insufficient, the request is directly rejected. The signature of the operation credentials is verified to ensure that the operation credentials have not been tampered with. At the same time, the user identity information and operation content in the operation credentials are checked to ensure that they meet expectations. The encrypted data is decrypted, the business parameters are restored, and the integrity of the decrypted data is verified. If the security verification passes, the target microservice 141 will execute specific business logic based on the decrypted business parameters. After the business logic is executed, the target microservice 141 generates response data, performs necessary security processing on the response data, and sends the processed response data back to the requesting microservice 131, completing the entire call process.

[0062] Furthermore, in order to achieve efficient and secure communication between different services, it is necessary to process the call request and generate corresponding code according to the target protocol specification to ensure compatibility and interoperability between services. The microservice secure communication method also includes the following steps:

[0063] Step S201: Process the call request and obtain the request processing result.

[0064] Step S203: Generate target protocol code according to the target protocol specification and the request processing result. The target protocol code includes service definition and protocol adaptation layer code.

[0065] First, the call request is received and parsed, key information is extracted, and the request processing result is obtained. Based on the request processing result, in order to ensure the compatibility and interoperability between services, the corresponding code needs to be generated according to the target protocol specification. This ensures the compatibility and interoperability between services and improves the flexibility and scalability of the system.

[0066] Specifically, step S201 processes the call request and obtains the request processing result, which specifically includes the following steps:

[0067] Step S2011: Prioritize the call requests according to the pre-assigned weight factors to obtain a priority-sorted request queue.

[0068] Step S2013: performing source protocol parsing on the request queue to obtain parsed data, which includes interface definition and data structure.

[0069] Step S2015: reorganize the parsed data according to the grammatical rules of the call request to obtain an abstract syntax tree, where each node in the abstract syntax tree represents an element of the protocol.

[0070] Step S2017: Based on the abstract syntax tree, regular expressions are used to match abstract syntax tree nodes, and semantic consistency of protocol conversion is checked through semantic analysis to obtain a request processing result, which is the reorganized request information.

[0071] Understandably, in a distributed system, call requests may have different urgency or importance. In order to optimize resource allocation and improve the response efficiency of the system, the call requests are prioritized.

[0072] Each call request is assigned a weight factor based on factors such as its source, type, and business importance. The weight factor can be a numerical value, with a higher value indicating a higher priority. For example, requests from core business systems may be assigned a higher weight, while requests from test environments may be assigned a lower weight. Requests involving user security or critical transactions are assigned a higher weight factor to ensure that these requests are handled first, and so on.

[0073] All received call requests are placed into a queue and sorted according to pre-assigned weight factors. In some cases, the weight factors can be dynamically adjusted based on real-time system load or business needs to optimize resource allocation. After prioritization, a queue of requests is created, with high-priority requests at the front of the queue being processed first.

[0074] Call requests may use different protocols, such as HTTP. To process these call requests, protocol parsing is performed on each call request in the request queue to extract key information. First, the source protocol is identified to determine the protocol type used by each request. The protocol is then parsed to parse the request's interface definition, including the service name, method name, and request path. For HTTP, the interface definition can be extracted from the URI and method in the request line. The data structure in the request body is parsed, including request parameters and message format. To further process the parsed data, it is reorganized according to the grammatical rules of the call request and an Abstract Syntax Tree (AST) is constructed. An AST is a tree structure that represents the grammatical structure of a protocol, where each node represents an element of the protocol, such as the request line, request header fields, or message fields. Syntax rules are defined according to the target protocol specification. For example, in HTTP, these rules include the format of the request line and the key-value pair format of the request header. The type and structure of AST nodes are defined. For example, node types can include "request line," "request header fields," and "message fields." Regular expressions are used to match AST nodes to locate specific patterns. Regular expressions can be defined according to the target protocol's syntax rules to match field names, field types, request paths, and more. Semantic analysis is performed on matched AST nodes to check the semantic consistency of protocol conversion. This analysis ensures the existence of fields, the correctness of field types, and the correct mapping between fields. Based on the target protocol specifications and information in the AST, target protocol code is generated using a template-driven approach. This target protocol code includes service definitions and protocol adaptation layer code, which implements request and response conversion between different protocols.

[0075] In this embodiment, through a series of steps such as parsing the source protocol, generating AST, regular expression matching, semantic analysis, and target protocol code generation, the request and response conversion between different protocols can be efficiently realized, which not only improves the flexibility and scalability of the system, but also ensures the accuracy and consistency of protocol conversion, providing strong support for service communication in distributed systems.

[0076] Specifically, based on step S2011, the call requests are prioritized according to the pre-assigned weight factors to obtain a priority-sorted request queue, which specifically includes the following steps:

[0077] Step S20111: Allocate weight factors according to the priority requirements of the microservice interfaces to obtain the weight factor of each microservice interface;

[0078] Step S20113: Obtaining requests in a weighted priority queue based on the call request and the weight factor;

[0079] Step S20115: Dynamically adjust the priority of requests in the weighted priority queue based on the Dijkstra algorithm, re-sort the queue, and obtain a request queue sorted by priority.

[0080] Different microservice interfaces may have different priority requirements. To rationally allocate resources and optimize system performance, each microservice interface needs to be assigned a weighting factor based on its priority requirements. First, the priority requirements need to be determined. Then, a weighting factor is assigned to each microservice interface. The weighting factor can be a numerical value, with larger values ​​indicating higher priority. A weighting factor table is generated, recording each microservice interface and its corresponding weighting factor. After assigning the weighting factors, call requests are placed into a weighted priority queue based on the weighting factors. Based on the target microservice 141 interface, the corresponding weighting factor is searched in the weighting factor table. The weighting factor is then associated with the call request to form a weighted request. A weighted priority queue is initialized, with each element in the queue containing the call request and its corresponding weighting factor. The weighted request is inserted into the priority queue, which sorts the requests based on the weighting factor. The higher the weighting factor, the higher the priority of the request in the queue. Finally, a weighted priority queue is created, containing the call request and the weighting factor. Within the weighted priority queue, the priority of requests may need to be adjusted based on dynamic conditions during system runtime. The Dijkstra algorithm is a shortest path algorithm that calculates the shortest path from the request source to the target interface. The path length can represent the priority of the request. The shorter the path, the higher the priority. The priority of the request is dynamically adjusted based on the result of the Dijkstra algorithm.

[0081] Through the above steps, we can assign weight factors according to the priority requirements of the microservice interface, put the call requests into the weighted priority queue, and dynamically adjust the priority of the request based on the Dijkstra algorithm, ensuring that the requests can be efficiently processed in order of priority, optimizing the allocation and utilization of system resources, and improving the overall performance and responsiveness of the system.

[0082] Furthermore, the microservice secure communication method further includes the following steps:

[0083] Step S301: Based on the call request, a confirmation message is returned to the requesting microservice 131.

[0084] Step S303: Allocate a child thread to process the call request.

[0085] The call request from the requesting microservice 131 is received and parsed, including the request header, request body, and request method. The request is then validated and, upon successful validation, a confirmation message is generated. This confirmation message is encapsulated in an HTTP response or other protocol response and returned to the requesting microservice 131. Simultaneously, an available child thread is allocated to retrieve the call request from the task queue and begin executing the specific business logic. This allows the requesting microservice 131 to continue other operations without being blocked waiting for a return from the target microservice 141. This approach significantly improves the concurrent processing capabilities of the microservice and reduces the time wasted waiting for data transmission.

[0086] Furthermore, the microservice secure communication method further includes the following steps:

[0087] Step S401: Acquire real-time network status data.

[0088] Step S403: Acquire target microservice 141 information, where the target microservice 141 information includes location information and network topology of the target microservice 141 .

[0089] Step S405: Based on the real-time network status data and the target microservice 141 information, a dynamic routing algorithm is used to obtain the optimal transmission path.

[0090] Step S407: When it is detected that the optimal transmission path fails or is congested, switching to a backup path is performed.

[0091] In this embodiment, real-time network status data can be obtained by monitoring the network status in real time and collecting and processing the network status data.

[0092] The IP address and port number of the target microservice 141 are obtained to determine the communication target. The network hierarchy of the target microservice 141, including information such as its subnet and VLAN, is obtained to generate a network topology map of the target microservice 141. Finally, information about the target microservice 141, including its location information and network topology, is obtained for path selection. A dynamic routing algorithm can adjust path selection in real time based on changes in network status. A shortest path algorithm, such as the Dijkstra algorithm, is selected. Real-time network status data and information about the target microservice 141 are input into the dynamic routing algorithm. Performance metrics for each possible path, such as latency, bandwidth, and packet loss rate, are evaluated, and the optimal path is selected based on the evaluation results. The network status of the optimal transmission path is continuously monitored to detect link or device failures along the optimal path. While selecting the optimal path, an alternative path is pre-calculated. When a failure or congestion is detected on the optimal path, the system automatically switches to the alternative path. Once the switch from the optimal path to the alternative path is complete, communication continuity and reliability are ensured, ensuring that microservice communication is not impacted. This not only ensures business continuity, but also eliminates the need for microservices to understand the route switching process.

[0093] like Figure 2 As shown, the present invention also proposes a microservice security communication system, including: an alliance chain 110, which is provided with a microservice management node and generates security information based on each microservice, and the security information includes identity information and permission information; a request microservice 131, which is suitable for initiating a call request and generating encrypted data based on the call request; a request transfer station 132, which is communicated with the request microservice 131 and the alliance chain 110 respectively, and the request transfer station 132 generates an operation credential based on the call request and stores it in the alliance chain 110; a data conversion module 120, which is suitable for transmitting data between microservices in different service domains and obtaining encrypted data; a target transfer station 142, which is communicated with the data conversion module 120, and the target transfer station 142 obtains encrypted data and calls the operation credential and security information for security verification. When the verification is passed, response data is generated and sent to the request microservice 131.

[0094] In this embodiment, the microservice secure communication system mainly includes: an alliance chain 110, a request microservice 131, a request transfer station 132, a request database 133, a data conversion module 120, a target microservice 141, a target transfer station 142 and a target database 143.

[0095] Data conversion module 120 ensures secure exchange of data requests and responses between different domains. By deploying a gateway device between microservices, remote requests and data transmission between microservices are facilitated through portability. The gateway device physically isolates microservices, making the data transfer process between microservices similar to copying data between microservices using a USB drive. Data conversion module 120 can also be an API gateway or VPN.

[0096] Request relay station 132 and target relay station 142 can be replaced by a service grid, which serves as a foundational layer and provides communication for microservices. Consortium chain 110 is used for identity and permission management. Each API call generates an unalterable operation credential, including user identity information and operation details. This credential is recorded in consortium chain 110 to ensure data consistency and immutability. Furthermore, when the requesting microservice 131 initiates a call request, request relay station 132 also transmits its identity information in the form of a digital certificate to the network gatekeeper.

[0097] The communication transfer station works between microservices and network gateway devices, and is mainly responsible for connecting microservices, making it easy for microservices in different security domains to call each other without affecting the business layer.

[0098] In addition, the request transfer station 132 is provided with a target microservice 141 interface. Applications in different security domains can register their microservice interfaces in the transfer station module. This is based on the principle of the nacos registration center. When the request microservice 131 needs to call a target microservice 141 in a different security domain, it only needs to call the target microservice 141 interface provided by the transfer station in the security domain where it is located. The underlying specific implementation is completed by the transfer station, which can provide seamless docking and transparent support for microservices. Microservices only need to follow simple standard protocols, such as HTTP or HTTPS, and interact with the interface provided by the target microservice 141 recorded in the transfer station, without having to pay attention to the underlying security mechanism and data synchronization details. When the request microservice 131 calls the target microservice 141, the request microservice 131 only needs to call the interface of the target microservice 141 provided by the transfer station in the security domain where it is located, just like calling a local service, and transmit the data to the transfer station. The transfer station is responsible for the subsequent process to ensure that the business layer is not affected, thereby greatly reducing the difficulty and complexity of microservice development and promoting the rapid deployment and application of microservice architecture in cross-domain scenarios.

[0099] Furthermore, if Figure 3As shown, the request transfer station 132 includes: a request processing module 1321, which is connected to the request microservice 131 architecture for communication, and a data processing module 1323 is suitable for obtaining and processing call requests to obtain request processing results; a protocol conversion module 1322, which is connected to the data processing module 1323 for communication, and the protocol conversion module 1322 is suitable for generating target protocol codes according to target protocol specifications and request processing results; a data processing module 1323, which is connected to the database for communication to store encrypted data in the database.

[0100] In this embodiment, the structure of the request transfer station 132 is the same as that of the target transfer station 142, but the data processed is different. The structure of the request transfer station 132 is used for explanation.

[0101] Among them, the protocol conversion module 1322 is the core module, which can realize the intelligent protocol conversion function: it adopts AST-based dynamic protocol parsing technology, and realizes the conversion of protocols such as HTTP / gRPC / AMQP through regular expressions + semantic analysis. After the transit station receives the call request issued by the microservice through the request processing module 1321, it first parses the source protocol, extracts the interface definition, data structure and other information and generates AST. Then use regular expressions to match the AST nodes, and also perform semantic analysis on them to check the semantic consistency of the conversion. Finally, based on the information obtained from the AST, the code defined by the target protocol service is dynamically generated to complete the call between microservices. At the same time, in order to ensure the efficiency of transmission, the data will also be optimized when performing protocol conversion, retaining only some key information, such as routing, authentication and other fields, to reduce the overhead of data transmission.

[0102] Protocol conversion module 1322 also introduces a weighted priority queue based on the Dijkstra algorithm to address response delays between microservice interfaces. By prioritizing microservice calls using pre-assigned weights, it ensures that high-priority data can be retrieved, processed, and responded to in near real-time between microservices, effectively reducing data processing latency and meeting the stringent real-time requirements of businesses.

[0103] When the request microservice 131 initiates a call request, the request transfer station 132 will also transmit the identity information with the digital certificate to the network gate through the data processing module 1323.

[0104] To improve data transmission efficiency and real-time performance, request relay station 132 uses asynchronous transmission. When requesting microservice 131 sends data to target microservice 141, the relay station returns an ACK to requesting microservice 131 after receiving the data. It then allocates a child thread to complete data processing, such as protocol conversion and data storage. The gateway then synchronizes the data with service B in a different security domain. This eliminates the need for requesting microservice 131 to block and wait for service B to respond, allowing it to continue with other operations. This approach significantly improves the concurrent processing capabilities of microservices and reduces the time wasted waiting for data transmission.

[0105] Furthermore, the relay station integrates real-time network monitoring capabilities, continuously acquiring information about the gateway device's status, including network latency, bandwidth utilization, and load. Furthermore, based on the location of the target microservice 141 and the network topology, the relay station uses a dynamic routing algorithm to select the optimal transmission path. If congestion or a failure is detected on a particular path, the relay station can rapidly switch to an alternate path, ensuring that microservice communication is not impacted. This not only ensures service continuity, but also obviates the need for microservices to understand the routing switching process.

[0106] Furthermore, the request relay station 132 encrypts the authenticated call request data using a symmetric encryption algorithm to ensure confidentiality during transmission. The request relay station 132 also signs the encrypted data using its own private key to ensure data integrity and non-repudiation. The signed data, along with the hash value of the encryption key, is stored in the relay station's database, awaiting data transmission by the gatekeeper module.

[0107] On the other hand, the present invention also provides an electronic device comprising: at least one processor; a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so as to enable the at least one processor to execute any one of the microservice secure communication methods.

[0108] On the other hand, the present invention also proposes a computer storage medium storing a computer program, which implements any one of the microservice secure communication methods when executed by a processor.

[0109] In a specific application, the microservice secure communication method and system proposed in the present invention is used, and the process is as follows:

[0110] Assume that there are two microservice domains, namely network A and network B. Network A is the request network 130, and network B is the target network 140. First, a gateway device is deployed at the boundary of network A and network B, and configured according to the pre-set security policy, including rules for allowing cross-domain calls, data format checking rules, etc. At the same time, a consortium chain 110 is built, and the management nodes of network A and network B are added to the consortium chain 110 as nodes. When microservice A in network A is the request microservice 131, it needs to call microservice B in network B, that is, the download interface of the target microservice 141. Among them, a request database 133 and a request transfer station 132 are also provided in network A, and a target transfer station 142 and a target database 143 are also provided in network B.

[0111] First, microservice A initiates an HTTP request to the download interface in the transfer station, encrypts, signs, and hashes the data in the request body, and then sends the identity information and call request-related data to the transfer station.

[0112] Transfer station A will first prioritize the download requests according to the pre-assigned weight factors. Then, it will parse them and construct them into an abstract syntax tree based on the grammatical rules of HTTP requests, including the request line, request header, request body, etc., and reconstruct the request in combination with the calling rules of microservice B. The specific process is: first parse the source protocol, extract information such as interface definition and data structure, and generate an abstract syntax tree. Each node in the tree represents an element of the protocol. Then, use regular expressions to match AST nodes, use quasi-regular syntax to locate specific patterns, and check the semantic consistency of protocol conversion through semantic analysis, such as ensuring the existence and mapping relationship of fields. Then, based on the target protocol specification and AST information, the target protocol code is generated through template drive, including service definition and protocol adaptation layer code, to realize the conversion of requests and responses between different protocols. Finally, the remote call request operation record and identity information are recorded in the alliance chain 110, and the encrypted data is also stored in the synchronization database.

[0113] After detecting that data is stored in the synchronization database, the network gate device will verify the format and signature of the data again, and determine whether the request complies with the security policy. After the verification is passed, the data will be synchronized to network B.

[0114] After detecting newly added data in the database, the relay station on Network B retrieves the relevant records of the call from the consortium chain 110 network. By verifying the data signature, it determines whether the identity is forged and whether the user complies with the authority to call the interface. At the same time, it compares the received data signature with the signature recorded on the consortium chain 110, as well as the data hash value, to ensure that the data has not been tampered with.

[0115] Microservice B encrypts and signs the response data and sends it to the relay station. The relay station then operates on the data, such as storing it in a database or uploading it to the consortium chain 110. The gateway device then synchronizes the data to the database on network A.

[0116] The communication relay station of network A reconstructs the response in its data table and then responds to microservice A.

[0117] Therefore, the present invention has the following beneficial effects:

[0118] 1. Strengthened Security: A hybrid encryption algorithm and digital signature technology ensure high-level data confidentiality. Furthermore, the user's registered identity and permissions on the consortium blockchain are leveraged to conduct comprehensive and in-depth verification of the caller's permissions, providing a solid foundation for secure traceability of microservice calls. Furthermore, the close collaboration between the transfer station and the gateway, as well as the gateway's own security check mechanisms, further strengthen security, ensuring that only secure and legal data can flow between different security domains.

[0119] 2. Seamless Integration and Transparent Communication: This technology provides seamless integration and transparent support for microservices. Microservices only need to follow simple interface specifications and common transmission protocols to interact with the relay station, without having to worry about the complex underlying security and transmission details. Dynamic protocol parsing technology ensures data transmission between different transmission protocols.

[0120] 3. Protocol Conversion and Notification Management Transfer Station: The transfer station intelligently identifies and adapts to business changes, automatically adjusting data transmission strategies and security mechanisms for data of different types and real-time requirements, effectively improving the system's response speed and ensuring that data can be transmitted between microservices in a timely and accurate manner, meeting the diverse needs and efficiency of the business.

[0121] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a non-volatile computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct RAMbus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM). The various embodiments in this specification are described in a progressive manner, and similar parts between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the embodiments of the apparatus, device, and non-volatile computer storage medium, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referenced to the partial description of the method embodiments.

[0122] The above embodiments are provided for illustrative purposes only and are not intended to limit the scope of implementation. Those skilled in the art will readily appreciate that other variations or modifications based on the above descriptions are possible. It is not necessary and impossible to provide an exhaustive list of all implementations. Obvious variations or modifications arising therefrom remain within the scope of protection of the present invention.

Claims

1. A microservice secure communication method for realizing communication between a requesting microservice and a target microservice, characterized in that: The microservice secure communication method includes: Generate security information based on the microservice, the security information including identity information and permission information; The request microservice initiates a call request; generating encrypted data based on the call request; Generate an operation credential based on the call request, the operation credential including user identity information and operation content; The target microservice obtains the encrypted data and calls the operation certificate and the security information for security verification. When the verification is successful, response data is generated and sent to the requesting microservice.

2. The microservice secure communication method according to claim 1, characterized in that: Generating security information based on the microservice specifically includes: Build microservice management nodes in the alliance chain; The security information is generated based on the microservice management node.

3. The microservice secure communication method according to claim 1, wherein: The call request includes request body data, and generating encrypted data based on the call request specifically includes: Encrypting the request body data to obtain request body encrypted data; Performing hash calculation on the encrypted data of the request body to obtain a hash value of the encryption key; Signing the request body data to obtain signature data; The encrypted data includes the request body encrypted data, the hash value of the encryption key and the signature data.

4. The microservice secure communication method according to claim 3, characterized in that: Encrypting the request body data to obtain encrypted request body data specifically includes: Encrypt the request body data using a symmetric encryption algorithm to obtain a symmetric encryption key; The symmetric encryption key is encrypted using an asymmetric encryption algorithm to obtain encrypted data of the request body.

5. The microservice secure communication method according to any one of claims 1 to 4, characterized in that: The target microservice calls the operation credential and the security information based on the encrypted data for security verification. When the verification passes, response data is generated and sent to the requesting microservice, specifically including: Call the security information, verify the data signature, determine whether the identity is forged, and whether it meets the authority to call the interface. If the judgment result is no, the verification is passed; Call the operation certificate, compare the received encrypted data signature with the signature in the operation certificate, and the hash value of the encrypted data to see if they are consistent. If the comparison results are consistent, the verification is passed; When all verifications are passed, the response data is generated and sent to the requesting microservice.

6. The microservice secure communication method according to any one of claims 1 to 4, characterized in that: Also includes: Process the call request and obtain the request processing result; A target protocol code is generated according to the target protocol specification and the request processing result, wherein the target protocol code includes a service definition and a protocol adaptation layer code.

7. The microservice secure communication method according to claim 6, characterized in that: Process the call request and obtain the request processing result, including: Prioritizing the call requests according to pre-assigned weight factors to obtain a priority-sorted request queue; Performing source protocol parsing on the request queue to obtain parsed data, the parsed data including interface definition and data structure; Reorganize the parsed data according to the grammatical rules of the call request to obtain an abstract syntax tree, where each node in the abstract syntax tree represents an element of the protocol; Based on the abstract syntax tree, regular expressions are used to match abstract syntax tree nodes, and semantic consistency of protocol conversion is checked through semantic analysis to obtain the request processing result, which is the reorganized request information.

8. The microservice secure communication method according to claim 7, characterized in that: Prioritizing the call requests according to the pre-assigned weight factors to obtain a priority-sorted request queue, specifically including: Assign weight factors according to the priority requirements of microservice interfaces to obtain the weight factor of each microservice interface; Obtaining a request in a weighted priority queue based on the call request and the weight factor; The priorities of the requests in the weighted priority queue are dynamically adjusted based on the Dijkstra algorithm, and the queues are re-sorted to obtain the request queue sorted by priority.

9. The microservice secure communication method according to claim 6, characterized in that: Also includes: Based on the call request, a confirmation message is returned to the requesting microservice; A child thread is assigned to process the call request.

10. The microservice secure communication method according to claim 6, characterized in that: Also includes: Get real-time network status data; Acquire the target microservice information, wherein the target microservice information includes location information and network topology of the target microservice; According to the real-time network status data and the target microservice information, a dynamic routing algorithm is used to obtain an optimal transmission path; When it is detected that the optimal transmission path fails or is congested, switching to a backup path is performed.

11. A microservice secure communication system, characterized in that: include: The alliance chain has a microservice management node and generates security information based on each microservice, including identity information and permission information; A request microservice, adapted to initiate a call request and generate encrypted data based on the call request; A request transfer station, which is in communication with the request microservice and the alliance chain respectively, and the request transfer station generates an operation credential based on the call request and stores it in the alliance chain; A data conversion module, adapted to transmit data between microservices in different service domains and obtain the encrypted data; The target transfer station is in communication with the data conversion module. The target transfer station obtains the encrypted data and calls the operation credentials and the security information for security verification. When the verification is successful, response data is generated and sent to the requesting microservice.

12. The microservice secure communication system according to claim 11, characterized in that: The request transfer station is provided with a target microservice interface.

13. The microservice secure communication system according to claim 11, characterized in that: The request transfer station includes: A request processing module is connected to the request microservice architecture, and the data processing module is adapted to obtain and process the call request to obtain a request processing result; A protocol conversion module, communicatively connected to the data processing module, the protocol conversion module being adapted to generate a target protocol code according to a target protocol specification and the request processing result; The data processing module is connected to the database for storing the encrypted data in the database.

14. The microservice secure communication system according to any one of claims 11 to 13, characterized in that: The data conversion module is a network gate device, an API gateway or a VPN.

15. An electronic device, characterized in that: include: at least one processor; a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the microservice secure communication method according to any one of claims 1 to 10.

16. A computer storage medium, characterized in that A computer program is stored, and when the computer program is executed by a processor, a microservice secure communication method according to any one of claims 1 to 10 is implemented.

Images