An authorization method, system, device and medium based on a micro-service architecture

Abstract

The application discloses a kind of authorization method, system, device and medium based on microservice architecture, comprising: receiving the first authorization request of client, decompose first authorization request and obtain business model parameter, obtain business classification, business belonging relationship and business history data according to business model parameter, determine whether there is business classification authorization script, business belonging authorization script and history access authorization script on gateway side, if gateway side exists verification authorization script set, business classification is substituted into business classification authorization script and carries out first layer authorization verification;Business belonging relationship is substituted into business belonging authorization script and carries out second layer authorization verification;Business history data is substituted into history access authorization script and carries out third layer authorization verification, if first layer authorization verification, second layer authorization verification and third layer authorization verification are all verified, return to client calling data.The present application can realize flexible authorization under fine-grained business scenario, and can be applied to microservice architecture technical field.

Description

Technical Field

[0001] This invention relates to the field of microservice architecture technology, and in particular to an authorization method, system, device and medium based on microservice architecture. Background Technology

[0002] In general system design and development, different functions rarely establish relationships due to differences in data structure and patterns. However, with the development of digitalization and artificial intelligence, the data relationships between different functions within and between systems have become more complex. Effective annotation can improve data quality and build more data relationships, supporting business expansion and fine-grained data processing capabilities. As application functions increase, the construction of more fine-grained data relationships can be based on authorization based on function and general affiliation. However, authorization based on function and general affiliation is not conducive to establishing scalable data business relationships, and the authorization granularity is inflexible and specific, affecting data sharing and exchange between systems and business integration. This leads to problems such as strong system constraints and insufficient scalability, and data security issues arise in fine-grained business scenarios, resulting in inadequate management and supervision. Summary of the Invention

[0003] To address one of the aforementioned problems, the present invention aims to provide an authorization method, system, device, and medium based on a microservice architecture, which can achieve flexible authorization in fine-grained business scenarios and improve the effectiveness of management and supervision.

[0004] On the one hand, this invention provides an authorization method based on a microservice architecture, comprising the following steps:

[0005] Receive the first authorization request from the client, decompose the first authorization request to obtain business model parameters, and obtain business classification, business affiliation and business history data based on the business model parameters;

[0006] Determine whether a set of verification and authorization scripts exists on the gateway side; the set of verification and authorization scripts includes service category authorization scripts, service-related authorization scripts, and historical access authorization scripts.

[0007] If the set of verification and authorization scripts exists on the gateway side, the service category is substituted into the service category authorization script for the first layer of authorization verification; the service affiliation is substituted into the service affiliation authorization script for the second layer of authorization verification; and the service historical data is substituted into the historical access authorization script for the third layer of authorization verification.

[0008] If the first layer of authorization verification, the second layer of authorization verification, and the third layer of authorization verification all pass the verification, the call data is returned to the client.

[0009] Optionally, determining whether a set of verification and authorization scripts exists on the gateway side specifically includes:

[0010] The business category, the business affiliation, and the business history data are substituted into a preset expression for matching. If a key-value pair of the business category authorization script is matched, it is determined that the business category authorization script exists.

[0011] If a key-value pair of the authorization script to which the service belongs is matched, it is determined that the authorization script to which the service belongs exists;

[0012] If a key-value pair of a historical access authorization script is matched, it is determined that the historical access authorization script exists.

[0013] Optionally, if the set of verification and authorization scripts does not exist on the gateway side, the gateway side sends a second authorization request to the container group;

[0014] This enables the container group to generate the service category authorization script, the service to which the authorization script belongs, and the historical access authorization script based on the second authorization request;

[0015] The service classification authorization script, the service-related authorization script, and the historical access authorization script are returned to the gateway side.

[0016] Optionally, the second authorization request includes the business category, the business affiliation, and the business historical data; the container group generates the business category authorization script, the business affiliation authorization script, and the historical access authorization script based on the second authorization request, specifically including:

[0017] The business categories are identified to obtain the authorization configuration and first execution logic for the business categories. The authorization script for the business categories is generated based on the authorization configuration and first execution logic.

[0018] The business affiliation is identified to obtain the authorization configuration and second execution logic of the business affiliation. The authorization script of the business affiliation is generated based on the authorization configuration and the second execution logic.

[0019] The business history data is matched to obtain new business history data, and the new business history data is converted into the historical access authorization script.

[0020] Optionally, returning the service classification authorization script, the service-to-entry authorization script, and the historical access authorization script to the gateway side specifically includes:

[0021] The business category authorization script, the business-related authorization script, and the historical access authorization script are sorted and duplicate expressions in the script calls are removed. The results of the removal are then added to a queue.

[0022] The queue is serialized, and the serialized queue is returned to the gateway side.

[0023] Optionally, the service classification authorization script, the service-related authorization script, and the historical access authorization script are cached on the gateway side in the form of a buffer stack.

[0024] On the other hand, the present invention provides an authorization system based on a microservice architecture, including a gateway traffic splitting module and a gateway authorization module, wherein,

[0025] The gateway traffic splitting module is used to receive the first authorization request from the client, decompose the first authorization request to obtain business model parameters, and obtain business classification, business affiliation and business historical data based on the business model parameters;

[0026] The gateway authorization module is used to determine whether a set of verification authorization scripts exists on the gateway side. The set of verification authorization scripts includes a service category authorization script, a service affiliation authorization script, and a historical access authorization script. If the set of verification authorization scripts exists on the gateway side, the service category is substituted into the service category authorization script for first-level authorization verification; the service affiliation is substituted into the service affiliation authorization script for second-level authorization verification; the historical service data is substituted into the historical access authorization script for third-level authorization verification; if the first-level authorization verification, the second-level authorization verification, and the third-level authorization verification all pass, the call data is returned to the client.

[0027] Optionally, the system further includes a parsing and generation module, which is used to send a second authorization request to the container group if the verification and authorization script set does not exist on the gateway side.

[0028] The container group generates the business category authorization script, the business to which the authorization script belongs, and the historical access authorization script based on the second authorization request;

[0029] The service classification authorization script, the service-related authorization script, and the historical access authorization script are returned to the gateway side.

[0030] Optionally, the gateway authorization module includes a plugin execution unit, which is used to cache the returned business category authorization script, the business-to-entry authorization script, and the historical access authorization script in the gateway authorization module in the form of a buffer stack.

[0031] On the other hand, the present invention provides an authorization device based on a microservice architecture, comprising:

[0032] At least one processor;

[0033] At least one memory for storing at least one program;

[0034] When the at least one program is executed by the at least one processor, the at least one processor performs the method described above.

[0035] On the other hand, the present invention provides a computer-readable storage medium storing a processor-executable program, which, when executed by a processor, is used to perform the methods described above.

[0036] Implementing this invention provides the following beneficial effects: Upon receiving a first authorization request from a client, the first authorization request is decomposed to obtain business model parameters. Based on these parameters, business categories, business affiliations, and historical business data are obtained. It is determined whether a set of verification authorization scripts exists on the gateway side. This set includes business category authorization scripts, business affiliation authorization scripts, and historical access authorization scripts. If such a set exists on the gateway side, the business category is substituted into the business category authorization script for first-level authorization verification. The business affiliation is substituted into the business affiliation authorization script for second-level authorization verification. Historical business data is substituted into the historical access authorization script for third-level authorization verification. If all three levels of authorization verification pass, the call data is returned to the client. By substituting the business category, business affiliation, and historical business data into different authorization scripts and executing different authorization logics, three levels of authorization verification are performed to obtain the business Pods participating in the business. This allows for better handling of data relationships, improved fine-grained data processing capabilities, and flexible authorization in fine-grained business scenarios, thereby enhancing management and supervision effectiveness. Attached Figure Description

[0037] Figure 1 This is a flowchart illustrating the steps of an authorization method based on a microservice architecture provided by the present invention.

[0038] Figure 2 This is a schematic diagram of a data structure for business classification, business affiliation, and business historical data provided by the present invention;

[0039] Figure 3 This invention provides a flowchart for substituting business model parameters into a preset expression to obtain relevant data;

[0040] Figure 4 This is a flowchart of the steps for generating an authorization script provided by the present invention;

[0041] Figure 5 This is a flowchart of the steps for generating an authorization script provided by the present invention;

[0042] Figure 6This is a flowchart of the steps for returning the authorization script to the gateway side provided by the present invention;

[0043] Figure 7 This is a schematic diagram of the structure of an authorization system based on a microservice architecture provided by the present invention;

[0044] Figure 8 This is a schematic diagram of another authorization system based on a microservice architecture provided by the present invention;

[0045] Figure 9 This is a system architecture diagram of Istio providing microservices provided by the present invention;

[0046] Figure 10 This is a schematic diagram of the structure of an authorization device based on a microservice architecture provided by the present invention. Detailed Implementation

[0047] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. The step numbers in the following embodiments are only for ease of explanation and do not limit the order of the steps. The execution order of each step in the embodiments can be adapted according to the understanding of those skilled in the art.

[0048] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the embodiments of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0049] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. In the description of this application, it should be understood that the terms "first / S100," "second / S200," "third / S300," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0050] To better understand the technical solution of the present invention, this embodiment uses the Istio service platform as an example for explanation and illustration.

[0051] Istio is an open-source service mesh platform, belonging to the cloud-native technology ecosystem. It aims to provide a unified, intelligent, and flexible method for connecting, monitoring, protecting, and controlling communication between services in a microservice architecture. Istio simplifies the deployment, scaling, and management of microservices, while providing advanced networking capabilities for developers and operations teams.

[0052] Business Model: This is a model built according to activities and stakeholder participation. It belongs to the data storage logic model and is a model built in a globally unified and standardized manner. Its main contents include activity code, creator, creation time, content, and secondary participation information.

[0053] like Figure 1-2 As shown, Figure 1 This is a flowchart illustrating the steps of an authorization method based on a microservice architecture. Figure 2 This invention provides a data structure diagram illustrating business classification, business affiliation, and historical business data. The method includes the following steps:

[0054] S100: Receive the first authorization request from the client, decompose the first authorization request to obtain business model parameters, and obtain business classification, business affiliation and business historical data based on the business model parameters.

[0055] Among them, such as Figure 2 As shown, business categories include, but are not limited to, category number, authorization mode, authorization affiliation, authorization role, and matching expression; business affiliation includes, but is not limited to, business number, participation method, participation function, participation role, and dual expression; business historical data includes, but is not limited to, business number, participant, participation method, participation frequency, and number expression.

[0056] Business model parameters include, but are not limited to, the business's identification number (i.e., the business's ID).

[0057] Specifically, the uplink data stream sent by the client (front-end page such as a browser) includes business data and a first authorization request. The first authorization request includes business model parameters. When the Istio gateway receives the uplink data, its gateway splitting module uses WASM technology to build a WASM plugin. This plugin splits the uplink data stream into business data and the first authorization request. The business data is sent along the original path to the designated business Pod for processing. The first authorization request is parsed to obtain the business model parameters. These parameters are then matched to obtain the business category, business affiliation, and historical business data. The gateway splitting module completes the dual-channel splitting processing of business data and the first authorization request, achieving layered processing. This effectively separates the processing of general capabilities and business data, simplifies business processing, and improves the system's scalability and security.

[0058] Matching based on business model parameters allows you to substitute these parameters into a preset expression and execute the expression to obtain business categories, business relationships, and historical business data. For example... Figure 3 As shown, Figure 3 This is a flowchart that substitutes business model parameters into a preset expression to obtain relevant data. Business model parameters, such as the business ID, are substituted into the preset expression. The execution logic of the preset expression can be to obtain the business category and result based on the business ID, and then obtain the participation path and historical data based on the business category. Participation paths include, but are not limited to, pattern participation and instance participation.

[0059] Based on the participation pattern, participants and category numbers are obtained. Based on the participants, authorization patterns are obtained, including but not limited to category participation and role participation. Based on the participation instance, business types and participation methods are obtained, including but not limited to process participation and invitation participation.

[0060] Based on historical data, if there is historical participation, determine whether the historical participation was disabled. If it was disabled, calculate the number of times it was disabled, determine whether the participation was successful, and if the participation was successful, determine the number of times the participation was successful, etc.

[0061] It is worth noting that, Figure 3 It is merely one feasible execution logic.

[0062] S200. Determine if a collection of verification and authorization scripts exists on the gateway side.

[0063] The collection of verification authorization scripts includes business category authorization scripts, business-specific authorization scripts, and historical access authorization scripts.

[0064] Specifically, the gateway caches preset expressions for matching scripts. Business categories, business relationships, and business history data are substituted into the preset expressions for execution. During execution, if a corresponding script exists, the corresponding execution result is returned, such as the corresponding key-value pair.

[0065] If the expression execution completes and returns a key-value pair of the business category authorization script, confirming the existence of the business category authorization script, then the business category authorization script is invoked to perform the first-level authorization verification.

[0066] If the key-value pair of the authorization script belonging to the business is returned, confirming the existence of the authorization script, then the authorization script belonging to the business is invoked to perform the second-level authorization verification.

[0067] If the key-value pair of the historical access authorization script is returned, confirming the existence of the historical access authorization script, then the historical access authorization script is invoked for third-level authorization verification.

[0068] S300a. If a set of authentication and authorization scripts exists on the gateway side, the business category is substituted into the business category authorization script for the first layer of authentication; the business affiliation is substituted into the business affiliation authorization script for the second layer of authentication; and the historical business data is substituted into the historical access authorization script for the third layer of authentication.

[0069] Specifically, if the gateway caches a business category authorization script, it calls the business category authorization script, substitutes the business category into the business category authorization script, executes the business category authorization script, and obtains the business Pod required to complete the business.

[0070] If the gateway caches the authorization script for the business, it calls the authorization script for the business, substitutes the business ownership relationship into the authorization script for the business, executes the authorization script for the business, and obtains the business Pod required to complete the business.

[0071] If the gateway caches historical access authorization scripts, it calls these scripts, substitutes historical business data into them, executes the scripts, and obtains the business Pods required to complete the business.

[0072] If the gateway does not have any of the above-mentioned authorization scripts, namely the business category authorization script, the business-related authorization script, and the historical access authorization script, the gateway can send a second authorization request to the corresponding Pod to generate the authorization script that does not exist on the gateway and return the generated authorization script to the gateway.

[0073] The first layer of authorization verification is defined based on the authorized role, focusing on the division of responsibilities among different users or system components; the second layer of authorization verification is defined according to the flow pattern, managing the process and state changes of activities; the third layer of authorization verification is defined based on historical access data, using past interaction records to optimize and adjust the current logical processing.

[0074] For the authorization scripts existing in the buffer, the gateway side loads the previously returned business category authorization script, business-related authorization script, and historical access authorization script by calling the wasm plugin. If the execution result is successful, the output obtained from executing the authorization script will be brought into the original path of the aforementioned business data. After passing the authorization verification, the same authorization process does not need to be authorized again. The plugin calls the output of the authorization script to complete the data integration by merging expressions and returns it to the client.

[0075] S400: If the first-level authorization verification, the second-level authorization verification, and the third-level authorization verification all pass the verification, return the call data to the client.

[0076] Specifically, if the first, second, and third layers of authorization verification all pass, several business Pods capable of performing the required business logic are generated. The gateway then flows data packets to these business Pods. These data packets may include, but are not limited to, business category, business affiliation, historical business data, and callback addresses. The business Pods execute callbacks via these data packets and return the resulting callback data to the browser, thus completing the corresponding business function. Each business Pod can perform calculations and store business data. Running independently as a microservice, each business Pod provides external call and callback interfaces. After verification, these interfaces allow for the invocation of relevant functions. For example, business data can be input into a business Pod, which then performs related calculations. The results are returned via these interfaces. In this way, multiple businesses can share the same business Pod, achieving Pod sharing.

[0077] In some embodiments, the above method may further include S500, automatic updating of authorization scripts. When the authorization logic of the container group changes, the corresponding business category authorization script, business-related authorization script and historical access authorization script are generated according to the changed authorization logic, and returned to the gateway side and cached on the gateway side. When the gateway side receives uplink data, it can perform authorization according to the above steps S100-S400.

[0078] After business data is sent along the original path to the designated business Pod for processing, and the data obtained and the data obtained through authorization verification are both returned to the gateway, the wasm plugin on the gateway side merges the data obtained from the two paths by calling a merge expression, and then returns the merged data to the client (caller).

[0079] In some embodiments, within the authorized Pod on the container group side, authorization expressions are constructed in a hierarchical manner, comprising three levels: business category, business affiliation, and business historical data. Each authorization expression handles the authorization logic related to business category, business affiliation, and business historical data, respectively. These authorization expressions can be called by the corresponding authorization scripts to complete the authorization process. The authorization logic is not an authentication process, but rather a process of obtaining the business Pod. Figure 4 As shown, Figure 4 This is a flowchart of the steps for generating an authorization script. Step S300 further includes step S300b, which specifically includes:

[0080] S310b If the gateway does not have a collection of authentication and authorization scripts, the gateway sends a second authorization request to the container group.

[0081] Specifically, if any authorization script in the set of verification authorization scripts does not exist on the gateway side, the gateway side sends a second authorization request to the container group to request the authorization Pod to return the non-existent authorization script.

[0082] The second authorization request may include, but is not limited to, business model parameters, business classification, business affiliation, and business historical data.

[0083] S320b, to enable the container group to generate a business category authorization script, a business ownership authorization script, and a history access authorization script based on the second authorization request.

[0084] After receiving the second authorization request, the authorized Pod in the container group parses the second authorization request to obtain business model parameters, business categories, business affiliations, and business historical data.

[0085] like Figure 5 As shown, Figure 5 This is a flowchart illustrating the steps for generating authorization scripts. In step S320b, the container group generates a business category authorization script, a business-related authorization script, and a historical access authorization script based on the second authorization request. Specifically, this includes:

[0086] S321b: Identify the business categories, obtain the authorization configuration and first execution logic of the business categories, and generate the business category authorization script based on the authorization configuration and first execution logic of the business categories.

[0087] The first execution logic is used to associate the category number, authorization mode, authorization affiliation, authorization role, and matching expression in the business category to obtain the business Pod that needs to be called to complete the corresponding business.

[0088] The business category authorization script can be a file containing business category authorization-related script programs and expression programs, which can call each other.

[0089] Specifically, the Pod is authorized to identify the business category and obtain the authorization configuration and first execution logic corresponding to the business category. The authorization configuration and first execution logic corresponding to the business category can be dynamically changed. When they change, the aforementioned step S500 can be actively executed to generate expression programs and script programs according to the authorization configuration and first execution logic.

[0090] S322b: Identify the business affiliation relationship, obtain the authorization configuration and second execution logic of the business affiliation relationship, and generate the business affiliation authorization script based on the authorization configuration and second execution logic of the business affiliation relationship.

[0091] The second execution logic is used to execute and transform the business number, participation path, participation function point, participation role and double expression in the business relationship to obtain a part of the business Pods that need to be called to complete the corresponding business.

[0092] The authorization script for a business can be a file containing scripts and expressions related to the authorization of that business.

[0093] Specifically, the Pod is authorized to identify the business affiliation, obtain the authorization configuration and second execution logic of the business affiliation, and generate scripts and expressions related to the business affiliation authorization according to the authorization configuration and second execution logic of the business affiliation.

[0094] S323b: Match the historical business data to obtain new historical business data, and convert the new historical business data into a historical access authorization script.

[0095] The authorization script for a business can be a file containing scripts and expressions related to the authorization of that business.

[0096] Specifically, the authorized Pod identifies and matches historical business data, transforms historical business data that has been transferred or involved in special ways into new historical business data, and matches scripts and expressions related to historical access authorization in the authorized Pod based on the new historical business data.

[0097] In some embodiments, for services that cannot be adapted to the authorization script to which the service belongs, the specific participants and participation methods are located based on the historical data of the service, and the historical access authorization script is generated using the service number, participation frequency and direct participant relationship data as the execution logic.

[0098] In some embodiments, if the authorization logic of any layer of authorization verification changes, the corresponding steps S321b, S322b, or S323b are executed according to the changed authorization logic, and the resulting script program and expression program are returned to the gateway side. For example, if the first execution logic changes, step S321b is executed to obtain the expression program and script program related to service classification authorization, and the expression program and script program related to service classification authorization are returned to the gateway side to replace the original expression program and script program related to service classification authorization on the gateway side, i.e., the update process of the aforementioned step S500.

[0099] In some embodiments, if the authorization logic changes, the authorization Pod sends an update command to the gateway to notify the gateway to update the authorization script. The update command may include, but is not limited to, the changed authorization logic.

[0100] If the gateway responds to the update command, the corresponding steps in steps S321b, S322b, or S323b are executed according to the changed authorization logic. If the gateway does not respond to the update command, the update policy is not executed.

[0101] S330b returns the service category authorization script, the service-related authorization script, and the historical access authorization script to the gateway side.

[0102] Specifically, when the gateway sends the second authorization request to the container group for the first time, it can directly execute the business classification authorization script, the business ownership authorization script, and the historical access authorization script in the authorized Pod, and return the obtained business Pod address, business classification authorization script, business ownership authorization script, and historical access authorization script to the gateway.

[0103] Alternatively, the business classification authorization script, the business-to-business authorization script, and the historical access authorization script can be returned to the gateway side, which will then execute these scripts to perform first-level authorization, second-level authorization, and third-level authorization.

[0104] After the authorized Pod returns the business category authorization script, the business-related authorization script, and the historical access authorization script to the gateway, the plugin execution unit on the gateway can cache the returned business category authorization script, the business-related authorization script, and the historical access authorization script in a buffer stack on the gateway. When receiving uplink data again, the gateway can directly call the business category authorization script, the business-related authorization script, and the historical access authorization script to perform three-level authorization without having to send a second authorization request to the authorized Pod again.

[0105] By caching the relevant authorization scripts on the gateway side using the S310b-S330b methods, a second authorization verification can be performed quickly using the authorization script after the first authorization verification is completed, thereby improving response speed and processing efficiency. Dynamic calls on the gateway side enable the reusability and scalability of the system.

[0106] In some embodiments, such as Figure 6 As shown, Figure 6 This is a flowchart of the steps to return the authorization script to the gateway. Step S330b returns the activity classification authorization script, the activity's associated authorization script, and the historical access authorization script to the gateway, specifically including:

[0107] S331b: Sort the activity category authorization script, the activity-related authorization script, and the historical access authorization script, and remove duplicate expressions from the script calls. Add the result of the removal to the queue.

[0108] Specifically, the expression programs related to business classification authorization, business-related authorization, and historical access authorization are integrated. The expression programs are sorted according to the most recent access authorization, duplicate expression programs are removed, and the remaining expression programs and script programs after removing duplicate expression programs are added to the queue.

[0109] S332b: Serialize the queue and return the serialized queue to the gateway.

[0110] Specifically, the expression programs and script programs in the queue are serialized, and the serialized queue is returned to the gateway side.

[0111] Upon receiving the serialized queue, namely the serialized business category authorization script, the business-related authorization script, and the historical access authorization script, the gateway caches them on the gateway side in the form of a buffer stack.

[0112] In some embodiments, the aforementioned method may further include S340b: caching the returned business classification authorization script, the business-to-business authorization script, and the historical access authorization script on the gateway side in the form of a buffer stack.

[0113] like Figure 7 As shown, Figure 7 This invention provides a schematic diagram of an authorization system based on a microservice architecture. The invention also provides an authorization system based on a microservice architecture, including a gateway traffic distribution module and a gateway authorization module.

[0114] The gateway traffic splitting module is used to receive the first authorization request from the client, decompose the first authorization request to obtain business model parameters, and obtain business classification, business affiliation and business history data based on the business model parameters;

[0115] The gateway authorization module is used to determine whether a set of verification authorization scripts exists on the gateway side. The set of verification authorization scripts includes business category authorization scripts, business affiliation authorization scripts, and historical access authorization scripts. If a set of verification authorization scripts exists on the gateway side, the business category is substituted into the business category authorization script for the first layer of authorization verification; the business affiliation is substituted into the business affiliation authorization script for the second layer of authorization verification; and the historical business data is substituted into the historical access authorization script for the third layer of authorization verification. If the first, second, and third layer of authorization verifications all pass, the call data is returned to the client.

[0116] It is evident that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0117] In some embodiments, the gateway traffic splitting module is specifically used to substitute the service category, service affiliation, and service historical data into a preset expression for matching. If a key-value pair of the service category authorization script is matched, it is determined that the service category authorization script exists; if a key-value pair of the service affiliation authorization script is matched, it is determined that the service affiliation authorization script exists; if a key-value pair of the historical access authorization script is matched, it is determined that the historical access authorization script exists.

[0118] It is evident that the content of the above method embodiments is applicable to the gateway traffic splitting module embodiments. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0119] like Figure 8 As shown, Figure 8 This is a schematic diagram of another authorization system based on a microservice architecture. The system also includes a parsing and generation module, which is used to send a second authorization request to the container group if the gateway does not have a set of verification authorization scripts. The container group generates a business category authorization script, a business-related authorization script, and a historical access authorization script based on the second authorization request. The business category authorization script, the business-related authorization script, and the historical access authorization script are then returned to the gateway.

[0120] In some embodiments, the parsing and generation module is specifically used to identify business categories, obtain the authorization configuration and first execution logic of the business category, and generate a business category authorization script based on the authorization configuration and first execution logic of the business category; identify business affiliation relationships, obtain the authorization configuration and second execution logic of the business affiliation relationships, and generate a business affiliation authorization script based on the authorization configuration and second execution logic of the business affiliation relationships; match business historical data to obtain new business historical data, and convert the new business historical data into a historical access authorization script.

[0121] The parsing and generation module is also used to sort the business category authorization script, the business-related authorization script, and the historical access authorization script, and remove duplicate expressions from the script calls. The result of the removal is added to a queue; the queue is serialized, and the serialized queue is returned to the gateway side.

[0122] As can be seen, the content of the above method embodiments is applicable to the parsing and generation module in the embodiments. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0123] In some embodiments, such as Figure 8 As shown, the gateway authorization module includes a plugin execution unit (which can be a WASM plugin) used to cache the returned business category authorization script, the business-related authorization script, and the historical access authorization script in the gateway authorization module in the form of a buffer stack.

[0124] In some embodiments, the parsing and generation module can also be used for lifecycle management, etc.

[0125] Implementing this invention has the following beneficial effects: By substituting business classification, business affiliation, and business historical data into different authorization scripts and executing different authorization logics, this invention performs three levels of authorization verification to obtain the business Pods participating in the business. This allows for better handling of data relationships, improves fine-grained data processing capabilities, enables flexible authorization in fine-grained business scenarios, enhances management and supervision effectiveness, increases the accuracy and standardization of data authorization granularity, and improves the security of system data and business.

[0126] This invention achieves layered processing by using a dual-channel splitting process for business data and the first authorization request. This effectively separates the processing of general capabilities from that of business data, simplifies business processing, and improves the system's scalability and security.

[0127] This invention caches the relevant authorization scripts on the gateway side through the above-described S310b-S330b. After completing the first authorization verification, the gateway layer realizes component invocation and fast authorization processing through wasm. It can quickly perform secondary authorization verification in the form of authorization scripts, thereby improving response speed and processing efficiency. Through dynamic invocation on the gateway side, the reusability and scalability of the system are realized.

[0128] like Figure 9 As shown, Figure 9 This is a system architecture diagram of Istio providing microservices, including clients, Istio gateways, and Pod groups. The Istio gateway is configured with a WASM plugin, and the Pod groups include authorized Pods and business Pods. The authorized Pods have a parsing and generation module, the function of which is the same as that of the aforementioned method and system embodiments, and will not be repeated here.

[0129] It is understood that the authorization method based on microservice architecture provided in this embodiment of the invention can be applied to any computer device with data processing and computing capabilities, and this computer device can be various terminals or servers. When the computer device in the embodiment is a server, the server is an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Optionally, the terminal can be a smartphone, tablet, laptop, or desktop computer, but it is not limited to these.

[0130] This invention can be applied to various types of authorization management and definition scenarios in general MIS or collaborative office scenarios based on ISTIO; it can also be applied to scenarios where the system has high requirements for data permissions and the relevant permissions need to achieve fine-grained permission control.

[0131] like Figure 10 As shown, Figure 10 This invention provides a schematic diagram of an authorization device based on a microservice architecture. The invention also provides an authorization device based on a microservice architecture, comprising:

[0132] At least one processor;

[0133] At least one memory for storing at least one program;

[0134] When the at least one program is executed by the at least one processor, the at least one processor performs the authorized method steps described in the above method embodiments.

[0135] The memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. The memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include remote memory located remotely relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0136] It is evident that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented in this device embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0137] Furthermore, this application also discloses a computer program product or computer program stored in a computer-readable storage medium. A processor of a computer device can read the computer program from the computer-readable storage medium, and the processor executes the computer program, causing the computer device to perform the described method. Similarly, the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0138] The present invention also provides a computer-readable storage medium storing a processor-executable program, which, when executed by a processor, is used to implement the above-described method.

[0139] It is understood that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0140] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0141] The above provides a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the described embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application. In the present invention, those skilled in the art will understand explicitly and implicitly that the embodiments described herein can be combined with other embodiments.

Claims

1. A method for authorization based on a microservice architecture, characterized in that, The method comprises the following steps: receiving a first authorization request of a client, decomposing the first authorization request to obtain a business model parameter, obtaining a business classification, a business belonging relationship and business history data according to the business model parameter; determining whether a verification authorization script set exists on the gateway side; the verification authorization script set comprises a business classification authorization script, a business belonging authorization script and a history access authorization script; if the verification authorization script set exists on the gateway side, substituting the business classification into the business classification authorization script to perform first-layer authorization verification; substituting the business belonging relationship into the business belonging authorization script to perform second-layer authorization verification; and substituting the business history data into the history access authorization script to perform third-layer authorization verification; if the first-layer authorization verification, the second-layer authorization verification and the third-layer authorization verification all pass the verification, returning calling data to the client.

2. The method of claim 1, wherein, The determination of whether the verification authorization script set exists on the gateway side specifically comprises: substituting the business classification, the business belonging relationship and the business history data into a preset expression to perform matching; if a key-value pair of the business classification authorization script is matched, it is determined that the business classification authorization script exists; if a key-value pair of the business belonging authorization script is matched, it is determined that the business belonging authorization script exists; if a key-value pair of the history access authorization script is matched, it is determined that the history access authorization script exists.

3. The method of claim 1, wherein, if the verification authorization script set does not exist on the gateway side, the gateway side sends a second authorization request to a container group; so that the container group generates the business classification authorization script, the business belonging authorization script and the history access authorization script according to the second authorization request; the business classification authorization script, the business belonging authorization script and the history access authorization script are returned to the gateway side.

4. The method of claim 3, wherein, The second authorization request comprises the business classification, the business belonging relationship and the business history data; the container group generates the business classification authorization script, the business belonging authorization script and the history access authorization script according to the second authorization request, specifically comprising: identifying the business classification to obtain an authorization configuration and a first execution logic of the business classification, and generating the business classification authorization script according to the authorization configuration and the first execution logic of the business classification; identifying the business belonging relationship to obtain an authorization configuration and a second execution logic of the business belonging relationship, and generating the business belonging authorization script according to the authorization configuration and the second execution logic of the business belonging relationship; matching the business history data to obtain new business history data, and converting the new business history data into the history access authorization script.

5. The method of claim 3, wherein, The returning of the business classification authorization script, the business belonging authorization script and the history access authorization script to the gateway side specifically comprises: sorting the business classification authorization script, the business belonging authorization script and the history access authorization script, and eliminating repeated expressions of script calls, and adding the eliminated results into a queue; serializing the queue, and returning the serialized queue to the gateway side.

6. The method according to any one of claims 3-5, characterized in that, The method further comprises: caching the business classification authorization script, the business belonging authorization script and the history access authorization script in a buffer stack at the gateway side.

7. An authorization system based on a microservice architecture, characterized in that, The system comprises a gateway shunting module and a gateway authorization module, wherein, The gateway shunting module is configured to receive a first authorization request of a client, decompose the first authorization request to obtain a business model parameter, and obtain a business classification, a business belonging relationship and business history data according to the business model parameter. The gateway authorization module is configured to determine whether a verification authorization script set exists at the gateway side; the verification authorization script set comprises a business classification authorization script, a business belonging authorization script and a history access authorization script; if the verification authorization script set exists at the gateway side, the business classification is substituted into the business classification authorization script for first-layer authorization verification; the business belonging relationship is substituted into the business belonging authorization script for second-layer authorization verification; and the business history data is substituted into the history access authorization script for third-layer authorization verification; if the first-layer authorization verification, the second-layer authorization verification and the third-layer authorization verification all pass the verification, calling data is returned to the client.

8. The system of claim 7, wherein, The system further comprises an analysis and generation module, which is configured to, if the verification authorization script set does not exist at the gateway side, send a second authorization request to a container group by the gateway side; The container group generates the business classification authorization script, the business belonging authorization script and the history access authorization script according to the second authorization request; The business classification authorization script, the business belonging authorization script and the history access authorization script are returned to the gateway side.

9. An authorization apparatus based on a microservice architecture, characterized in that, The system comprises: at least one processor; at least one memory for storing at least one program; when the at least one program is executed by the at least one processor, the at least one processor implements the method of any one of claims 1-6.

10. A computer readable storage medium having stored therein a program which is executable by a processor, characterized in that, The program executable by the processor, when executed by the processor, is used to execute the method of any one of claims 1-6.

Images