Data permission management method and related equipment

Abstract

The embodiment of the invention discloses a data permission management method and related equipment, belongs to the technical field of data security, and is used for realizing transfer and automatic inheritance of data permissions in a distributed micro-service system. The method is applied to the distributed micro-service system, is executed by a management micro-service node in the distributed micro-service system, and comprises the following steps: determining a first micro-service node and a second micro-service node; wherein the second business object in the business process is an associated object depending on the first business object; acquiring authority data in the first micro-service node; the authority data comprises a mapping relationship between the user identifier and the identifier of the business data of the first business object, and a user indicated by the user identifier with the mapping relationship has an operation authority for the business data indicated by the identifier of the business data; sending the permission data to the second micro-service 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 field of data security technology, and in particular, to a data permission management method and related equipment. Background Art

[0002] The customer relationship management system (CRM) is mainly used to manage the interaction between enterprises and customers. Enterprises can record basic information about customers through the CRM system, which can also help enterprises better conduct marketing and management. In the CRM system, various business objects are interrelated and jointly carry the key business information of the enterprise. In order to ensure the security and compliance of these data, it is particularly important to control the data permissions of these business objects.

[0003] In related technologies, attribute-based access control (ABAC) and policy-based access control (PBAC) models are usually used. The ABAC model is based on a set of attributes (e.g., user attributes, environment attributes, object attributes, etc.) to decide whether a user has the right to access the data resources of a business object. The PBAC model is based on a policy script to express that users can access the data resources of certain business objects under certain conditions.

[0004] However, under the current microservice architecture, CRM business objects are often dispersed among different microservices and databases for storage and management. Business objects within each microservice manage their own data permissions through ABAC or PBAC according to their own attribute rules. This results in the decentralized implementation of data permissions and the management of business objects. The associations between business objects do not extend to data permissions, resulting in the inability to inherit and transfer data permissions of business objects across microservices. When users request data permissions, they need to request them separately for different business objects. As the number of business objects increases and the complexity of their associations increases, data permission management becomes increasingly difficult. Summary of the invention

[0005] The embodiments of the present application provide a data permission management method and related equipment, which can realize the transfer and automatic inheritance of data permissions of business objects in a distributed microservice system, thereby improving the efficiency of data permission management.

[0006] In a first aspect, a data permission management method is provided, which is applied to a distributed microservice system and executed by a management microservice node in the distributed microservice system, and the method includes: determining 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, 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 a mapping relationship between a user identifier and an identifier of the business data of the first business object, and a user indicated by a user identifier having a mapping relationship has operation permission on the business data indicated by the identifier of the business data; sending 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 by 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. 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. This improves the management efficiency of data permissions of the distributed microservice system.

[0008] In one possible implementation, an operation log of the first microservice node is obtained; the operation log is used to record that a user triggers the first microservice node to perform a business operation on business data of the first business object; and permission data in the first microservice node is obtained by parsing the operation log.

[0009] As can be seen from the above, the management microservice node can obtain the operation log of the business data in the first microservice, and can determine the identity of the user who operates the first business data from the operation log, thereby determining the permission data. Dynamic update of permission data can be achieved, further improving the efficiency of data permission management.

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

[0011] From the above, we can see that storing 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 one possible implementation, 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 a 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 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 the first access result according to the permission data and the user identifier of the first user.

[0014] In a possible implementation, the dependency relationship between business objects corresponding to each microservice node in the distributed microservice system is obtained by using the unified modeling language UML; and the first microservice node and the second microservice node are determined according to the dependency relationship.

[0015] As can be seen from the above, by marking the relationship between various business objects in the distributed microservice 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 one possible implementation, the permission data in the share model is synchronized to the second microservice node through a cloud service.

[0017] From the above, it can be seen that synchronizing the permission data in the share model to the second microservice node through the cloud service can improve the efficiency of data permission synchronization, thereby improving the efficiency of data permission management.

[0018] In a second aspect, a data permission management method is provided, which is applied to a distributed microservice system and executed by a second microservice node in the distributed microservice system, the method comprising: 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, which 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; wherein 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; 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 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 permission on 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.

[0019] In a possible implementation, the distributed microservice system includes a management microservice node, which is used to obtain an operation log of a first microservice node, and obtain 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 a business operation on the business data of the first business object.

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

[0021] In a third aspect, a data permission management method is provided, which is applied to a distributed microservice system and executed by a client in the distributed microservice system, and the method 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, which 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; wherein 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; in the business process, the second business object is an associated object that depends on the first business object; receiving a first access result sent by the second microservice node; the first access result is determined by the second microservice node based on 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 permission on 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.

[0022] In a possible implementation, the distributed microservice system includes a management microservice node, which is used to obtain an operation log of a first microservice node, and obtain 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 a business operation on the business data of the first business object.

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

[0024] In a fourth aspect, a data permission management device is provided, the device comprising: 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 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; 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 business data of the first business object, and a user indicated by a user identifier having a mapping relationship has operation permission on the business data indicated by the identifier of the business data; A synchronization module is used to send 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.

[0025] In one possible implementation, the acquisition module is also used to 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 a business operation on the business data of the first business object; and the permission data in the first microservice node is obtained by parsing the operation log.

[0026] It can be seen from the above that the description of possible technical solutions and beneficial effects executed by the above-mentioned various functional modules can refer to the technical solutions provided by the above-mentioned first aspect or its corresponding possible implementation methods, and will not be repeated here.

[0027] In a fifth aspect, an embodiment of the present application provides a server, the server comprising a processor and a memory for storing processor executable instructions; the processor is configured to execute instructions so that the server executes the data permission management method of the first aspect or the second aspect mentioned above.

[0028] In a sixth aspect, an embodiment of the present application provides a terminal device, which runs a client, including a processor and a memory for storing processor executable instructions; the processor is configured to execute instructions so that the terminal device executes the data permission management method of the third aspect mentioned above.

[0029] In the seventh aspect, an embodiment of the present application provides a computer-readable storage medium, in which at least one computer program is stored, and the computer program is loaded and executed by a processor to implement the data permission management method as described in the first aspect or the second aspect above.

[0030] 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 including computer instructions, the computer instructions being 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 various optional implementations of the first aspect or the second aspect.

[0031] For the specific description of the third to eighth aspects and their various implementations in the embodiments of the present application, reference can be made to the detailed description in the first aspect, the second aspect and their various implementations; and for the beneficial effects of the third to eighth aspects and their various implementations, reference can be made to the analysis of the beneficial effects in the various implementations of the first aspect and the second aspect, which will not be repeated here.

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

[0033] Figure 1 A schematic diagram of the architecture of an attribute-based access control model ABAC provided by the related art is shown; Figure 2 A schematic diagram of the architecture of a policy-based access control model PBAC provided by the related technology is shown; Figure 3 A schematic diagram of the structure of a CRM system that controls permissions through ABAC or PBAC in a microservice architecture provided by related technologies is shown; Figure 4 A schematic diagram of the architecture of a distributed microservice system 100 provided in an embodiment of the present application is shown; Figure 5 A schematic diagram of the hardware architecture of a CRM system provided in an embodiment of the present application is shown; Figure 6 A schematic diagram of an application architecture of a data rights management system provided by an embodiment of the present application is shown; Figure 7 A schematic diagram of a data permission management method provided in an embodiment of the present application is shown; Figure 8 A schematic diagram showing the association relationship of business objects at the business level in a CRM system provided in an embodiment of the present application; Fig. 9 A schematic diagram showing a UML class diagram provided in an embodiment of the present application marking an association relationship between a contract business object and a customer business object; Fig.10 A schematic diagram of a process for obtaining an operation log through a cloud service provided in an embodiment of the present application is shown; Fig.11 A schematic diagram of an interactive process of a data authority management method provided in an embodiment of the present application is shown; Fig.12 A schematic diagram of the structure of a data authority management device 400 provided in an embodiment of the present application is shown; Fig.13 A schematic diagram of server 220 hardware provided in an embodiment of the present application is shown; Fig.14 A schematic diagram of a server cluster provided in an embodiment of the present application is shown; Fig.15 A schematic diagram showing a possible implementation of a network connection provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] The technical solution in the embodiment of the present application will be described below in conjunction with the drawings in the embodiment of the present application. Among them, in the description of the present application, unless otherwise specified, " / " indicates 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 kind of association relationship describing the associated objects, indicating that there can be three relationships, for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, 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 of the following" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple. In addition, in order to clearly describe the technical solutions of 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 or similar items with basically the same functions and effects.

[0035] Those skilled in the art will appreciate that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit the difference. At the same time, in some embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0036] In addition, the device architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. A person of ordinary skill in the art can appreciate that with the evolution of the device architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0037] Terminology Introduction: Customer Relationship Management System (CRM): is a systematic management method used to optimize the relationship between enterprises and customers. CRM improves customer satisfaction and loyalty by centrally managing customer information, tracking customer interaction history, and analyzing customer behavior and preferences. At the same time, it helps enterprises to automate processes and effectively analyze data in terms of customer acquisition, customer retention, and customer relationship maintenance, thereby achieving business growth.

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

[0039] Related object: In the CRM system, an associated object refers to a business object that is closely related to or has a dependent relationship with a certain business object. The existence of an associated object is usually to achieve business linkage.

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

[0041] First, the application scenarios of the embodiments of the present application are exemplarily introduced.

[0042] 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.

[0043] 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.

[0044] 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 2 As shown in the figure, when a user initiates an access request to a data resource, authentication is performed through the policy execution point on the access path. The policy execution point determines whether the user has the right to access the data resource through the policy engine. The policy engine dynamically executes pre-defined permission policies and databases, and returns the policy execution results to the user. Among them, the policy script of the policy engine is relatively flexible and can be regarded as a small language. The attributes, conditional rules, expressions, and even some business logic in ABAC can be written into the policy to assist in calculations.

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

[0046] Since there are ABAC or PBAC that control business object permissions in the customer microservice and contract microservice respectively, users need to apply separately when applying for customer business objects or contract business objects. This results in the data permissions of each business object being scattered, and the data permissions of business objects cannot be inherited and transferred across microservices. For example, if a user has applied for data permissions for a customer business object, he should be able to automatically see the data of the contract associated with the customer without having to apply for data permissions for the contract separately. Therefore, when users need data permissions for multiple business objects, they need to apply for them one by one. Not only does this affect the user experience; but in the scenario of multiple permissions applications, the interface performance when users access data will also decrease. As a result, the efficiency of data permission management in the CRM system is low.

[0047] In view of this, an embodiment of the present application provides a method for managing data permissions, which is applied to a distributed microservice system, and the distributed microservice system 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 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 permissions on 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.

[0048] In the case where the second microservice node receives a first access request for the second business data, the second microservice node determines the first access result and performs data authentication based on the above-mentioned permission data and the user identifier of the first user included in the first access request. Specifically, if the permission data includes a 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 having the mapping relationship has the operation authority 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 authority 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, and there is no need to apply for the operation authority of the second business data in the second microservice node separately, thereby improving the management efficiency of data permissions of the distributed microservice system.

[0049] Secondly, the system architecture of the embodiment of the present application is exemplarily introduced.

[0050] Figure 4 FIG. 1 shows a schematic diagram of the architecture of a distributed microservice system 100 provided in an embodiment of the present application. Figure 4 As shown, the distributed microservice 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 business data of different business objects.

[0051] 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.

[0052] 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.

[0053] 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 5As 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.

[0054] 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.

[0055] The terminal device 210 runs a client of the CRM system, and the user can access the CRM system through the client on the terminal device 210. The terminal device 210 also includes a display screen for displaying a user interface of the CRM system, and the user can interact with the CRM system through the user interface. The terminal device 210 may specifically include a mobile phone, a smart watch, a tablet computer, a foldable electronic device, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (Ultra-Mobile Personal Computer, UMPC), a netbook, a cellular phone, a personal digital assistant (Personal Digital Assistant, PDA), an augmented reality (Augmented Reality, AR) device, a virtual reality (Virtual Reality, VR) device, an artificial intelligence (Artificial Intelligence, AI) device, a wearable device, a vehicle-mounted device, and other electronic devices with communication capabilities. The embodiment of the present application does not impose any special restrictions on the specific type of the terminal device 210.

[0056] The terminal device 210 is used to send a first access request for the second business data to the second microservice node in the server 220. The first access request includes a user identifier of the first user; 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; and the second business object is an associated object that depends on the first business object in the business process.

[0057] The terminal device 210 receives the 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 the operation permission for 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.

[0058] Optional, Figure 6 FIG. 1 is a schematic diagram showing an application architecture of a data rights management system provided by an embodiment of the present application. Figure 6 As shown, the user can access the CRM system running in the server 220 through the CRM user interface on the terminal device 210. The CRM system includes business object 01 and the corresponding first database, business object 02 and the corresponding second database, business object 03 and the corresponding third database. There is an association relationship between the various business objects in the CRM system, and they run independently in their respective corresponding microservice nodes. The management microservice node 120 can be a different microservice node from the microservice nodes corresponding to each business object in the CRM system, and is used to implement the data authority management method.

[0059] It is understandable 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 authority management system is only an example and does not constitute a limitation on the technical solution provided in the embodiment of the present application.

[0060] It should be noted that the system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of the system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0061] For ease of understanding, the following is an exemplary introduction to the data permission management method provided by the present application in conjunction with the accompanying drawings. The data permission management method is applicable to Figure 4 A distributed microservice system 100 is shown.

[0062] Figure 7 The following is a flow chart of a data permission management method provided by an embodiment of the present application, which is executed by a management microservice node in a distributed microservice system. Figure 7 As shown, the method comprises the following steps: S101: A management microservice node determines a first microservice node and a second microservice node.

[0063] 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.

[0064] For example, a distributed microservice system usually includes a large number of business objects, and business operations corresponding to business data of different business objects are executed by different microservice nodes. Each business object usually has an association relationship at the business level. Figure 8 A schematic diagram showing the association relationship of business objects at the business level in a CRM system provided in an embodiment of the present application is shown. Figure 8 As shown, the CRM system includes customer business objects, contract business objects, after-sales business objects, product business objects, and work order business objects. Among them, the customer business object is the root object of the CRM system. Since the corresponding customer business object must be selected first when creating a contract business object, the contract data is generated based on the customer data. Therefore, the contract business object is dependent on the customer business object, and the data corresponding to the contract business object is also dependent on the contract business object. Similarly, the contract business object, after-sales business object, and 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.

[0065] In a possible implementation, the dependency relationship between business objects corresponding to each microservice node in the distributed microservice system is obtained by using the unified modeling language UML; and the first microservice node and the second microservice node are determined according to the dependency relationship.

[0066] Exemplarily, the relationship between each business object in the distributed microservice system is marked by a UML class diagram, and the first microservice node and the second microservice node are determined according to the association relationship between each business data in the business process. For example, taking the customer business object and contract business object in the CRM system as an example, Fig. 9 A schematic diagram showing the association relationship between a contract business object and a customer business object in a UML class diagram provided by an embodiment of the present application is shown. Fig. 9As shown, the contract business object includes the contract identifier A and the contract name; the customer business object includes the customer identifier A and the customer name. Among them, the contract identifier A corresponds to the contract name; the customer identifier A corresponds to the customer name. On the domain model of the contract business object, there is customer identification information pointing to the customer business object. That is, there is a pointing relationship between the identification information of the contract object in the contract business object and the identification information of the corresponding customer object. If the identification information of the first customer is A, then the identification information of the contract corresponding to the first customer is also A, and the contract depends on the customer information. In the above way, the relationship between the main business objects in the distributed microservice system can be gradually marked out, thereby determining the first microservice node and the second microservice node of the system.

[0067] Therefore, in Figure 8 The 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 a microservice node corresponding to a customer business object, then the second microservice node is a microservice node corresponding to an associated object of the customer business object, including a microservice node corresponding to a contract business object, a microservice node corresponding to an after-sales business object, and a microservice node corresponding to a product business object. If the first microservice node is a microservice node corresponding to an after-sales business object, then the second microservice node is a microservice node corresponding to an associated object of the after-sales business object, including a microservice node corresponding to a work order business object.

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

[0069] The authority 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 a mapping relationship has operation authority over the business data indicated by the identifier of the business data.

[0070] In a possible implementation manner, an operation log of the first microservice node is obtained; and permission data in the first microservice node is obtained by parsing the operation log.

[0071] 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.

[0072] Optionally, before obtaining the operation log corresponding to the first business data, determine the attribute information related to the data authority in the operation log. The operation log includes some attribute fields related to the authority of the business data corresponding to the business object. The user identification of the first user includes fields related to the authority of the first business data.

[0073] For example, check 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 a customer business object as an example, the user ID of the first user includes a responsible person field, a sales team field, or an approver field.

[0074] In one possible implementation, the management microservice node obtains a binary operation log of a database corresponding to the first business data in the first microservice node; the binary operation log is used to record the change operation 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.

[0075] 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 operation of the database corresponding to the first microservice node and the change of the field corresponding to the first user in the binary operation log, thereby obtaining the operation log of the first business data.

[0076] for example, Fig.10 A schematic diagram of a process for obtaining an operation log through a cloud service provided by an embodiment of the present application is shown. Fig.10 As shown, after determining the first microservice node, determine the attribute field corresponding to the first user corresponding to the first business data, record the attribute field table storing the user information of the first user, obtain the binary log of the first database corresponding to the first business object, and synchronize the binary log of the first database to the kafka service through the data replication service (DRS) cloud 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, generates a mapping relationship between the identifier of the first business data and the user identifier of the first user, and thus generates permission data.

[0077] 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.

[0078] In some exemplary embodiments, the management microservice node modifies the user identifier of the first user in the permission data that has a mapping relationship with the identifier of the first business data based on the user identifier of the first user in the operation log, thereby updating the mapping relationship between the identifier of the first business data and the user identifier of the first user.

[0079] The permission data is stored in the Share model. The fields in the Share model include user ID, business data ID and permission type. The permission type includes read operation and / or write operation.

[0080] Optionally, the Share model can also include the reason for exercising the right. The reason for exercising the right field indicates the way in which the user obtains the access rights to the first business data in the first microservice. In the CRM system, the most common types of reasons for exercising the right are Owner, Sales Team, Approve, Organization, Application for Permission, etc. The reason for exercising the right field can be further subdivided into secondary reasons for exercising the right. For example, if the reason for exercising the right is the sales team, there can be team members with different roles such as Project Manager (PM), Pre-sales Engineer, System Analyst (SA), or Ecosystem Manager.

[0081] In other exemplary embodiments, 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 identification information of the first user in the identifier of the first business data, that is, adding a new first user, the permission information of the first business data has changed, and the management microservice node parses the operation log to obtain the change of the field information corresponding to the first user, thereby updating the permission data.

[0082] For example, manage microservice nodes to connect to the above Fig.10 The Kafka service in the parses the operation log according to the message format when DRS delivers Kafka. The data structure obtained after parsing is as follows: Public class BinlogEvent{ Private String eventKey; Private String tableName; / / When Kafka delivers binlog events, the shard is key, and the format is eventKey. tableName Private map<string,string> afterDateMap; / / All fields of the data row after this update Private map<string,string> beforeDateMap; / / All fields of the data row before this update Private String operation; / / Change type: INERT\UPDATE\DELETE Private List <string>changedFields; / / Which fields have been modified in this update } The above data structure contains the field Key / Value information before and after the data row is changed, 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 StringeventKey field represents the string key value; the Private String tableName field represents the string file name; the Private map<string,string> The afterDateMap field indicates all fields of the data row after this update; Private map<string,string> The beforeDateMap field indicates all fields of the data row before this update; Private String operation indicates the type of change, which can be add, update, or delete; Private List <string>changedFields indicates which fields have been modified in this update.

[0083] It should be understood that the data structure obtained after the above analysis is only an example and does not constitute a specific limitation. Different data structures correspond to different application scenarios and permission data requirements.

[0084] Taking the example that the first user field includes the responsible person field, the user identifier corresponding to the responsible person field indicates the user who has the right to access the first business data. The user's identification information may specifically include the user's unique identifier such as the user's work number, ID number, mobile phone number, or CRM system account. If the user's identification information corresponding to the responsible person field corresponding to the first business data includes 001, 002, and 003. When user 001 accesses the first business data and adds the user's identification information 004 corresponding to the responsible person field, the operation log is parsed according to the message format when DRS delivers to Kafka, and it can be determined that the responsible person field has been modified.

[0085] Taking the first business object as a customer business object as an example, the data identifier 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 results of parsing the operation log, the ID, responsible person ID, exercise reason and exercise type of the first business data are extracted from the operation log, and the obtained permission information before and after the update is shown in Table 1: Table 1

[0086] As can be seen from the above table, the responsible persons in the updated permission data include 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.

[0087] S103: The management microservice node sends permission data to the second microservice node.

[0088] 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.

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

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

[0091] From the above, it can be seen that the permission data is synchronized to the database corresponding to the second microservice node, and the user indicated by the user identifier with a mapping relationship in the permission data has the operation permission for the business data indicated by the identifier of the business data, which 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 contained in the permission data. The problem that the second microservice node cannot automatically inherit the data permissions of the first microservice node is solved. Ultimately, users in the distributed microservice system only need to apply for and understand the data permissions of the first microservice node, and they automatically have the permission to access the business data in the second microservice node associated with the first microservice node. The data permissions of a business object are transferred to another associated object.

[0092] The above describes the data permission management method in the distributed microservice system from the perspective of managing microservice nodes. The first microservice node and the second microservice node are determined by the management microservice node, and the permission data obtained in the first microservice node is sent to the second microservice node, thereby realizing the transfer and automatic inheritance of data permissions. The following describes the data permission management method in the distributed microservice system for users from the perspective of the client of the distributed microservice system.

[0093] In one possible implementation, 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 a 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 a second business object in the second microservice node.

[0094] For example, Fig.11 FIG. 1 is a schematic diagram showing an interactive process of a data authority management method provided by an embodiment of the present application. Fig.11 As shown, a CRM system is running on the server 220. 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, and 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 rights in different business objects.

[0095] In the case where 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, which 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, the first user requests access to the second business data in the second microservice node, that is, 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 (S202) according to the permission data and the user identifier of the first user.

[0096] Among them, 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 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. Exemplarily, the permission data can be stored in a share model. Since the second business object is an associated object that depends 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 customer's identification information. 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: select count(1) from AccountShare where AccountShare.accountId = 'object id' and AccountShare.userId = 'user id of the first user' The second microservice node in the server 220 determines the first access result according to the user identifier 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). If the second microservice node in the server 220 determines that there is a mapping relationship between the user identifier of the first user in the permission data and the identifier of the second business data, it means that the first user has the permission to access the second business data. The first user continues to access the second business data according to the access request. If the second microservice node in the server 220 determines that there is no mapping relationship between the user identifier of the first user in the permission information and the identifier of the second business data, it means that the first user does not have the permission to access the second business data. At this time, the access result is that the second user has no access to the second business data.

[0097] 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 second user's user ID and customer A in the customer object is updated. The management microservice node synchronizes the permission data to the contract business object. When the second user wants to access the data of the contract corresponding to customer A, the contract business object determines that the second user also has access to customer A's contract data by querying the permission data between the second user's user ID and customer A in the object. The second user does not need to apply again to access the data corresponding to the contract of customer A in the contract business object. This not only realizes the transfer and automatic inheritance of data permissions, but also improves the efficiency of data permission management. Moreover, in the process of authentication, dynamic calculation of permission relationships is avoided by looking up tables. This saves system computing power and further improves the efficiency of data permission management.

[0098] The permission data can also provide users with query functions, further improving user convenience and user satisfaction. Figure 8 As shown, in the case where the first microservice node in the CRM system is a customer business object, when the share model storing permission data is synchronized to the contract business object, after-sales business object, and product business object, the customer business object can directly filter and screen data permissions based on the share model table.

[0099] For example, users can directly query the business data list of customer business objects that they have permission to access through paging query of the share model. The query method is as follows: select Account.* from Account join AccountShare where Account.id = AccountShare.AccountId and AccountShare.userId = 'Login user id' limit 0,10 For example, users can directly query the business data list of the contract business object to which they have permission to access through the paging query of the share model. The query method is as follows: select Contract.* from Contract c left join AccountShare a For another example, a user can verify whether the current user has the authority to edit contract business data through paging query of the share model. The query method is as follows: Select count(1) from Contract c left join AccountShare a where c.accountId = a.accountId and (c.contractId = 'Contract ID passed from the page') and (AccountShare.userId = 'Login user id' or (c.ownerId= 'Login user id')or (c.approver= 'Login user id')) Through the share model, the associated objects of the customer business object automatically inherit the permissions of the customer business object's business data. This means that users who have the read and write permissions of the customer business object's business data automatically have the read and write permissions of the business data in the contract business object associated with the customer business object. When applying for permissions for business data in each business object, users only need to understand and apply for permissions for 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 using the business, you only need to simply connect to the Share model table, and the interface quickly applies the permission data. This improves the performance of the business interface after superimposing the data permission logic.

[0100] In summary, the embodiment of the present application provides a data permission management method, 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 includes an application 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 the second business object is an associated object that depends on the first business object in the business process. The management microservice node obtains the permission data in the first microservice node and sends the permission data to the second microservice node. wherein 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 authority over 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.

[0101] When the second microservice node receives the first access request for the second business data, the second microservice node determines the first access result and performs data authentication based on the above-mentioned permission data and the user identifier of the first user included in the first access request. Specifically, the permission data includes a 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 having the mapping relationship has the operation authority 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 authority for the second business data of the second business object.

[0102] In the above, the permission data is synchronized to the database corresponding to the second microservice node. The user indicated by the user identifier with a mapping relationship in the permission data has the operation permission for the business data indicated by the identifier of the business data, which can be automatically synchronized to the second microservice node. The second microservice node can automatically inherit the permission data in the first microservice node, and there is no need to apply for the operation permission of the second business data in the second microservice node separately, thereby improving the management efficiency of data permissions of the distributed microservice system.

[0103] The above mainly introduces the scheme of the embodiment of the present application from the perspective of the method. It is understandable that, in order to realize the functions in the management of the above-mentioned data permissions, the data authority management device includes at least one of the hardware structures and software modules corresponding to the execution of each function. It should be easily appreciated by those skilled in the art that, in combination with 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 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 and technical personnel 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.

[0104] The embodiment of the present application can divide the data permission management device into functional units according to the above method example. 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 software functional units. It should be noted that the division of units in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

[0105] For example, Fig.12 FIG. 4 is a schematic diagram showing a structure of a data authority management device 400 provided in an embodiment of the present application. Fig.12 As shown, the data authority management device 400 can be applied to Figure 5 In the server 220 shown, the data authority management device 400 includes: The judgment module 410 is 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 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; The acquisition module 420 is used to obtain the 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 the operation permission for the business data indicated by the identifier of the business data; 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.

[0106] In one possible implementation, the acquisition module 420 is also used to 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 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.

[0107] As can be seen from the above, the data authority management device 400 can be applied to Figure 4 In the management microservice node 120 shown in FIG. Figure 7 How to manage data permissions in .

[0108] Among them, the judgment module 410, the acquisition module 420 and the synchronization module 430 can all be implemented by software, or can be implemented by hardware. Exemplarily, the following takes the judgment module 410 as an example to introduce the implementation of the judgment module 410. Similarly, the implementation of the acquisition module 420 and the synchronization module 430 can refer to the implementation of the judgment module 410.

[0109] The judgment module 410 is taken as an example of a software functional unit, and 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-mentioned 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 used to run the code may be distributed in the same region (region) or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, and each AZ includes a data center or multiple data centers with similar geographical locations. Among them, usually a region can include multiple AZs.

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

[0111] The judgment module 410 is taken as an example of a hardware functional unit, and the judgment module 410 may include at least one computing device, such as a server, etc. Alternatively, the judgment module 410 may also be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), etc. The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0112] The multiple computing devices included in the judgment module 410 can be distributed in the same region or in different regions. The multiple computing devices included in the judgment module 410 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the judgment module 410 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0113] It should be noted that, in other embodiments, the judgment module 410 can be used to execute any step in the data permission management method, the acquisition module 420 and the synchronization module 430 can be used to execute any step in the data permission management method, and the steps that the judgment module 410, the acquisition module 420 and the synchronization module 430 are responsible for implementing can be specified as needed. The judgment module 410, the acquisition module 420 and the synchronization module 430 respectively implement different steps in the data permission management method to realize all the functions of the data permission management device 400.

[0114] Fig.13 FIG. 2 shows a schematic diagram of a server 220 hardware provided in an embodiment of the present application. Fig.13 As shown, 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 present application does not limit the number of processors and memories in the server 220.

[0115] The bus 901 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.13 The bus 901 is represented by only one line, but it does not mean that there is only one bus or one type of bus. The bus 901 may include a path for transmitting information between various components of the server 220 (eg, the processor 902, the memory 903, and the communication interface 904).

[0116] The processor 902 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0117] The memory 903 may include a volatile memory, such as a random access memory (RAM). The processor 902 may 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).

[0118] The memory 903 stores executable program codes, and 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 data permission management method. In other words, the memory 903 stores instructions for executing the data permission management method.

[0119] Alternatively, the memory 903 stores executable codes, and the processor 902 executes the executable codes to respectively implement the functions of the aforementioned data authority management device 400, thereby implementing the data authority management method. That is, the memory 903 stores instructions for executing the data authority management method.

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

[0121] As an example, combining Fig.12 , some or all of the functions in the judgment module 410, the acquisition module 420 and the synchronization module 430 of the data authority management device 400 can be Fig.13 The server 220 in is implemented.

[0122] 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.

[0123] Fig.14 A schematic diagram of a server cluster provided in an embodiment of the present application is shown. Fig.14 As shown, the server cluster includes at least one server 220. The memory 903 in one or more servers 220 in the server cluster may store the same instructions for executing the data authority management method.

[0124] In some possible implementations, the memory 903 of one or more servers 220 in the server cluster may also store partial instructions for the data authority management method. In other words, the combination of one or more servers 220 may jointly execute instructions for executing the data authority management method.

[0125] It should be noted that the memory 903 in different servers 220 in the server cluster can store different instructions, which are respectively used for part of the functions of the data authority management device 400. That is, the instructions stored in the memory 903 in different servers 220 can realize the functions of one or more modules in the judgment module 410, the collection module 420, and the synchronization module 430.

[0126] In some possible implementations, one or more servers in the server cluster may be connected via a network, which may be a wide area network or a local area network. Fig.15 A schematic diagram showing a possible implementation of a network connection provided by an embodiment of the present application is shown. Fig.15 As shown, the first server 220A and the second server 220B are connected via a network. Specifically, they are connected to the network via a communication interface in each server. In this type of possible implementation, the memory 903 in the first server 220A stores instructions for executing the functions of the judgment module 410 and the acquisition module 420. At the same time, the memory 903 in the second server 220B stores instructions for executing the functions of the synchronization module 430.

[0127] Fig.15 The connection method between the computing device clusters shown may be considered to be in accordance with the data authority management method provided in this application (eg, storing a large amount of data), and therefore the functions implemented by the synchronization module may be considered to be executed by the second server 220B.

[0128] It should be understood that Fig.15 The function of the first server 220A shown in FIG. 2 may also be completed by multiple servers 220. Similarly, the function of the second server 220B may also be completed by multiple servers 220.

[0129] The present application embodiment also provides another server cluster. The connection relationship between the computing devices in the computing device cluster can be similar to that of Fig.14 and Fig.15 The connection mode of the server cluster is shown in FIG. 1. The difference is that the memory 903 in one or more servers 220 in the server cluster may store the same instructions for executing the data authority management method.

[0130] In some possible implementations, the memory 903 of one or more servers 220 in the server cluster may also store partial instructions for executing the data authority management method. In other words, the combination of one or more servers 220 may jointly execute the instructions for executing the data authority management method.

[0131] It should be noted that the memory 903 in different servers 220 in the server cluster can store different instructions for executing part of the functions of the distributed microservice system 100. That is, the instructions stored in the memory 903 in different servers 220 can implement the functions of the data authority management device 400.

[0132] An embodiment of the present application also provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computer, the computer executes operations corresponding to any one implementation scheme and various feasible implementation schemes of the data permission management method.

[0133] The embodiment of the present application also provides a computer program product including instructions, which, when executed on a computer, enables the computer to execute operations corresponding to any one implementation scheme and various feasible implementation schemes of the data permission management method.

[0134] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0135] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0136] An embodiment of the present application also provides a chip system, including: a processor, the processor is coupled to a memory, the memory is used to store programs or instructions, when the program or instructions are executed by the processor, the chip system implements the method in any of the above method embodiments.

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

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

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

[0140] The electronic device, computer storage medium or computer program product provided in this application is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above and will not be repeated here.

[0141] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0142] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. 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 is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0143] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, which may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

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

[0145] 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 embodiment of the present application can be essentially or the contributing part or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the methods of each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0146] The above contents are only specific implementation methods 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 shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall 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 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 and is executed by a second microservice node in the distributed microservice system. 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 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; 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 and is executed by a client in the distributed microservice system. The method 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 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; 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 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