A method for managing data permissions and related devices

Abstract

An embodiment of the present application discloses a method for managing data permissions and related devices, belonging to the technical field of data security, and is used to implement the transfer and automatic inheritance of data permissions in a distributed microservices system. The method is applied to a distributed microservices system and is executed by a management microservice node in the distributed microservices system. The method includes: determining a first microservice node and a second microservice node; wherein, in a business process, a second business object is an associated object that depends on a first business object; obtaining permission data in the first microservice node; the permission data includes a mapping relationship between a user identifier and an identifier of business data of the first business object, and a user indicated by a user identifier having the mapping relationship has an operation permission for the business data indicated by the identifier of the business data; sending the permission data to the second microservice node; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of data security, and in particular, to a method for managing data permissions and related devices. Background Art

[0002] A customer relationship management (CRM) system is mainly used to manage the interactions between an enterprise and its customers. An enterprise can record the basic information of customers through the CRM system, and it can also help the enterprise conduct better marketing and management. In the CRM system, various business objects are interrelated and jointly carry the key business information of the enterprise. To ensure the security and compliance of this data, it is particularly important to control the data permissions of these business objects.

[0003] In the related art, the Attribute-Based Access Control (ABAC) and Policy-Based Access Control (PBAC) models are usually adopted. Among them, the ABAC model makes a decision on whether a user has the right to access the data resources of a certain business object based on a set of attributes (for example, user attributes, environmental attributes, object attributes, etc.). The PBAC model, on the other hand, expresses that a user can access the data resources of certain business objects under certain conditions based on a policy script.

[0004] However, in the current microservices architecture, the business objects of the CRM are often scattered in various different microservices and databases for storage and management. The business objects within each microservice manage their respective data permissions according to their own attribute rules through ABAC or PBAC. This results in the implementation of data permissions and the management of business objects being decentralized, and the association between business objects does not extend to data permissions, thus causing the data permissions of business objects to be unable to be inherited and transferred across microservices. When a user requests data permissions, different business objects need to be requested separately. As the number of business objects increases and the complexity of their associations increases, the difficulty of data permission management becomes greater and greater. Summary of the Invention

[0005] The embodiments of the present application provide a method for managing data permissions and related devices, which can realize the transfer and automatic inheritance of data permissions of business objects in a distributed microservices system, and improve the efficiency of data permission management.

[0006] In a first aspect, a method for managing data permissions is provided. This method is applied to a distributed microservices system and is executed by a management microservice node in the distributed microservices system. The method includes: determining a first microservice node and a second microservice node; the first microservice node is used to perform business operations on the business data of a first business object; the second microservice node is used to perform business operations on the business data of a second business object; wherein, in the business process, the second business object is an associated object that depends on the first business object; obtaining permission data in the first microservice node; the permission data includes the mapping relationship between the user identifier and the identifier of the business data of the first business object, and the user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data; sending the permission data to the second microservice node; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object.

[0007] As can be seen from the above, the management microservice node will synchronize the permission data obtained from the first microservice node to the second microservice node. The permission data includes the mapping relationship between the user identifier of the first user and the identifier of the first business data, and the user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data. Since the identifier of the second business data of the second business object is the same as the identifier of the first business data of the first business object, the first user automatically obtains the operation permission for the second business data of the second business object. Thus, the management efficiency of data permissions in the distributed microservices system is improved.

[0008] In a possible implementation manner, obtain the operation log of the first microservice node; the operation log is used to record the user triggering the first microservice node to perform business operations on the business data of the first business object; by parsing the operation log, obtain the permission data in the first microservice node.

[0009] As can be seen from the above, by obtaining the operation log of the business data in the first microservice, the management microservice node can determine the identifier of the user who operates on the first business data from the operation log, thereby determining the permission data. It can realize the dynamic update of the permission data and further improve the efficiency of data permission management.

[0010] In a possible implementation manner, the permission data is stored in a data sharing share model; the fields in the share model include user identifier, identifier of business data, and permission type; the permission type includes read operation and / or write operation.

[0011] As can be seen from the above, storing the permission data in the share model ensures the sharing of data resources between microservice nodes and improves the consistency and convenience of permission data synchronization.

[0012] In a possible implementation, the distributed microservices system further includes a client. When a first user logs in to the client, the client is used to send a first access request to a second microservice node. The first access request includes the user identifier of the first user and is used to request access to the business data of a second business object in the second microservice node.

[0013] In a possible implementation, the second microservice node is used to receive the first access request and determine a first access result based on the permission data and the user identifier of the first user.

[0014] In a possible implementation, the dependency relationships between the business objects corresponding to the respective microservice nodes in the distributed microservices system are obtained through the Unified Modeling Language (UML); based on the dependency relationships, the first microservice node and the second microservice node are determined.

[0015] As can be seen from the above, by marking the relationships between the respective business objects in the distributed microservices system in the form of a UML class diagram, the first microservice node and the second microservice node can be determined more efficiently and accurately.

[0016] In a possible implementation, the permission data in the share model is synchronized to the second microservice node through cloud services.

[0017] As can be seen from the above, by synchronizing the permission data in the share model to the second microservice node through cloud services, the efficiency of synchronizing data permissions can be improved, thereby improving the efficiency of data permission management.

[0018] In a second aspect, a method for managing data permissions is provided. The method is applied to a distributed microservices system and is executed by a second microservice node in the distributed microservices system. The method includes: receiving a first access request for second business data sent by a client; the first access request includes the user identifier of a first user and is used to request access to the business data of a second business object in the second microservice node; the identifier of the business data of the second business object is the same as the identifier of the business data of a first business object; wherein, the first microservice node is used to perform a business operation on the business data of the first business object; the second microservice node is used to perform a business operation on the business data of the second business object; in the business process, the second business object is an associated object that depends on the first business object; determining a first access result based on the permission data and the user identifier of the first user; the permission data includes the mapping relationship between the user identifier and the identifier of the business data of the first business object, and the user indicated by the user identifier having the mapping relationship has the operation permission for the business data indicated by the identifier of the business data; the permission data is sent by a management microservice node to the second microservice node.

[0019] In a possible implementation, the distributed microservices system includes a management microservices node, which is used to obtain the operation logs of the first microservices node and obtain the permission data in the first microservices node by parsing the operation logs;

[0020] Among them, the operation logs are used to record the business operations performed by the user triggering the first microservices node on the business data of the first business object.

[0021] In a possible implementation, the permission data is stored in the data sharing share model; the fields in the share model include the user identifier, the identifier of the business data, and the permission type; the permission type includes read operation and / or write operation.

[0022] In a third aspect, a method for managing data permissions is provided. This method is applied to a distributed microservices system and is executed by a client in the distributed microservices system. The method includes: sending a first access request for second business data to a second microservices node; the first access request includes the user identifier of the first user and is used to request access to the business data of the second business object in the second microservices node; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object; among them, the first microservices node is used to perform business operations on the business data of the first business object; the second microservices node is used to perform business operations on the business data of the second business object; in the business process, the second business object is an associated object that depends on the first business object; receiving the first access result sent by the second microservices node; the first access result is determined by the second microservices node according to the permission data and the user identifier of the first user; the permission data includes the mapping relationship between the user identifier and the identifier of the business data of the first business object, and the user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data; the permission data is sent by the management microservices node to the second microservices node.

[0023] In a possible implementation, the distributed microservices system includes a management microservices node, which is used to obtain the operation logs of the first microservices node and obtain the permission data in the first microservices node by parsing the operation logs;

[0024] Among them, the operation logs are used to record the business operations performed by the user triggering the first microservices node on the business data of the first business object.

[0025] In a possible implementation, the permission data is stored in the data sharing share model; the fields in the share model include the user identifier, the identifier of the business data, and the permission type; the permission type includes read operation and / or write operation.

[0026] Fourthly, a management device for data permissions is provided. The device includes a judgment module configured to determine a first microservice node and a second microservice node. The first microservice node is used to perform business operations on the business data of a first business object. The second microservice node is used to perform business operations on the business data of a second business object. Wherein, in the business process, the second business object is an associated object dependent on the first business object.

[0027] An acquisition module is configured to obtain permission data in the first microservice node. The permission data includes a mapping relationship between a user identifier and an identifier of the business data of the first business object. The user indicated by the user identifier having the mapping relationship has the operation permission for the business data indicated by the identifier of the business data.

[0028] A synchronization module is configured to send the permission data to the second microservice node. The identifier of the business data of the second business object is the same as the identifier of the business data of the first business object.

[0029] In a possible implementation manner, the acquisition module is further configured to obtain the operation log of the first microservice node. The operation log is used to record that a user triggers the first microservice node to perform a business operation on the business data of the first business object. By parsing the operation log, the permission data in the first microservice node is obtained.

[0030] As can be seen from the above, the descriptions of the possible technical solutions and beneficial effects executed by each of the above-divided functional modules can refer to the technical solutions provided in the first aspect or its corresponding possible implementation manners above, and will not be elaborated here.

[0031] Fifthly, an embodiment of the present application provides a server. The server includes a processor and a memory for storing processor-executable instructions. The processor is configured to execute the instructions such that the server executes the management method for data permissions in the first aspect or the second aspect above.

[0032] Sixthly, an embodiment of the present application provides a terminal device. The terminal device runs a client and includes a processor and a memory for storing processor-executable instructions. The processor is configured to execute the instructions such that the terminal device executes the management method for data permissions in the third aspect above.

[0033] Seventhly, an embodiment of the present application provides a computer-readable storage medium. At least one computer program is stored in the computer-readable storage medium. The computer program is loaded and executed by a processor to implement the management method for data permissions in the first aspect or the second aspect above.

[0034] In an eighth aspect, an embodiment of the present application provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computing node reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computing node executes the data permission management method provided in the various optional implementations of the first aspect or the second aspect above.

[0035] For the specific descriptions of the third aspect to the eighth aspect and their various implementation manners in the embodiments of the present application, reference may be made to the detailed descriptions in the first aspect, the second aspect and their various implementation manners; and, for the beneficial effects of the third aspect to the eighth aspect and their various implementation manners, reference may be made to the beneficial effect analysis in the various implementation manners of the first aspect and the second aspect, which will not be elaborated herein.

[0036] These aspects or other aspects of the embodiments of the present application will be more clearly understood in the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 FIG. shows a schematic architectural diagram of an attribute-based access control model ABAC provided by the related art;

[0038] Figure 2 FIG. shows a schematic architectural diagram of a policy-based access control model PBAC provided by the related art;

[0039] Figure 3 FIG. shows a schematic structural diagram of a CRM system for controlling permissions through ABAC or PBAC under a microservices architecture provided by the related art;

[0040] Figure 4 FIG. shows a schematic architectural diagram of a distributed microservices system 100 provided by an embodiment of the present application;

[0041] Figure 5 FIG. shows a schematic hardware architecture diagram of a CRM system provided by an embodiment of the present application;

[0042] Figure 6 FIG. shows a schematic application architecture diagram of a data permission management system provided by an embodiment of the present application;

[0043] Figure 7 FIG. shows a schematic flowchart of a data permission management method provided by an embodiment of the present application;

[0044] Figure 8 FIG. shows a schematic diagram of the association relationship of business objects at the business level in a CRM system provided by an embodiment of the present application;

[0045] Figure 9It shows a schematic diagram of the association relationship between the UML class diagram marked contract business object and the customer business object provided by the embodiment of the present application;

[0046] Figure 10 It shows a schematic diagram of the process of obtaining operation logs through cloud services provided by the embodiment of the present application;

[0047] Figure 11 It shows a schematic diagram of the interaction process of a data permission management method provided by the embodiment of the present application;

[0048] Figure 12 It shows a schematic diagram of the structure of a data permission management device 400 provided by the embodiment of the present application;

[0049] Figure 13 It shows a schematic diagram of the hardware of a server 220 provided by the embodiment of the present application;

[0050] Figure 14 It shows a schematic diagram of a server cluster provided by the embodiment of the present application;

[0051] Figure 15 It shows a schematic diagram of a possible implementation manner of a network connection provided by the embodiment of the present application. Detailed implementation manners

[0052] Next, the technical solutions in the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application. Among them, in the description of the present application, unless otherwise specified, " / " means that the objects associated before and after are in an "or" relationship. For example, A / B can represent A or B; "and / or" in the present application is only a description of the association relationship of the associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. These three situations, where A and B can be singular or plural. And, in the description of the present application, unless otherwise specified, "multiple" means two or more than two. "At least one (piece)" or its similar expression below refers to any combination of these items, including any combination of single item (piece) or plural items (pieces). For example, at least one (piece) of a, b, or c can represent: a, b, c, a - b, a - c, b - c, or a - b - c, where a, b, c can be single or multiple. In addition, in order to clearly describe the technical solutions in the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish the same items or similar items with basically the same functions and effects.

[0053] Those skilled in the art can understand that terms such as "first" and "second" do not limit the quantity and execution order, and "first", "second" and other terms do not necessarily limit differences. At the same time, in some embodiments of the present application, words such as "exemplary" or "for example" are used to represent examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be construed as more preferred or more advantageous than other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner for easy understanding.

[0054] In addition, the device architecture and business scenarios described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those of ordinary skill in the art know that with the evolution of the device architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

[0055] Term introduction:

[0056] Customer Relationship Management System CRM: It is a systematic management method used to optimize the relationship between an enterprise and its customers. CRM centralizes the management of customer information, tracks the history of customer interactions, analyzes customer behavior and preferences to improve customer satisfaction and loyalty. At the same time, it helps the enterprise to automate processes and effectively analyze data in customer acquisition, customer retention and customer relationship maintenance, thereby achieving business growth of the enterprise.

[0057] Business object: It represents a data entity or object with specific business meanings in the CRM system. It usually reflects actual elements in real business (such as customers, contracts, after-sales, etc.) and contains characteristics, states and behaviors related to the business entity.

[0058] Associated object: In the CRM system, an associated object refers to a business object that is closely related to or has a dependency relationship with a certain business object. The existence of the associated object is usually to achieve business linkages.

[0059] Data permission: It refers to the control right or permission for data access and operation. It is usually used to determine the accessible range and operation permissions of a certain user or user group for a certain specific data in a specific system or application. In the CRM system, data permissions are used to manage users' access and operation permissions for business objects to ensure that the data of business objects is only visible and operable to authorized personnel.

[0060] First, an exemplary introduction to the application scenarios of the embodiments of the present application is given.

[0061] The CRM system can provide a centralized platform within the enterprise. It can not only collect, organize and analyze a large amount of customer data to provide support for enterprise management and decision-making, but also share customer information, promote enterprise team collaboration and improve work efficiency. The CRM system contains a large number of core business objects that carry the key business information of the enterprise, such as customers, opportunities, contracts, partners, leads, service tickets, etc. In order to ensure the security and compliance of data and limit unnecessary data exposure, it is particularly important to control the data permissions of these data.

[0062] In related technologies, the solutions for data permission control of CRM business objects mainly include attribute-based access control (ABAC) and policy-based access control (PBAC). The core idea of ​​the ABAC model is to decide whether a user has the right to access the data resources of a business object based on a set of attributes (such as user attributes, environment attributes, object attributes, etc.). Figure 1 FIG. 1 shows an architecture diagram of an attribute-based access control model ABAC provided by the related art. Figure 1 As shown in the figure, when a user wants to access the data resource of a specific protected business object, he must first determine whether he has the right to access the data resource through the policy execution point superimposed on the data resource access path, based on the calculation result returned by the policy execution point. When the user initiates an access request, the policy execution point triggers the policy execution of the policy decision point. When the policy decision point is executed, it performs dynamic permission calculation based on the attributes 1, attribute 2...attribute n corresponding to the policy information point (such as user attributes, environment attributes, context attributes, resource attributes, etc.), and according to the execution policy determined by the policy management point in the policy warehouse. The policy decision point returns the calculated result to the policy execution point. When the calculation result of the policy decision point is true, it means that the current user has access rights to the data resource, and the access request issued by the user can successfully access the protected data resource. When the calculation result is false, it means that the current user does not have the right to access the current protected resource. The policy execution point returns an error message to the user.

[0063] The PBAC model is based on a policy script to express which data resources of certain business objects users can access under certain conditions. PBAC is generally implemented based on models. Figure 2 FIG. 1 shows a schematic diagram of the architecture of a policy-based access control model PBAC provided by the related art. Figure 2As shown, when a user initiates an access request to a data resource, authentication is performed through a policy enforcement point on the access path. The policy enforcement point determines whether the user has the right to access the data resource through a policy engine. The policy engine dynamically executes predefined permission policies and databases and returns the policy execution result to the user. Among them, the policy script of the policy engine is relatively flexible and can be regarded as a small language that can write attributes, conditional rules, expressions, and even some business logics in ABAC into the policy to assist in operations.

[0064] However, in a microservices architecture, business objects in a CRM system are often scattered in various different microservices and databases for storage and management, and data interaction between business objects is mainly through interfaces. Business objects within each microservice manage their own data permissions through ABAC or PBAC according to their own attribute rules. Figure 3 The structure diagram of a CRM system that controls permissions through ABAC or PBAC in a microservices architecture provided by the related art is shown. As Figure 3 shown, a user can access business data in the CRM system through a business gateway. Business objects in the CRM system include customers and contracts, which are respectively implemented through a customer microservice and a contract microservice, and the business data generated by their respective microservices are stored in a customer database and a contract database. Among them, the contract business object is an associated object of the customer business object. That's because a contract is signed based on a customer, and its validity and content often depend on the customer's information. Business objects within the customer microservice and the contract microservice manage their own data permissions through ABAC or PBAC according to their own attribute rules.

[0065] Since there are ABAC or PBAC for controlling the permissions of business objects within the customer microservice and the contract microservice respectively, when a user applies for a customer business object or a contract business object, a separate application is required. This results in the dispersion of data permissions for each business object, and the data permissions of business objects cannot be inherited and transferred across microservices. For example, if a user has already applied for the data permission of a customer business object, they should automatically be able to see the data of the contract associated with the customer without having to apply for the data permission of the contract separately. Therefore, when a user needs the data permissions of multiple business objects, they need to apply one by one. This not only affects the user experience but also, in the scenario of applying for permissions multiple times, leads to a decline in the interface performance when the user accesses the data. Consequently, the efficiency of data permission management in the CRM system is low.

[0066] In view of this, an embodiment of the present application provides a method for managing data permissions. This method is applied to a distributed microservices system, which includes a first microservice node, a second microservice node, and a management microservice node. The method includes that the management microservice node determines the first microservice node and the second microservice node. The first microservice node is used to perform business operations on the business data of the first business object; the second microservice node is used to perform business operations on the business data of the second business object. Among them, in the business process, the second business object is an associated object that depends on the first business object. The management microservice node obtains the permission data in the first microservice node and sends the permission data to the second microservice node. Among them, the permission data contains the mapping relationship between the user identifier and the identifier of the business data of the first business object. The user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object.

[0067] When the second microservice node receives a first access request for the second business data, the second microservice node determines a first access result according to the above permission data and the user identifier of the first user included in the first access request, and performs data authentication. Specifically, if the permission data includes the mapping relationship between the user identifier of the first user and the identifier of the first business data, the user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data. Since the identifier of the second business data of the second business object is the same as the identifier of the first business data of the first business object, the first user automatically obtains the operation permission for the second business data of the second business object. Therefore, the second microservice node can automatically inherit the permission data in the first microservice node without having to separately apply for the operation permission for the second business data in the second microservice node, thereby improving the management efficiency of data permissions in the distributed microservices system.

[0068] Secondly, an exemplary introduction to the system architecture of the embodiment of the present application is given.

[0069] Figure 4 FIG. shows a schematic diagram of the architecture of a distributed microservices system 100 provided by an embodiment of the present application. As Figure 4 shown, the distributed microservices system 100 includes multiple microservice nodes 110 and a management microservice node 120. The multiple microservice nodes 110 are used to perform business operations on the business data of different business objects.

[0070] The management microservice node 120 is used to determine a first microservice node and a second microservice node among multiple microservice nodes 110; the first microservice node is used to perform a business operation on the business data of the first business object; the second microservice node is used to perform a business operation on the business data of the second business object; wherein, in the business process, the second business object is an associated object that depends on the first business object, and the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object.

[0071] The management microservice node 120 is also used to obtain the permission data in the first microservice node. The permission data includes a mapping relationship between the user identifier and the identifier of the business data of the first business object, and the user indicated by the user identifier having the mapping relationship has the operation permission for the business data indicated by the identifier of the business data. At the same time, the management microservice node 120 sends the permission data to the second microservice node.

[0072] Taking the distributed microservice system including the CRM system as an example, Figure 5 FIG. 1 is a schematic diagram showing the hardware architecture of a CRM system provided by an embodiment of the present application. Figure 5 As shown, the CRM system includes a terminal device 210 and a server 220. The terminal device 210 and the server 220 are connected to each other via a network.

[0073] The server 220 may be a standard general-purpose server, specifically a blade server, a high-density server, a rack server, or a high-performance server. A CRM system is running on the server 220. The CRM system includes multiple business objects, and each business object and the business data corresponding to each business object are executed by each microservice node. Specifically, the server 220 includes a first microservice node, a second microservice node, and a management microservice node. The first microservice node is used to perform business operations on the business data of the first business object; the second microservice node is used to perform business operations on the business data of the second business object.

[0074] A client of the CRM system runs on the terminal device 210, and users can access the CRM system through the client on the terminal device 210. The terminal device 210 also includes a display screen for displaying the user interface of the CRM system, and users can interact with the CRM system through the user interface. The terminal device 210 may specifically include electronic devices with communication capabilities such as mobile phones, smart watches, tablet computers, foldable electronic devices, desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (UMPCs), netbooks, cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices, in-vehicle devices, etc. The specific type of the terminal device 210 is not particularly limited in the embodiments of the present application.

[0075] The terminal device 210 is used to send a first access request for the second service data to the second microservice node in the server 220. The first access request includes the user identifier of the first user; the identifier of the service data of the second service object is the same as the identifier of the service data of the first service object. Among them, the first microservice node is used to perform service operations on the service data of the first service object; the second microservice node is used to perform service operations on the service data of the second service object; in the service process, the second service object is an associated object that depends on the first service object.

[0076] The terminal device 210 receives the first access result sent by the second microservice node. Among them, the first access result is determined by the second microservice node according to the permission data and the user identifier of the first user; the permission data contains the mapping relationship between the user identifier and the identifier of the service data of the first service object, and the user indicated by the user identifier with the mapping relationship has the operation permission for the service data indicated by the identifier of the service data; the permission data is sent by the management microservice node to the second microservice node.

[0077] Optionally, Figure 6 It shows a schematic diagram of the application architecture of a data permission management system provided by the embodiments of the present application. As Figure 6As shown, the user can access the CRM system running on the server 220 through the CRM user interface on the terminal device 210. The CRM system includes business object 01 and its corresponding first database, business object 02 and its corresponding second database, and business object 03 and its corresponding third database. There are association relationships among the various business objects in the CRM system, and they operate independently in their respective corresponding microservice nodes. The management microservice node 120 can be a different microservice node from the microservice nodes corresponding to the various business objects in the CRM system, and is used to implement the data permission management method.

[0078] It can be understood that the management microservice node 120 can also be the same microservice node as the microservice node corresponding to any business object in the CRM system. The application architecture of the above data permission management system is only an example and does not constitute a limitation on the technical solutions provided by the embodiments of the present application.

[0079] It should be noted that the system architecture and application scenarios described in the embodiments of the present application are for more clearly explaining the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those of ordinary skill in the art know that with the evolution of the system architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

[0080] For the convenience of understanding, the following provides an exemplary introduction to the data permission management method provided by the present application in combination with the accompanying drawings. This data permission management method is applicable to Figure 4 the distributed microservice system 100 shown.

[0081] Figure 7 FIG. shows a schematic flowchart of a data permission management method provided by an embodiment of the present application. This method is executed by the management microservice node in the distributed microservice system. As Figure 7 shown, the method includes the following steps:

[0082] S101, the management microservice node determines the first microservice node and the second microservice node.

[0083] Among them, the first microservice node is used to perform business operations on the business data of the first business object; the second microservice node is used to perform business operations on the business data of the second business object; among them, in the business process, the second business object is an associated object that depends on the first business object.

[0084] Exemplarily, in a distributed microservice system, there are usually a large number of business objects. The business operations corresponding to the business data of different business objects are performed by different microservice nodes, and each business object usually has an association relationship at the business level. Figure 8The figure shows a schematic diagram of the association relationship of business objects at the business level in a CRM system provided by an embodiment of the present application. As Figure 8 shown, the CRM system includes a customer business object, a contract business object, an after-sales business object, a product business object, and a work order business object. Among them, the customer business object is the root object of the CRM system. Since when creating a contract business object, the corresponding customer business object must be selected first, and contract data is generated based on customer data. Therefore, the contract business object depends on the customer business object, and the data corresponding to the contract business object also depends on the contract business object. Similarly, the contract business object, the after-sales business object, and the product business object are associated objects of the customer business object. The work order business object is an associated object of the after-sales business object.

[0085] In a possible implementation manner, the dependency relationship between business objects corresponding to each microservice node in a distributed microservice system is obtained through the Unified Modeling Language (UML); according to the dependency relationship, the first microservice node and the second microservice node are determined.

[0086] Exemplarily, the relationships of each business object in the distributed microservice system are marked by means of a UML class diagram, and according to the association relationship between each business data in the business process, the first microservice node and the second microservice node are determined.

[0087] For example, taking the customer business object and the contract business object in the CRM system as an example. Figure 9 The figure shows a schematic diagram of a UML class diagram marking the association relationship between the contract business object and the customer business object provided by an embodiment of the present application. As Figure 9 shown, the contract business object includes a contract identifier A and a contract name; the customer business object includes a customer identifier A and a customer name. Among them, the contract identifier A corresponds to the contract name; the customer identifier A corresponds to the customer name. There is an indication information of the customer pointing to the customer business object on the domain model of the contract business object. That is, there is a pointing relationship between the identifier information of the contract object in the contract business object and the identifier information of the corresponding customer object. If the identifier information of the first customer is A, then the identifier information of the contract corresponding to the first customer is also A, and the contract depends on the customer information for existence. Through the above method, the relationships of the main business objects in the distributed microservice system can be marked step by step, so as to determine the first microservice node and the second microservice node of the system.

[0088] Therefore, in Figure 8The first microservice node in the CRM system shown includes a customer business object or an after-sales business object. If the first microservice node is the microservice node corresponding to the customer business object, then the second microservice node is the microservice node corresponding to the associated object of the customer business object, including the microservice node corresponding to the contract business object, the microservice node corresponding to the after-sales business object, and the microservice node corresponding to the product business object. If the first microservice node is the microservice node corresponding to the after-sales business object, then the second microservice node is the microservice node corresponding to the associated object of the after-sales business object, including the microservice node corresponding to the work order business object.

[0089] S102. The management microservice node obtains the permission data in the first microservice node.

[0090] Among them, the permission data contains the mapping relationship between the user identifier and the identifier of the business data of the first business object. The user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data.

[0091] In a possible implementation manner, obtain the operation log of the first microservice node; by parsing the operation log, obtain the permission data in the first microservice node.

[0092] Among them, the operation log is used to record that the user triggers the first microservice node to perform a business operation on the business data of the first business object.

[0093] Optionally, before obtaining the operation log corresponding to the first business data, determine the attribute information related to data permissions in the operation log. There are some attribute fields in the operation log, which are related to the permissions of the business data corresponding to the business object. The user identifier of the first user includes fields related to the permissions of the first business data.

[0094] For example, view the table structure corresponding to the domain model of the first business object, and determine which attributes affect the data permissions of the business object based on the data permission rules of the first business object. Taking the first business object as the customer business object as an example, the user identifier of the first user includes fields such as the responsible person field, the sales team field, or the approver field.

[0095] In a possible implementation manner, the management microservice node obtains the binary operation log of the database corresponding to the first business data in the first microservice node; the binary operation log is used to record the change operations of the database; the management microservice node parses the binary operation log to obtain the operation log of the first business data corresponding to the first microservice node.

[0096] Exemplarily, the management microservice node monitors and obtains the binary operation log (binlog event) of the database corresponding to the first microservice node through the cloud service, and can obtain the change operations of the database corresponding to the first microservice node, as well as the changes in the fields corresponding to the first user in the binary operation log, so as to obtain the operation log of the first business data.

[0097] For example, Figure 10 FIG. shows a schematic flow diagram of obtaining an operation log through a cloud service provided by an embodiment of the present application. As Figure 10 shown, after determining the first microservice node, determine the fields of the attributes corresponding to the first user of the first business data, record the table storing the attribute fields of the user information of the first user, and obtain the binary log of the first database corresponding to the first business object. Through the data replication service (DRS) cloud service, synchronize the binary log of the first database to the kafka service, so that the management microservice node obtains the operation log including the user identifier of the first user. The management microservice node parses the operation log, obtains the user identifier of the first user, and generates a mapping relationship between the identifier of the first business data and the user identifier of the first user, thereby generating permission data.

[0098] In a possible implementation manner, the management microservice node obtains the operation log of the first business data in the first microservice node, parses the operation log, and updates the permission data.

[0099] In some examples, the management microservice node modifies the user identifier of the first user that has a mapping relationship with the identifier of the first business data in the permission data according to the user identifier of the first user in the operation log, so as to update the mapping relationship between the identifier of the first business data and the user identifier of the first user.

[0100] Among them, the permission data is stored in the Share model, and the fields in the share model include user identifier, identifier of business data, and permission type; the permission type includes read operation and / or write operation.

[0101] Optionally, the Share model may also include the reason for exercising the right. The field of the reason for exercising the right indicates the way through which the user obtains the access right to the first business data in the first microservice. In the CRM system, the most common types of reasons for exercising the right include the responsible person (Owner), the sales team (Team), the approval process (Approve), the organization (Organization), and the application for permission. The field of the reason for exercising the right can be further subdivided into secondary reasons for exercising the right. For example, when the reason for exercising the right is the sales team, there may be different team role members such as the project manager (PM), the pre-sales engineer, the system analyst (SA), or the ecological manager.

[0102] In some other examples, before updating the permission data according to the operation log of the first business data, the server parses the obtained operation log to obtain the change of the field information corresponding to the user identifier of the first user. If the operation log includes adding the identifier information of the first user in the identifier of the first business data, that is, a new first user is added, at this time, the permission information of the first business data has changed. The management microservice node parses the operation log to obtain the change of the field information corresponding to the first user, so as to update the permission data.

[0103] For example, the management microservice node docks with the Figure 10 kafka service mentioned above, parses the operation log according to the message format when DRS delivers kafka, and the data structure obtained after parsing is as follows:

[0104] Public class BinlogEvent{

[0105] Private String eventKey;

[0106] Private String tableName; / / When kafka delivers binlog events, the shard is the key, and the format is eventKey. tableName

[0107] Private map<string, string> afterDateMap; / / All fields of the data row after this update

[0108] Private map<string, string> beforeDateMap; / / All fields of the data row before this update

[0109] Private String operation; / / Change type: INERT\UPDATE\DELETE

[0110] Private List <string>changedFields; / / Which fields have been modified in this update

[0111] }

[0112] The above data structure contains the field Key / Value information before and after the data row change, as well as the type of data change. Among them, the Public class BinlogEvent field represents the binary event of the public class; the Private String eventKey field represents the string key value; the Private String tableName field represents the string file name; the Private map<string, string> afterDateMap field represents all fields of the data row after this update; the Private map<string, string> beforeDateMap field represents all fields of the data row before this update; the Private String operation represents the type of change, which can be specifically new, update, or delete; the Private List <string>changedFields indicates which fields have been modified in this update.

[0113] It should be understood that the data structure obtained after the above parsing is only an example and does not constitute a specific limitation. For different application scenarios and requirements of permission data, there are corresponding different data structures.

[0114] Taking the first user field including the responsible person field as an example, the user identifier corresponding to the responsible person field represents the user who has the right to access the first business data. The identification information of the user can specifically include the user's job number, ID number, mobile phone number, or the account number of the CRM system, etc., which are the user's unique identifiers. If the identification information of the user corresponding to the responsible person field of the first business data includes 001, 002, and 003. When user 001 accesses the first business data and adds the identification information 004 of the user corresponding to the responsible person field, by parsing the operation log according to the message format when DRS delivers kafka, it can be determined that the responsible person field has been modified.

[0115] Taking the first business object as the customer business object as an example, the data identifiers of the first business data and the second business data can be the customer ID. Based on the core fields of the Share model and the result of parsing the operation log, extract the ID of the first business data, the responsible person ID, the reason for exercising the right, and the type of exercising the right from the operation log. The permission information before and after the update is shown in Table 1:

[0116] Table 1

[0117]

[0118] It can be seen from the above table that the responsible person in the updated permission data includes user 004, that is, user 004 has the permission to read and write the page data of the customer corresponding to the customer ID 0xefudefx01.

[0119] S103, the management microservice node sends permission data to the second microservice node.

[0120] Among them, the identifier of the business data of the second business object is the same as that of the business data of the first business object.

[0121] Exemplarily, the permission data can be stored in the database corresponding to the management microservice node and can be synchronized to the database corresponding to the second microservice node through the DRS cloud service.

[0122] For example, select the database corresponding to the management microservice node as the source database, and select the database where the second microservice node is located as the target database. Select the Share model table in the management microservice node as the source table. In this way, the Share table of the management microservice node can be synchronized to the database corresponding to the second microservice node.

[0123] As can be seen from the above, when synchronizing the permission data to the database corresponding to the second microservice node, the users indicated by the user identifiers with mapping relationships in the permission data have operation permissions for the business data indicated by the identifiers of the business data, and can be automatically synchronized to the second microservice node. Since the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object, the data permissions in the second microservice node are consistent with the mapping relationship included in the permission data. This solves the problem that the second microservice node cannot automatically inherit the data permissions of the first microservice node. Ultimately, in the distributed microservice system, users only need to apply for and understand the data permissions of the first microservice node, and then automatically have the permissions to access the business data in the second microservice node associated with the first microservice node. This realizes the transfer of the data permissions of one business object to another associated object.

[0124] The above describes the data permission management method in the distributed microservice system from the perspective of the management microservice node. By determining the first microservice node and the second microservice node through the management microservice node, and sending the obtained permission data in the first microservice node to the second microservice node, the transfer and automatic inheritance of data permissions are realized. Next, from the perspective of the client of the distributed microservice system, the method for users to apply the data permission management in the distributed microservice system will be described.

[0125] In a possible implementation manner, the distributed microservice system further includes a client. When the first user logs in to the client, the client is used to send a first access request to the second microservice node. The first access request includes the user identifier of the first user and is used to request access to the business data of the second business object in the second microservice node.

[0126] Exemplarily, Figure 11 shows an interaction process schematic diagram of a data permission management method provided by an embodiment of the present application. As Figure 11 shown, a CRM system runs on the server 220. Among them, the CRM system adopts a distributed microservice architecture, and different business objects correspond to different microservice nodes and databases. The terminal device 210 runs a CRM client. The first user can log in to the CRM system through the CRM client running on the terminal device and access the data with access permissions in different business objects.

[0127] When the first microservice node corresponds to the customer business object and the second microservice node corresponds to the contract business object, the first user logs in to the CRM system through the client running on the terminal device 210. The client sends a first access request for the second business data to the second microservice node (S201). Among them, the second microservice node runs on the server 220. The first access request includes the user identifier of the first user and is used to request access to the business data of the second business object in the second microservice node; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object. Specifically, when the first user requests access to the second business data in the second microservice node, it is to request access to the second business data in the contract business object. After the second microservice node in the server 220 obtains the first access request, it determines the first access result according to the permission data and the user identifier of the first user (S202).

[0128] Among them, the permission data includes the mapping relationship between the user identifier and the identifier of the business data of the first business object. The user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data; the permission data is sent from the management microservice node to the second microservice node. Exemplarily, the permission data can be stored in the share model. Since the second business object is an associated object dependent on the first business object in the business process, when the first business object is a customer object and the second business object is a contract business object, the identifier of the second business data is the identifier information of the customer. For example, the second microservice node in the server 220 queries the permission data through the share model according to the user identifier of the first user included in the first access request and the identifier corresponding to the second business data, and determines whether the first user has the right to access the second business data according to the query result. Specifically, the method of directly judging based on the share model is as follows:

[0129] select count(1)

[0130] from AccountShare

[0131] where AccountShare.accountId = 'object id' and AccountShare.userId = 'user identifier of the first user'

[0132] The second microservice node in server 220 determines a first access result based on the user identification and permission information of the first user included in the first access request, and the client receives the first access result sent by the second microservice node (S203). Among them, if the second microservice node in server 220 determines that there is a mapping relationship between the user identification of the first user in the permission data and the identification of the second service data, it indicates that the first user has the permission to access the second service data. The first user continues to access the second service data according to the access request. If the second microservice node in server 220 determines that there is no mapping relationship between the user identification of the first user in the permission information and the identification of the second service data, it indicates that the first user does not have the permission to access the second service data. At this time, the access result is that the second user has no access permission to the second service data.

[0133] Optionally, when the first business object is a customer object and the second business object is a contract business object, if the second user applies to access the data corresponding to customer A in the customer object, the permission data between the user identification of the second user and customer A in the customer object is updated at this time. The management microservice node synchronizes the permission data to the contract business object. When the second user wants to access the contract data corresponding to customer A, the contract business object determines that the second user also has the permission to access the contract data of customer A by querying the permission data between the user identification of the second user and customer A in the object. The second user does not need to apply to access the contract data corresponding to customer A in the contract business object again. This not only realizes the transfer and automatic inheritance of data permissions, improving the efficiency of data permission management. Moreover, in the process of authentication, by looking up the table, the dynamic calculation of permission relationships is avoided. Saving system computing power further improves the efficiency of data permission management.

[0134] The permission data can also provide a query function for users, further improving user convenience and user satisfaction. For example Figure 8 As shown, when the first microservice node in the CRM system is a customer business object, when the share model storing the permission data is synchronized to the contract business object, the after-sales business object, and the product business object, the customer business object can directly perform data permission filtering and screening based on the share model table.

[0135] For example, through the paging query of the share model, the user can directly query the list of business data of the customer business object that the user has permission to access. The query method is as follows:

[0136] select Account.*

[0137] from Account

[0138] join AccountShare

[0139] where Account.id = AccountShare.AccountId

[0140] and AccountShare.userId = 'user ID of the logged-in user'

[0141] limit 0, 10

[0142] For another example, through the paging query of the share model, the user can directly query the business data list of the contract business objects with access permissions. The query method is as follows:

[0143] select Contract.*

[0144] from Contract c

[0145] left join AccountShare a

[0146] For another example, through the paging query of the share model, the user can authenticate whether the current user has the permission to edit the contract business data. The query method is as follows:

[0147] Select count(1)

[0148] from Contract c

[0149] left join AccountShare a

[0150] where c.accountId = a.accountId and (c.contractId = 'contract ID passed from the page')

[0151] and (AccountShare.userId = 'user ID of the logged-in user' or (c.ownerId = 'user ID of the logged-in user') or (c.approver = 'user ID of the logged-in user'))

[0152] In the way of the share model, the associated objects of the customer business object automatically inherit the permissions of the business data of the customer business object. It realizes that the user who has the read and write permissions of the business data of the customer business object automatically has the read and write permissions of the business data in the contract business object associated with the customer business object. When the user applies for the permissions of the business data in each business object, the user only needs to understand and apply for the permissions of the business data of the customer business object. At the same time, since the permission data is calculated in advance and written into the Share model, when the service is used, only the Share model table needs to be simply connected, and the interface can quickly apply the permission data. This improves the performance of the service interface after adding the data permission logic.

[0153] In summary, the embodiment of the present application provides a method for managing data permissions, which realizes the transfer and automatic inheritance of data permissions in a distributed microservice system, and further improves the efficiency of data permission management. The method is applied to a distributed microservice system, which includes a first microservice node, a second microservice node, and a management microservice node. The method includes that the management microservice node determines the first microservice node and the second microservice node. The first microservice node is used to perform business operations on the business data of the first business object; the second microservice node is used to perform business operations on the business data of the second business object; wherein, in the business process, the second business object is an associated object that depends on the first business object. The management microservice node obtains the permission data in the first microservice node and sends the permission data to the second microservice node. Among them, the permission data includes the mapping relationship between the user identifier and the identifier of the business data of the first business object, and the user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object.

[0154] When the second microservice node receives a first access request for the second business data, the second microservice node determines a first access result according to the above permission data and the user identifier of the first user included in the first access request, and performs data authentication. Specifically, the permission data includes the mapping relationship between the user identifier of the first user and the identifier of the first business data, and the user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data. Since the identifier of the second business data of the second business object is the same as the identifier of the first business data of the first business object, the first user automatically obtains the operation permission for the second business data of the second business object.

[0155] The above-mentioned synchronization of permission data to the database corresponding to the second microservice node enables the users indicated by the user identifiers with mapping relationships in the permission data to automatically synchronize the operation permissions for the business data indicated by the identifiers of the business data to the second microservice node. The second microservice node can automatically inherit the permission data in the first microservice node, eliminating the need to separately apply for operation permissions for the second business data in the second microservice node, thereby improving the management efficiency of data permissions in the distributed microservice system.

[0156] The above mainly introduced the solution of the embodiment of the present application from the perspective of methods. It can be understood that in order to implement the functions in the above-mentioned data permission management, the data permission management device includes at least one of the corresponding hardware structures and software modules for executing each function. Those skilled in the art should easily realize that, combining the units and algorithm steps of each example described in the embodiments disclosed herein, the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiments of the present application.

[0157] The embodiments of the present application can divide the data permission management device into functional units according to the above method examples. For example, each functional unit can be divided corresponding to each function, or two or more functions can be integrated into one processing unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit. It should be noted that the division of units in the embodiments of the present application is illustrative, only a logical function division, and there may be other division methods in actual implementation.

[0158] Exemplarily, Figure 12 shows a schematic structural diagram of a data permission management device 400 provided by an embodiment of the present application. As Figure 12 shown, the data permission management device 400 can be applied to Figure 5 the server 220 shown. The data permission management device 400 includes:

[0159] A judgment module 410, configured to determine a first microservice node and a second microservice node; the first microservice node is used to perform business operations on the business data of the first business object; the second microservice node is used to perform business operations on the business data of the second business object; wherein, in the business process, the second business object is an associated object that depends on the first business object;

[0160] The collection module 420 is used to obtain the permission data in the first microservice node; the permission data includes the mapping relationship between the user identifier and the identifier of the business data of the first business object, and the user indicated by the user identifier with the mapping relationship has the operation permission for the business data indicated by the identifier of the business data.

[0161] The synchronization module 430 is used to send the permission data to the second microservice node; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object.

[0162] In a possible implementation manner, the collection module 420 is further used to obtain the operation log of the first microservice node; the operation log is used to record that the user triggers the first microservice node to perform a business operation on the business data of the first business object; by parsing the operation log, the permission data in the first microservice node is obtained.

[0163] As can be seen from the above, the above data permission management device 400 can be applied in Figure 4 the management microservice node 120 shown in the figure to implement the above Figure 7 data permission management method.

[0164] Among them, the judgment module 410, the collection module 420, and the synchronization module 430 can all be implemented by software or by hardware. Exemplarily, next, taking the judgment module 410 as an example, the implementation manner of the judgment module 410 is introduced. Similarly, the implementation manners of the collection module 420 and the synchronization module 430 can refer to the implementation manner of the judgment module 410.

[0165] As an example of a software functional unit, the judgment module 410 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above computing instance may be one or more. For example, the judgment module 410 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers for running this code may be distributed in the same region, or may be distributed in different regions. Further, the multiple hosts / virtual machines / containers for running this code may be distributed in the same availability zone (AZ), or may be distributed in different AZs, and each AZ includes one data center or multiple geographically close data centers. Among them, usually one region may include multiple AZs.

[0166] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Usually, one VPC is set up within one region. For cross-region communication between two VPCs within the same region and between VPCs in different regions, communication gateways need to be set up within each VPC to achieve interconnection between VPCs through these gateways.

[0167] As an example of a hardware functional unit, the determination module 410 may include at least one computing device, such as a server. Alternatively, the determination module 410 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). Among them, the above PLD may be implemented using a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0168] The multiple computing devices included in the determination module 410 can be distributed within the same region or across different regions. The multiple computing devices included in the determination module 410 can be distributed within the same availability zone (AZ) or across different AZs. Similarly, the multiple computing devices included in the determination module 410 can be distributed within the same VPC or across multiple VPCs. Among them, the multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0169] It should be noted that in other embodiments, the determination module 410 can be used to execute any step in the data permission management method, and the collection module 420 and the synchronization module 430 can be used to execute any step in the data permission management method. The steps to be implemented by the determination module 410, the collection module 420, and the synchronization module 430 can be specified as needed. The entire function of the data permission management device 400 is achieved by the determination module 410, the collection module 420, and the synchronization module 430 respectively implementing different steps in the data permission management method.

[0170] Figure 13 Shows a schematic diagram of the hardware of a server 220 provided by an embodiment of the present application. As Figure 13 As shown in the figure, the server 220 includes: a bus 901, a processor 902, a memory 903, and a communication interface 904. The processor 902, the memory 903, and the communication interface 904 communicate with each other through the bus 901. It should be understood that the number of processors and memories in the server 220 is not limited in this application.

[0171] The bus 901 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience in representation, Figure 13 only one line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus. The bus 901 can include a path for transmitting information between various components of the server 220 (for example, the processor 902, the memory 903, and the communication interface 904).

[0172] The processor 902 can include any one or more of processors such as a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Micro Processor (MP), or a Digital Signal Processor (DSP).

[0173] The memory 903 can include a volatile memory, such as a Random Access Memory (RAM). The processor 902 can also include a non-volatile memory, such as a Read-Only Memory (ROM), a flash memory, a Hard Disk Drive (HDD), or a Solid State Drive (SSD).

[0174] The memory 903 stores executable program codes. The processor 902 executes the executable program codes to respectively implement the functions of the judgment module 410, the acquisition module 420, and the synchronization module 430, thereby implementing the method for managing data permissions. That is to say, the memory 903 stores instructions for executing the method for managing data permissions.

[0175] Alternatively, executable code is stored in the memory 903, and the processor 902 executes the executable code to implement the functions of the aforementioned data permission management device 400 respectively, thereby implementing the data permission management method. That is, instructions for executing the data permission management method are stored on the memory 903.

[0176] The communication interface 904 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement the communication between the server 220 and other devices or communication networks.

[0177] As an example, in combination with Figure 12 , some or all of the functions of the judgment module 410, the acquisition module 420, and the synchronization module 430 of the data permission management device 400 can be implemented by Figure 13 the server 220 in

[0178] The embodiment of the present application also provides a server cluster. The server cluster includes at least one server. For example, it is a central server, an edge server, or a local server in a local data center. In some embodiments, the server can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0179] Figure 14 FIG. shows a schematic diagram of a server cluster provided by an embodiment of the present application. As Figure 14 shown, the server cluster includes at least one server 220. Instructions for executing the data permission management method that are the same can be stored in the memory 903 of one or more servers 220 in the server cluster.

[0180] In some possible implementation manners, partial instructions for the data permission management method can also be stored separately in the memory 903 of one or more servers 220 in the server cluster. In other words, a combination of one or more servers 220 can jointly execute the instructions for executing the data permission management method.

[0181] It should be noted that the memories 903 in different servers 220 in the server cluster can store different instructions, which are respectively used for partial functions of the data permission management device 400. That is, the instructions stored in the memories 903 of different servers 220 can implement the functions of one or more of the judgment module 410, the acquisition module 420, and the synchronization module 430.

[0182] In some possible implementation manners, one or more servers in the server cluster can be connected through a network. Among them, the network can be a wide area network or a local area network, etc. Figure 15 FIG. shows a schematic diagram of a possible implementation manner of a network connection provided by an embodiment of the present application. As Figure 15 As shown, the first server 220A and the second server 220B are connected via a network. Specifically, they are connected to the network through the communication interfaces in each server. In this possible implementation, the instructions for implementing the functions of the judgment module 410 and the acquisition module 420 are stored in the memory 903 of the first server 220A. At the same time, the instructions for implementing the function of the synchronization module 430 are stored in the memory 903 of the second server 220B.

[0183] Figure 15 The connection method between the computing device clusters shown can be considered in view of the requirements of the data permission management method provided in this application (such as storing a large amount of data). Therefore, it is considered to hand over the function implemented by the synchronization module to the second server 220B for execution.

[0184] It should be understood that Figure 15 the functions of the first server 220A shown in can also be completed by multiple servers 220. Similarly, the functions of the second server 220B can also be completed by multiple servers 220.

[0185] The embodiments of this application also provide another server cluster. The connection relationship between the computing devices in this computing device cluster can be similarly referred to Figure 14 and Figure 15 the connection method of the server cluster shown. The difference is that the same instructions for implementing the data permission management method can be stored in the memory 903 of one or more servers 220 in this server cluster.

[0186] In some possible implementations, the memory 903 of one or more servers 220 in this server cluster can also store some of the instructions for implementing the data permission management method respectively. In other words, a combination of one or more servers 220 can jointly execute the instructions for implementing the data permission management method.

[0187] It should be noted that the memories 903 in different servers 220 in the server cluster can store different instructions for implementing some functions of the distributed microservice system 100. That is, the instructions stored in the memories 903 of different servers 220 can implement the functions of the data permission management device 400.

[0188] The embodiments of this application also provide a computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When it runs on a computer, it causes the computer to execute the operations corresponding to any one of the implementation schemes and various feasible implementation manners of the data permission management method.

[0189] The embodiments of the present application further provide a computer program product containing instructions. When it runs on a computer, it causes the computer to execute the operations corresponding to any one of the implementation schemes and various feasible implementation manners of the method for managing data permissions.

[0190] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0191] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0192] The embodiments of the present application further provide a chip system, including: a processor, the processor is coupled with a memory, and the memory is used to store programs or instructions. When the programs or instructions are executed by the processor, the chip system implements the method in any one of the foregoing method embodiments.

[0193] Optionally, the processor in the chip system can be one or more. The processor can be implemented by hardware or by software. When implemented by hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented by software, the processor can be a general-purpose processor that realizes by reading the software code stored in the memory.

[0194] Optionally, the memory in the chip system can also be one or more. The memory can be integrated with the processor or can be separately arranged from the processor, which is not limited in the embodiments of the present application. Exemplarily, the memory can be a non-transitory processor, such as a read-only memory ROM, which can be integrated with the processor on the same chip or can be separately arranged on different chips. The embodiments of the present application do not specifically limit the type of the memory and the setting manner of the memory and the processor.

[0195] Exemplarily, the chip system may be a field programmable gate array (FPGA), may be an application specific integrated circuit (ASIC), may also be a system on chip (SoC), may also be a central processing unit (CPU), may also be a network processor (NP), may also be a digital signal processing circuit (DSP), may also be a microcontroller unit (MCU), may also be a programmable logic device (PLD) or other integrated chips.

[0196] The electronic device, computer storage medium, or computer program product provided in this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be elaborated here.

[0197] Through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and brevity of description, only the above division of each functional module is used as an example. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

[0198] In several embodiments provided in this application, it should be understood that the disclosed device and method can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point, the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical, mechanical or other form.

[0199] The unit described as a separated component may or may not be physically separated. The component displayed as a unit may be a physical unit or multiple physical units, and may be located in one place or distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0200] In addition, in each embodiment of the present application, each functional unit can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0201] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of the present application, in essence, or the part that makes a contribution, or all or part of the technical solution, can be embodied in the form of a software product. The software product is stored in a storage medium and includes several instructions for causing a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods of the embodiments of the present application. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

[0202] The above content is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.< / string> < / string>

Claims

1. A data authority management method, characterized in that: The method is applied to a distributed microservice system and is executed by a management microservice node in the distributed microservice system. The method includes: Determine a first microservice node and a second microservice node; the first microservice node is used to perform a business operation on the business data of the first business object; the second microservice node is used to perform a business operation on the business data of the second business object; wherein the second business object is an associated object that depends on the first business object in the business process; Obtaining permission data in the first microservice node; the permission data includes a mapping relationship between a user identifier and an identifier of the business data of the first business object, and the user indicated by the user identifier having the mapping relationship has operation permission on the business data indicated by the identifier of the business data; The permission data is sent to the second microservice node; the permission data is used by the second microservice node to determine an access result; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object.

2. The method according to claim 1, characterized in that The obtaining the permission data in the first microservice node includes: Obtaining an operation log of the first microservice node; the operation log is used to record a user triggering the first microservice node to perform the business operation on the business data of the first business object; The permission data in the first microservice node is obtained by parsing the operation log.

3. The method according to claim 1 or 2, characterized in that: The permission data is stored in a data sharing share model; the fields in the share model include the user identifier, the identifier of the business data and the permission type; the permission type includes a read operation and / or a write operation.

4. The method according to claim 1, characterized in that: The distributed microservice system also includes a client. When a first user logs in to the client, the client is used to send a first access request to the second microservice node. The first access request includes a user identifier of the first user and is used to request access to business data of the second business object in the second microservice node.

5. The method according to claim 4, characterized in that The second microservice node is used to receive the first access request and determine a first access result according to the permission data and a user identifier of the first user.

6. A data authority management method, characterized in that: The method is applied to a distributed microservice system, wherein the distributed microservice system includes a first microservice node, a second microservice node and a client; The method is performed by the second microservice node, and the method includes: receiving a first access request for second business data sent by a client; the first access request includes a user identifier of a first user, and is used to request access to business data of a second business object in the second microservice node; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object; The first microservice node is used to perform a business operation on the business data of the first business object; the second microservice node is used to perform a business operation on the business data of the second business object; in the business process, the second business object is an associated object that depends on the first business object; A first access result is determined based on the permission data and the user identifier of the first user; the permission data includes a mapping relationship between the user identifier and the identifier of the business data of the first business object, and the user indicated by the user identifier having the mapping relationship has operation authority over the business data indicated by the identifier of the business data; the permission data is sent by the management microservice node to the second microservice node.

7. The method according to claim 6, characterized in that The distributed microservice system includes the management microservice node, and the management microservice node is used to obtain the operation log of the first microservice node, and obtain the permission data in the first microservice node by parsing the operation log; The operation log is used to record that a user triggers the first microservice node to perform the business operation on the business data of the first business object.

8. The method according to claim 6 or 7, characterized in that: The permission data is stored in a data sharing share model; the fields in the share model include the user identifier, the identifier of the business data and the permission type; the permission type includes a read operation and / or a write operation.

9. A data authority management method, characterized in that: The method is applied to a distributed microservice system, wherein the distributed microservice system includes a first microservice node, a second microservice node and a client; The method is executed by the client, and includes: Sending a first access request for second business data to a second microservice node; the first access request includes a user identifier of a first user, and is used to request access to business data of a second business object in the second microservice node; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object; The first microservice node is used to perform a business operation on the business data of the first business object; the second microservice node is used to perform a business operation on the business data of the second business object; in the business process, the second business object is an associated object that depends on the first business object; Receive a first access result sent by the second microservice node; the first access result is determined by the second microservice node according to the permission data and the user identifier of the first user; the permission data includes a mapping relationship between the user identifier and the identifier of the business data of the first business object, and the user indicated by the user identifier having the mapping relationship has operation authority over the business data indicated by the identifier of the business data; the permission data is sent by the management microservice node to the second microservice node.

10. The method according to claim 9, characterized in that The distributed microservice system includes the management microservice node, and the management microservice node is used to obtain the operation log of the first microservice node, and obtain the permission data in the first microservice node by parsing the operation log; The operation log is used to record that a user triggers the first microservice node to perform the business operation on the business data of the first business object.

11. The method according to claim 9 or 10, characterized in that: The permission data is stored in a data sharing share model; the fields in the share model include the user identifier, the identifier of the business data and the permission type; the permission type includes a read operation and / or a write operation.

12. A data authority management device, characterized in that: The device is applied to manage microservice nodes, including: A judgment module, used to determine a first microservice node and a second microservice node; the first microservice node is used to perform a business operation on the business data of a first business object; the second microservice node is used to perform a business operation on the business data of a second business object; wherein the second business object is an associated object that depends on the first business object in the business process; A collection module, used to obtain permission data in the first microservice node; the permission data includes a mapping relationship between a user identifier and an identifier of the business data of the first business object, and the user indicated by the user identifier having the mapping relationship has operation permission on the business data indicated by the identifier of the business data; A synchronization module is used to send the permission data to the second microservice node; the permission data is used by the second microservice node to determine the access result; the identifier of the business data of the second business object is the same as the identifier of the business data of the first business object.

13. A server, characterized in that: The server includes: a processor and a memory for storing instructions executable by the processor; the processor is configured to execute the instructions so that the server executes the data authority management method as described in any one of claims 1-5 or 6-8.

14. A terminal device, characterized in that: The terminal device runs a client, including a processor and a memory for storing instructions executable by the processor; the processor is configured to execute the instructions so that the terminal device executes the data authority management method as described in any one of claims 9-11.

15. A computer program product, characterized in that The computer program product comprises instructions, and when the instructions are executed by a server, the server executes the data rights management method according to any one of claims 1-5 or 6-8.

Images