Token synchronization method and device based on micro service, equipment and storage medium

Abstract

The invention discloses a token synchronization method and device based on micro-service, equipment and a storage medium, and relates to the technical field of application software development, and the method comprises the steps: analyzing a target request comprising a first token to obtain token expiration time; and if the current time does not exceed the token expiration time, judging whether the remaining effective duration is greater than a target duration threshold, if the remaining effective duration is not greater than the target duration threshold and a token refreshing mark does not exist, setting the token refreshing mark in the preset cache database, refreshing the token, and issuing an obtained second token to the front-end micro-service, the front-end micro-service accesses the back-end micro-service based on the second token; and calling the independent micro-service to analyze a first token issued by the front-end micro-service to obtain the user identifier, so that the independent micro-service accesses a preset cache database by using a key generated based on the user identifier to obtain a second token, and accesses the rear-end micro-service based on the second token, and enabling the back-end micro-service to transmit the access response information to the independent micro-service for processing. Therefore, the token synchronization efficiency can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of application software development, and in particular to a token synchronization method, apparatus, device and storage medium based on microservices. Background Art

[0002] The microservices architecture consists of front-end microservices and back-end microservices. Front-end microservices provide user interaction interfaces, and users must access these interfaces to operate the system. Back-end microservices implement the system's core business logic, such as creating user information, storing system data, authenticating interface permissions, and generating tokens. Only requests carrying valid tokens can access the back-end microservice interfaces.

[0003] Currently, a new independent microservice needs to be inserted into the current microservice architecture to provide new functionality. To use it, users first need to launch the independent microservice through the front-end microservice, and then call the new functionality through the independent microservice. During the launch, the front-end microservice will send its authentication token to the independent microservice. The independent microservice then uses the token to access the back-end microservice and obtain all the parameter information required to execute the new functionality.

[0004] However, after being launched by the frontend microservice, the independent microservice continues to hold the token originally shared by the frontend microservice. For security reasons, tokens have a validity period; after this period, they expire, requiring the user to log in again. To reduce the number of times users have to log in again, the frontend microservice checks the remaining time until the token expires each time it accesses the backend microservice. If the remaining validity period is less than half of the validity period, the frontend microservice uses the old token to access the refresh token API of the backend microservice to obtain a new token, allowing it to access the backend microservice with the new token. However, since the independent microservice continues to hold the token from when it was launched, it never gets updated. As a result, while communication between the frontend and backend microservices continues normally, users receive "token expired" errors when accessing the independent microservice, significantly impacting the user experience.

[0005] As can be seen from the above, how to improve the efficiency of token synchronization between microservices in the microservice-based token synchronization process is an urgent problem to be solved. Summary of the Invention

[0006] In view of this, the purpose of the present invention is to provide a microservice-based token synchronization method, apparatus, device, and storage medium, which can improve the efficiency of token synchronization between microservices during the microservice-based token synchronization process, thereby improving the speed and security of the production process. The specific solution is as follows:

[0007] In a first aspect, the present application provides a microservice-based token synchronization method, which is applied to backend microservices, including:

[0008] Filtering each access request using a token filter to obtain a target request including a first token for performing authority authentication, and then parsing the target request to obtain a token expiration time corresponding to the first token;

[0009] Determine whether the current time exceeds the token expiration time; if not, determine the remaining valid duration based on the token expiration time and the current time, and determine whether the remaining valid duration is greater than a target duration threshold; if not, check whether there is a token refresh flag in a preset cache database; if not, set the token refresh flag in the preset cache database;

[0010] Performing a token refresh operation based on the token refresh flag, storing the obtained second token in the preset cache database, and then sending the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using the login information determined based on the second token;

[0011] The independent microservice is called to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice can access the preset cache database using a key generated based on the user identifier, and obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then the back-end microservice will pass the access response information to the independent microservice for processing.

[0012] Optionally, the step of filtering each access request using a token filter to obtain a target request including a first token for authorization authentication, and then parsing the target request to obtain a token expiration time corresponding to the first token includes:

[0013] Configuring a token filter in the backend microservice to use the token filter to determine whether each access request sent to the backend microservice includes a token according to preset request filtering rules;

[0014] If the access request does not include a token, determining that the access request is a request that does not require authorization authentication, and allowing the access request to perform a login operation or a public interface call operation based on the access request;

[0015] If the access request includes a token, the access request is determined to be a request that requires authorization authentication, the access request is set as a target request, and a signature legitimacy verification operation is performed on the target request to obtain a verification result;

[0016] If the verification result indicates that the verification has failed, an exception response is generated and returned to the request initiator. If the verification result indicates that the verification has passed, the target request is parsed to obtain the token expiration time corresponding to the first token.

[0017] Optionally, the determining whether the current time exceeds the token expiration time, and if not, determining a remaining valid duration based on the token expiration time and the current time, and determining whether the remaining valid duration is greater than a target duration threshold, includes:

[0018] Determining a total validity period of the first token based on the user authority level and the system security policy, and determining a target validity period threshold based on a preset ratio and the total validity period; wherein the user authority level corresponding to the user is positively correlated with the total validity period;

[0019] Determine whether the current time exceeds the token expiration time; if the current time does not exceed the token expiration time, determine the remaining valid duration based on the token expiration time and the current time, and determine whether the remaining valid duration is greater than the target duration threshold;

[0020] If the remaining valid duration is greater than the target duration threshold, it is determined that the first token does not need to be refreshed, and it is determined that the request corresponding to the first token meets the release conditions, the request corresponding to the first token is directly released, and the valid status of the first token is maintained.

[0021] Optionally, the step of checking whether a token refresh flag exists in a preset cache database, and if not, setting a token refresh flag in the preset cache database includes:

[0022] Check whether there is a token refresh flag in the preset cache database. If there is no token refresh flag in the preset cache database, count the total number of requests that currently require a token refresh operation;

[0023] Determine whether the total number of requests is greater than one. If the total number of requests is greater than one, use the atomic operation in the preset cache database to lock the setting permission of the token refresh flag, monitor the request status corresponding to each target request, and then perform a token refresh flag configuration operation on the first target request that is successfully monitored to obtain a corresponding token refresh flag;

[0024] When it is detected that the token refresh flag exists, the remaining target requests are released, and the first token is used to perform permission verification on each target request.

[0025] Optionally, performing a token refresh operation based on the token refresh flag, storing the obtained second token in the preset cache database, and then sending the second token to the front-end microservice so that the front-end microservice accesses the back-end microservice using login information determined based on the second token, includes:

[0026] Performing a token refresh operation based on the token refresh flag to obtain a second token, storing the second token in a preset cache database, and then releasing the locking state of the token refresh flag;

[0027] After receiving the communication connection request carrying the service identifier issued by the front-end microservice, the legitimacy of the service identifier is verified, and after the verification is passed, an independent communication session identifier is allocated to the front-end microservice, and then a two-way communication link is established between the front-end microservice and the front-end microservice based on the communication session identifier; the service identifier is used to distinguish each front-end microservice instance;

[0028] Sending a response message to the front-end microservice at a preset detection time interval; if no response message from the front-end microservice is received when the current number of transmissions is not less than a preset transmission number threshold, closing the bidirectional communication link and jumping to the step of verifying the legitimacy of the service identifier after receiving the communication connection request carrying the service identifier from the front-end microservice;

[0029] The second token is sent to the front-end microservice through the bidirectional communication link, so that the front-end microservice determines login information based on the second token and accesses the back-end microservice based on the login information.

[0030] Optionally, the calling of the independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice uses a key generated based on the user identifier to access the preset cache database to obtain the second token, includes:

[0031] After receiving the independent microservice trigger instruction issued by the user through the operation interface of the front-end microservice, calling the front-end microservice to pass the first token to the independent microservice using a secure transmission protocol, so that the front-end microservice sends the initialization parameters of the independent microservice page corresponding to the independent microservice determined based on the independent microservice trigger instruction and the first token to the independent microservice;

[0032] The independent microservice is called to decrypt and integrity check the first token in the initialization parameter. If the verification result indicates that the verification fails, the service is refused and a token invalid prompt message is returned. If the verification result indicates that the verification passes, the user identifier in the first token is parsed to obtain a key corresponding to the user identifier, and the key is bound to the operation session of the independent microservice to obtain a binding result, so as to use the binding result to obtain the preset cache database to obtain the second token.

[0033] Optionally, the calling of the independent microservice parses the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice uses a key generated based on the user identifier to access the preset cache database, obtains the second token, and allows the independent microservice to access the back-end microservice based on the second token, and then instructs the back-end microservice to pass access response information to the independent microservice for processing, including:

[0034] Calling the independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice can concatenate the user identifier, the preset prefix character, and the fixed separator in a preset concatenation order to obtain a key; wherein the preset prefix character is used to distinguish token storage areas for different business scenarios;

[0035] Perform a historical token record query operation on the preset cache database using the key. If there are several historical token records corresponding to the key in the preset cache database, sort the historical token records in reverse order according to the order of token generation timestamps corresponding to the historical token records, and set the token with the latest timestamp in the sorting result as the second token;

[0036] If there is no historical token record corresponding to the key in the preset cache database, a token reissue request is initiated to the backend microservice, and after receiving the token issued by the backend microservice, the token entry in the preset cache database is updated;

[0037] After obtaining the second token, the independent microservice calls the independent microservice to embed the second token into the header information of the request, and determines whether the remaining validity period of the second token is less than the target duration threshold each time the backend microservice is accessed. If the remaining validity period of the second token is less than the target duration threshold, the process jumps to the step of checking whether there is a token refresh flag in the preset cache database.

[0038] In a second aspect, the present application provides a microservice-based token synchronization device, which is applied to backend microservices, including:

[0039] a token expiration time determination module, configured to filter each access request using a token filter to obtain a target request including a first token for performing authority authentication, and then parse the target request to obtain a token expiration time corresponding to the first token;

[0040] a remaining valid duration determination module, configured to determine whether the current time exceeds the token expiration time; if not, determine the remaining valid duration based on the token expiration time and the current time, and determine whether the remaining valid duration is greater than a target duration threshold; if not, check whether a token refresh flag exists in a preset cache database; if not, set the token refresh flag in the preset cache database;

[0041] A token refresh module is configured to perform a token refresh operation based on the token refresh flag, store the obtained second token in the preset cache database, and then send the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using login information determined based on the second token;

[0042] The information transmission module is used to call the independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice can use the key generated based on the user identifier to access the preset cache database, obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then instruct the back-end microservice to pass the access response information to the independent microservice for processing.

[0043] In a third aspect, the present application provides an electronic device, comprising:

[0044] Memory, used to store computer programs;

[0045] A processor is configured to execute the computer program to implement the aforementioned microservice-based token synchronization method.

[0046] In a fourth aspect, the present application provides a computer-readable storage medium for storing a computer program, wherein the computer program implements the aforementioned microservice-based token synchronization method when executed by a processor.

[0047] As can be seen from the above, before performing microservice-based token synchronization, this application needs to use a token filter to filter each access request to obtain a target request including a first token for permission authentication, and then parse the target request to obtain the token expiration time corresponding to the first token; determine whether the token expiration time is less than the current time. If it is less, determine the remaining valid time based on the token expiration time and the current time, and determine whether the remaining valid time is greater than the target time threshold. If it is not greater, check whether there is a token refresh flag in the preset cache database. If not, set the token refresh flag in the preset cache database; perform a token refresh operation based on the token refresh flag, and store the obtained second token in the preset cache database, and then send the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using the login information determined based on the second token; call the independent microservice to parse the first token issued by the front-end microservice to obtain the user identifier, so that the independent microservice can access the preset cache database using the key generated based on the user identifier to obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then let the back-end microservice pass the access response information to the independent microservice for processing.

[0048] It can be seen that this application first needs to use a token filter to filter each access request to obtain a target request including a first token for permission authentication, and then parse the target request to obtain the token expiration time corresponding to the first token; then, determine whether the token expiration time is less than the current time. If it is less, determine the remaining valid time based on the token expiration time and the current time, and determine whether the remaining valid time is greater than the target time threshold. If it is not greater, check whether there is a token refresh flag in the preset cache database. If not, set the token refresh flag in the preset cache database; then, perform a token refresh operation based on the token refresh flag, and store the obtained second token in the preset cache database, and then send the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using the login information determined based on the second token; finally, call the independent microservice to parse the first token issued by the front-end microservice to obtain the user identifier, so that the independent microservice can access the preset cache database using the key generated based on the user identifier to obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then let the back-end microservice pass the access response information to the independent microservice for processing. In this way, the efficiency of token synchronization between microservices is improved during the microservice-based token synchronization process, thereby improving the speed and security of the production process. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0050] Figure 1 This is a flow chart of a microservice-based token synchronization method disclosed in this application;

[0051] Figure 2 A schematic diagram of an original microservice architecture disclosed in this application;

[0052] Figure 3 This is a schematic diagram of an architecture diagram after introducing microservice components into an original microservice architecture disclosed in this application;

[0053] Figure 4 This is a schematic diagram of a specific backend microservice token refresh process disclosed in this application;

[0054] Figure 5 This is a specific timing diagram of calling an independent microservice component disclosed in this application;

[0055] Figure 6 This is a timing diagram of a specific front-end microservice disclosed in this application obtaining a second token obtained after the back-end microservice refreshes;

[0056] Figure 7 This is a schematic diagram of the structure of a microservice-based token synchronization device disclosed in this application;

[0057] Figure 8 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0058] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0059] The microservice architecture consists of front-end microservices and back-end microservices. The front-end microservice is responsible for providing user interaction interfaces, while the back-end microservice implements the system's core business logic. Currently, a new independent microservice needs to be added to the current microservice architecture to provide new functionality. To use it, the user must first launch the independent microservice through the front-end microservice and then invoke the new functionality through the independent microservice. During the launch, the front-end microservice sends its authentication token to the independent microservice, allowing the independent microservice to access the back-end microservice with the token and obtain all the parameters required to execute the new functionality. However, after being launched by the front-end microservice, the independent microservice retains the token originally shared with it by the front-end microservice. For security reasons, the token has a validity period. After the expiration of the token, the user must re-login. To reduce the number of times users need to re-login, the front-end microservice checks the token's remaining time before expiration each time it accesses the back-end microservice, significantly impacting the system's user experience. To this end, the present application provides a microservice-based token synchronization method, which can improve the efficiency of token synchronization between microservices in the microservice-based token synchronization process, thereby improving the speed and security of the production process.

[0060] See also Figure 1 As shown, an embodiment of the present invention discloses a token synchronization method based on microservices, which is applied to backend microservices, including:

[0061] Step S11: Filter each access request using a token filter to obtain a target request including a first token for performing permission authentication, and then parse the target request to obtain a token expiration time corresponding to the first token.

[0062] In this embodiment, the schematic diagram of the original microservice architecture is as follows: Figure 2 As shown in the figure: Users operate the application through the front-end microservices, where the application is composed of front-end microservices and back-end microservices. The architecture diagram after the introduction of microservice components is as follows Figure 3 As shown: Users pull up independent microservices through the front-end microservices, and then call new functions through the independent microservices.

[0063] Furthermore, the process diagram of backend microservice refreshing token (ie token) is as follows Figure 4As shown in the following example: First, a token filter is created in the backend microservice. This filter intercepts all incoming access requests and filters out those that require a token refresh. Specifically, the filter checks whether the request contains a token. If not, the request does not require authentication, such as a login request. The request is then directly allowed. If the request contains a token, further filtering is performed and the token is parsed to determine the current token's expiration date. Specifically, using a token filter to filter each access request to obtain a target request including a first token for permission authentication, and then parsing the target request to obtain a token expiration time corresponding to the first token, can include: configuring a token filter in the backend microservice to use the token filter to determine whether each access request sent to the backend microservice includes a token according to a preset request filtering rule; if the access request does not include a token, the access request is determined to be a request that does not require permission authentication, and the access request is released to perform a login operation or a public interface call operation based on the access request; if the access request includes a token, the access request is determined to be a request that requires permission authentication, the access request is set as a target request, and a signature legitimacy verification operation is performed on the target request to obtain a verification result; if the verification result indicates that the verification fails, an exception response is generated, and the exception response is returned to the request initiator; if the verification result indicates that the verification passes, the target request is parsed to obtain a token expiration time corresponding to the first token.

[0064] Step S12: Determine whether the current time exceeds the token expiration time. If not, determine the remaining valid duration based on the token expiration time and the current time, and determine whether the remaining valid duration is greater than the target duration threshold. If not, check whether there is a token refresh flag in the preset cache database. If not, set the token refresh flag in the preset cache database.

[0065] In this embodiment, after obtaining the expiration time corresponding to the current token, the embodiment of the present application needs to compare the current time with the expiration time of the token. If the current time has exceeded the token expiration time, it means that the token has expired. At this time, the request is directly released to generate the exception information of "token expired" using the subsequent logic and return it to the initiator of the request, so that the initiator of the request can perform the exception processing of "requiring the user to log in again" after receiving the exception information. In addition, if the current time does not exceed the token expiration time, proceed to the next step of judgment. First, the remaining valid time corresponding to the token is determined based on the calculation formula of the remaining valid time of the token, and the expression is as follows:

[0066] The remaining validity time of the token = the expiration time of the token - the current time;

[0067] Then, after obtaining the remaining validity time of the token, the embodiment of the present application needs to compare the remaining validity time of the token with the validity period corresponding to the token. In a specific embodiment, if the remaining validity time corresponding to the token is greater than half of the validity period corresponding to the token, there is no need to refresh the token and it can be directly released. Otherwise, the token needs to be refreshed. Subsequently, after the above process, a request for refreshing the token can be obtained. Subsequently, the embodiment of the present application can use the token corresponding to the request for refreshing the token as a parameter, and then use the above parameters to access the interface for refreshing the token to obtain a new token.

[0068] Specifically, judging whether the current time exceeds the token expiration time, and if not, determining the remaining valid time based on the token expiration time and the current time, and judging whether the remaining valid time is greater than the target time threshold, may include: determining the total valid time of the first token based on the user authority level and the system security policy, and determining the target time threshold based on a preset ratio and the total valid time; wherein, the user authority level corresponding to the user is positively correlated with the total valid time; judging whether the current time exceeds the token expiration time, and if the current time does not exceed the token expiration time, determining the remaining valid time based on the token expiration time and the current time, and judging whether the remaining valid time is greater than the target time threshold; if the remaining valid time is greater than the target time threshold, judging that the first token does not need to be refreshed, and judging that the request corresponding to the first token meets the release condition, directly releasing the request corresponding to the first token, and maintaining the valid state of the first token.

[0069] It's worth noting that to prevent a large number of requests carrying soon-to-expire tokens from concurrently accessing the backend microservice, which could cause the backend microservice to repeatedly refresh invalid tokens, this embodiment of the application first checks the Redis (Remote Dictionary Server) database for a token refresh flag each time a token is refreshed. If so, the request is allowed without refreshing the token.

[0070] Specifically, checking whether there is a token refresh flag in the preset cache database, if not, setting the token refresh flag in the preset cache database, can include: checking whether there is a token refresh flag in the preset cache database, if the token refresh flag does not exist in the preset cache database, counting the total number of requests that currently require a token refresh operation; judging whether the total number of requests is greater than one, if the total number of requests is greater than one, using the atomic operation in the preset cache database to lock the setting permission of the token refresh flag, and monitoring the request status corresponding to each target request, and then performing a token refresh flag configuration operation on the first target request that is monitored to succeed, to obtain the corresponding token refresh flag; when it is detected that the token refresh flag already exists, releasing the remaining target requests, and using the first token to perform permission verification on each target request.

[0071] Step S13: perform a token refresh operation based on the token refresh flag, store the obtained second token in the preset cache database, and then send the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using the login information determined based on the second token.

[0072] In this embodiment, if the token refresh flag does not exist in the Redis database, a flag indicating that the token is being refreshed, i.e., the token refresh flag, is added to the Redis database, and then the token refresh operation is performed based on the token refresh flag. After the token refresh operation is completed, the refreshed token, i.e., the second token, is stored in the Redis database, and the second token is passed to the front-end microservice via WebSocket. It is worth mentioning that after refreshing the first token to obtain the second token, the embodiment of the present application needs to delete the token refresh flag in the Redis database. Furthermore, since refreshing the token takes a certain amount of time, when refreshing the token, other concurrent requests have been released, and the next access request to the back-end microservice will carry the latest token after the refresh.

[0073] It is worth mentioning that the timing diagram for calling independent microservice components is as follows Figure 5 As shown: First, the user fills out a login form on the front-end microservice's corresponding login page. The front-end microservice then sends the login information to the back-end microservice via an API request. After the back-end microservice verifies the login information, it obtains a token, or second token, which includes the user ID (identifier) and an expiration date. The back-end microservice can then store the second token in a Redis database as a key-value pair. The specific format of the key-value pair is: auth:token:user_{user ID}, and the value is the second token generated by the back-end microservice.

[0074] Subsequently, the timing diagram of the front-end microservice obtaining the second token obtained after the back-end microservice refreshes is as follows Figure 6 As shown: First, the front-end microservice needs to apply to establish a WebSocket connection with the back-end microservice. After the back-end microservice agrees to establish a WebSocket connection with the front-end microservice, a persistent and stable two-way communication channel can be established between the front-end microservice and the back-end microservice. Subsequently, the back-end microservice performs a refresh operation on the second token, obtains the second token, and feeds back the refreshed second token to the front-end microservice via WebSocket, so that after receiving the WebSocket message, the front-end microservice extracts the second token from it and overwrites the original cached first token with the second token. In this way, the token in the corresponding request of the front-end microservice to access the back-end microservice is the second token.

[0075] Specifically, a token refresh operation is performed based on the token refresh flag, and the obtained second token is stored in a preset cache database, and then the second token is sent to the front-end microservice so that the front-end microservice can access the back-end microservice using the login information determined based on the second token. It can include: performing a token refresh operation based on the token refresh flag, obtaining the second token, and storing the second token in a preset cache database, and then releasing the lock state of the token refresh flag; after receiving the communication connection request carrying the service identifier sent by the front-end microservice, verifying the legitimacy of the service identifier, and assigning an independent communication session identifier to the front-end microservice after the verification is passed, and then Then, a two-way communication link is established with the front-end microservice based on the communication session identifier; the service identifier is used to distinguish each front-end microservice instance; a response message is sent to the front-end microservice according to a preset detection time interval. If no response message is received from the front-end microservice when the current number of transmissions is not less than the preset transmission number threshold, the two-way communication link is closed and the process jumps to the step of verifying the legitimacy of the service identifier after receiving the communication connection request carrying the service identifier issued by the front-end microservice; the second token is sent to the front-end microservice through the two-way communication link, so that the front-end microservice determines the login information based on the second token and accesses the back-end microservice based on the login information.

[0076] It is worth mentioning that the backend microservice needs to return a successful login response signal and response information including the second token to the frontend microservice. After receiving the successful login response signal, the frontend microservice extracts the second token from the response information and caches it so that the frontend microservice can send a request to the backend microservice with the second token. The backend microservice will only return information to the frontend microservice after the authentication token is passed. Subsequently, the frontend microservice is called to jump to the system homepage through the login page and return the system homepage to the current user interface so that the user can enter the system.

[0077] Step S14: Call the independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice can access the preset cache database using a key generated based on the user identifier, and obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then instruct the back-end microservice to pass the access response information to the independent microservice for processing.

[0078] In this embodiment, after a user enters the system through the homepage, they can find the independent microservice entry in the front-end microservice menu and click the button to call the independent microservice. Furthermore, the front-end microservice shares the first token with the independent microservice, allowing the independent microservice to parse the first token and obtain the current operating user ID. Based on the user ID, the independent microservice generates a key: auth:token:user_{userId}. The key is then used to access the Redis database to retrieve the second token generated for the current operating user by the back-end microservice. Specifically, calling an independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier so that the independent microservice can access a preset cache database using a key generated based on the user identifier to obtain a second token can include: after receiving an independent microservice trigger instruction issued by the user through the operation interface of the front-end microservice, calling the front-end microservice to use a secure transmission protocol to pass the first token to the independent microservice, so that the front-end microservice will send the initialization parameters of the independent microservice page corresponding to the independent microservice determined based on the independent microservice trigger instruction and the first token to the independent microservice; calling the independent microservice to decrypt and perform integrity verification on the first token in the initialization parameters. If the verification result indicates that the verification failed, the service is refused and a token invalid prompt message is returned. If the verification result indicates that the verification passed, the user identifier in the first token is parsed to obtain a key corresponding to the user identifier, and the key is bound to the operation session of the independent microservice to obtain a binding result, so as to use the binding result to preset a cache database to obtain a second token.

[0079] Furthermore, after the independent microservice obtains the second token, it can access the back-end microservice based on the second token to obtain the information required to provide the service, and the process is as follows: the back-end microservice must first verify the second token, and after the verification is passed, it generates a response message containing the information requested by the independent microservice, and returns the response message to the independent microservice. Subsequently, the independent microservice can extract the response information and process it based on the extracted information, and finally return the processing result to the user to implement the response operation to the user operation.

[0080] Specifically, calling an independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier so that the independent microservice can access a preset cache database using a key generated based on the user identifier to obtain a second token so that the independent microservice can access a back-end microservice based on the second token, and then instructing the back-end microservice to pass the access response information to the independent microservice for processing, which may include: calling an independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier so that the independent microservice can splice the user identifier, the preset prefix character and the fixed separator in a preset splicing order to obtain a key; wherein the preset prefix character is used to distinguish token storage areas for different business scenarios; using the key to perform a historical token record query operation on the preset cache database, if the preset cache database contains a record corresponding to the key, If there are several historical token records, they are sorted in reverse order according to the order of the token generation timestamps corresponding to each historical token record, and the token with the latest timestamp in the sorting result is set as the second token; if there is no historical token record corresponding to the key in the preset cache database, a token reissue request is initiated to the back-end microservice, and the token entry in the preset cache database is updated after receiving the token issued by the back-end microservice; after the independent microservice obtains the second token, it calls the independent microservice to embed the second token into the header information of the request, and determines whether the remaining valid time of the second token is less than the target time threshold each time the back-end microservice is accessed. If the remaining valid time of the second token is less than the target time threshold, jump to the step of checking whether there is a token refresh flag in the preset cache database.

[0081] As can be seen from the above, the embodiment of the present application first needs to use a token filter to filter each access request to obtain a target request including a first token for permission authentication, and then parse the target request to obtain the token expiration time corresponding to the first token; then, determine whether the token expiration time is less than the current time. If it is less than, determine the remaining valid time based on the token expiration time and the current time, and determine whether the remaining valid time is greater than the target time threshold. If it is not greater than, check whether there is a token refresh flag in the preset cache database. If not, set the token refresh flag in the preset cache database; then, perform a token refresh operation based on the token refresh flag, and store the obtained second token in the preset cache database, and then send the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using the login information determined based on the second token; finally, call the independent microservice to parse the first token issued by the front-end microservice to obtain the user identifier, so that the independent microservice can access the preset cache database using the key generated based on the user identifier to obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then let the back-end microservice pass the access response information to the independent microservice for processing. In this way, the efficiency of token synchronization between microservices is improved during the microservice-based token synchronization process, thereby improving the speed and security of the production process.

[0082] Accordingly, see Figure 7 As shown, the present application also provides a microservice-based token synchronization device, which is applied to backend microservices, including:

[0083] A token expiration time determination module 11 is configured to filter each access request using a token filter to obtain a target request including a first token for performing permission authentication, and then parse the target request to obtain a token expiration time corresponding to the first token;

[0084] The remaining effective duration determination module 12 is configured to determine whether the current time exceeds the token expiration time. If not, the remaining effective duration is determined based on the token expiration time and the current time, and whether the remaining effective duration is greater than a target duration threshold. If not, the module checks whether a token refresh flag exists in a preset cache database. If not, the module sets a token refresh flag in the preset cache database.

[0085] A token refresh module 13 is configured to perform a token refresh operation based on the token refresh flag, store the obtained second token in the preset cache database, and then send the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using login information determined based on the second token;

[0086] The information transmission module 14 is used to call the independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice can use the key generated based on the user identifier to access the preset cache database, obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then instruct the back-end microservice to pass the access response information to the independent microservice for processing.

[0087] It can be seen that the embodiment of the present application first needs to use a token filter to filter each access request to obtain a target request including a first token for permission authentication, and then parse the target request to obtain the token expiration time corresponding to the first token; then, determine whether the token expiration time is less than the current time. If it is less, determine the remaining valid time based on the token expiration time and the current time, and determine whether the remaining valid time is greater than the target time threshold. If it is not greater, check whether there is a token refresh flag in the preset cache database. If not, set the token refresh flag in the preset cache database; then, perform a token refresh operation based on the token refresh flag, and store the obtained second token in the preset cache database, and then send the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using the login information determined based on the second token; finally, call the independent microservice to parse the first token issued by the front-end microservice to obtain the user identifier, so that the independent microservice can access the preset cache database using the key generated based on the user identifier to obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then let the back-end microservice pass the access response information to the independent microservice for processing. In this way, the efficiency of token synchronization between microservices is improved during the microservice-based token synchronization process, thereby improving the speed and security of the production process.

[0088] In some specific implementations, the token expiration time determination module 11 may specifically include:

[0089] An access request judgment unit, configured to configure a token filter in the backend microservice, so as to use the token filter to judge whether each access request sent to the backend microservice includes a token according to a preset request filtering rule;

[0090] a first request release unit, configured to, if the access request does not include a token, determine that the access request is a request that does not require authorization authentication, and release the access request, so as to perform a login operation or a public interface call operation based on the access request;

[0091] a request verification unit, configured to, if the access request includes a token, determine that the access request is a request requiring authorization authentication, set the access request as a target request, and perform a signature legitimacy verification operation on the target request to obtain a verification result;

[0092] The request parsing unit is used to generate an exception response if the verification result indicates that the verification has failed, and return the exception response to the request initiator; if the verification result indicates that the verification has passed, parse the target request to obtain the token expiration time corresponding to the first token.

[0093] In some specific implementations, the remaining effective duration determination module 12 may specifically include:

[0094] a duration threshold determination unit, configured to determine a total validity duration of the first token based on a user authority level and a system security policy, and to determine a target duration threshold based on a preset ratio and the total validity duration; wherein the user authority level corresponding to the user is positively correlated with the total validity duration;

[0095] a remaining valid duration determining unit, configured to determine whether the current time exceeds the token expiration time; if the current time does not exceed the token expiration time, determine the remaining valid duration based on the token expiration time and the current time, and determine whether the remaining valid duration is greater than the target duration threshold;

[0096] The second request release unit is used to determine that the first token does not need to be refreshed if the remaining valid duration is greater than the target duration threshold, and to determine that the request corresponding to the first token meets the release conditions, directly release the request corresponding to the first token, and maintain the valid state of the first token.

[0097] In some specific implementations, the remaining effective duration determination module 12 may specifically include:

[0098] A request quantity counting unit is used to check whether there is a token refresh flag in the preset cache database, and if there is no token refresh flag in the preset cache database, count the total number of requests that currently require a token refresh operation;

[0099] a token refresh flag acquisition unit, configured to determine whether the total number of requests is greater than one; if the total number of requests is greater than one, locking the setting permission of the token refresh flag by using an atomic operation in the preset cache database, monitoring the request status corresponding to each target request, and then performing a token refresh flag configuration operation on the first target request that is successfully monitored to obtain a corresponding token refresh flag;

[0100] The request permission verification unit is used to release the remaining target requests when detecting that the token refresh flag exists, and use the first token to perform permission verification on each target request.

[0101] In some specific implementations, the token refresh module 13 may specifically include:

[0102] A token storage unit, configured to perform a token refresh operation based on the token refresh flag, obtain a second token, store the second token in a preset cache database, and then release the locked state of the token refresh flag;

[0103] a communication link establishing unit configured to, upon receiving a communication connection request carrying a service identifier from the front-end microservice, verify the legitimacy of the service identifier, assign an independent communication session identifier to the front-end microservice after the verification is successful, and then establish a bidirectional communication link with the front-end microservice based on the communication session identifier; the service identifier is used to distinguish between front-end microservice instances;

[0104] a response information sending unit, configured to send a response message to the front-end microservice according to a preset detection time interval, and if no response message is received from the front-end microservice when the current number of transmissions is not less than a preset transmission number threshold, close the bidirectional communication link and jump to the step of verifying the legitimacy of the service identifier after receiving the communication connection request carrying the service identifier from the front-end microservice;

[0105] The token issuing unit is used to issue the second token to the front-end microservice through the bidirectional communication link, so that the front-end microservice determines login information based on the second token and accesses the back-end microservice based on the login information.

[0106] In some specific implementations, the information transmission module 14 may specifically include:

[0107] an instruction receiving unit, configured to, after receiving an independent microservice trigger instruction issued by a user through an operation interface of the front-end microservice, call the front-end microservice to transmit the first token to the independent microservice using a secure transmission protocol, so that the front-end microservice can send initialization parameters of an independent microservice page corresponding to the independent microservice, which are determined based on the independent microservice trigger instruction and the first token, to the independent microservice;

[0108] The first independent microservice calling unit is used to call the independent microservice to decrypt and verify the integrity of the first token in the initialization parameter. If the verification result indicates that the verification failed, the service is refused and a token invalid prompt message is returned. If the verification result indicates that the verification passed, the user identifier in the first token is parsed to obtain a key corresponding to the user identifier, and the key is bound to the operation session of the independent microservice to obtain a binding result, so as to use the binding result to obtain the second token in the preset cache database.

[0109] In some specific implementations, the information transmission module 14 may specifically include:

[0110] a second independent microservice calling unit, configured to call the independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice can concatenate the user identifier, a preset prefix character, and a fixed separator in a preset concatenation order to obtain a key; wherein the preset prefix character is used to distinguish token storage areas for different business scenarios;

[0111] a token record query unit, configured to perform a historical token record query operation on the preset cache database using the key, and if there are a plurality of historical token records corresponding to the key in the preset cache database, sort the historical token records in reverse order according to the order of token generation timestamps corresponding to the historical token records, and set the token with the latest timestamp in the sorting result as the second token;

[0112] A token reissue request initiating unit, configured to initiate a token reissue request to the backend microservice if there is no historical token record corresponding to the key in the preset cache database, and update the token entry in the preset cache database after receiving the token issued by the backend microservice;

[0113] The third independent microservice calling unit is used to call the independent microservice to embed the second token into the header information of the request after the independent microservice obtains the second token, and determine whether the remaining valid time of the second token is less than the target time threshold each time the backend microservice is accessed. If the remaining valid time of the second token is less than the target time threshold, jump to the step of checking whether there is a token refresh flag in the preset cache database.

[0114] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 8This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram should not be considered as any limitation on the scope of use of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the microservice-based token synchronization method disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0115] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0116] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or CD, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0117] The operating system 221 is used to manage and control the hardware devices and computer program 222 on the electronic device 20, and can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of implementing the microservice-based token synchronization method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program capable of completing other specific tasks.

[0118] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when executed by a processor, the computer program implements the aforementioned disclosed microservice-based token synchronization method. The specific steps of this method can be referred to the corresponding content disclosed in the aforementioned embodiments and will not be repeated here.

[0119] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0120] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0121] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0122] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0123] The above is a detailed introduction to the technical solution provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A token synchronization method based on microservices, characterized in that: Applied to backend microservices, including: Filtering each access request using a token filter to obtain a target request including a first token for performing authority authentication, and then parsing the target request to obtain a token expiration time corresponding to the first token; Determine whether the current time exceeds the token expiration time; if not, determine the remaining valid duration based on the token expiration time and the current time, and determine whether the remaining valid duration is greater than a target duration threshold; if not, check whether there is a token refresh flag in a preset cache database; if not, set the token refresh flag in the preset cache database; Performing a token refresh operation based on the token refresh flag, storing the obtained second token in the preset cache database, and then sending the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using the login information determined based on the second token; The independent microservice is called to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice can access the preset cache database using a key generated based on the user identifier, and obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then the back-end microservice will pass the access response information to the independent microservice for processing.

2. The token synchronization method based on microservices according to claim 1, characterized in that: The token filter is used to filter each access request to obtain a target request including a first token for authorization authentication, and then the target request is parsed to obtain a token expiration time corresponding to the first token, including: Configuring a token filter in the backend microservice to use the token filter to determine whether each access request sent to the backend microservice includes a token according to preset request filtering rules; If the access request does not include a token, determining that the access request is a request that does not require authorization authentication, and allowing the access request to perform a login operation or a public interface call operation based on the access request; If the access request includes a token, the access request is determined to be a request that requires authorization authentication, the access request is set as a target request, and a signature legitimacy verification operation is performed on the target request to obtain a verification result; If the verification result indicates that the verification has failed, an exception response is generated and returned to the request initiator. If the verification result indicates that the verification has passed, the target request is parsed to obtain the token expiration time corresponding to the first token.

3. The token synchronization method based on microservices according to claim 1, characterized in that: The determining whether the current time exceeds the token expiration time, and if not, determining the remaining valid duration based on the token expiration time and the current time, and determining whether the remaining valid duration is greater than a target duration threshold, includes: Determining a total validity period of the first token based on the user authority level and the system security policy, and determining a target validity period threshold based on a preset ratio and the total validity period; wherein the user authority level corresponding to the user is positively correlated with the total validity period; Determine whether the current time exceeds the token expiration time; if the current time does not exceed the token expiration time, determine the remaining valid duration based on the token expiration time and the current time, and determine whether the remaining valid duration is greater than the target duration threshold; If the remaining valid duration is greater than the target duration threshold, it is determined that the first token does not need to be refreshed, and it is determined that the request corresponding to the first token meets the release conditions, the request corresponding to the first token is directly released, and the valid status of the first token is maintained.

4. The token synchronization method based on microservices according to claim 1, characterized in that: The step of checking whether a token refresh flag exists in a preset cache database, and if not, setting a token refresh flag in the preset cache database, includes: Check whether there is a token refresh flag in the preset cache database. If there is no token refresh flag in the preset cache database, count the total number of requests that currently require a token refresh operation; Determine whether the total number of requests is greater than one. If the total number of requests is greater than one, use the atomic operation in the preset cache database to lock the setting permission of the token refresh flag, monitor the request status corresponding to each target request, and then perform a token refresh flag configuration operation on the first target request that is successfully monitored to obtain a corresponding token refresh flag; When it is detected that the token refresh flag exists, the remaining target requests are released, and the first token is used to perform permission verification on each target request.

5. The token synchronization method based on microservices according to claim 4, characterized in that: The method of performing a token refresh operation based on the token refresh flag, storing the obtained second token in the preset cache database, and then sending the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using login information determined based on the second token, includes: Performing a token refresh operation based on the token refresh flag to obtain a second token, storing the second token in a preset cache database, and then releasing the locking state of the token refresh flag; After receiving the communication connection request carrying the service identifier issued by the front-end microservice, the legitimacy of the service identifier is verified, and after the verification is passed, an independent communication session identifier is allocated to the front-end microservice, and then a two-way communication link is established between the front-end microservice and the front-end microservice based on the communication session identifier; the service identifier is used to distinguish each front-end microservice instance; Sending a response message to the front-end microservice at a preset detection time interval; if no response message from the front-end microservice is received when the current number of transmissions is not less than a preset transmission number threshold, closing the bidirectional communication link and jumping to the step of verifying the legitimacy of the service identifier after receiving the communication connection request carrying the service identifier from the front-end microservice; The second token is sent to the front-end microservice through the bidirectional communication link, so that the front-end microservice determines login information based on the second token and accesses the back-end microservice based on the login information.

6. The token synchronization method based on microservices according to claim 1, characterized in that: The calling of the independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice uses a key generated based on the user identifier to access the preset cache database to obtain the second token, including: After receiving the independent microservice trigger instruction issued by the user through the operation interface of the front-end microservice, calling the front-end microservice to pass the first token to the independent microservice using a secure transmission protocol, so that the front-end microservice sends the initialization parameters of the independent microservice page corresponding to the independent microservice determined based on the independent microservice trigger instruction and the first token to the independent microservice; The independent microservice is called to decrypt and integrity check the first token in the initialization parameter. If the verification result indicates that the verification fails, the service is refused and a token invalid prompt message is returned. If the verification result indicates that the verification passes, the user identifier in the first token is parsed to obtain a key corresponding to the user identifier, and the key is bound to the operation session of the independent microservice to obtain a binding result, so as to use the binding result to obtain the preset cache database to obtain the second token.

7. The microservice-based token synchronization method according to any one of claims 1 to 6, characterized in that: The calling independent microservice parses the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice uses a key generated based on the user identifier to access the preset cache database, obtains the second token, so that the independent microservice accesses the back-end microservice based on the second token, and then causes the back-end microservice to pass access response information to the independent microservice for processing, including: Calling the independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice can concatenate the user identifier, the preset prefix character, and the fixed separator in a preset concatenation order to obtain a key; wherein the preset prefix character is used to distinguish token storage areas for different business scenarios; Perform a historical token record query operation on the preset cache database using the key. If there are several historical token records corresponding to the key in the preset cache database, sort the historical token records in reverse order according to the order of token generation timestamps corresponding to the historical token records, and set the token with the latest timestamp in the sorting result as the second token; If there is no historical token record corresponding to the key in the preset cache database, a token reissue request is initiated to the backend microservice, and after receiving the token issued by the backend microservice, the token entry in the preset cache database is updated; After obtaining the second token, the independent microservice calls the independent microservice to embed the second token into the header information of the request, and determines whether the remaining validity period of the second token is less than the target duration threshold each time the backend microservice is accessed. If the remaining validity period of the second token is less than the target duration threshold, the process jumps to the step of checking whether there is a token refresh flag in the preset cache database.

8. A token synchronization device based on microservices, characterized in that: Applied to backend microservices, including: a token expiration time determination module, configured to filter each access request using a token filter to obtain a target request including a first token for performing authority authentication, and then parse the target request to obtain a token expiration time corresponding to the first token; a remaining valid duration determination module, configured to determine whether the current time exceeds the token expiration time; if not, determine the remaining valid duration based on the token expiration time and the current time, and determine whether the remaining valid duration is greater than a target duration threshold; if not, check whether a token refresh flag exists in a preset cache database; if not, set the token refresh flag in the preset cache database; A token refresh module is configured to perform a token refresh operation based on the token refresh flag, store the obtained second token in the preset cache database, and then send the second token to the front-end microservice so that the front-end microservice can access the back-end microservice using login information determined based on the second token; The information transmission module is used to call the independent microservice to parse the first token issued by the front-end microservice to obtain a user identifier, so that the independent microservice can use the key generated based on the user identifier to access the preset cache database, obtain the second token, so that the independent microservice can access the back-end microservice based on the second token, and then instruct the back-end microservice to pass the access response information to the independent microservice for processing.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the microservice-based token synchronization method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that Used to store a computer program, wherein when the computer program is executed by a processor, the microservice-based token synchronization method according to any one of claims 1 to 7 is implemented.

Images