Micro-service calling method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses an inter-micro-service calling method and device, electronic equipment and a storage medium, and relates to the technical field of safety calling under micro-service architecture.The method comprises the steps that a key configuration center is constructed, and when a service provider starts service, corresponding safety information is stored in the key configuration center, the method comprises the following steps: acquiring key information required by a current security algorithm through a service calling party according to an interface of a service provider and a key configuration center; the method comprises the following steps: a service calling party performs security processing on a request message according to key information, and sends the processed request message to a service provider; a service provider obtains corresponding secret key information from a secret key configuration center and then verifies a response message of a request message, and after verification is passed, the response message is subjected to service processing and safety processing and then sent to a service calling party. The problems that the security level cannot be dynamically adjusted, key management is complex and difficult to update, and compatibility and flexibility are insufficient in the prior art are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of secure invocation under a microservices architecture, and particularly to a method, device, electronic device, and storage medium for invoking between microservices. Background Art

[0002] With the widespread popularity of microservices architecture in enterprise-level applications, the security and flexibility of invocations between microservices have become key issues to be urgently solved. Traditional microservices invocation methods usually adopt fixed security policies or static key configurations, which are inadequate when faced with diverse business requirements.

[0003] On the one hand, businesses with high security requirements may face security risks due to the use of low-level security algorithms; on the other hand, businesses with low security requirements may waste system resources due to excessive encryption, affecting performance. In addition, the key management of traditional methods is complex, with keys stored dispersedly or lacking a unified configuration center, resulting in difficult key updates, and low key synchronization efficiency between service invokers and service providers, increasing the risk of system attacks.

[0004] More seriously, traditional microservices invocation methods have obvious deficiencies in terms of compatibility and flexibility. The service side lacks a dynamic verification mechanism for supporting the security algorithms of invoker requests, and it is easy to cause invocation failures or security vulnerabilities due to mismatched security algorithms.

[0005] Therefore, there is an urgent need for a microservices invocation method that can dynamically adjust the security level, simplify key management, and enhance compatibility and flexibility. Summary of the Invention

[0006] Embodiments of the present invention provide a method for invoking between microservices to solve the problems of the prior art relying on fixed security policies or static key configurations, being unable to dynamically adjust the security level according to business types, having complex key management and difficult updates, and lacking compatibility and flexibility. The technical solutions are as follows: According to one aspect of the present invention, a method for invoking between microservices, the method includes: constructing a key configuration center, and when the service provider starts the service, storing corresponding security information in the key configuration center; the security information includes a security algorithm and a corresponding key; obtaining, by the service invoker, the key information required for the current security algorithm according to the interface of the service provider and the key configuration center; performing security processing on the request message by the service invoker according to the key information, and sending the processed request message to the service provider; obtaining, by the service provider, the corresponding key information from the key configuration center, verifying the response message of the request message, and after passing the verification, performing business processing and security processing on the response message and sending it to the service invoker.

[0007] In one embodiment, storing corresponding security information in the key configuration center is achieved through the following steps: creating a key-value pair group in the key configuration center, using the name of the microservice as the key and the key information corresponding to the microservice as the value; setting a structured data object for the key information; the structured data object includes an algorithm name, a key type, and a key value; setting corresponding security algorithms according to the business requirements of each microservice to form key-value pairs, and storing the key-value pairs in the key configuration center.

[0008] In one embodiment, the service invoker obtains the key information required for the current security algorithm based on the interface of the service provider and the key configuration center through the following steps: the service invoker obtains the original request information and the service provider instance, and obtains the interface address of the service provider through the service provider instance; obtaining the corresponding business type according to the interface address, determining the corresponding security level and security algorithm according to the business type, and obtaining the corresponding key information from the key configuration center according to the name of the service provider and the security algorithm.

[0009] In one embodiment, the service invoker performs security processing on the request message according to the key information and sends the processed request message to the service provider through the following steps: selecting a security processing method according to the security algorithm, and performing security processing on the request message according to the security processing method and the key information; the security processing methods include encryption and signature addition.

[0010] In one embodiment, verifying the response message of the request message, and after verification, performing business processing and security processing on the response message and sending it to the service invoker is achieved through the following steps: receiving the response message returned by the service provider, decrypting and verifying the response message according to the key information; the decryption processing includes decryption or signature verification; after verification, performing corresponding business logic processing, and then performing security processing on the response message according to the security algorithm and key information at the time of invocation and returning it to the service invoker.

[0011] In one embodiment, after verifying the response message, performing business processing and security processing on the response message and sending it to the service invoker, the following steps are further included: the service invoker decrypts and verifies the message information returned by the service provider based on the key information, and if the verification is passed, the call is successful.

[0012] In one embodiment, the method further includes the following steps: recording a current first timestamp when the service invoker receives a request to invoke the service provider, and recording a current second timestamp after the security information is stored in the key configuration center; recording a current third timestamp after requesting the interface of the service provider, and recording a current fourth timestamp after processing the data of the service provider; calculating the security processing time, interface call time, security verification time, and total time according to the first timestamp, second timestamp, third timestamp, and fourth timestamp, and matching the current business type and storing it in the database. According to one aspect of the present invention, a device for inter-microservice invocation, the device includes: a security information storage module, configured to construct a key configuration center, and store corresponding security information in the key configuration center when the service provider starts the service; the security information includes a security algorithm and a corresponding key; a security information invocation module, configured to obtain the key information required by the current security algorithm according to the interface of the service provider and the key configuration center through the service invoker; a data security processing module, configured to perform security processing on the request message according to the key information through the service invoker, and send the processed request message to the service provider; a data security verification module, configured to verify the response message of the request message after obtaining the corresponding key information from the key configuration center through the service provider, and perform business processing and the security processing on the response message after verification and send it to the service invoker.

[0013] According to one aspect of the present invention, an electronic device includes at least one processor and at least one memory, wherein computer-readable instructions are stored on the memory; the computer-readable instructions are executed by one or more of the processors, so that the electronic device implements the inter-microservice invocation method as described above.

[0014] According to one aspect of the present invention, a storage medium stores computer-readable instructions thereon, and the computer-readable instructions are executed by one or more processors to implement the inter-microservice invocation method as described above.

[0015] The beneficial effects brought by the technical solution provided by the present invention are: In the above technical solution, when the service provider starts the service, the present invention stores security information in the key configuration center, including security algorithms and corresponding keys, and stores them in the form of key-value pairs grouped by keys. A structured data object is set up, and key-value pairs are formed according to business requirements. The service invoker obtains the key information required by the current security algorithm based on the service provider interface and the key configuration center. Subsequently, the service invoker performs security processing on the request message, such as encryption or signature addition, and sends it to the service provider. After receiving the request, the service provider obtains the key information from the key configuration center, verifies the response message, and performs business processing and security processing after passing the verification, and then returns it to the service invoker. After receiving the response message, the service invoker performs decryption processing and verification again. If the verification passes, the call is successful. In addition, the method also records multiple timestamps, including the timestamps when the service invoker receives the request, the key configuration center stores information, the request interface, and the data is processed. The time consumption of each link is calculated through these first timestamp, second timestamp, third timestamp, and fourth timestamp, and the business type is matched and stored in the database. Through the above steps, the present invention realizes secure and efficient calls between microservices, enhances the security and reliability of the system, improves the security of communication between microservices, and thus can effectively solve the problems of the prior art relying on fixed security policies or static key configurations, being unable to dynamically adjust the security level according to the business type, having complex key management and difficult updates, and insufficient compatibility and flexibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments of the present invention. Obviously, the following drawings are only some embodiments of the present invention. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0017] Figure 1 is a flowchart of a method for calling between microservices shown according to an exemplary embodiment; Figure 2 is a schematic flowchart of a method for calling between microservices in an exemplary embodiment; Figure 3 is Figure 2 a schematic diagram of the interaction relationship of the key configuration center in the corresponding embodiment; Figure 4 is a block diagram of a device for calling between microservices shown according to an exemplary embodiment; Figure 5 is a hardware structure diagram of an electronic device shown according to an exemplary embodiment; Figure 6 is a block diagram of an electronic device shown according to an exemplary embodiment. Detailed Implementation Manner

[0018] The embodiments of the present invention will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be construed as a limitation of the present invention.

[0019] Those skilled in the art of the present technology can understand that, unless specifically stated otherwise, the singular forms "a", "an", "the", and "said" used herein may also include the plural forms. It should be further understood that the term "including" used in the specification of the present disclosure means the presence of the described features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or their groups. It should be understood that when we say an element is "connected" or "coupled" to another element, it can be directly connected or coupled to other elements, or there may also be intermediate elements. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The term "and / or" used herein includes all or any unit and all combinations of one or more related listed items.

[0020] The present invention provides a method for inter-microservice invocation. By uniformly managing security parameters such as keys and certificates through a key configuration center, the risk of key leakage is reduced, the overall security of the system is improved, and the problems in the prior art that rely on fixed security policies or static key configurations, with complex key management, difficult updates, and insufficient compatibility and flexibility are solved. The method for inter-microservice invocation is applicable to an inter-microservice invocation device, and the inter-microservice invocation device may be an electronic device. The method for inter-microservice invocation in the embodiments of the present invention can be applied to various scenarios, such as the invocation of application programs, etc.

[0021] Please refer to Figure 1 , the embodiments of the present invention provide a method for inter-microservice invocation, and this method is applicable to an electronic device.

[0022] In the following method embodiments, for the convenience of description, the execution subject of each step of the method is taken as an electronic device as an example for illustration, but this does not constitute a specific limitation thereto.

[0023] As Figure 1 shown, this method may include the following steps: Step 110, construct a key configuration center, and when the service provider starts the service, store the corresponding security information in the key configuration center.

[0024] In a possible implementation, a key-value pair group is created in the key configuration center. The name of the microservice is used as the key, and the corresponding key information of the microservice is used as the value. A structured data object is set for the key information, and the corresponding security algorithm is set according to the business requirements of each microservice to form key-value pairs, which are stored in the key configuration center. Among them, the structured data object includes the algorithm name, key type, and key value.

[0025] Specifically, a key-value pair group is created inside the key configuration center. The name of the microservice is used as the key, and the corresponding key information of the microservice is used as the value. For example, if there is a microservice named "User Service", "User Service" is used as the key, and its corresponding key information is stored as the value in this group.

[0026] Furthermore, a structured data object is set for the key information, which contains key information such as the algorithm name, key type, and key value. For example, the algorithm name can be "AES", the key type is "symmetric key", and the key value is a specific character sequence.

[0027] Furthermore, according to the business requirements of each microservice, the corresponding security algorithm is set to form key-value pairs, and these key-value pairs are stored in the key configuration center. Microservices with different business requirements use different security algorithms. For example, microservices for financial transactions require a higher-level encryption algorithm.

[0028] In the above process, the embodiments of the present invention store security information in the key configuration center in a structured manner, which is convenient for management and maintenance. By associating the microservice name with the key information, the security information of a specific microservice can be quickly located and obtained. The structured data object clarifies the key attributes of the key, improves the readability and operability of the information, provides a basis for subsequent service callers and service providers to obtain and use key information, and ensures the key management for secure communication between microservices.

[0029] Step 120, the service caller obtains the key information required by the current security algorithm according to the interface of the service provider and the key configuration center.

[0030] In a possible implementation, the service caller obtains the original request information and the service provider instance, obtains the interface address of the service provider through the service provider instance, determines the corresponding business type according to the interface address, determines the corresponding security level and security algorithm according to the business type, and obtains the corresponding key information from the key configuration center according to the name of the service provider and the security algorithm.

[0031] Specifically, the service invoker first obtains the original request information and the service provider instance, and then obtains the interface address of the service provider through this service provider instance. For example, in a distributed system, the service invoker discovers the service provider instance through the service registry and then obtains its interface address.

[0032] Furthermore, obtain the corresponding business type according to the interface address, and determine the corresponding security level and security algorithm based on the business type. For example, services involving user privacy information require high-security algorithms, and obtain the corresponding key information from the key configuration center according to the name of the service provider and the determined security algorithm.

[0033] In the above process, the embodiments of the present invention enable the service invoker to dynamically obtain key information according to business requirements, and dynamically determine the security algorithm and key information, which can adapt to the security requirements of different services.

[0034] Step 130, the service invoker performs security processing on the request message according to the key information and sends the processed request message to the service provider.

[0035] In a possible implementation, select the security processing method according to the security algorithm, and perform security processing on the request message according to the security processing method and the key information.

[0036] Among them, the security processing methods include encryption and signature addition.

[0037] Specifically, select a suitable security processing method according to the determined security algorithm, such as encryption or signature addition, and perform security processing on the request message using this security processing method and the obtained key information. For example, use the AES encryption algorithm to encrypt the sensitive data in the request message.

[0038] In the above process, the embodiments of the present invention dynamically determine the security algorithm and key information, which can adapt to the security requirements of different services. Security processing methods such as encryption and signature addition ensure the security and integrity of the request message during transmission, ensure that the request message sent by the service invoker to the service provider is secure, and prevent sensitive information leakage and message tampering.

[0039] Step 140, after the service provider obtains the corresponding key information from the key configuration center, verify the response message of the request message, and after verification, perform business processing and security processing on the response message and send it to the service invoker.

[0040] In a possible implementation, receive the response message returned by the service provider, decrypt and verify the response message according to the key information, execute the corresponding business logic processing after verification, and then perform security processing on the response message according to the security algorithm and key information during the call and return it to the service invoker.

[0041] Among them, the decryption process includes decryption or signature verification.

[0042] Specifically, the service provider receives the returned response message, decrypts and verifies the response message according to the key information. For example, if the request message is encrypted, the response message also needs to be decrypted accordingly; if signature is added, signature verification operation needs to be performed.

[0043] In a possible implementation, after passing the verification, the response message is subjected to service processing and security processing and then sent to the service invoker. After that, the service invoker decrypts and verifies the message information returned by the service provider based on the key information. If the verification passes, the call is successful.

[0044] Furthermore, after passing the verification, the service provider executes the corresponding business logic processing to complete the business function. Then, according to the security algorithm and key information at the time of invocation, the response message is subjected to security processing, such as encryption or signature addition. Finally, the processed response message is returned to the service invoker.

[0045] In the above process, the embodiment of the present invention performs two-way security processing on the response message through the service provider, ensuring the security and integrity of the response message. Verifying first and then performing service processing ensures that only legitimate response messages can enter the service processing flow, avoiding the impact of illegal messages on the system. Returning the response message after security processing guarantees the security of data during transmission, making the response message received by the service invoker secure and reliable, providing guarantee for the secure communication between microservices.

[0046] In a possible implementation, when the service invoker receives a request to call the service provider, it records the current first timestamp. After storing the security information in the key configuration center, it records the current second timestamp; after requesting the interface of the service provider, it records the current third timestamp, and after processing the data of the service provider, it records the current fourth timestamp; calculates the security processing time, interface call time, security verification time and total time according to the first timestamp, second timestamp, third timestamp and fourth timestamp, and matches the current business type and stores it in the database.

[0047] Specifically, calculates the security processing time (the difference between the second timestamp and the first timestamp), interface call time (the difference between the third timestamp and the second timestamp), security verification time (the part related to security verification in the difference between the data processing completion time and the third timestamp), and total time (the difference between the fourth timestamp and the first timestamp) according to the recorded first timestamp, second timestamp, third timestamp and fourth timestamp, and matches these time-consuming information with the current business type and stores it in the database.

[0048] In the above process, embodiments of the present invention record key timestamps to analyze the time consumption of each link in the microservice call, enabling accurate understanding of the time consumption of each stage in the microservice call process, providing data support for performance optimization, storing the time consumption information according to the business type, facilitating targeted analysis and optimization for different businesses, helping to discover system performance bottlenecks, optimizing the efficiency of microservice calls, and improving the performance and stability of the entire system.

[0049] Through the above process, the present invention provides a key management foundation for secure communication between microservices by constructing a key configuration center and reasonably storing security information. The service caller obtains the key information according to the business requirements and performs security processing on the request message, ensuring the secure transmission of the request message. The service provider verifies and processes the response message and then returns it, guaranteeing the security and integrity of the response message. Finally, by recording the call process timestamps and analyzing the time consumption, strong support is provided for system performance optimization. The entire solution forms a complete secure call system between microservices from key management, message security processing to performance analysis, effectively improving the security and performance of the microservice architecture.

[0050] In an exemplary embodiment, a highly secure microservice call service provided by a microservice call system is shown. The system includes a registration center, a service provider, a service caller, and a key configuration center.

[0051] As Figure 2 shown, it may specifically include the following steps: Step A: Security information injection by the service provider.

[0052] Specifically, when the service provider starts the service, it will first inject the security information supported by this service into the metadata of the registration center.

[0053] Among them, the security information includes but is not limited to supported business types (such as user authentication, data query, etc.), the corresponding security types for each business type (such as encrypted transmission, digital signature, etc.), and the specific security algorithms used for the current security type (such as AES encryption algorithm, RSA signature algorithm, etc.), which are not limited here.

[0054] In the above process, the service provider clarifies the security standards for the services it provides externally, providing a basis for the subsequent secure calls by the service caller.

[0055] Step B: The service caller obtains security information.

[0056] Specifically, when the service invoker needs to call the interface of the service provider, it will first obtain the security information of the service provider from the metadata in the registry. This step includes parsing the metadata and extracting the business type corresponding to the request interface, the security type corresponding to the business type, and the security algorithm information.

[0057] In the above process, based on the obtained security information, the service invoker can understand the security requirements of the service provider and prepare for subsequent security processing.

[0058] Step C: Obtain security parameters and perform security processing.

[0059] Specifically, the service invoker further obtains the required security parameters, such as keys, certificates, etc., from the key configuration center according to the security information obtained from the registry. These parameters are crucial for security processing.

[0060] Furthermore, the service invoker uses the obtained security parameters and the corresponding security algorithm to perform security processing on the request message, such as encryption or signature addition, to ensure the security and integrity of the request message during transmission.

[0061] Step D: The service provider verifies the request message.

[0062] Specifically, after receiving the request message from the service invoker, the service provider will first obtain the corresponding security parameters from the key configuration center. Then, it uses these parameters and the same security algorithm to perform verification processing on the request message, such as decryption or signature verification.

[0063] Furthermore, only when the verification passes will the service provider continue to execute the subsequent business logic processing; otherwise, it will reject the request.

[0064] Step E: Execute the business logic and securely process the response message.

[0065] Specifically, after the verification passes, the service provider will execute the corresponding business logic processing to complete the business function requested by the service invoker. Subsequently, the service provider will use the same security information as the request message to perform security processing on the response message, such as encryption or signature addition.

[0066] In the above process, this step ensures the security and integrity of the response message during transmission, echoing the security processing of the request message by the service invoker.

[0067] Step F: The service invoker verifies the response message and completes the call.

[0068] Specifically, after receiving the response message returned by the service provider, the service invoker will use the previously obtained security parameters and the corresponding security algorithm to perform verification processing on the response message.

[0069] Further, after the verification passes, the service invoker confirms the success of the current business call and can perform subsequent business processing as needed. This step marks the end of the entire service call process.

[0070] As Figure 3 shown, the key configuration center can be subscribed to by the service provider. After the subscription is completed, when there are changes in the configuration, it will be pushed to the corresponding services in a timely manner. At the same time, it can also be used by the service invoker to obtain the configured key information according to the application name and encryption algorithm of the service provider.

[0071] Through the above process, the embodiments of the present invention have described in detail the interaction process between the service provider and the service invoker based on security information. Through six steps including service provider security information injection, service invoker obtaining security information, obtaining security parameters and performing security processing, service provider verifying the request message, executing the business logic and securely processing the response message, and service invoker verifying the response message and completing the call, secure and reliable communication between microservices is achieved. This process not only ensures the security and integrity of data during transmission, but also improves the overall stability and reliability of the microservice architecture.

[0072] In an application scenario, after a user places an order in an e-commerce system, a payment operation needs to be performed. The payment operation involves the transmission of sensitive information (such as bank card numbers, payment passwords, etc.), so it is necessary to ensure the security of the payment interface. This embodiment will detail the secure call process of the payment interface (such as " / un / pay") between the service invoker and the service provider.

[0073] The first step is to prepare the key configuration center.

[0074] Specifically, under the "secret_key" group in the key configuration center, configure the following security information for the payment service (app-pay): service name, signature configuration, signature field name, signature position, signature algorithm, signature key, encryption configuration, encryption algorithm, and encryption key.

[0075] The second step is to configure the service provider (app-pay).

[0076] Specifically, when the service provider starts, scan the classes containing the payment interface, identify that the " / un / pay" interface belongs to the "payment" business type, read the configuration file, and determine that the security type of the "payment" business type is "signing only" and the security algorithm is "SHA1".

[0077] Further, register the relationship between the interface path " / un / pay" and the business type "Payment", the corresponding security type "Signing Only" of the business type, and the security algorithm "SHA1" information into the metadata of the registration center.

[0078] Step 3: The service invoker invokes the payment interface.

[0079] Specifically, after receiving the user payment request, the service invoker obtains the metadata information of the payment service (app-pay) from the registration center through the service discovery mechanism, and matches the business type as "Payment" according to the " / un / pay" interface path.

[0080] Further, obtain the SHA1 signature key corresponding to the payment service from the key configuration center, perform SHA1 signature processing on the payment request message, put the signature information into the request header, and send the signed request message to the payment service (app-pay).

[0081] Step 4: The payment service (app-pay) processes the request.

[0082] Specifically, after receiving the request, the payment service matches the business type as "Payment" according to the interface path, obtains the security information (SHA1 signature) of the "Payment" business type from the registration center metadata, performs SHA1 signature verification processing on the request message to verify the authenticity and integrity of the request. After the signature verification passes, execute the business logic processing (such as calling the payment gateway to complete the payment operation), generate a payment response message, and perform SHA1 signature processing, and return the signed response message to the service invoker.

[0083] Step 5: The service invoker processes the response.

[0084] Specifically, after receiving the response message, the service invoker performs SHA1 signature verification processing on the response message according to the security information during the call. After the signature verification passes, process the payment result and display it to the user.

[0085] Step 6: Elapsed time monitoring.

[0086] Specifically, the service invoker records the timestamps before the call, after generating the security information, after requesting the interface, and after processing the response, calculates the security processing elapsed time, interface call elapsed time, security verification elapsed time, and total elapsed time, and stores this information in the database.

[0087] Through the above process, the embodiments of the present invention achieve secure invocation of payment interfaces in an e-commerce system by constructing a complete secure interaction process between the key configuration center, service providers, and service invokers. Specifically, when payment operations involve the transmission of sensitive information, the embodiments of the present invention ensure the security of payment interfaces by performing signature addition and verification on request and response messages through the SHA1 signature algorithm, effectively preventing data tampering and forgery. At the same time, through the time-consuming monitoring mechanism, the time consumption of security processing, interface invocation, and security verification is recorded and analyzed, providing data support for performance optimization. This solution not only ensures the security and reliability of payment operations but also improves the overall performance and user experience of the system, thus solving the problems of the prior art relying on fixed security policies or static key configurations, being unable to dynamically adjust the security level according to business types, having complex key management and difficult updates, and insufficient compatibility and flexibility.

[0088] In another embodiment, users in the e-commerce system need to apply for a refund for various reasons. The refund operation also involves the transmission of sensitive information, but its security requirements may be different from those of payment operations. This embodiment will detail the secure invocation process of the refund interface (such as " / un / refund") between the service invoker and the service provider and show how to dynamically adjust the security level according to business requirements.

[0089] The first step is key configuration center preparation (initial security level).

[0090] Specifically, under the "secret_key" group in the key configuration center, configure the following security information for the refund service (app-refund): service name, signature encryption configuration, signature field name, signature position, signature encryption algorithm: RSA, RSA private key, and RSA public key.

[0091] The second step is service provider (app-refund) configuration (initial security level).

[0092] Specifically, when the service provider starts up, scan the classes containing the refund interface, identify that the " / un / refund" interface belongs to the "refund" business type, read the configuration file, and determine that the security type of the "refund" business type is "signature encryption" and the security algorithm is "RSA".

[0093] Furthermore, register the relationship between the interface path " / un / refund" and the business type "refund", the security type "signature encryption" corresponding to the business type, and the security algorithm "RSA" information in the metadata of the registry.

[0094] The third step is the service invoker to call the refund interface (initial security level).

[0095] Specifically, after receiving the user's refund request, the service invoker obtains the metadata information of the refund service (app-refund) from the registry through the service discovery mechanism, and matches the business type as "refund" according to the interface path " / un / refund".

[0096] Furthermore, obtain the RSA public and private key pair corresponding to the refund service from the key configuration center, perform RSA signature encryption processing on the refund request message, put the signature encryption information into the request header, and send the signed and encrypted request message to the refund service (app-refund).

[0097] The fourth step is for the refund service (app-refund) to process the request (initial security level).

[0098] Specifically, after receiving the request, the refund service matches the business type as "refund" according to the interface path, obtains the security information (RSA signature encryption) of the "refund" business type from the registry metadata, performs RSA signature verification and decryption processing on the request message, verifies the authenticity and integrity of the request, and decrypts the original request message.

[0099] Furthermore, after the signature verification and decryption pass, execute the business logic processing (such as reviewing the refund application and processing the refund), generate a refund response message, perform RSA signature encryption processing, and return the signed and encrypted response message to the service invoker.

[0100] It should be noted that if the business requirements change and the security level of the refund interface needs to be reduced to only signing (SHA1), then update the security information of the refund service (app-refund) in the key configuration center: remove the RSA signature encryption configuration and add the SHA1 signature configuration, and update the configuration file of the service provider (app-refund), modify the security type of the "refund" business type to "only signing", modify the security algorithm to "SHA1", and restart the service provider (app-refund) to make it load the new security configuration.

[0101] Among them, the SHA1 signature configuration includes the signature field name, signature position, signature algorithm, and signature key (the new SHA1 key).

[0102] The fifth step is for the service invoker to call the refund interface (adjusted security level).

[0103] Specifically, after detecting the update of the security configuration of the refund service (app-refund), the service invoker re-obtains the latest metadata information from the registry, and according to the interface path " / un / refund" and the new metadata information, matches the business type as "refund", the security type as "only signing", and the security algorithm as "SHA1".

[0104] Further, obtain the SHA1 signature key corresponding to the refund service from the key configuration center, perform SHA1 signature processing on the refund request message, put the signature information into the request header, and send the signed request message to the refund service (app-refund).

[0105] Step 6: The refund service (app-refund) processes the request (adjusted security level).

[0106] Specifically, after receiving the request, the refund service matches the business type as "refund", the security type as "only signed", and the security algorithm as "SHA1" according to the new metadata information. Perform SHA1 signature verification processing on the request message to verify the authenticity and integrity of the request.

[0107] Further, after the signature verification passes, execute the business logic processing (such as reviewing the refund application and processing the refund), generate a refund response message, perform SHA1 signature processing, and return the signed response message to the service invoker.

[0108] Step 7: Elapsed time monitoring.

[0109] Specifically, during the entire call process, the service invoker continuously records and monitors the elapsed time for security processing, interface call, security verification, and total elapsed time, so as to evaluate the performance under different security levels.

[0110] Through the above two embodiments, it can be clearly seen how to implement interface calls with dynamically adjustable security levels in a microservices architecture, and how to flexibly adjust security policies according to business requirements. At the same time, it avoids directly using JSON configuration data and instead uses text descriptions for configuration information.

[0111] Through the above process, in the embodiments of the present invention, the initial security level of the refund service is configured as RSA signature encryption first, ensuring a high level of security for the refund request during transmission. When the business requirements change and the security level needs to be reduced, by updating the configurations of the key configuration center and the service provider, the security level is flexibly adjusted to only signed (SHA1). The service invoker can detect the update of the security configuration in real time and adjust the security processing method of the request accordingly. During the whole process, the elapsed time monitoring mechanism continuously records and analyzes the elapsed time of each stage, providing strong support for performance optimization. This solution not only meets the security requirements for refund operations, but also improves the flexibility and response speed of the system by dynamically adjusting the security level, effectively solving the problems of the prior art relying on fixed security policies or static key configurations, being unable to dynamically adjust the security level according to business types, having complex key management and difficult updates, and insufficient compatibility and flexibility.

[0112] The following is an embodiment of the device of the present invention, which can be used to execute the method for inter-microservice call involved in the present invention. For details not disclosed in the embodiment of the device of the present invention, please refer to the method embodiment of the method for inter-microservice call involved in the present invention.

[0113] Please refer to Figure 4 , an inter-microservice call device 800 is provided in an embodiment of the present invention.

[0114] The inter-microservice call device 800 includes but is not limited to: a security information storage module 810, a security information call module 830, a data security processing module 850, and a data security verification module 870.

[0115] Among them, the security information storage module 810 is used to build a key configuration center, and when the service provider starts the service, corresponding security information is stored in the key configuration center; the security information includes a security algorithm and a corresponding key.

[0116] The security information call module 830 is used for the service caller to obtain the key information required by the current security algorithm according to the interface of the service provider and the key configuration center.

[0117] The data security processing module 850 is used for the service caller to perform security processing on the request message according to the key information, and send the processed request message to the service provider.

[0118] The data security verification module 870 is used for the service provider to obtain the corresponding key information from the key configuration center and then verify the response message of the request message. After the verification passes, the response message is subjected to service processing and security processing and then sent to the service caller.

[0119] It should be noted that when the above-mentioned embodiment provides an inter-microservice call, only the above-mentioned division of each functional module is used for illustration. In practical applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the inter-microservice call device will be divided into different functional modules to complete all or part of the functions described above.

[0120] In addition, the inter-microservice call device provided in the above-mentioned embodiment and the embodiment of the inter-microservice call method belong to the same concept. The specific ways in which each module performs operations have been described in detail in the method embodiment, and will not be repeated here.

[0121] Figure 5 A schematic diagram of the structure of an electronic device shown according to an exemplary embodiment.

[0122] It should be noted that this electronic device is only an example adapted to the present invention and should not be considered as imposing any limitation on the scope of use of the present invention. Nor should this electronic device be construed as requiring dependence on or necessarily having Figure 5 one or more components of the exemplary electronic device 2000 shown.

[0123] The hardware structure of the electronic device 2000 may vary greatly due to different configurations or performances. For example, Figure 5 as shown, the electronic device 2000 includes: a power supply 210, an interface 230, at least one memory 250, and at least one central processing unit (CPU) 270.

[0124] Specifically, the power supply 210 is used to provide working voltage for each hardware device on the electronic device 2000.

[0125] The interface 230 includes at least one wired or wireless network interface 231 for interacting with external devices. Of course, in other examples adapted to the present invention, the interface 230 may further include at least one serial-parallel conversion interface 233, at least one input / output interface 235, and at least one USB interface 237, etc. Figure 5 as shown, and no specific limitation is constituted hereby.

[0126] The memory 250, as a carrier for resource storage, can be a read-only memory, a random access memory, a magnetic disk, an optical disk, etc. The resources stored thereon include an operating system 251, application programs 253, and data 255, etc. The storage method can be temporary storage or permanent storage.

[0127] Among them, the operating system 251 is used to manage and control each hardware device and application program 253 on the electronic device 2000 to implement the operation and processing of a large amount of data 255 in the memory 250 by the central processing unit 270. It can be WindowsServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0128] The application program 253 is a computer-readable instruction that completes at least one specific task based on the operating system 251. It may include at least one module ( Figure 5 not shown), and each module can respectively contain computer-readable instructions for the electronic device 2000. For example, the microservice inter-call device can be regarded as an application program 253 deployed on the electronic device 2000.

[0129] The data 255 can be signal information, etc., and is stored in the memory 250.

[0130] The central processing unit 270 may include one or more processors and is configured to communicate with the memory 250 via at least one communication bus to read computer-readable instructions stored in the memory 250, and further implement the operation and processing of the massive data 255 in the memory 250. For example, the inter-microservice call method is completed by reading a series of computer-readable instructions stored in the memory 250 through the central processing unit 270.

[0131] In addition, the present invention can also be implemented by hardware circuits or a combination of hardware circuits and software. Therefore, the implementation of the present invention is not limited to any specific hardware circuit, software, or a combination of the two.

[0132] Please refer to Figure 6 , in an embodiment of the present invention, an electronic device 4000 is provided. The electronic device 4000 may include: a desktop computer, a laptop computer, a server, etc. with sensor recognition capabilities.

[0133] In Figure 6 , the electronic device 4000 includes at least one processor 4001 and at least one memory 4003.

[0134] Among them, the data interaction between the processor 4001 and the memory 4003 can be realized through at least one communication bus 4002. The communication bus 4002 may include a path for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity of representation, Figure 6 in the figure, only a thick line is used to represent it, but it does not mean that there is only one bus or one type of bus.

[0135] Optionally, the electronic device 4000 may further include a transceiver 4004, and the transceiver 4004 can be used for data interaction between the electronic device and other electronic devices, such as data sending and / or data receiving, etc. It should be noted that in practical applications, the transceiver 4004 is not limited to one, and the structure of the electronic device 4000 does not constitute a limitation to the embodiments of the present invention.

[0136] The processor 4001 can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logical blocks, modules, and circuits described in connection with the disclosure of the present invention. The processor 4001 can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0137] The memory 4003 can be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or it can also be an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, or any other medium that can be used to carry or store desired program instructions or code in the form of instruction or data structures and can be accessed by the electronic device 4000, but is not limited thereto.

[0138] Computer-readable instructions are stored on the memory 4003, and the processor 4001 can read the computer-readable instructions stored in the memory 4003 through the communication bus 4002.

[0139] The computer-readable instructions are executed by one or more processors 4001 to implement the microservice inter-call method in the above embodiments.

[0140] In addition, an embodiment of the present invention provides a storage medium on which computer-readable instructions are stored, and the computer-readable instructions are executed by one or more processors to implement the microservice inter-call method as described above.

[0141] In an embodiment of the present invention, a computer program product is provided. The computer program product includes computer-readable instructions stored in a storage medium. One or more processors of an electronic device read the computer-readable instructions from the storage medium, load and execute the computer-readable instructions, so that the electronic device implements the microservice inter-call method described above.

[0142] Compared with the related art, the beneficial effects of the present invention are as follows: 1. The present invention can achieve secure and flexible calls between microservices. By constructing a key configuration center to centrally store and manage security information, it supports the service provider and the service invoker to dynamically obtain and update security algorithms and keys according to business requirements, ensuring the security and integrity of data transmission, and at the same time providing the ability to flexibly adjust security policies.

[0143] 2. The present invention has efficient security processing and comprehensive performance monitoring. By selecting appropriate security processing methods (such as encryption and signature) for request and response messages, and recording and monitoring the time consumption of each stage such as security processing, interface call, and security verification, the present invention optimizes the system performance while ensuring security, providing data support for performance optimization.

[0144] 3. The present invention can provide end-to-end security protection. By the service invoker performing security processing on the request message, the service provider verifying and performing security processing on the response message, and the service invoker finally verifying the response message, the data security during the entire microservice call process is ensured, effectively preventing data leakage and tampering.

[0145] 4. The present invention has the characteristics of flexible security configuration and easy integration and deployment. By setting corresponding security algorithms and key information for each microservice and adopting standardized interfaces and processes, the present invention realizes flexible security configuration, meets the security requirements of different microservices, and at the same time reduces the difficulty and cost of integrating and deploying new services.

[0146] It should be understood that although the steps in the flowchart of the accompanying drawings are shown in sequence according to the indication of the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order limit, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same moment, but can be executed at different moments, and their execution order is not necessarily sequential, but can be executed alternately or alternately with at least a part of other steps or sub-steps or stages of other steps.

[0147] The above are only some embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. A method for invoking between microservices, characterized in that, The method includes: Construct a key configuration center. When the service provider starts the service, store the corresponding security information in the key configuration center; the security information includes a security algorithm and the corresponding key. The service invoker obtains the key information required by the current security algorithm according to the interface of the service provider and the key configuration center. The service invoker performs security processing on the request message according to the key information and sends the processed request message to the service provider. After the service provider obtains the corresponding key information from the key configuration center, it verifies the response message of the request message. After verification, it performs business processing and security processing on the response message and sends it to the service invoker.

2. The microservice call method according to claim 1, wherein The storing the corresponding security information in the key configuration center includes: Create a key-value pair group in the key configuration center. Use the name of the microservice as the key and the key information corresponding to the microservice as the value. Set a structured data object for the key information; the structured data object includes an algorithm name, a key type, and a key value. Set the corresponding security algorithm according to the business requirements of each microservice to form a key-value pair, and store the key-value pair in the key configuration center.

3. The microservice call method according to claim 1, wherein The service invoker obtains the key information required by the current security algorithm according to the interface of the service provider and the key configuration center, including: The service invoker obtains the original request information and the service provider instance, and obtains the interface address of the service provider through the service provider instance. Obtain the corresponding business type according to the interface address, determine the corresponding security level and security algorithm according to the business type, and obtain the corresponding key information from the key configuration center according to the name of the service provider and the security algorithm.

4. The microservice call method according to claim 3, wherein The service invoker performs security processing on the request message according to the key information and sends the processed request message to the service provider, including: Select a security processing method according to the security algorithm, and perform security processing on the request message according to the security processing method and the key information; the security processing methods include encryption and signature addition.

5. The microservice call method according to claim 1, wherein Verifying the response message of the request message, and after verification, performing business processing and security processing on the response message and sending it to the service invoker, including: Receive the response message returned by the service provider, and perform decryption processing and verification on the response message according to the key information; the decryption processing includes decryption or signature verification. After verification, execute the corresponding business logic processing, and then perform security processing on the response message according to the security algorithm and key information at the time of invocation and return it to the service invoker.

6. The microservice call method according to claim 1, characterized in that, After the response message is sent to the service invoker after performing business processing and security processing after verification, it further includes: The service invoker performs decryption processing and verification on the message information returned by the service provider based on the key information. If the verification is passed, the call is successful.

7. The microservice call method according to claim 1, characterized in that, The method further includes: Record the current first timestamp when the service invoker receives a request to call the service provider, and record the current second timestamp after storing the security information in the key configuration center; Record the current third timestamp after requesting the interface of the service provider, and record the current fourth timestamp after processing the data of the service provider; Calculate the security processing time, interface call time, security verification time, and total time according to the first timestamp, second timestamp, third timestamp, and fourth timestamp, and match the current business type and store it in the database.

8. An inter-microservice call device, characterized in that, The device includes: A security information storage module, configured to construct a key configuration center, and store corresponding security information in the key configuration center when the service provider starts the service; the security information includes a security algorithm and a corresponding key; A security information invocation module, configured to obtain the key information required by the current security algorithm by the service invoker according to the interface of the service provider and the key configuration center; A data security processing module, configured to perform security processing on the request message by the service invoker according to the key information, and send the processed request message to the service provider; A data security verification module, configured to verify the response message of the request message by the service provider after obtaining the corresponding key information from the key configuration center, and perform business processing and the security processing on the response message after passing the verification and send it to the service invoker.

9. An electronic device, characterized in that, Includes: At least one processor and at least one memory, wherein, The memory stores computer-readable instructions; The computer-readable instructions are executed by one or more of the processors, so that the electronic device implements the microservice inter-call method according to any one of claims 1 to 7.

10. A storage medium having computer-readable instructions stored thereon, characterized in that, The computer-readable instructions are executed by one or more processors to implement the microservice inter-call method according to any one of claims 1 to 7.

Images