访问数据的方法及装置与流程

1.本公开涉及计算机技术领域，并且更为具体地，涉及一种访问数据的方法及装置。


背景技术：

2.现有技术中，分布式资源管理(distributed resource management，drm)配置类杂乱无章的放置使用，增加了线上drm配置变更的故障率。


技术实现要素：

3.本公开实施例提供一种访问数据的方法及装置。下面对本公开实施例涉及的各个方面进行介绍。
4.第一方面，提供一种访问数据的方法，包括：运行第一应用，所述第一应用的软件包包括分布式资源管理drm配置包，所述drm配置包的包目录具有多个层级，所述多个层级之间从高层级到低层级排列，所述多个层级中的第一层级高于所述多个层级中的第二层级，且所述第一层级与所述第二层级相邻，所述第一层级包括所述第一应用的第一配置包，所述第一配置包用于描述所述第一应用对应的领域，所述第一配置包包括所述领域对应的drm配置类和/或第二配置包，其中，所述领域对应的drm配置类和/或所述第二配置包位于所述第二层级，所述第二配置包用于描述所述领域的从属领域；访问所述第一应用的drm配置类。
5.作为一种可能的实现方式，所述drm配置包的包目录具有树状结构，所述树状结构的根节点对应所述drm配置包，所述树状结构的叶子节点对应所述第一应用的drm配置类。
6.作为一种可能的实现方式，所述树状结构具有位于所述第一层级的叶子节点，所述第一层级的叶子节点对应第一drm配置类，其中，所述第一drm配置类包括所述领域对应的drm配置类。
7.作为一种可能的实现方式，所述多个层级依次包括应用层、产品层、场景层和配置层。
8.作为一种可能的实现方式，所述第一应用的drm配置类中的配置值基于map容器或注解进行更新。
9.第二方面，一种访问数据的装置，包括：运行单元，用于运行第一应用，所述第一应用的软件包包括分布式资源管理drm配置包，所述drm配置包的包目录具有多个层级，所述多个层级之间从高层级到低层级排列，所述多个层级中的第一层级高于所述多个层级中的第二层级，且所述第一层级与所述第二层级相邻，所述第一层级包括所述第一应用的第一配置包，所述第一配置包用于描述所述第一应用对应的领域，所述第一配置包包括所述领域对应的drm配置类和/或第二配置包，其中，所述领域对应的drm配置类和/或所述第二配置包位于所述第二层级，所述第二配置包用于描述所述领域的从属领域；访问单元，用于利用所述drm配置包，访问所述第一应用的drm配置类。
10.作为一种可能的实现方式，所述drm配置包的包目录具有树状结构，所述树状结构
的根节点对应所述drm配置包，所述树状结构的叶子节点对应所述第一应用的drm配置类。
11.作为一种可能的实现方式，所述树状结构具有位于所述第一层级的叶子节点，所述第一层级的叶子节点对应第一drm配置类，其中，所述第一drm配置类包括所述领域对应的drm配置类。
12.作为一种可能的实现方式，所述多个层级依次包括应用层、产品层、场景层和配置层。
13.作为一种可能的实现方式，所述第一应用的drm配置类中的配置值基于map容器或注解进行更新。
14.第三方面，提供一种访问数据的装置，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面或第一方面中任一实现方式所述的方法。
15.第四方面，提供一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第一方面中任一实现方式所述的方法。
16.第五方面，提供一种计算机程序产品，包括可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第一方面中任一实现方式所述的方法。
17.本公开实施例通过在第一应用中设置用于管理drm配置类的drm配置包，并将drm配置包的文件目录设置为具有从高层级到低层级排列的多个层级。该多个层级中的第一层级包括描述第一应用对应的领域的第一配置包，第一配置包包括该领域对应的drm配置类和/或第一配置包的从属领域配置包。这样一来，就使得第一应用中的drm配置类呈现集中有序的状态，减轻了学习drm配置数据的时间成本，从而有助于降低线上drm配置变更的故障率。
附图说明
18.图1是本公开一实施例提供的访问数据的方法的流程示意图。
19.图2是本公开一实施例提供的树状结构包目录的结构示意图。
20.图3是本公开一实施例提供的树状结构领域模型的结构示意图。
21.图4是本公开一实施例提供的访问数据的装置的结构示意图。
22.图5是本公开另一实施例提供的访问数据的装置的结构示意图。
具体实施方式
23.下面将结合本公开实施例的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本公开一部分实施例，而不是全部的实施例。
24.为便于理解本公开实施例，下面先对本公开实施例中涉及的术语进行简单介绍。
25.分布式资源管理
26.分布式资源管理(distributed resource management，drm)为一种应用配置资源管理框架，可以在应用运行时动态、即时的改变应用系统内存中的资源值。例如可以通过变更应用的一些配置数据，来管控应用逻辑。该配置数据也可以称为drm配置数据或drm资源。
27.由于drm系统的使用场景丰富、便捷性等优点，使得drm系统得到了开发者的青睐。利用drm系统进行应用配置化的需求也越来越多，随之而来的，线上drm配置的故障也越来
越多。经研究发现，由drm配置变更所导致的故障占据主导地位。而这背后的主要原因是操作人员(例如可以是开发人员或测试人员)不清楚drm配置数据中的变更字段的含义。
28.目前，在应用的开发过程中，为了开发方便，开发人员通常根据个人习惯会将应用中的drm配置数据(该drm配置数据可以包括drm配置类)放置在每个业务逻辑代码包下，然后进行打包。这样一来，就使得drm配置类可能分布于不同应用包中的不同位置。有时一个应用包就可能包括几十甚至上百个drm配置类，当操作人员对杂乱无章的drm配置类中的变更字段进行了解时，更是无从下手，这无疑是加重了对drm配置数据的学习时间成本，进而增加了线上drm配置的故障率。
29.为了解决上述问题，本公开实施例通过在第一应用中设置用于管理drm配置类的drm配置包，并将drm配置包的文件目录设置为具有从高层级到低层级排列的多个层级。该多个层级中的第一层级包括描述第一应用对应的领域的第一配置包，第一配置包包括该领域对应的drm配置类和/或第一配置包的从属领域配置包。这样一来，就使得第一应用中的drm配置类呈现集中有序的状态，减轻了学习drm配置数据的时间成本，从而有助于降低线上drm配置变更的故障率。
30.下文结合图1，对本公开实施例提供的一种访问数据的方法进行详细描述。如图1所示，该访问数据的方法100包括步骤s120～s140。
31.在步骤s120，运行第一应用。
32.该第一应用可以是指用于特定目的的计算机程序。例如可以是安装在终端设备上的应用程序或应用包。应理解，终端设备可以为电脑、手机、平板电脑或者其他电子设备等，本公开对比不做具体限制。
33.以第一应用为应用程序为例，该第一应用可以为终端设备上安装的任一应用程序。在一些实施例中，第一应用可以为终端设备的操作系统中的应用程序，也可以为第三方提供的应用程序。应理解，第一应用还可以为部署于后端服务器中的应用程序。第一应用例如可以为社交应用、音乐应用、视频应用、购物应用或者信息浏览应用等。
34.以第一应用为应用包为例，该第一应用可以为上述提及的任一应用程序中的任一应用功能包。例如，该功能包可以是用于实现特定功能的代码程序包。此时，第一应用例如可以为登录功能包、支付功能包、存储功能包等。
35.需要说明的是，用于特定目的功能的第一应用无论为应用程序或应用功能包，第一应用的软件包都可以包括应用逻辑代码包和drm配置包(也可以称为drm配置数据包或drm配置文件包)。其中，应用逻辑代码包中包括应用逻辑代码，可用于实现特定的目的或功能。drm配置包中可以包括drm配置数据，利用drm配置数据可以对应用逻辑代码包中的应用逻辑代码进行配置变更，以管控应用逻辑。
36.可选地，drm配置数据可以是指第一应用中的配置类(也可以称为drm配置类)。该drm配置类可以包括drm配置值，例如，该drm配置值可以是指一些代码逻辑开关、也可以指一些影响代码逻辑判断的常量数据。在一些实施例中，可以通过访问drm配置数据中的一些drm配置值(也可以称为变更字段)来变更应用逻辑代码中的一些代码逻辑开关或逻辑常量，从而实现对应用逻辑的管控。示例性地，以登录功能为例，例如变更字段a》b可以表示普通登录，变更字段c》d可以表示会员登录，若要更改当前drm变更字段，需要先了解变更前后的drm变更字段的含义，这样才能保证drm配置变更的准确性，正是由于存在大量杂乱无章
放置的变更字段，开发人员或测试人员需要花费较高的学习时间成本，才使得线上drm配置变更的故障率比较高。
37.为了解决对drm配置类中的变更字段学习成本高的问题，本公开实施例中提出一种集中有序放置drm配置类的方案，例如可以在第一应用中设置分布式资源管理drm配置包，drm配置包的包目录可以具有多个层级，该多个层级之间从高层级到低层级可以有序的排列，每个层级可以具有一个或多个配置包，该一个或多个配置包可以按照从高层级到低层级有序的放置在多个层级中，接着将drm配置类对应有序的放置在多个层级的多个配置包中，从而使得drm配置类从杂乱无序的状态回归到有序状态，以降低drm配置类的学习时间成本，进而有助于降低线上drm配置变更的故障率。
38.下面以多个层级中的任意两个相邻的层级为例，对drm配置类的有序放置进行说明。
39.drm配置包的包目录具有多个层级，该多个层级包括第一层级和第二层级，其中，该第一层级高于该第二层级，且第一层级与第二层级相邻，即第二层级是第一层级的下一个层级。应理解，第一层级可以是指多个层级中的任一层级，但不包括第一层级为最后一个层级。第一层级可以包括第一应用的第一配置包，该配置包可用于描述第一应用对应的领域，在该第一配置包中可以包括该领域对应的drm配置类和/或第二配置包，该领域对应的drm配置类和/或第二配置包位于第二层级。第二配置包可用于描述该领域的从属领域，即，第二配置包可以理解为第一配置的子配置包。需要说明的是，第一配置包中可以包括一个或多个子配置包，其中，第二配置包可以是指多个子配置包中的任一配置包。第一应用对应的领域可以是指第一应用的应用功能或应用包的功能领域名称。
40.作为一个示例，当第一应用为登录功能包时，第一配置包可用于描述该第一应用的登录功能领域，这样一来，第一配置包中就可以包括第一应用的所有关于登录功能领域的drm配置类和/或第二配置包，该drm配置类例如可以是第一配置包所描述的登录功能领域的基础参数配置类。当第一应用的登录功能领域还包含更细的登录场景领域时，第二配置包就可用于描述登录场景这一从属领域。此时，该第二配置包中就包括登录场景领域相关的drm配置类和/或第三配置包，该drm配置类例如可以是第二配置包所描述的支付场景领域的基础参数配置类。应理解，该第三配置包为第二配置包的子配置包，可用于描述上述登录场景从属领域的从属领域。以此类推，从高层级到低层级，对不同功能的drm配置类进行放置，从而保证drm配置类的有序放置。
41.为了加深理解本公开实施例中的包目录层级、drm配置类和配置包，下面结合另一个示例进行进一步的说明，当第一应用为支付功能包时，第一配置包可用于描述该第一应用的支付功能领域，第一配置包中就可以包括第一应用的所有关于支付功能领域的drm配置类和/或第二配置包，该drm配置类例如可以是第一配置包所描述的支付功能领域的基础参数配置类。当第一应用的支付功能领域还包含更细的支付场景领域时，第二配置包可用于描述该支付场景这一从属领域。此时，该第二配置包中就包括支付场景领域相关的drm配置类和/或第三配置包，该drm配置类例如可以是第二配置包所描述的支付场景领域的基础参数配置类。应理解，该第三配置包为该第二配置包的子配置包，可用于描述上述支付场景从属领域的从属领域。以此类推，从高层级到低层级，对不同功能的drm配置类进行放置，从而保证drm配置类的有序放置。
42.可选地，drm配置包的包目录可以是具有树状结构的多个层级，该树状结构的包目录例如可以包括根节点、中间节点、叶子节点等节点。该树状结构的根节点例如可以对应drm配置文件包，即，根节点可以是多个层级的首层中的配置包，该最上层的配置包可以作为drm配置包的访问入口。树状结构的中间节点可以是指首层中的配置包的各个子配置包。树状结构的叶子节点可以任意配置包中的drm配置类。(后文会结合图2和图3对drm配置包的包目录的树状结构以及树状包目录的各种节点进行举例说明，具体可以参见图2和图3的相关描述，在此暂不做详细描述)。
43.在一些实施例中，下一层级的比较常用或比较重要的drm配置类可以放置在该下一层级的上一层级，从而可以快速预览该下一层级中的比较常用或比较重要的drm配置类。作为一个示例，假若前文提及的第一层级具有多个叶子节点，该多个叶子节点可以对应第一drm配置类，即第一drm配置类可以是该多个叶子节点对应的drm配置类的集合。其中，第一drm配置类中可以包括第一应用的领域对应的drm配置类，其中，第一应用的领域对应的drm配置类位于第二层级。示例性地，第一应用例如可以是通信类应用，假若第一层级可以包括该第一应用的叶子节点和第一配置包，该第一配置包例如可用于描述第一应用的登录功能领域，第一层级中的叶子节点对应第一drm配置类。该第一drm配置类可以包括该通信应用(即第一应用)的框架基础参数配置类。该第一配置包还可以包括第一应用的所有关于登录功能领域的drm配置类和/或第二配置包，该登录功能领域的drm配置类和/或第二配置包位于第二层。此时，第一drm配置类中可以包括部分或全部的第一应用的登录功能领域的drm配置类。也就是说，第二层级中的部分或全部的drm配置类可以向上提一层，放置于第一层，从而可以提高开发人员或测试人员等浏览第一应用配置类的速度，也会增加drm在线配置的速度。
44.在一些实施例中，drm配置包的包目录是基于领域模型建立的，该领域模型呈现一个树状结构，可以对外提供一个根节点作为入口。例如可以将根节点作为唯一入口，以便对第一应用的drm配置数据进行管控。于是，杂乱无章的drm配置类，在领域模型的基础上也呈现出有序状态。本公开实施例中的领域模型例如可以是依据drm配置数据的应用产品归属、基本配置参数(例如可以包括超参数)、配置场景等因素建立的。本公开实施例对领域模型中的每一层的命名方式不做具体限制，只要便于对drm配置类进行分类放置管理即可。示例性地，树状领域模型的多层级可以依次包括应用层、产品层、场景层和配置层。作为一个示例，应用层例如可以对应第一层级，该第一层级可以以第一应用的应用名称或应用类型来命名；产品层可以对应第二层级，该第二层级例如可以以第一应用中的应用功能包的功能领域或产品来命名；场景层可以对应第三层级，该第三层可以以应用功能包的子功能领域来命名，例如可以以应用功能的配置场景来命名；配置层可以对应第四层级，第四层级例如可以以第四层中的drm配置类来命名。
45.在步骤s140，利用drm配置包，访问第一应用的drm配置类。
46.在对drm配置包的包目录建立树状结构领域模型的基础上，在drm配置变更的过程中，如果想要获取drm配置数据，则可以利用drm配置包，快速访问第一应用的drm配置类。例如可以将树状结构的根节点对应的drm配置文件包作为入口，通过该drm配置文件包一步一步向下访问叶子节点处对应的drm配置类，进而可以获取所需的drm配置变更字段。更具体地，作为一个示例，通过根节点一步一步往下访问获取所需的drm配置变更字段的伪代码可
以为：应用名drm
→
get产品层级()
→
get场景层级()
→
get配置()。
47.在一些实施例中，可以将领域模型的首层可以命名为“应用名+drm”，以drm为后缀作为包名，可以快捷的标识该包为drm配置数据包。
48.如前文所述，本公开实施例以第一应用为单位，在应用级别层面，对drm配置数据从代码上就建立相关领域模型，可以收集聚拢第一应用中的各种drm配置类，以便进行配置资源管控。这样一来，在线上drm变更之前，将会极大减少操作人员对第一应用中的各种drm配置数据的学习时间成本。相关人员如果想要去了解变更字段背后的意义，也将会很方便，从而可以有助于降低线上drm变更所导致的故障率。
49.为了进一步阐述本公开实施例中drm配置包的包目录的树状结构，下面以第一应用的drm配置包目录为例，结合图2进行详细描述。需要说明的是，第一应用可以是前文提及的任一类型的应用，为方便描述，下文以第一应用为通信类应用为例进行说明。
50.如图2所示，本公开实施例提供的一种树状结构的包目录，该第一应用的包目录为四层结构。在第一层级，该树状结构的领域模型可以包括根节点200，根节点200对应的配置包也可以称为第一应用的drm配置包200，该drm配置包200可以作为第一应用的drm配置类的访问入口，该drm配置包200例如可以以“第一应用的应用名+drm”来命名，从而有助于快捷的查找该drm配置数据包，该drm配置包200可以包括该通信类应用(即第一应用)的所有应用配置类数据。
51.在第二层级，该第一应用的根节点200例如可以包括中间节点210、中间节点220以及叶子节点230。中间节点210和中间节点220对应的配置包可以称为第一配置包210和第一配置包220。第一配置包210和第一配置包220为drm配置包200的两个子配置包。例如，第一配置包210可用于描述第一应用对应的登录功能领域，第一配置包220可用于描述第一应用对应的支付功能领域。叶子节点230对应第一应用的配置数据，该叶子节点230对应的配置数据例如可以是第一应用的基础配置参数、框架配置参数或超类参数。
52.在第三层级，中间节点210可以包括中间节点211和叶子节点212。应理解，中间节点也可以不包括叶子节点，比如中间节点220可以仅包括中间节点221。中间节点211对应的配置包可以称为第二配置包211，叶子节点212对应的配置类可以称为drm配置类212。从图2可以看出，在第三层级，第一配置包210中可以包括第一应用的所有关于登录功能领域的第二配置包211和drm配置类212。第二配置包211为第一配置包210的子配置包，第二配置包211例如可用于描述登录场景功能领域，应理解，登录场景功能领域为登录功能领域的从属领域。drm配置类212例如可以是登录功能领域的基础参数配置类。从图2还可以看出，在第三层级，第一配置包220中可以包括第一应用的关于支付功能领域的第二配置包221。第二配置包221为第一配置包220的子配置包，第二配置包221例如可用于描述支付场景功能领域，应理解，支付场景功能领域为支付功能领域的从属领域。
53.在第四层级，中间节点211可以包括叶子节点211a和叶子节点211b。中间节点221可以包括叶子节点221a。应理解，叶子节点211a和叶子节点211b对应的配置数据为登录场景对应的drm配置类数据，例如叶子节点211a可以对应登录场景中的第一场景对应的drm配置类，叶子节点211b可以对应登录场景中的第二场景对应的drm配置类。叶子节点221a可以为支付场景功能领域中的支付场景对应的drm配置类。
54.根据上述内容可以看出，本公开实施例以第一应用为单位，在应用级别层面，对
drm配置数据从代码上就建立相关领域模型，可以收集聚拢第一应用中的各种drm配置类，以便进行配置资源管控。这样一来，在线上drm变更之前，将会极大减少操作人员对第一应用中的各种drm配置数据的学习时间成本。相关人员如果想要去了解变更字段背后的意义，也将会很方便，从而可以有助于降低线上drm变更所导致的故障率。
55.为了进一步阐述本公开实施例中树状结构的领域模型，下面结合图3进行详细描述。
56.如图3所示，本公开实施例依据drm配置类的应用产品归属以及配置场景等因素，将drm配置类分为应用层、产品层、场景层、配置层，并以此为例，建立了四层树状结构的领域模型。应理解，要建立这样的一个领域模型，首先需要对drm配置包的包目录进行一个领域分层，本公开实施例对领域分层的方式不做具体限制，例如，可以根据应用产品需求，由开发人员根据功能场景来确定各个层级，如上文中的应用层、产品层、场景层、配置层。该领域模型的第一层可以是以“应用名+drm”构成，以drm为后缀作为第一层的包名，可以快捷的标识该包为drm配置数据包。
57.参见图3，图3中清晰的展示了领域模型的第一层对象和它的成员的从属关系。在第一层级，根节点“yingyong1drm(应用1)”为应用1的drm配置包，可以以应用1的应用名称来描述其领域。在第二层级，drm配置包“yingyong1drm(应用1)”可以包括“chanpin1(产品1)”、“chanpin2(产品2)”、“chanpin3(产品3)”三个成员对象(也可以称三个子配置包)，可以理解的是，该三个成员对象为drm配置包“yingyong1drm(应用1)”的子配置包，该三个子配置包例如可以分别用于描述应用1的登录功能领域、支付功能领域和储存功能领域。可以看出drm配置包“chanpin2(产品2)”和“chanpin3(产品3)”处于未展开状态。其中，关于支付功能领域的drm配置包“chanpin2”可以持有下一层级中的对象“cp2changjing1(产品2中的配置场景1)”，该对象为drm配置包“chanpin2(产品2)”的子配置包，例如可用于描述支付场景功能领域，该支付场景功能领域为支付功能领域的从属领域。在第四层级，drm配置包“cp2changjing1”可以持有支付场景功能的drm配置类对象“config1”。本公开实施例中的方案，多个层级之间从高层级到低层级有序排列，从而建立一个树状结构的领域模型。这样就使得各种包下的drm配置数据从分散无序状态回归到了集中有序状态，减轻了学习drm配置数据的时间成本，从而有助于降低线上drm配置变更的故障率。
58.在一些实施例中，下一层级的比较常用或比较重要的drm配置类可以放置在该下一层级的上一层级，从而可以快速预览该下一层级中的比较常用或比较重要的drm配置类。继续参见图3，作为一个示例，第二层级对应drm配置类“yingyong1drm”例如可以是应用1的超参数配置类。本公开可以将第三层级中比较常用的drm配置类“chanpin1”、“chanpin2”、“chanpin3”放置于第二层级中，由此，在drm配置变更之前，通过展开第一层级的drm配置包“yingyong1drm”就可以快速浏览学习比较常用或比较重要的第一drm配置类，从而降低了对drm配置数据的学习时间成本，有助于降低线上drm变更的故障率。应理解，此时的第一drm配置类可以是指drm配置类“chanpin1”、“chanpin2”、“chanpin3”和“yingyong1drm”。
59.作为另一个示例，本公开实施例还可以将第四层级中比较常用的drm配置类“cp2changjing1”和“cp2changjing1”放置于第三层级，由此，在drm配置变更之前，通过展开第二层级的drm配置包“chanpin2”就可以快速浏览学习比较常用或比较重要的第一drm配置类，从而降低了对drm配置数据的学习时间成本，有助于降低线上drm变更的故障率。此
时的第一drm配置类可以是指“cp2changjing1”和“cp2changjing1”。
60.需要说明的是，为了降低对drm配置类的学习时间成本，可以将低层级的比较重要的drm配置类向上提一个层级或多个层级，本公开实施例对此不做具体限制。但是，如果存在大量的drm配置类，此时若跨级向上层级移动放置，可能会导致drm配置类再次变为无序状态，因此，通常仅将比较重要的drm配置类向上提一个层级。
61.实际上，本公开实施例中的领域模型如果按照层级对象之间的从属关系进行依次递推下去，则可以建立深度的多级层次。但是，为了保证对drm配置包的数据访问效率，例如该领域模型的层级可以控制不超过四层。假若一层可以有10个对象，那么，总共是可以持有10*10*10＝1000个drm配置资源。也就是说，即便是四层的领域模型，其可以持有的对象对于第一应用系统而言通常也是足够的。
62.在一些实施例中，位于叶子节点处的drm配置类，其对象可以以drm为后缀，以便标识该drm配置类是处于最底层(也就是叶子节点)的配置类。作为一个示例，参见图3，图3中的drm配置类对象“config1”可以命名为“config1drm”，以标识该最底层的drm配置类。
63.在一些实施例中，drm配置包例如可以建立在一个基础模块的基本包路径下。该基础模块可以是指第一应用下的可以同时被该第一应用中的其他模块所依赖的底层模块，这样一来，在对drm配置包进行访问时，就可以通过基础包路径容易的获取drm配置包的相关配置资源。本公开实施例对基础模块的位置不做具体限制，只要能够同时被其他模块所依赖即可。该基础模块可以是第一应用的较底层模块或最底层模块，例如可以是core模块。
64.在一些实施例中，为了防止drm配置变更导致的系统重新启动，关于配置中心的开源框架应运而生，如apollo、nacos。这些开源框架的诞生可以实现线上drm资源配置的动态修改，实时生效，且无需重启服务。这也让drm配置资源得到了大量的使用，甚至广泛的滥用，从而导致drm配置类杂乱无章的放置使用的情况日益凸显。本公开实施例正是在该环境下提出的对drm配置资源的访问管理方法。
65.目前，在对第一应用进行drm资源配置的过程中，第一应用在获取drm配置变更字段之前，需要先对第一应用中的drm配置类中的配置值进行更新。本公开实施例对drm配置类的更新方式不做具体限制，例如可以由第一应用从配置中心获取配置值，以更新drm配置类中的配置值。具体地，例如可以基于容器技术来进行更新。例如也可以由配置中心对第一应用中的drm配置类中的配置值进行更新。具体地，例如可以基于注解的方式进行更新。下面对该两种drm配置类的更新方式进行详细的描述。
66.以由第一应用利用容器技术对drm配置类中的配置值进行更新为例，本公开实施例可以通过容器化的技术对drm配置类中的配置值进行更新。示例性地，假若想要获取更新drm配置资源中的属性hello的配置值，通过唯一的key值就可以基于容器主动从配置中心获取hello的更新值。应理解，该容器是一个map数据结构，以键值对的形式存储drm配置数据，该容器也可以称为map容器。
67.在一些实施例中，例如可以给drm配置数据中的属性hello设定一个默认值，这个默认值需要依据自身应用来确定一个合适的值。这样一来，在极端情况下，当第一应用并没有从配置中心获取到drm配置资源时，可以用默认值进行兜底，以防止进程错误。具体实现代码如下：
[0068][0069]
如上述代码所示，其中drmholder就是一个容器。在一些实施例中，容器的建立可以是在第一应用启动过程中，例如可以依据配置中心框架获取的drm资源配置值进行创建。当依据配置中心框架获取到最新的drm配置资源的相关配置值时，接着，就可以更新容器中的配置值。这种方式，drm配置资源就可以实现与领域模型之间的解耦。也就是说，本公开中间通过容器进行桥接，使得drm资源配置类的更新并不依赖于树状领域模型的结构。应理解，当采用容器进行桥接时，需要在底层重复建立一个和drm资源配置几乎一样的类。
[0070]
以由配置中心框架对drm配置类中的配置值进行更新为例，本公开实施例可以对领域模型中的所有层级中的对象进行加注解，交由spring创建bean(bean可以是指一个托管的对象)。当一个类文件被注解修饰时，drm将在启动时加载该类的对象为一个bean，然后由drm系统框架来实现成员属性注入。drm资源配置类的值则交由配置中心框架赋值和更新，这里则不再需要容器作为桥梁获取值。
[0071]
在一些实施例中，当对drm系统管理的实例属性进行注解修饰时，drm系统将在启动时上报该属性信息到drm服务端，此时可以在后台页面对该属性进行修改，然后第一应用可以访问获取所需要的变更字段，以完成drm资源配置。可以根据当前的业务需求，例如改变逻辑代码开关的状态、执行一段代码等。
[0072]
在一些实施例中，当第一应用对drm配置包进行访问时，本公开实施例仅提供了get方法，并未提供set方法，这样可以防止相关数据被修改。接下来，可以通过get方法的伪代码“应用名drm
→
get产品层级()
→
get场景层级()
→
get配置()”获取到对应配置值。如果获取值的实际代码长度过长，可以对该段代码进行适当的封装。
[0073]
在一些实施例中，当领域模型建好之后，接下来，就是首层入口对象的放置，例如可以通过拦截器等技术把该对象放置在请求参数中，又例如也可以通过依赖注入放置在相关业务代码的成员属性中。本公开实施例对此不做具体限制。
[0074]
上文结合图1至图3，详细描述了本公开的方法实施例，下面结合图4和图5，详细描述本公开的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
[0075]
图4是本公开实施例提供的一种访问数据的装置的结构示意图。该装置400包括运行单元410和访问单元420。
[0076]
运行单元410可用于运行第一应用，所述第一应用的软件包包括分布式资源管理
drm配置包，所述drm配置包的包目录具有多个层级，所述多个层级之间从高层级到低层级排列，所述多个层级中的第一层级高于所述多个层级中的第二层级，且所述第一层级与所述第二层级相邻，所述第一层级包括所述第一应用的第一配置包，所述第一配置包用于描述所述第一应用对应的领域，所述第一配置包包括所述领域对应的drm配置类和/或第二配置包，其中，所述领域对应的drm配置类和/或所述第二配置包位于所述第二层级，所述第二配置包用于描述所述领域的从属领域；
[0077]
访问单元420可用于利用所述drm配置包，访问所述第一应用的drm配置类。
[0078]
可选地，所述drm配置包的包目录具有树状结构，所述树状结构的根节点对应所述drm配置包，所述树状结构的叶子节点对应所述第一应用的drm配置类。
[0079]
可选地，所述多个层级包括第一层级和第二层级，所述第一层级为所述第二层级的上一层级，所述树状结构具有位于所述第一层级的叶子节点，所述第一层级的叶子节点对应第一drm配置类，其中，所述领域对应的drm配置类。
[0080]
可选地，所述多个层级依次包括应用层、产品层、场景层和配置层。
[0081]
可选地，所述第一应用的drm配置类中的配置值基于map容器或注解进行更新。
[0082]
图5是本公开实施例提供的另一种访问数据的装置的结构示意图。图5所述的访问数据的装置500可以包括存储器510和处理器520，存储器510可以用于存储可执行代码。处理器520可以用于执行存储器510中存储的可执行代码，以实现前文描述的各个方法中的步骤。在一些实施例中，该装置500还可以包括网络接口530，处理器520与外部设备的数据交换可以通过该网络接口530实现。
[0083]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储装置。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，数字通用光盘(digital video disc，dvd))或者半导体介质(例如，固态硬盘(solid state disk，ssd))等。
[0084]
以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。