Distributed microservice authentication and service invocation method, system and financial platform

Abstract

The present application provides a method, a system and a financial platform for inter-service authentication and service invocation among distributed microservices. The method includes: if a new configuration file for providing an inter-service authentication scheme is received from a distributed microservice architecture, caching the new configuration file locally, and also caching the original configuration file locally, where the configuration file contains inter-service call whitelist relationship data and symmetric keys; performing inter-service authentication between itself and other microservices based on the inter-service call whitelist relationship data and symmetric keys corresponding to the new or original configuration file locally, and determining whether to invoke the service information of itself or other microservices. The present application can achieve inter-service authentication among internal services in a microservice architecture, is applicable to financial platforms with high security requirements such as cloud chain platforms, and can improve the security and efficiency of interface invocation and data transmission, thereby improving the security, efficiency and reliability of service scheduling in financial platforms such as cloud chain platforms.

Description

Technical Field

[0001] This application relates to the technical field of data processing, and particularly to an authentication and business call method, system, and financial platform between distributed microservices. Background Art

[0002] For financial platforms such as cloud chain platforms that are built based on microservices and deployed in clusters for the supply chain, due to the adoption of the microservice architecture, they are developed using the open-source application framework Spring Boot microservice method on the Java platform. Taking the cloud chain platform as an example, currently, all the services exposed by the cloud chain platform have passed permission verification through the gateway, and all microservices of the cloud chain platform have integrated the Nacos configuration and registration center, and the time of its servers is obtained from a unified time center to ensure that the time is consistent. The service division of the cloud chain platform is mainly divided into business services, integration services, tool-based basic services, fund-based basic services, bank and third-party channel services. For the calls to the interfaces of the fund-based basic services and the claims in the business services, strict management is required to ensure the security of the fund transactions of such financial platforms.

[0003] Currently, there is no authentication for the interface calls between various services of financial platforms such as cloud chain platforms, and the services are also transmitted in the form of http (HyperText Transfer Protocol based on the network) plaintext. The lack of management for the interface calls between services poses a relatively high risk to the security of business data, and thus the fund security of such financial platforms cannot be guaranteed. Therefore, there is an urgent need to design an authentication and business call method between internal services in the microservice architecture. Summary of the Invention

[0004] In view of this, the embodiments of this application provide an authentication and business call method, system, and financial platform between distributed microservices to eliminate or improve one or more defects existing in the prior art.

[0005] One aspect of this application provides an authentication and business call method between distributed microservices, including:

[0006] If a new configuration file for providing an inter-service authentication scheme is received from the distributed microservice architecture, then cache the new configuration file locally, where the original configuration file is also cached locally, and the configuration file contains: inter-service call whitelist relationship data and corresponding symmetric keys;

[0007] Based on the inter-service call whitelist relationship data and symmetric keys corresponding to the new configuration file or the original configuration file locally, perform inter-service authentication between itself and other microservices, and determine whether to call the business information of itself or other microservices according to the corresponding authentication result.

[0008] In some embodiments of the present application, the service - to - service call whitelist relationship data includes: the correspondence relationship between the consumer service identifier, the producer service identifier, the producer service interface identifier, and the effective time range, where the consumer service identifier and the producer service identifier belong to different microservices respectively.

[0009] In some embodiments of the present application, receiving a new configuration file for providing an inter - service authentication scheme in the self - distributed microservice architecture includes:

[0010] In the distributed microservice architecture where it is located, receiving a new configuration file for providing an inter - service authentication scheme sent by a timing task scheduling module, where the timing task scheduling module pre - pulls a new configuration file for providing an inter - service authentication scheme from an inter - service authentication scheme configuration module.

[0011] In some embodiments of the present application, the timing task scheduling module is used to periodically check in the inter - service authentication scheme configuration module whether there is a new configuration file for providing an inter - service authentication scheme. If so, the timing task scheduling module, according to the consumer service identifier and the producer service identifier in the configuration file, obtains the IP addresses and port numbers of the corresponding microservices from the configuration center and the service registration center, and based on the IP addresses and port numbers of the respective microservices, sends the new configuration file for providing an inter - service authentication scheme to each of the microservices respectively.

[0012] In some embodiments of the present application, performing inter - service authentication between itself and other microservices based on the service - to - service call whitelist relationship data and the symmetric key corresponding to the local new configuration file or the original configuration file, and determining whether to call the business information of itself or other microservices according to the corresponding authentication result includes:

[0013] Obtain the producer service identifier corresponding to the target microservice to be accessed by itself;

[0014] Check in the locally cached new configuration file or the original configuration file whether there is service - to - service call whitelist relationship data including the correspondence relationship between its own consumer service identifier and the producer service identifier of the target microservice. If so, further determine whether the current time is included in the effective time range in the service - to - service call whitelist relationship data;

[0015] If the current time is included in the effective time range in the service - to - service call whitelist relationship data, determine that the authentication between itself and the target microservice is successful, and encrypt the service demand data based on the symmetric key corresponding to the service - to - service call whitelist relationship data and generate a corresponding service request;

[0016] Based on the producer service interface identifier of the target microservice in the inter-service call whitelist relationship data, send the service request to the target microservice, so that the target microservice decrypts the encrypted service demand data and performs inter-service authentication based on the new configuration file or the original configuration file cached locally, to determine whether to issue the service information corresponding to the service request data.

[0017] In some embodiments of the present application, performing inter-service authentication between itself and other microservices based on the inter-service call whitelist relationship data and the symmetric key corresponding to the new configuration file or the original configuration file locally, and determining whether to call the service information of itself or other microservices according to the corresponding authentication result, includes:

[0018] Receive the service request of the original microservice that intends to call its own service, and the consumer service identifier corresponding to the original microservice;

[0019] Check whether there is inter-service call whitelist relationship data recorded in the new configuration file or the original configuration file cached locally that contains the corresponding relationship between its own producer service identifier and the consumer service identifier of the original microservice. If so, further determine whether the current time is within the effective time range in the inter-service call whitelist relationship data;

[0020] If the current time is within the effective time range in the inter-service call whitelist relationship data, and it is verified that the encrypted service demand data is non-empty data, determine that the authentication between itself and the original microservice is successful, and decrypt the encrypted service demand data in the service request based on the symmetric key corresponding to the inter-service call whitelist relationship data to obtain the corresponding service demand data;

[0021] Based on the consumer service interface identifier of the original microservice in the inter-service call whitelist relationship data, encrypt the service information corresponding to the service demand data and send it to the original microservice.

[0022] Another aspect of the present application provides a distributed microservice system, including: multiple distributed microservices;

[0023] Each of the microservices is used to execute the distributed microservice inter-authentication and service call method.

[0024] Another aspect of the present application provides a financial platform, including: an inter-service authentication scheme configuration module, a timing task scheduling module, and a distributed microservice system;

[0025] Among them, the distributed microservice system includes: multiple distributed microservices, and each microservice is used to execute the inter-distributed microservice authentication and service call method;

[0026] The inter-service authentication scheme configuration module is used to configure a new configuration file, and the configuration file contains: inter-service call whitelist relationship data and corresponding symmetric keys;

[0027] The timing task scheduling module is used to pull a new configuration file for providing an inter-service authentication scheme from the inter-service authentication scheme configuration module, and distribute the configuration file to each corresponding microservice in the distributed microservice system.

[0028] In some embodiments of the present application, the inter-service authentication scheme configuration module in the financial platform includes:

[0029] A data acquisition unit, which is used to acquire the corresponding relationship between the consumer service identifier, the producer service identifier, the producer service interface identifier, and the effective time range;

[0030] A file configuration unit, which is used to use the corresponding relationship between the consumer service identifier, the producer service identifier, the producer service interface identifier, and the effective time range as the inter-service call whitelist relationship data, and generate a new configuration file according to the inter-service call whitelist relationship data and the corresponding symmetric key, where the consumer service identifier and the producer service identifier belong to different microservices respectively.

[0031] In some embodiments of the present application, the timing task scheduling module in the financial platform includes:

[0032] A timing pull unit, which is used to periodically check in the inter-service authentication scheme configuration module whether there is a new configuration file for providing an inter-service authentication scheme. If so, acquire the new configuration file for providing an inter-service authentication scheme;

[0033] A data distribution unit, which is used to obtain the IP addresses and port numbers of the corresponding microservices from the configuration center and the service registration center according to the consumer service identifier and the producer service identifier in the configuration file, and based on the IP addresses and port numbers of the respective microservices, send the new configuration file for providing the inter-service authentication scheme to each of the microservices.

[0034] The authentication and service invocation method between distributed microservices provided by this application, if a new configuration file for providing an inter-service authentication solution is received from the distributed microservice architecture, caches the new configuration file locally, where the original configuration file is also cached locally. The configuration file contains: the whitelist relationship data for inter-service invocations and the corresponding symmetric keys; based on the whitelist relationship data and symmetric keys corresponding to the new configuration file or the original configuration file locally, performs inter-service authentication between itself and other microservices, and determines whether to invoke the business information of itself or other microservices according to the corresponding authentication results. It is mainly applicable to the authentication of interface invocations between internal services in a microservice architecture. Different from the authentication of externally exposed interfaces, the granularity of inter-service authentication is service plus interface. The authentication and service invocation method between distributed microservices provided by this application adopts a distributed architecture, makes full use of the server hardware resources where the service consumers are located, and marginalizes resource utilization; it is mainly applicable to service platforms with high security requirements, especially applicable to application scenarios such as financial platforms for funds, bank interface invocations, basic services, important debt transfers, and business contract signings, and can preferably be directly used on cloud chain platforms. It performs refined management on the service governance between services. By implementing inter-service authentication and encrypted data transmission in the microservice architecture, it can improve the security of interface invocations and data transmissions, facilitate the management of invocation behaviors of important interfaces, and audit the invocations of important interfaces. The service authentication configuration is combined with dynamic and timed distribution according to the needs of service producers and consumers to solve the key management problem, and symmetric encryption is used to encrypt and decrypt important business messages, which can further balance the security and efficiency of service invocations.

[0035] Additional advantages, objects, and features of this application will be partially described below and will become partially apparent to those of ordinary skill in the art after studying the following text, or may be learned from the practice of this application. The objects and other advantages of this application can be achieved and obtained by the structures specifically pointed out in the specification and the drawings.

[0036] Those skilled in the art will understand that the objects and advantages that can be achieved by this application are not limited to the above specific descriptions, and the above and other objects that this application can achieve will be more clearly understood according to the following detailed description. Brief Description of the Drawings

[0037] The drawings described herein are used to provide a further understanding of this application, form a part of this application, and do not limit this application. The components in the drawings are not drawn to scale, but only to illustrate the principles of this application. To facilitate the illustration and description of some parts of this application, the corresponding parts in the drawings may be enlarged, that is, they may become larger relative to other components in the exemplary device actually manufactured according to this application. In the drawings:

[0038] Figure 1 This is the first schematic flow diagram of the authentication and service call method between distributed microservices in an embodiment of the present application.

[0039] Figure 2 This is the second schematic flow diagram of the authentication and service call method between distributed microservices in an embodiment of the present application.

[0040] Figure 3 This is a schematic structural diagram of a financial platform in another embodiment of the present application.

[0041] Figure 4 This is another schematic structural diagram of a financial platform in another embodiment of the present application.

[0042] Figure 5 This is a schematic diagram showing an example of the execution logic of the authentication and service call method between distributed microservices in an application example of the present application. Detailed implementation manners

[0043] To make the objectives, technical solutions and advantages of the present application more clear and understandable, the present application will be further described in detail below in conjunction with the implementation manners and the drawings. Herein, the illustrative implementation manners of the present application and their descriptions are used to explain the present application, but do not limit the present application.

[0044] Herein, it should also be noted that in order to avoid obscuring the present application due to unnecessary details, only the structures and / or processing steps closely related to the solution of the present application are shown in the drawings, while other details less related to the present application are omitted.

[0045] It should be emphasized that the term "including / containing" when used herein refers to the presence of features, elements, steps or components, but does not exclude the presence or addition of one or more other features, elements, steps or components.

[0046] Herein, it should also be noted that if not otherwise specified, the term "connection" in this document can refer not only to a direct connection, but also to an indirect connection with an intermediate.

[0047] In the following, embodiments of the present application will be described with reference to the drawings. In the drawings, the same reference numerals represent the same or similar components, or the same or similar steps.

[0048] In one or more embodiments of the present application, a microservice refers to a software development technology, which is a variant of the service-oriented architecture (SOA) architectural style. It advocates dividing a single application into a group of small services that coordinate and cooperate with each other to provide ultimate value to users. Each service runs in its own independent process, and lightweight communication mechanisms (usually RESTful APIs based on HTTP) are used to communicate between services. Each service is built around specific business and can be independently deployed to production environments, pre-production environments, etc. Additionally, a unified and centralized service management mechanism should be avoided as much as possible. For a specific service, an appropriate language and tool should be selected for its construction according to the context.

[0049] In one or more embodiments of the present application, inter-service authentication is a solution to handle the issue of mutual access permissions between microservices. It mainly means that the microservice provider needs to verify the permissions of the consumer to ensure that the service consumer has the permission to call and protect data security.

[0050] In one or more embodiments of the present application, symmetric encryption is an encryption method using a single-key cryptosystem. The same key can be used for both encryption and decryption of information simultaneously. This encryption method is called symmetric encryption or single-key encryption.

[0051] Regarding the current situation that there is no authentication for the interface calls between various services in the cloud chain platform, and the services are also transmitted in plain text via http (the network-based hypertext transfer protocol), there are problems such as lack of management for service interface calls, high risk of business data security, and fund security. First, the solution of using an interface gateway can be considered, and using a fixed token (the resource credential required when accessing the resource interface API) can also be considered to solve the inter-service authentication problem.

[0052] However, if the common interface gateway solution is adopted, all internal service calls need to be forwarded through the gateway before reaching the service producer. For microservice architectures and cluster deployments, there are problems such as excessive gateway traffic consuming server hardware resources, high-concurrency scenarios easily leading to service outages, and high development difficulty of gateway services (requiring the solution of different key management).

[0053] In addition, if a fixed token (the resource credential required when accessing the resource interface API) is used to solve the inter-service authentication problem, however, if the common fixed token is used to solve the inter-service authentication problem, it is first required to generate a fixed token during the development stage and hard-code the token in the code, which will have risks such as developers leaking the token, inflexible configuration, the need to develop code when adding token verification to the interface, and the inability to encrypt business messages.

[0054] Therefore, in the process of designing the present application, the inventor adopted a distributed architecture, made full use of the server hardware resources where the service consumers are located, and marginalized the resource utilization; the service authentication configuration combines dynamic and timed distribution according to the needs of service producers and consumers to solve the key management problem; for service consumers, the message parameters are encrypted according to the request interceptor before each call, greatly improving the encryption efficiency of the message.

[0055] In addition, when designing the distributed microservice authentication of the present application, centralized security management of the token management, configuration, and update is required to further ensure the security of the token; for the encryption of important service messages, both security and efficiency should be considered during the design process, so a dynamic token plus symmetric encryption method is used to encrypt and decrypt the service messages.

[0056] That is to say, the main purpose of the present application is to conduct refined management of service governance between services through a unified inter-service authentication scheme to ensure interface call and data security. Combining the architecture characteristics of the cloud chain platform, the present application proposes an architecture for distributed inter-service authentication, which solves problems such as centralized management of inter-service call tokens, dynamically setting call tokens according to business security level requirements, dynamic token refresh, and the absence of an authentication center node.

[0057] Specific details are described in detail through the following embodiments.

[0058] The embodiment of the present application provides a method for distributed microservice authentication and service call. Refer to Figure 1 , the method for distributed microservice authentication and service call that can be executed by a microservice (also referred to as a microservice node) specifically includes the following content:

[0059] Step 100: If a new configuration file for providing an inter-service authentication scheme is received from the distributed microservice architecture, then cache the new configuration file locally, where the original configuration file is also cached locally, and the configuration file contains: inter-service call whitelist relationship data and corresponding symmetric keys.

[0060] It can be understood that when the current microservice node receives a new configuration file for providing an inter-service authentication scheme in its distributed microservice architecture, it caches the new configuration file locally, where the original configuration file is also cached locally. In one case, the content of the original configuration file on the microservice node may also be empty, that is, for this microservice node, the new configuration file is the first configuration file it has received.

[0061] In one or more embodiments of the present application, the whitelist relationship data for inter-service calls refers to the callable relationship data between internal microservices in a distributed microservice architecture; the symmetric key refers to the key of a symmetric encryption algorithm. To further improve the security of inter-service authentication and service calls, different symmetric keys can be configured for different whitelist relationship data for inter-service calls to prevent theft and misuse.

[0062] Step 200: Based on the whitelist relationship data for inter-service calls and the symmetric key corresponding to the local new configuration file or the original configuration file respectively, perform inter-service authentication between itself and other microservices, and determine whether to call the service information of itself or other microservices according to the corresponding authentication result.

[0063] In step 200, although the same pair of microservice identifiers may be stored in both the local new configuration file and the original configuration file, their effective times may be different. Therefore, even if the new configuration file has been obtained and cached locally, it may not be available for authentication because the effective time has not arrived yet. So, it is necessary to obtain the whitelist relationship data for inter-service calls and the symmetric key with the effective time not expired from the original configuration file for inter-service authentication.

[0064] From the above description, it can be seen that the inter-service authentication and service call method provided by the embodiments of the present application is mainly applicable to the authentication of interface calls between internal services in a microservice architecture. Different from the authentication of externally exposed interfaces, the granularity of inter-service authentication is service plus interface. The inter-service authentication and service call method provided by the present application adopts a distributed architecture, makes full use of the server hardware resources where the service consumers are located, and marginalizes the resource utilization; it is mainly applicable to service platforms with high security requirements, especially applicable to application scenarios of financial platforms such as funds, bank interface calls, basic services, important debt transfers, and business contract signings, and preferably can be directly used on cloud chain platforms. For the refined management of service governance between services, by implementing inter-service authentication and encrypted data transmission in the microservice architecture, the security of interface calls and data transmission can be improved, facilitating the management of call behaviors of important interfaces and the auditing of important interface calls. The service authentication configuration combines dynamic and timed distribution according to the needs of service producers and consumers, solves the key management problem, and encrypts and decrypts important service messages using symmetric encryption, which can further balance the security and efficiency of service calls.

[0065] To further improve the application effectiveness and reliability of the whitelist relationship data for inter-service calls, the whitelist relationship data for inter-service calls in a distributed microservice inter-service authentication and service call method provided by an embodiment of the present application specifically includes the following content:

[0066] The correspondence relationship among a consumer service identifier, a producer service identifier, a producer service interface identifier, and a valid time range, where the consumer service identifier and the producer service identifier belong to different microservices respectively.

[0067] Specifically, the consumer service identifier refers to the unique identifier of the original microservice or the original service acting as the consumer role, and the producer service identifier refers to the unique identifier of the target microservice or the target service acting as the producer role, both of which can adopt their microservice IDs.

[0068] To further improve the effectiveness and reliability of microservice nodes obtaining new configuration files for providing an inter-service authentication scheme, in a distributed inter-service authentication and service invocation method provided in an embodiment of the present application, refer to Figure 2 Step 100 in the distributed inter-service authentication and service invocation method specifically includes the following content:

[0069] Step 110: In the distributed microservice architecture where it is located, receive a new configuration file for providing an inter-service authentication scheme sent by a timing task scheduling module, where the timing task scheduling module pre-pulls the new configuration file for providing an inter-service authentication scheme from an inter-service authentication scheme configuration module.

[0070] To further improve the effectiveness and reliability of timing task scheduling, in a distributed inter-service authentication and service invocation method provided in an embodiment of the present application, the timing task scheduling module is used to periodically check in the inter-service authentication scheme configuration module whether there is a new configuration file for providing an inter-service authentication scheme. If so, the timing task scheduling module obtains the IP addresses and port numbers of the corresponding microservices from the configuration center and the service registration center according to the consumer service identifier and the producer service identifier in the configuration file, and based on the IP addresses and port numbers of the respective microservices, sends the new configuration file for providing an inter-service authentication scheme to each of the microservices.

[0071] To further improve the efficiency and reliability of a microservice acting as a consumer for inter-service authentication and service invocation, in a distributed inter-service authentication and service invocation method provided in an embodiment of the present application, refer to Figure 2 Step 200 in the distributed inter-service authentication and service invocation method specifically includes the following content:

[0072] Step 211: Obtain the producer service identifier corresponding to the target microservice to be accessed by itself.

[0073] Step 212: Check whether the service - to - service call whitelist relationship data containing the correspondence between its own consumer service identifier and the producer service identifier of the target microservice exists in the newly cached configuration file or the original configuration file locally. If so, execute Step 213; if not, directly throw an exception with the exception message "No permission to call this service".

[0074] Step 213: Further determine whether the current time is within the effective time range in the service - to - service call whitelist relationship data. If so, execute Step 214; if not, directly throw an exception with the exception message "No permission to call this service".

[0075] Step 214: If the current time is within the effective time range in the service - to - service call whitelist relationship data, it is determined that the authentication between itself and the target microservice is successful, and the symmetric key corresponding to the service - to - service call whitelist relationship data is used to encrypt the service requirement data and generate a corresponding service request.

[0076] Step 215: Based on the producer service interface identifier of the target microservice in the service - to - service call whitelist relationship data, send the service request to the target microservice, so that the target microservice decrypts the encrypted service requirement data and performs service - to - service authentication based on its newly cached configuration file or the original configuration file locally to determine whether to issue the service information corresponding to the service request data.

[0077] To further improve the efficiency and reliability of service - to - service authentication and service call when a microservice acts as a producer, in a distributed service - to - service authentication and service call method provided in an embodiment of the present application, refer to Figure 2 , Step 200 in the distributed service - to - service authentication and service call method further specifically includes the following content:

[0078] Step 221: Receive the service request of the original microservice that needs to call its own service, and the corresponding consumer service identifier of the original microservice.

[0079] Step 222: Check whether the service - to - service call whitelist relationship data containing the correspondence between its own producer service identifier and the consumer service identifier of the original microservice is recorded in the newly cached configuration file or the original configuration file locally. If so, execute Step 223; if not, directly reject this request and throw an exception message "No permission to call this service".

[0080] Step 223: Further determine whether the current time is within the effective time range in the service - to - service call whitelist relationship data. If so, execute Step 224; if not, directly reject this request and throw an exception message "No permission to call this service".

[0081] Step 224: If the current time is included in the effective time range in the service - to - service call whitelist relationship data, and it is verified that the encrypted business requirement data is non - empty data, then it is determined that the authentication between itself and the original microservice is successful, and the encrypted business requirement data in the service request is decrypted based on the symmetric key corresponding to the service - to - service call whitelist relationship data to obtain the corresponding business requirement data.

[0082] Step 225: Based on the consumer service interface identifier of the original microservice in the service - to - service call whitelist relationship data, encrypt the business information corresponding to the business requirement data and send it to the original microservice.

[0083] It can be understood that the execution order between Step 211 and Step 215 and between Step 221 and Step 225 is not limited, and it is specifically set according to the actual application scenario. That is to say, a microservice can currently be a producer of other microservices, and at the same time, before or after, it can also be a consumer of other microservices.

[0084] From a software perspective, based on the foregoing embodiments of the distributed microservice - to - microservice authentication and service call method, the present application further provides a distributed microservice system, and the distributed microservice system specifically includes the following:

[0085] Multiple distributed microservices; each microservice is used to execute the foregoing embodiments of the distributed microservice - to - microservice authentication and service call method.

[0086] The microservices in the distributed microservice system provided by the present application can specifically be used to execute the processing flow of the foregoing embodiments of the distributed microservice - to - microservice authentication and service call method, and its functions will not be elaborated here. Reference can be made to the detailed description of the foregoing embodiments of the distributed microservice - to - microservice authentication and service call method.

[0087] From the above description, it can be seen that the distributed microservice system provided by the embodiments of the present application can implement the authentication between internal services in a microservice architecture, and is mainly applicable to financial platforms with high security requirements such as cloud chain platforms, and can improve the security and efficiency of interface calls and data transmissions, and further improve the security and reliability of business scheduling in financial platforms with high security requirements such as cloud chain platforms.

[0088] Based on the foregoing embodiments of the distributed microservice system and / or the distributed microservice - to - microservice authentication and service call method, the present application further provides an embodiment of a financial platform. See Figure 3 and the financial platform specifically includes the following:

[0089] An inter-service authentication scheme configuration module 10, a timing task scheduling module 20, and a distributed microservice system 30;

[0090] Among them, the distributed microservice system 30 includes: a plurality of distributed microservices 31, and each microservice 31 is used to execute the embodiments of the aforementioned distributed microservice inter-authentication and service call method;

[0091] The inter-service authentication scheme configuration module 10 is used to configure a new configuration file, and the configuration file contains: inter-service call whitelist relationship data and corresponding symmetric keys;

[0092] The timing task scheduling module 20 is used to pull a new configuration file for providing an inter-service authentication scheme from the inter-service authentication scheme configuration module, and distribute the configuration file to each corresponding microservice in the distributed microservice system.

[0093] The microservices in the financial platform (which can also be called a financial service platform) provided by this application can specifically be used to execute the processing flow of the embodiments of the distributed microservice inter-authentication and service call method in the above embodiments. Its functions will not be elaborated here and can refer to the detailed description of the embodiments of the distributed microservice inter-authentication and service call method.

[0094] The part of the financial platform for distributed microservice inter-authentication and service call can be executed in the server. In another actual application scenario, all operations can also be completed in the client device. Specifically, it can be selected according to the processing ability of the client device and the limitations of the user usage scenario. This application does not make a limitation on this. If all operations are completed in the client device, the client device may further include a processor for specifically processing distributed microservice inter-authentication and service call.

[0095] The above client device can have a communication module (i.e., a communication unit) and can communicate with a remote server to realize data transmission with the server. The server can include a server on the task scheduling center side. In other implementation scenarios, it can also include a server of an intermediate platform, such as a server of a third-party server platform having a communication link with the task scheduling center server. The server can include a single computer device, or a server cluster composed of multiple servers, or a server structure of a distributed device.

[0096] Any suitable network protocol can be used for communication between the above-mentioned server and the client device, including network protocols that have not been developed as of the filing date of this application. The network protocol can include, for example, TCP / IP protocol, UDP / IP protocol, HTTP protocol, HTTPS protocol, etc. Of course, the network protocol can also include, for example, RPC protocol (Remote Procedure Call Protocol) and REST protocol (Representational State Transfer) used on top of the above-mentioned protocols.

[0097] In one or more embodiments of this application, the financial platform can select a cloud chain platform.

[0098] As can be seen from the above description, the financial platform provided by the embodiments of this application is mainly applicable to the authentication of interface calls between internal services in a microservices architecture, which is different from the authentication of externally exposed interfaces. The granularity of inter-service authentication is service plus interface. The distributed inter-microservice authentication and service call method provided by this application adopts a distributed architecture, makes full use of the server hardware resources where the service consumer is located, and marginalizes the resource utilization; it is mainly applicable to service platforms with high security requirements, especially applicable to application scenarios of financial platforms such as funds, bank interface calls, basic services, important debt transfers, and business contract signings. Preferably, it can be directly used on a cloud chain platform. For the refined management of service governance between services, by implementing inter-service authentication and encrypted data transmission in a microservices architecture, the security of interface calls and data transmission can be improved, facilitating the management of call behaviors of important interfaces and auditing of important interface calls. The service authentication configuration is combined with dynamic and timed distribution according to the needs of service producers and consumers to solve the key

[0099] management problem, and symmetric encryption is used to encrypt and decrypt important business messages, which can further balance the security and efficiency of 5 service calls.

[0100] In order to further improve the effectiveness and reliability of microservice nodes to obtain a new configuration file for providing an inter-service authentication solution, in the financial platform provided by the embodiments of this application, see Figure 4 The inter-service authentication solution configuration module 10 specifically includes the following contents:

[0101] A data acquisition unit 11, configured to acquire the correspondence between the consumer service identifier, the producer service identifier, the producer service interface identifier, and the effective time range;

[0102] A file configuration unit 12 is used to use the correspondence between the consumer service identifier, the producer service identifier, the producer service interface identifier, and the effective time range as the service - to - service call whitelist relationship data, and generate a new configuration file according to the service - to - service call whitelist relationship data and the corresponding symmetric key. Among them, the consumer service identifier and the producer service identifier belong to different microservices respectively.

[0103] 5 To further improve the effectiveness and reliability of the scheduled task scheduling, in the financial platform provided in the embodiment of the present application,

[0104] See Figure 4 , the scheduled task scheduling module 20 specifically includes the following content:

[0105] A scheduled pulling unit 21 is used to periodically search in the service - to - service authentication scheme configuration module to check if there is a new configuration file for providing the service - to - service authentication scheme. If so, obtain the new configuration file for providing the service - to - service authentication scheme.

[0106] 0 A data distribution unit 22 is used to, according to the consumer service identifier and the producer service identifier in the configuration file,

[0107] obtain the IP addresses and port numbers of the corresponding individual microservices from the configuration center and the service registration center, and based on the IP addresses and port numbers of the individual microservices, send the new configuration file for providing the service - to - service authentication scheme to each of the microservices respectively.

[0108] To further illustrate the present solution, the present application also provides a specific application example of a distributed microservice - to - microservice authentication and service call method. See Figure 5 , which specifically includes: 1. Pull the service authentication scheme configuration; 2. Distribute the service - to - service authentication scheme configuration; 3. Locally cache the authentication scheme; 4. Encrypt the service data and then make a call. Based on this, the distributed microservice - to - microservice authentication and service call method provided by the application example of the present application specifically includes the following content:

[0109] (I) Service - to - service authentication scheme configuration

[0110] The main function of the service - to - service authentication scheme configuration service is to configure the whitelist relationship for API calls between each service, and obtain the service - to - service call whitelist relationship data of the service - to - service authentication scheme. The service - to - service call whitelist relationship data includes: the correspondence between the consumer service identifier, the producer service identifier, the producer service interface identifier, and the effective time range. Among them, the consumer service identifier and the producer service identifier belong to different microservices respectively. In a specific example, the service - to - service call whitelist relationship data may include: the name of the original service (consumer), the name of the target service (producer), the name of the target service (producer) interface, and the effective time range, and their relationship is 1:1:n:1, where n is a positive integer. The service - to - service call whitelist relationship data can be simply referred to as configuration relationship data, and this configuration relationship data can be stored in a MySQL database; at the same time, the generation rule of the symmetric key also needs to be configured to send the configuration relationship data and the symmetric key to the producer and the consumer together later.

[0111] Among them, for the configuration form of the service - to - service authentication scheme, this configuration form is the name of the original service, the name of the target service, the name of the target service interface, and the effective time range, which can be written as ['consumer service name', 'producer service name', 'API producer service interface path', 'effective time range'].

[0112] (2) Scheduled task scheduling

[0113] The main function of the scheduled task scheduling is to execute a scheduled task at a preset time point (such as 11:30 p.m. every day) in each time period (such as every day). The scheduled task includes the following steps:

[0114] S21: Determine whether there is a new service - to - service authentication scheme. If there is a new service - to - service authentication scheme, then execute S22;

[0115] S22: Obtain the IP address and port number of each service from Nacos (configuration center and service registry) respectively according to the name of the original service and the name of the target service recorded in the configuration relationship data of the new service - to - service authentication scheme;

[0116] S23: Send the configuration file corresponding to the new service - to - service authentication scheme, which contains the configuration relationship data and the symmetric key, to the producer and the consumer.

[0117] Among them, the channel for scheduling and distributing timed tasks is the configuration channel for calling the microservice to register with Nacos (configuration center and service registry). Using this channel, the configuration file can be directly read into the memory in the form of properties (a configuration file format based on key-value pairs), and the Spring Context (a general term for the spring framework container context) context can be dynamically refreshed and obtained.

[0118] (3) Inter-service authentication

[0119] S31: When the authentication scheme is distributed to the service, the target service caches the configuration file locally in the form of properties based on the dynamic refresh ability of the Nacos client (configuration center and service registry client), and the original authentication scheme also exists in the cached configuration.

[0120] S32: When the service consumer is about to access the service producer, first obtain the annotation of @FeignClient (a class marked as an instance of remote inter-service call in the spring framework, through which the service producer can be directly remotely called) of the feign (a way of remote inter-service call encapsulated by the spring framework) instance, obtain the target service name produced by the service, and query the effective authentication configuration scheme in the cache of step 31 based on this target service name and the current time. If no effective configuration scheme is found, directly throw an exception, and the exception information is that there is no permission to call this service. If an effective configuration scheme is found, symmetrically encrypt the configuration scheme parameters according to the corresponding symmetric key in the configuration file, and store the encrypted result in the sign (a fixed key value of the message parameter, storing the value after the message is encrypted) field. This field is passed into the service producer along with the http (hypertext transfer protocol based on the network) message header parameters.

[0121] S33: When the service producer receives the service call request from the service consumer, first obtain the original service name of the service consumer, and obtain the effective authentication configuration from the cache of the authentication configuration. If it cannot be obtained, directly reject this request and throw an exception message that there is no permission to call this service; if the effective authentication configuration is obtained, first perform a non-null check on the value of sign (a fixed key value of the message parameter, storing the value after the message is encrypted). If it is null, throw an exception message that the parameter is incorrect; if it is not null, symmetrically decrypt the value of the sign (a fixed key value of the message parameter, storing the value after the message is encrypted) s field. If the decryption fails, throw an exception message that the verification fails, please check the key. If the verification is correct, pass the request down and return the correct business information.

[0122] In summary, in view of the problem that there is no inter-service authentication in the current cloud chain platform, the method provided by this application can well solve the problem of inter-service authentication, effectively control the behavior of service calls, greatly improve the security of interfaces, especially for fund-related interfaces.

[0123] Compared with the solution using an inter-service gateway, the method provided by this application has high availability, there is no central node, and the downtime of the inter-service authentication solution service will not affect the authentication of the entire platform. Each service reads the cache configuration, and there is no problem of calling through interfaces, ensuring efficiency and security.

[0124] For the fixed token solution, the general current solution is either a global token or a fixed token for each interface. This solution is fixed during the code writing stage, there is a risk of leakage by developers, and service producers only verify the legality of this token and there is a token management disaster. Correspondingly, the method provided by this application adopts an authentication configuration scheme to be issued through a timing task, which can effectively solve the problems of code modification, untimely token update, and token management disaster. In terms of business data protection, a mature symmetric encryption and decryption scheme is adopted, which not only ensures security but also considers efficiency, and has little impact on the call of service APIs. After measurement, this takes less than 50 ms.

[0125] The embodiment of this application also provides an electronic device (i.e., a computer device), which may include a processor, a memory, a receiver, and a transmitter. The processor is used to execute the functions of the financial platform mentioned in the above embodiments. The processor and the memory may be connected through a bus or other means. Taking the connection through the bus as an example. The receiver can be connected to the processor and the memory in a wired or wireless manner. The electronic device can receive real-time motion data from sensors in the wireless multimedia sensor network and receive the original video sequence from the video acquisition device.

[0126] The processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. chips, or a combination of the above types of chips.

[0127] The memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the financial platform in the embodiments of the present application. By running the non-transitory software programs, instructions, and modules stored in the memory, the processor executes various functional applications and data processing of the processor, that is, implements the authentication and service call method between distributed microservices in the above method embodiments.

[0128] The memory may include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created by the processor, etc. In addition, the memory may include high-speed random access memory and may also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory may optionally include a memory remotely provided with respect to the processor, and these remote memories can be connected to the processor through a network. Examples of the above networks include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0129] The one or more modules are stored in the memory and, when executed by the processor, execute the functions of the financial platform in the embodiments.

[0130] In some embodiments of the present application, the user equipment may include a processor, a memory, and a transceiver unit. The transceiver unit may include a receiver and a transmitter. The processor, the memory, the receiver, and the transmitter may be connected through a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to transmit and receive signals.

[0131] As an implementation manner, the functions of the receiver and the transmitter in the present application can be considered to be implemented through a transceiver circuit or a dedicated transceiver chip, and the processor can be considered to be implemented through a dedicated processing chip, a processing circuit, or a general-purpose chip.

[0132] As another implementation manner, a general computer can be considered to be used to implement the server provided in the embodiments of the present application. That is, the program codes for implementing the functions of the processor, the receiver, and the transmitter are stored in the memory, and the general-purpose processor implements the functions of the processor, the receiver, and the transmitter by executing the codes in the memory.

[0133] The embodiments of the present application further provide a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it realizes the functions of the foregoing financial platform. The computer-readable storage medium may be a tangible storage medium, such as a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, floppy disk, hard disk, removable storage disk, CD-ROM, or any other form of storage medium well-known in the technical field.

[0134] Those of ordinary skill in the art should understand that the various exemplary components, systems, and methods described in connection with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Specifically, whether to implement in hardware or software depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application. When implemented in hardware, it can be, for example, an electronic circuit, an application-specific integrated circuit (ASIC), appropriate firmware, a plug-in, a functional card, etc. When implemented in software, the elements of the present application are programs or code segments used to perform the required tasks. The programs or code segments can be stored in a machine-readable medium or transmitted through a data signal carried in a carrier wave on a transmission medium or a communication link.

[0135] It should be clear that the present application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, the detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order between steps after understanding the spirit of the present application.

[0136] In the present application, the features described and / or illustrated for one embodiment can be used in the same or a similar manner in one or more other embodiments, and / or combined with the features of other embodiments or replace the features of other embodiments.

[0137] The above are only the preferred embodiments of the present application and are not used to limit the present application. For those skilled in the art, the embodiments of the present application can have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for authentication and business invocation between distributed microservices, characterized in that, it includes: If a new configuration file for providing an inter-service authentication scheme is received from the distributed microservice architecture, cache the new configuration file locally, where the original configuration file is also cached locally, and the configuration file contains: inter-service call whitelist relationship data and corresponding symmetric keys; Based on the inter-service call whitelist relationship data and symmetric keys corresponding to the new configuration file or the original configuration file locally, perform inter-service authentication between itself and other microservices, and determine whether to invoke the business information of itself or other microservices according to the corresponding authentication result; The inter-service call whitelist relationship data includes: the corresponding relationship between the consumer service identifier, the producer service identifier, the producer service interface identifier, and the effective time range, where the consumer service identifier and the producer service identifier belong to different microservices respectively; The performing inter-service authentication between itself and other microservices based on the inter-service call whitelist relationship data and symmetric keys corresponding to the new configuration file or the original configuration file locally, and determining whether to invoke the business information of itself or other microservices according to the corresponding authentication result includes: Obtain the producer service identifier corresponding to the target microservice to be accessed by itself; Search in the new configuration file or the original configuration file cached locally to find whether there is inter-service call whitelist relationship data including the corresponding relationship between its own consumer service identifier and the producer service identifier of the target microservice. If so, further determine whether the current time is included in the effective time range in the inter-service call whitelist relationship data; If the current time is included in the effective time range in the inter-service call whitelist relationship data, determine that the authentication between itself and the target microservice is successful, and encrypt the business requirement data based on the symmetric key corresponding to the inter-service call whitelist relationship data and generate a corresponding business request; Based on the producer service interface identifier of the target microservice in the inter-service call whitelist relationship data, send the business request to the target microservice, so that the target microservice decrypts the encrypted business requirement data and performs inter-service authentication based on the new configuration file or the original configuration file cached locally to determine whether to issue the business information corresponding to the business request data.

2. The method for authentication and business invocation between distributed microservices according to claim 1, characterized in that, the receiving a new configuration file for providing an inter-service authentication scheme from the distributed microservice architecture includes: In the distributed microservice architecture where it is located, receive a new configuration file for providing an inter-service authentication scheme sent by the timing task scheduling module, where the timing task scheduling module pre-pulls a new configuration file for providing an inter-service authentication scheme from an inter-service authentication scheme configuration module.

3. The method for authentication and business invocation between distributed microservices according to claim 2, characterized in that, The timing task scheduling module is used to periodically check in the inter-service authentication scheme configuration module whether there is a new configuration file for providing the inter-service authentication scheme. If so, the timing task scheduling module obtains the IP addresses and port numbers of the corresponding microservices from the configuration center and the service registry according to the consumer service identifier and the producer service identifier in the configuration file, and based on the IP addresses and port numbers of the respective microservices, sends the new configuration file for providing the inter-service authentication scheme to each of the microservices respectively.

4. The distributed microservice inter-authentication and service invocation method according to claim 1, wherein, performing inter-service authentication between itself and other microservices based on the inter-service call whitelist relationship data and the symmetric key corresponding to the local new configuration file or the original configuration file, and determining whether to invoke the service information of itself or other microservices according to the corresponding authentication result, further includes: receiving a service request of the original microservice for invoking its own service, and the consumer service identifier corresponding to the original microservice; checking in the locally cached new configuration file or the original configuration file whether there is inter-service call whitelist relationship data recording the corresponding relationship between its own producer service identifier and the consumer service identifier of the original microservice. If so, further determining whether the current time is within the effective time range in the inter-service call whitelist relationship data; if the current time is within the effective time range in the inter-service call whitelist relationship data, and it is verified that the encrypted service requirement data is non-empty data, determining that the authentication between itself and the original microservice is successful, and decrypting the encrypted service requirement data in the service request based on the symmetric key corresponding to the inter-service call whitelist relationship data to obtain the corresponding service requirement data; based on the consumer service interface identifier of the original microservice in the inter-service call whitelist relationship data, and encrypting the service information corresponding to the service requirement data and sending it to the original microservice.

5. A distributed microservice system, wherein, includes: a plurality of distributed microservices; each of the microservices is used to execute the distributed microservice inter-authentication and service invocation method according to any one of claims 1 to 4.

6. A financial platform, wherein, includes: an inter-service authentication scheme configuration module, a timing task scheduling module, and a distributed microservice system; wherein, the distributed microservice system includes: a plurality of distributed microservices, and each of the microservices is used to execute the distributed microservice inter-authentication and service invocation method according to any one of claims 1 to 4; the inter-service authentication scheme configuration module is used to configure a new configuration file, and the configuration file contains: inter-service call whitelist relationship data and the corresponding symmetric key; The timing task scheduling module is used to pull a new configuration file for providing an inter-service authentication scheme from the inter-service authentication scheme configuration module, and distribute the configuration file to each corresponding microservice in the distributed microservice system.

7. The financial platform according to claim 6, wherein, the inter-service authentication scheme configuration module includes: a data acquisition unit, configured to acquire the correspondence relationship between the consumer service identifier, the producer service identifier, the producer service interface identifier, and the effective time range; a file configuration unit, configured to use the correspondence relationship between the consumer service identifier, the producer service identifier, the producer service interface identifier, and the effective time range as the inter-service call whitelist relationship data, and generate a new configuration file according to the inter-service call whitelist relationship data and the corresponding symmetric key, wherein the consumer service identifier and the producer service identifier belong to different microservices respectively.

8. The financial platform according to claim 7, wherein, the timing task scheduling module includes: a timing pull unit, configured to periodically check in the inter-service authentication scheme configuration module whether there is a new configuration file for providing an inter-service authentication scheme, and if so, acquire the new configuration file for providing an inter-service authentication scheme; a data distribution unit, configured to obtain the IP addresses and port numbers of the corresponding microservices from the configuration center and the service registry according to the consumer service identifier and the producer service identifier in the configuration file, and based on the IP addresses and port numbers of the respective microservices, send the new configuration file for providing an inter-service authentication scheme to each of the microservices.

Images