配置数据的更新方法、装置、电子设备及计算机可读介质与流程

1.本公开涉及通信技术领域，具体而言，涉及一种配置数据的更新方法、配置数据的更新装置、电子设备及计算机可读介质。


背景技术：

2.随着互联网的发展，网络通讯发展迅猛，各地区以及跨地区的网络存在远程通讯的需求。网络情况的复杂性直接影响了网络质量高低，同地区不同运营商、不同地区运营商等现实情况的存在会导致客户端获取服务端的配置数据变得不够可靠。
3.目前一般是通过加密访问网站获取配置数据接口的方式获取配置数据。在弱网环境或者用户运营商无法访问到域名的时候，会使用用户本地默认配置。如果用户清理本地缓存，则会丢失最新配置。这种情况下，如果是用户跨地区网络链路影响了访问，则跟业务期望使用的最新配置数据存在差距。
4.鉴于此，本领域亟需一种配置数据的更新方法，能够提升配置数据有效下发的成功率，让变更的配置数据及时下发到客户端，提升用户体验。
5.需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。


技术实现要素：

6.本公开的目的在于提供一种配置数据的更新方法、配置数据的更新装置、电子设备及计算机可读介质，进而至少在一定程度上能够提升配置数据有效下发的成功率。
7.根据本公开的第一个方面，提供一种配置数据的更新方法，应用于客户端，包括：
8.获取服务端的多个域名，并向所述多个域名发起配置获取请求，获取所述服务端的目标配置数据；
9.若通过所述多个域名获取所述目标配置数据失败，则根据预先配置的云服务商信息，通过多个cdn云服务商获取所述服务端的目标配置数据；
10.若通过所述多个cdn云服务商获取所述目标配置数据失败，则获取本地存储的配置数据作为所述目标配置数据；
11.根据所述目标配置数据更新本地配置数据，以及所述本地配置数据对应的版本号。
12.在本公开的一种示例性实施例中，所述向所述多个域名发起配置获取请求，获取所述服务端的目标配置数据，包括：
13.根据所述多个域名的响应速度对所述多个域名进行排序，并根据排序结果依次向每个域名发起配置获取请求，获取所述服务端的目标配置数据。
14.在本公开的一种示例性实施例中，所述根据预先配置的云服务商信息，通过多个cdn云服务商获取所述服务端的目标配置数据，包括：
15.根据预先配置的云服务商信息获取多个cdn云服务商的配置文件；
16.依次将各个所述cdn云服务商的配置文件中的版本号与所述本地配置数据对应的版本号进行对比；
17.若所述cdn云服务商的配置文件中的版本号大于所述本地配置数据对应的版本号，则通过所述cdn云服务商获取所述服务端的目标配置数据。
18.在本公开的一种示例性实施例中，所述获取本地存储的配置数据作为所述目标配置数据，包括：
19.获取上一次更新的本地配置数据作为所述目标配置数据；
20.若获取所述上一次更新的本地配置数据失败，则将本地存储的默认配置数据作为所述目标配置数据。
21.根据本公开的第二个方面，提供一种配置数据的更新方法，应用于配置后台，包括：
22.通过配置管理功能更新服务端各个配置项的配置内容，生成相应的配置数据和版本号，并保存至配置数据库中；
23.根据第一预设时间间隔查询所述配置数据库中的版本号，若所述版本号有更新，则调用文件存储服务接口获取所述版本号对应的配置数据，并根据所述配置数据和对应的版本号生成配置文件；
24.将所述配置文件上传到多个cdn云服务商对应的云存储中，用于响应客户端向所述cdn云服务商发起配置获取请求以更新所述客户端的本地配置数据。
25.在本公开的一种示例性实施例中，所述方法还包括：
26.通过所述文件存储服务接口从配置记录数据库中查询配置文件目录，判断所述配置文件是否为首次发布；
27.若所述配置文件为首次发布，则调用cdn预热接口，将所述配置文件推送至所述cdn云服务商的边缘节点；
28.按照预设的文件更新时间间隔刷新所述配置文件目录，并更新所述cdn云服务商的边缘节点中的所述配置文件。
29.根据本公开的第三个方面，提供一种配置数据的更新方法，应用于配置服务集群，包括：
30.从配置数据库中获取配置数据，将所述配置数据写入内存全局字典，并根据所述配置数据的版本号确定内存全局版本号；
31.根据第二预设时间间隔查询所述配置数据库中的版本号，若所述版本号大于当前所述内存全局版本号，则获取所述版本号对应的配置数据，并更新所述内存全局字典和所述内存全局版本号；
32.响应于客户端向域名发起的配置获取请求，根据所述配置获取请求中的请求条件从所述内存全局字典中获取目标配置数据；
33.将所述目标配置数据返回至所述客户端，以使所述客户端根据所述目标配置数据更新本地配置数据以及对应的版本号。
34.根据本公开的第四方面，提供一种配置数据的更新装置，应用于客户端，包括：
35.服务域名请求模块，用于获取服务端的多个域名，并向所述多个域名发起配置获取请求，获取所述服务端的目标配置数据；
36.云服务商请求模块，用于若通过所述多个域名获取所述目标配置数据失败，则根据预先配置的云服务商信息，通过多个cdn云服务商获取所述服务端的目标配置数据；
37.本地数据获取模块，用于若通过所述多个cdn云服务商获取所述目标配置数据失败，则获取本地存储的配置数据作为所述目标配置数据；
38.本地配置更新模块，用于根据所述目标配置数据更新本地配置数据，以及所述本地配置数据对应的版本号。
39.根据本公开的第五方面，提供一种配置数据的更新装置，应用于配置后台，包括：
40.配置数据生成模块，用于通过配置管理功能更新服务端各个配置项的配置内容，生成相应的配置数据和版本号，并保存至配置数据库中；
41.配置文件生成模块，用于根据第一预设时间间隔查询所述配置数据库中的版本号，若所述版本号有更新，则调用文件存储服务接口获取所述版本号对应的配置数据，并根据所述配置数据和对应的版本号生成配置文件；
42.配置文件上传模块，用于将所述配置文件上传到多个cdn云服务商对应的云存储中，用于响应客户端向所述cdn云服务商发起配置获取请求以更新所述客户端的本地配置数据。
43.根据本公开的第六方面，提供一种配置数据的更新装置，应用于配置服务集群，包括：
44.内存全局字典写入模块，用于从配置数据库中获取配置数据，将所述配置数据写入内存全局字典，并根据所述配置数据的版本号确定内存全局版本号；
45.内存全局字典更新模块，用于根据第二预设时间间隔查询所述配置数据库中的版本号，若所述版本号大于当前所述内存全局版本号，则获取所述版本号对应的配置数据，并更新所述内存全局字典和所述内存全局版本号；
46.配置获取请求响应模块，用于响应于客户端向域名发起的配置获取请求，根据所述配置获取请求中的请求条件从所述内存全局字典中获取目标配置数据；
47.目标配置数据返回模块，用于将所述目标配置数据返回至所述客户端，以使所述客户端根据所述目标配置数据更新本地配置数据以及对应的版本号。
48.根据本公开的第七方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的配置数据的更新方法。
49.根据本公开的第八方面，提供一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的配置数据的更新方法。
50.本公开示例性实施例可以具有以下有益效果：
51.本公开示例实施方式的配置数据的更新方法中，通过结合多个域名、多个cdn云服务商就近提供服务、以及用户本地存储的配置数据等方式，保障用户可以使用到最新的配置数据，提升配置数据有效下发的成功率，解决了跨地区长链路、弱网、网络抖动等情况下获取业务配置数据失败的问题。通过加入就近cdn多云商服务提供新的配置数据，可以使用户就近访问其能访问到的cdn云服务商，提升了可用性。通过提升可用性，可以让变更的配置数据及时下发到客户端，进而提升用户体验。
52.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不
能限制本公开。
附图说明
53.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
54.图1示出了本公开示例实施方式应用于客户端的配置数据的更新方法的流程示意图；
55.图2示出了本公开示例实施方式的通过多个cdn云服务商获取服务端的目标配置数据的流程示意图；
56.图3示出了根据本公开的一个具体实施方式中应用于客户端的配置数据的更新方法的流程示意图；
57.图4示出了本公开示例实施方式应用于配置后台的配置数据的更新方法的流程示意图；
58.图5示出了本公开示例实施方式的配置文件首次发布预热以及更新的流程示意图；
59.图6示出了根据本公开的一个具体实施方式中的配置后台调用文件存储服务进行数据分发的流程示意图；
60.图7示出了本公开示例实施方式应用于配置服务集群的配置数据的更新方法的流程示意图；
61.图8示出了根据本公开的一个具体实施方式中的配置服务集群加载配置的流程示意图；
62.图9示出了根据本公开的一个具体实施方式中配置数据的更新方法的总体流程示意图；
63.图10示出了本公开示例实施方式应用于客户端的配置数据的更新装置的框图；
64.图11示出了适于用来实现本公开实施方式的电子设备的计算机系统的结构示意图。
具体实施方式
65.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
66.此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标
记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
67.在一些相关的实施例中，可以使用多域名的方案来获取配置数据，但是在用户跨地区或者对于同个主域的访问都无法到达的时候，该方案也无法获取到新的配置数据。
68.因此，为了保障用户网络在各类不可预估的情况下，能够尽可能从多渠道就近加载到新的配置数据，需解决不同运营商、不同地区的网络可能出现的弱网、dns(domain name system，域名系统)污染等情况而导致无法正常获取到新配置的问题。
69.本示例实施方式首先提供了一种配置数据的更新方法，应用于客户端。参考图1所示，上述配置数据的更新方法可以包括以下步骤：
70.步骤s110.获取服务端的多个域名，并向多个域名发起配置获取请求，获取服务端的目标配置数据。
71.步骤s120.若通过多个域名获取目标配置数据失败，则根据预先配置的云服务商信息，通过多个cdn云服务商获取服务端的目标配置数据。
72.步骤s130.若通过多个cdn云服务商获取目标配置数据失败，则获取本地存储的配置数据作为目标配置数据。
73.步骤s140.根据目标配置数据更新本地配置数据，以及本地配置数据对应的版本号。
74.本公开示例实施方式的配置数据的更新方法中，通过结合多个域名、多个cdn云服务商就近提供服务、以及用户本地存储的配置数据等方式，保障用户可以使用到最新的配置数据，提升配置数据有效下发的成功率，解决了跨地区长链路、弱网、网络抖动等情况下获取业务配置数据失败的问题。通过加入就近cdn多云商服务提供新的配置数据，可以使用户就近访问其能访问到的cdn云服务商，提升了可用性。通过提升可用性，可以让变更的配置数据及时下发到客户端，进而提升用户体验。
75.举例而言，如果原本的数据上报只针对ios系统，当业务需要扩展到对某品牌的android(安卓)系统进行数据上报时，部分区域的用户无法收到实时配置数据，即无法打开上报开关，因此会丢失部分客户端的采集数据。如果使用本公开示例实施方式中的配置数据的更新方法，在请求服务器失败时，还可以就近请求cdn云服务商提供实时配置，跟用户同个运营商的cdn可以保证可用。
76.下面，结合图2至图3对本示例实施方式的上述步骤进行更加详细的说明。
77.在步骤s110中，获取服务端的多个域名，并向多个域名发起配置获取请求，获取服务端的目标配置数据。
78.本示例实施方式中，配置数据指的是前端使用的配置信息，可以用于决策不同系统的不同用户使用什么样的配置，可以动态解决兼容性问题和提供个性化管理。例如，对于同一个功能，a游戏配置特殊处理流程，走a游戏逻辑实现，b游戏配置默认逻辑，走默认逻辑配置实现，以上报数据为例，a游戏配置上报，b游戏配置不上报。如果在某段时间想采集b游戏的上报数据，配置数据实时推送，尽可能保证送达给用户，尽量保证b游戏走上报数据流程。配置数据不限制使用场景，可以由前端决定应用在哪些场景。目标配置数据指的是服务
端最新的配置数据。
79.本示例实施方式中，首先，可以根据多个域名的响应速度对多个域名进行排序，并根据排序结果依次向每个域名发起配置获取请求，获取服务端的目标配置数据。
80.域名是在数据传输时对服务端的定位标识，通过探测多个域名，根据响应速度进行排序，从响应速度最快的域名开始执行请求。例如a.config.com(a域名)、b.config.com(b域名)，如果探测出a域名响应速度较快，则用户首先尝试请求a域名获取最新配置。如果通过此步骤能获取到配置，则完成获取配置流程。
81.在步骤s120中，若通过多个域名获取目标配置数据失败，则根据预先配置的云服务商信息，通过多个cdn云服务商获取服务端的目标配置数据。
82.本示例实施方式中，如果通过多个域名获取目标配置数据失败，则客户端会走获取cdn配置数据的逻辑。cdn的全称是content delivery network，即内容分发网络，其能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决网络拥挤的状况，提高用户访问网站的响应速度。
83.本示例实施方式中，如图2所示，根据预先配置的云服务商信息，通过多个cdn云服务商获取服务端的目标配置数据，具体可以包括以下几个步骤：
84.步骤s210.根据预先配置的云服务商信息获取多个cdn云服务商的配置文件。
85.本示例实施方式中，客户端上预先默认配置多个已知的cdn云服务商的云服务商信息。客户端通过cdn获取配置数据时，会根据预先配置的云服务商信息，分批调用获取多个cdn云服务商的配置文件。其中，配置文件是由配置后台根据最新的配置数据生成并存储在cdn边缘节点中的。
86.步骤s220.依次将各个cdn云服务商的配置文件中的版本号与本地配置数据对应的版本号进行对比。
87.客户端获取多个cdn云服务商的配置文件之后，依次将各个cdn云服务商的配置文件中的版本号与本地配置数据对应的版本号进行对比。其中，版本号可以根据配置数据生成的时间得到。
88.步骤s230.若cdn云服务商的配置文件中的版本号大于本地配置数据对应的版本号，则通过cdn云服务商获取服务端的目标配置数据。
89.若cdn云服务商的配置文件中的版本号大于本地配置数据对应的版本号，则更新到本地存储，每一批配置文件优先保存版本号最大的配置数据。
90.在步骤s130中，若通过多个cdn云服务商获取目标配置数据失败，则获取本地存储的配置数据作为目标配置数据。
91.本示例实施方式中，如果通过多个域名以及多个cdn云服务商获取目标配置数据都失败，则获取客户端本地存储的配置数据作为目标配置数据。
92.具体而言，可以先获取上一次更新的本地配置数据作为目标配置数据，若获取上一次更新的本地配置数据失败，则将本地存储的默认配置数据作为目标配置数据。
93.在步骤s140中，根据目标配置数据更新本地配置数据，以及本地配置数据对应的版本号。
94.获取目标配置数据之后，根据目标配置数据更新本地配置数据，以及本地配置数
据对应的版本号。
95.例如，当前存储服务配置数据的版本号是1653910000.01，配置数据为：
96.enable_multi_bands_dpcrn_ns＝0
97.enable_dpcrn_ns_cpu_least＝4
98.新增配置next_logic＝1，此时生成版本号为当前时刻1653996292.32，配置数据为：
99.enable_multi_bands_dpcrn_ns＝0
100.enable_dpcrn_ns_cpu_least＝4
101.next_logic＝1
102.修改配置next_logic＝2，此时生成版本号为当前时刻1653996342.15，配置数据为：
103.enable_multi_bands_dpcrn_ns＝0
104.enable_dpcrn_ns_cpu_least＝4
105.next_logic＝2
106.如图3所示是本公开的一个具体实施方式中应用于客户端的配置数据的更新方法的完整流程图，是对本示例实施方式中的上述步骤的举例说明，该流程图的具体步骤如下：
107.程序启动，启动加载配置流程。
108.步骤s310.探测多域名质量。
109.步骤s320.判断是否还有域名。
110.若有，则进入步骤s330；若无，则进入步骤s340。
111.步骤s330.判断是否请求获取配置api成功。
112.若成功，则完成获取配置流程；若请求失败，则返回步骤s320。
113.步骤s340.进行cdn请求。
114.步骤s350.多cdn并行请求。
115.步骤s360.判断是否能获取到配置数据。
116.若能获取到cdn配置数据，则完成获取配置流程；若请求失败，则进入步骤s370。
117.步骤s370.使用本地上次更新的配置。
118.本示例实施方式中，除了通过多域名、域名回源的方式获取配置数据，还增加了多云商cdn缓存的能力，提供就近用户的多cdn厂商缓存配置数据，尽可能保证将新配置下发给用户。即便所有渠道都失败了，用户本地还保存有上一次更新的配置，最终还可以使用默认配置作为兜底配置数据。
119.接下来，本示例实施方式还提供了一种配置数据的更新方法，应用于配置后台。参考图4所示，上述配置数据的更新方法可以包括以下步骤：
120.步骤s410.通过配置管理功能更新服务端各个配置项的配置内容，生成相应的配置数据和版本号，并保存至配置数据库中。
121.后台通过配置管理功能更新某些配置项的内容，生成以当前时刻作为新版本号的配置数据，保存到配置数据库中，其中，配置数据库为持久化存储服务。后台将配置数据上传到配置数据库中，可以提供给配置服务集群使用。
122.步骤s420.根据第一预设时间间隔查询配置数据库中的版本号，若版本号有更新，
则调用文件存储服务接口获取版本号对应的配置数据，并根据配置数据和对应的版本号生成配置文件。
123.后台通过定时任务，按照第一预设时间间隔查询配置数据库中的版本号，判断是否有新版本的配置数据，如果配置数据库中有新的版本号，且一段时间例如5分钟内没有再变更，则触发分发逻辑调用文件存储服务api(application programming interface，应用程序编程接口)，通知其获取新版本配置数据，文件存储服务获取到配置数据后，根据配置数据和对应的版本号生成配置文件。
124.步骤s430.将配置文件上传到多个cdn云服务商对应的云存储中，用于响应客户端向cdn云服务商发起配置获取请求以更新客户端的本地配置数据。
125.后台通过文件存储服务管理云服务商资源，文件存储服务将上述生成的配置文件上传到多个cdn云服务商对应的云存储中，例如aws(amazon web services，亚马逊云平台)s3，云服务商过设置cdn回源域名指向云存储，完成用户就近请求cdn云服务商访问配置文件数据的操作。
126.除此之外，本示例实施方式中，如图5所示，应用于配置后台的配置数据的更新方法还可以包括以下几个步骤：
127.步骤s510.通过文件存储服务接口从配置记录数据库中查询配置文件目录，判断配置文件是否为首次发布。
128.后台通过文件存储服务在配置记录数据库中查询配置文件目录，判断配置文件是否为首次发布。其中，首次发布的配置文件的名称和用途与其他配置文件不同。
129.步骤s520.若配置文件为首次发布，则调用cdn预热接口，将配置文件推送至cdn云服务商的边缘节点。
130.如果该配置文件是首次发布，则文件存储服务完成上述的上传操作后，会触发cdn预热操作，调用cdn预热api，完成资源首次发布预热，将配置文件推送至cdn云服务商的边缘节点。
131.步骤s530.按照预设的文件更新时间间隔刷新配置文件目录，并更新cdn云服务商的边缘节点中的配置文件。
132.与此同时，文件存储服务会通过定时任务，按照预设的文件更新时间间隔，例如每小时检查最近更新的配置文件，提取符合条件的配置文件，调用各个云服务商api执行轮询刷新各个云服务商的cdn对应的配置文件目录的缓存，完成cdn回源获取新的配置文件。通过设置文件更新时间间隔，例如一小时，可以降低刷新cdn配置文件的频率。文件存储服务通过控制定时发布配置文件，以及控制定时刷新cdn的频率，来完成cdn发布。
133.如图6所示是本公开的一个具体实施方式中的配置后台调用文件存储服务进行数据分发的流程示意图，该流程示意图的具体内容与图4和图5中的步骤类似，此处不再赘述。
134.接下来，本示例实施方式还提供了一种配置数据的更新方法，应用于配置服务集群。参考图7所示，上述配置数据的更新方法可以包括以下步骤：
135.步骤s710.从配置数据库中获取配置数据，将配置数据写入内存全局字典，并根据配置数据的版本号确定内存全局版本号。
136.配置服务集群中的每个节点的进程启动后，通过调用加载配置模块，从配置数据库中获取配置数据，然后将配置数据写入内存全局字典，并根据配置数据的版本号确定内
存全局版本号。其中，内存全局版本号为内存全局字典中最新的配置数据版本号。
137.步骤s720.根据第二预设时间间隔查询配置数据库中的版本号，若版本号大于当前内存全局版本号，则获取版本号对应的配置数据，并更新内存全局字典和内存全局版本号。
138.配置服务集群通过定时器按照第二预设时间间隔，例如每15秒查询配置数据库中的版本号是否有更新，如果配置数据库中的版本号大于当前内存全局版本号，则获取版本号对应的配置数据，并更新内存全局字典和内存全局版本号。
139.步骤s730.响应于客户端向域名发起的配置获取请求，根据配置获取请求中的请求条件从内存全局字典中获取目标配置数据。
140.当请求配置服务的api获取配置时，根据配置获取请求中的请求条件，从内存全局字典中筛选出符合条件的目标配置数据，响应给客户端。
141.步骤s740.将目标配置数据返回至客户端，以使客户端根据目标配置数据更新本地配置数据以及对应的版本号。
142.配置服务集群响应于客户端向域名发起的配置获取请求，将目标配置数据返回至客户端，以使客户端根据目标配置数据更新本地配置数据以及对应的版本号。
143.如图8所示是本公开的一个具体实施方式中的配置服务集群加载配置的流程示意图，该流程示意图的具体内容与图7中的步骤类似，此处不再赘述。
144.如图9所示是本公开的一个具体实施方式中配置数据的更新方法的总体流程示意图，该流程示意图的具体内容如下：
145.客户端启动预加载语音sdk(software development kit，软件开发工具包)向服务端获取配置数据。客户端首先通过域名向配置服务集群进行请求；如果通过域名获取配置数据失败，则采用兜底策略1，向多个cnd云服务商发起请求，从cnd云服务商对应的云存储中获取配置数据；如果cnd配置数据也获取失败，则采用兜底策略2，使用本地存储的配置数据。
146.后台将新生成的配置数据保存到配置数据库中，提供给配置服务集群使用，以响应客户端向域名发起的请求，同时通过定时任务查询配置数据库，触发分发逻辑调用文件存储服务，将配置文件上传到多个cdn云服务商对应的云存储中，以响应客户端向cdn云服务商发起的请求。
147.对于海外域名回源可以通过海外云服务商接入节点转发请求回国内机房配置服务集群，然后按照相同的流程进行。
148.应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
149.进一步的，本公开还提供了一种配置数据的更新装置，应用于客户端。参考图10所示，该配置数据的更新装置可以包括服务域名请求模块1010、云服务商请求模块1020、本地数据获取模块1030以及本地配置更新模块1040。其中：
150.服务域名请求模块1010可以用于获取服务端的多个域名，并向多个域名发起配置获取请求，获取服务端的目标配置数据；
151.云服务商请求模块1020可以用于若通过多个域名获取目标配置数据失败，则根据预先配置的云服务商信息，通过多个cdn云服务商获取服务端的目标配置数据；
152.本地数据获取模块1030可以用于若通过多个cdn云服务商获取目标配置数据失败，则获取本地存储的配置数据作为目标配置数据；
153.本地配置更新模块1040可以用于根据目标配置数据更新本地配置数据，以及本地配置数据对应的版本号。
154.在本公开的一些示例性实施例中，服务域名请求模块1010可以包括域名排序单元，可以用于根据多个域名的响应速度对多个域名进行排序，并根据排序结果依次向每个域名发起配置获取请求，获取服务端的目标配置数据。
155.在本公开的一些示例性实施例中，云服务商请求模块1020可以包括配置文件获取单元、版本号对比单元以及云服务商配置获取单元。其中：
156.配置文件获取单元可以用于根据预先配置的云服务商信息获取多个cdn云服务商的配置文件；
157.版本号对比单元可以用于依次将各个cdn云服务商的配置文件中的版本号与本地配置数据对应的版本号进行对比；
158.云服务商配置获取单元可以用于若cdn云服务商的配置文件中的版本号大于本地配置数据对应的版本号，则通过cdn云服务商获取服务端的目标配置数据。
159.在本公开的一些示例性实施例中，本地数据获取模块1030可以包括前一更新数据获取单元以及默认配置数据获取单元。其中：
160.前一更新数据获取单元可以用于获取上一次更新的本地配置数据作为目标配置数据；
161.默认配置数据获取单元可以用于若获取上一次更新的本地配置数据失败，则将本地存储的默认配置数据作为目标配置数据。
162.进一步的，本公开还提供了一种配置数据的更新装置，应用于配置后台。该配置数据的更新装置可以包括配置数据生成模块、配置文件生成模块以及配置文件上传模块。其中：
163.配置数据生成模块可以用于通过配置管理功能更新服务端各个配置项的配置内容，生成相应的配置数据和版本号，并保存至配置数据库中；
164.配置文件生成模块可以用于根据第一预设时间间隔查询配置数据库中的版本号，若版本号有更新，则调用文件存储服务接口获取版本号对应的配置数据，并根据配置数据和对应的版本号生成配置文件；
165.配置文件上传模块可以用于将配置文件上传到多个cdn云服务商对应的云存储中，用于响应客户端向cdn云服务商发起配置获取请求以更新客户端的本地配置数据。
166.在本公开的一些示例性实施例中，本公开提供的一种应用于配置后台的配置数据的更新装置还可以包括文件目录查询模块、首次发布预热模块以及配置文件更新模块。其中：
167.文件目录查询模块可以用于通过文件存储服务接口从配置记录数据库中查询配置文件目录，判断配置文件是否为首次发布；
168.首次发布预热模块可以用于若配置文件为首次发布，则调用cdn预热接口，将配置
文件推送至cdn云服务商的边缘节点；
169.配置文件更新模块可以用于按照预设的文件更新时间间隔刷新配置文件目录，并更新cdn云服务商的边缘节点中的配置文件。
170.进一步的，本公开还提供了一种配置数据的更新装置，应用于配置服务集群。该配置数据的更新装置可以包括内存全局字典写入模块、内存全局字典更新模块、配置获取请求响应模块以及目标配置数据返回模块。其中：
171.内存全局字典写入模块可以用于从配置数据库中获取配置数据，将配置数据写入内存全局字典，并根据配置数据的版本号确定内存全局版本号；
172.内存全局字典更新模块可以用于根据第二预设时间间隔查询配置数据库中的版本号，若版本号大于当前内存全局版本号，则获取版本号对应的配置数据，并更新内存全局字典和内存全局版本号；
173.配置获取请求响应模块可以用于响应于客户端向域名发起的配置获取请求，根据配置获取请求中的请求条件从内存全局字典中获取目标配置数据；
174.目标配置数据返回模块可以用于将目标配置数据返回至客户端，以使客户端根据目标配置数据更新本地配置数据以及对应的版本号。
175.上述配置数据的更新装置中各模块/单元的具体细节在相应的方法实施例部分已有详细的说明，此处不再赘述。
176.图11示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。
177.需要说明的是，图11示出的电子设备的计算机系统1100仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
178.如图11所示，计算机系统1100包括中央处理单元(cpu)1101，其可以根据存储在只读存储器(rom)1102中的程序或者从存储部分1108加载到随机访问存储器(ram)1103中的程序而执行各种适当的动作和处理。在ram 1103中，还存储有系统操作所需的各种程序和数据。cpu 1101、rom 1102以及ram 1103通过总线1104彼此相连。输入/输出(i/o)接口1105也连接至总线1104。
179.以下部件连接至i/o接口1105：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至i/o接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。
180.特别地，根据本发明的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被中央处理单元(cpu)1101执行时，执行本技术的系统中限定的各种功能。
181.需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不
限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。
182.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
183.作为另一方面，本技术还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如上述实施例中所述的方法。
184.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。
185.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本技术旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。
186.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。