CN113067733B - 具有隐私保护的多站点配置控制方法、装置以及设备 - Google Patents

Abstract

本说明书实施例公开了一种具有隐私保护的多站点配置控制方法、装置以及设备。方案包括：多站点包括至少一个中心站，以及多个本地站；通过中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定全局管理平台不将配置数据在中心站内持久化；接收并响应于针对指定业务的指示信息，在多个本地站中，确定具有指定业务的至少两个本地站；在配置数据中，为至少两个本地站分别确定差异化的配置数据；将差异化的配置数据，从全局管理平台，下发给对应的本地站内不具有针对配置数据的操作入口的本地管理平台；通过本地管理平台，将下发得到的差异化的配置数据在本地站内持久化，并加载使用。

Description

具有隐私保护的多站点配置控制方法、装置以及设备

技术领域

本说明书涉及计算机软件技术领域，尤其涉及一种具有隐私保护的多站点配置控制方法、装置以及设备。

背景技术

随着国际贸易的发展，国际业务的规模、数量、覆盖范围也越来越大。

在国际业务中，为了提高业务能力，会建立大量的业务站点，而在对这些业务站点进行配置时，通常会使用相同的配置数据，各业务站点则分别全量加载这些相同的配置数据。

基于此，需要能够更有效的保护配置数据安全、加强站点配置控制的方案。

发明内容

本说明书一个或多个实施例提供一种具有隐私保护的多站点配置控制方法、装置以及设备，用以解决如下技术问题：需要能够更有效的保护配置数据安全、加强站点配置控制的方案。

为解决上述技术问题，本说明书一个或多个实施例是这样实现的：

本说明书一个或多个实施例提供的一种具有隐私保护的多站点配置控制方法，所述多站点包括至少一个中心站，以及多个本地站，包括：

通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化；

接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站；

在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据；

将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

本说明书一个或多个实施例提供的一种具有隐私保护的多站点配置控制装置，所述多站点包括至少一个中心站，以及多个本地站，所述装置包括：

获取模块，通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化；

本地站确定模块，接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站；

差异化确定模块，在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据；

差异化下发模块，将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

加载模块，通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

本说明书一个或多个实施例提供的一种具有隐私保护的多站点配置控制设备，所述多站点包括至少一个中心站，以及设置于境外国家的多个本地站，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化；

接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站；

在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据；

将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

本说明书一个或多个实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化；

接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站；

在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据；

将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

本说明书一个或多个实施例采用的上述至少一个技术方案能够达到以下有益效果：提供了中心站与多个本地站(本地站比如设置于境外，对于隐私合规等方面的要求较高)配合的多站点结构，基于中心站的全局管理平台与本地站的本地管理平台的交互，由全局管理平台向本地站下发差异化的配置数据，避免了全量下发带来的冗余计算、资源浪费，可提高本地站的配置效率，也有助于保护本地站所在国的国内隐私内容。同时，全局管理平台不对配置数据持久化，仅由本地管理平台自己对配置数据进行持久化存储，提高了配置数据的安全性，防止配置数据中的隐私内容泄露。此外，通过中心站的全局管理平台，可针对指定业务与对应的本地站进行调度与编排，对多个本地站进行配置数据的统一控制。本地管理平台仅需接收来自全局管理平台下发的配置数据，进行配置，无需考虑其他本地站，有利于避免重复配置，提高配置效率，增强多站点的稳定性和配置完整性。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本说明书一个或多个实施例提供的一种具有隐私保护的多站点配置控制方法的流程示意图；

图2为本说明书一个或多个实施例提供的一种应用场景下，图1中方法对应的具有隐私保护的多站点配置控制的系统结构示意图；

图3为本说明书一个或多个实施例提供的一种应用场景下，图1中方法的一种详细流程示意图；

图4为本说明书一个或多个实施例提供的一种应用场景下，本地站内的配置数据加载处理示意图；

图5为本说明书一个或多个实施例提供的一种应用场景下，具有隐私保护的多站点配置控制方法的另一种详细流程示意图；

图6为本说明书一个或多个实施例提供的一种具有隐私保护的多站点配置控制装置的结构示意图；

图7为本说明书一个或多个实施例提供的一种具有隐私保护的多站点配置控制设备的结构示意图。

具体实施方式

本说明书实施例提供一种具有隐私保护的多站点配置控制方法、装置、设备以及存储介质。

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

在本说明书一个或多个实施例中，提供了一种多站点结构，包括：以国际中心站(以下简称为“中心站”)为核心、以境外各国内的国际本地站(以下简称为“本地站”)为支持的多站点结构。其中，中心站具有核心计算能力，可承接多国业务，本地站基于境外各国当地的数据合规要求建设，具有部分计算能力，仅支持本地业务。需要说明的是，上面这种国际多站点是一种实际应用场景，下面一些实施例也主要以该场景为例说明，本说明书方案同样也是用于不限地域的多站点场景。

通过中心站内的全局管理平台，为本地站分别下发差异化的配置数据，使本地站仅需对自身需要的配置数据进行同步处理，避免冗余计算；并且，中心站不对配置数据进行持久化，仅由本地站通过本地管理平台的操作入口对配置数据进行管理，可加强配置数据中的隐私内容的安全保护；此外，中心站通过全局管理平台确定指定业务以及对应的本地站内的机房，本地站仅需对下发得到的指定业务的配置数据进行处理，避免了本地站的额外操作，加强了多站点体系的配置数据控制管理。下面基于这样的思路，具体进行说明。

图1为本说明书一个或多个实施例提供的一种具有隐私保护的多站点配置控制方法的流程示意图。该流程可以由相应领域的计算设备执行，流程中的某些输入参数或者中间结果允许人工干预调节，以帮助提高准确性。

在多站点结构中，多站点包括至少一个中心站，以及设置于境外国家的多个本地站。其中，中心站可设置在本国境内，也可根据国际业务的需要，设置在相应的境外国家。本地站分别设置于不同境外国家内，基于相应国家对数据合规的要求而设置。中心站、本地站的数量均可基于国际业务的范围、业务量等确定，本说明书对此不做限定。

图1中的流程可以包括以下步骤：

S102：通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化。

一些配置数据往往涉及用户隐私，比如，包含用户账户、商户的客户信息、经营数据等隐私数据的内容。配置数据表示本地站执行国际业务时对应的站内配置信息，包括支付配置数据、风控配置数据等。

中心站的全局管理平台不将获取的配置数据存储至数据库或写入日志，不进行持久化处理，可通过缓存、内存等方式，对配置数据进行临时存储，并在完成配置数据下发后，再对临时存储的配置数据进行删除等操作。这样能够防止配置数据中与境外国家相关的隐私内容的泄露，提高配置数据的安全性。

中心站内的全局管理平台用于对中心站管理的各本地站的配置控制进行统一管理，并对配置数据的获取、下发等过程进行生命周期管理，可以由全局管理平台提供唯一的操作入口(比如，管理页面入口)，而后面将要提到的本地管理平台均不具有操作入口。在一种应用场景下，比如将全局管理平台称为“全局管理时”、全局管理系统等，该名称并不构成对其功能的限定。

S104：接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站。

在本说明书一个或多个实施例中，配置人员可针对指定业务进行相关本地站的配置。于是，通过中心站的全局管理平台，可接收配置人员确定的针对指定业务的指示信息。全局管理平台响应于指示信息，可在多个本地站中，确定具有指定业务的至少两个本地站，比如，对于跨国的商户，以其经营的业务作为指定业务，通过这种方式，直接筛选出分布在多个不同国家的本地站。之后，全局管理平台可在配置数据中，为确定出的至少两个本地站分别确定差异化的配置数据。

S106：在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据。

中心站可同时向对应的多个本地站下发配置数据。不同本地站对应的配置数据可能相同，也可能不同。中心站在同时向至少两个所需配置数据不同的本地站下发配置数据时，需要分别确定该至少两个配置数据分别对应的差异化的配置数据。

在本说明书一个或多个实施例中，上述的至少两个本地站分别设置于不同的境外国家，上述的指定业务也与境外国家关联，这些境外国家分别有自己的合规要求(比如，本国法律要求、业务数据的保密等级、对于本地民族的禁忌事项、公文敏感词等、相关手续费用等)。基于此，在全局管理平台已得到的配置数据中，获取适应于该境外国家的指示了合规要求的合规信息的配置数据，根据所述适应于所述合规信息的配置数据，为所述至少两个本地站分别确定差异化的配置数据。这里的差异化一方面体现了合规的差异化，另一方面体现了本地站上的自身的业务差异化(比如，是控制支付业务风险、还是控制贷款业务风险等)。

S108：将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台。

针对中心站向各本地站的差异化的配置数据的下发，不同本地站得到的配置数据均为本站所需的配置数据。于是，本地站可直接对下发得到的配置数据进行处理，节省了全量下发过程中对无用的配置数据的识别过程与额外的工作量，提高了本地站的配置效率，同时防止其他站点随意获知本站的配置数据，提高了配置数据的安全性。本地管理平台不具有上述的操作入口以免在本地人为为下发的配置数据干预，而脱离中心站的管控。

在本说明书一个或多个实施例中，各本地站分别部署有本地管理平台，用于对本地站进行管理，对获得的配置数据进行配置处理及发布。在一种应用场景下，比如将本地管理平台称为“本地管理时”、本地管理系统等。

并且，中心站内也可部署有本地管理平台。中心站内的本地管理平台用于对中心站自身的配置数据进行处理，负责中心站的内部管理，与其他各站点相互独立。

在本说明书一个或多个实施例中，对于无需隐私保护的配置数据，中心站可通过全局管理平台，向对应的所有本地站进行全量下发，以提高下发效率。

具体地，中心站内的全局管理平台可基于超文本传输协议(HyperText TransferProtocol，HTTP)、远程过程调用(Remote Procedure Call，RPC)等方式，与各本地站的本地管理平台的接口进行交互。

S110：通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

本地站可通过本地管理平台，将下发得到的配置数据存储至数据库，实现持久化存储。各本地站之间相互隔离，数据库也相互独立隔离，本地站难以获知其他站点的配置数据。

在本说明书一个或多个实施例中，本地站部署有多个运行平台，运行平台用于对配置数据进行加载使用。在一种应用场景下，比如将运行平台称为“运行时”、运行系统等。

通过图1的方法，提供了中心站与多个境外本地站配合的多站点结构，基于中心站的全局管理平台与本地站的本地管理平台的交互，由全局管理平台向本地站下发差异化的配置数据，避免了全量下发带来的冗余计算、资源浪费，可提高本地站的配置效率，也有助于保护本地站所在国的国内隐私内容。同时，全局管理平台不对配置数据持久化，仅由本地管理平台自己对配置数据进行持久化存储，提高了配置数据的安全性，防止配置数据中的隐私内容泄露。此外，通过中心站的全局管理平台，可针对指定业务与对应的本地站进行调度与编排，对多个本地站进行配置数据的统一控制。本地管理平台仅需接收来自全局管理平台下发的配置数据，进行配置，无需考虑其他本地站。这样有利于避免重复配置，提高配置效率，增强多站点的稳定性和配置完整性。

在该多站点结构中，提供了巧妙的权限控制，即实现了配置数据的顺利下发加载，又将各站点的权限限制到较低的必要程度。比如，中心站的全局管理平台虽然有操作入口，但是自身却不能将配置数据持久化，而对于本地站的本地管理平台，其虽然能够将下发给自己的数据持久化，但是自身却没有操作入口，也即，对于能够掌握第一手配置数据的一方，这些数据只是很快从自己这里过一路，而对于要使用这些数据的一方，只能乖乖地推进使用动作，而不具备其他操控余地，通过这种方式，保障了数据隐私性，而且有助于满足本地站所在地的合规要求，尤其适用于本地站点在境外国家的国际业务场景。

基于图1的方法，本说明书还提供了该方法的一些具体实施方案和扩展方案，下面继续进行说明。

在本说明书一个或多个实施例中，中心站对各本地站进行统一管理，通过中心站内的全局管理平台提供的操作入口，可编辑得到包含预定隐私内容的配置数据。其中，对配置数据的编辑操作包括新增、删除、修改等。

之后，中心站可将配置数据下发给对应的本地站内不具有针对配置数据的操作入口的本地管理平台。本地站可通过本地管理平台接收中心站下发的配置数据，但无法对配置数据进行编辑。这样能确保中心站对各本地站的统一管理，由中心站进行统一配置，提高配置效率，有助于提高中心站的掌控程度，从而也提高配置数据的安全，减少在本地被篡改的风险。

在本说明书一个或多个实施例中，指定业务与境外国家相关联，指定业务可以根据业务本身划分，或者根据法人进行划分，比如，指定业务是境外国家内的客户的电商业务(比如，某个线上购物应用)、支付业务、大体量应用中内嵌的微应用(比如，某个“小程序”)等，或者是境外国家内的指定客户的至少部分业务等。指示信息用于确定指定业务，可包括指定业务的标识等。

进一步地，可同时指定多个业务，一同下发配置数据。于是，全局管理平台可分别确定这多个指定业务对应的本地站，并向相应本地站下发差异化的配置数据。

具体地，可根据境外国家内的不同商户，划分出不同支付业务。于是，配置人员可基于不同商户对应的支付业务进行指定。则中心站的全局管理平台可接收针对指定的商户的支付业务的指示信息，并对指定的商户的支付业务对应的本地站进行配置，以满足指定的商户的业务需求。其中，商户可表示企业、协会、组织等相对独立的商业个体，商户与支付业务之间的对应关系，可基于商户的需求确定。

在本说明书一个或多个实施例中，业务与本地站之间可预设有默认对应关系。针对指定业务，可确定与指定业务默认关联的本地站，并向确定出的默认关联的本地站下发配置数据。这样能够节省确定本地站的操作，方便快捷。

进一步地，针对确定出的默认关联的本地站，可通过全局管理平台，基于实际需求，对本地站进行增加、删除等操作，以确定最终下发配置数据的本地站，灵活易操作。

在本说明书一个或多个实施例中，各站点中分别设置有至少一个机房，用于容纳实际的计算设备，包括服务器、操作终端等。一个业务可部署在多个机房中，具体基于业务需求以及业务量等确定。

具体地，中心站的全局管理平台可确定至少两个本地站分别对应的机房。之后，全局管理平台可在配置数据中，为至少两个本地站分别对应的机房确定差异化的配置数据，并将差异化的配置数据，从全局管理平台下发给对应的本地站对应的机房内的本地管理平台。

进一步地，本地站与其对应的机房之间可存在默认关联关系。全局管理平台在确定了本地站对应的机房后，可向其对应的默认关联的机房下发配置数据。其中，一个本地站对应的多个机房下发得到的配置数据是相同的。

更进一步地，一个本地站对应多个默认关联的机房时，全局管理平台也可通过删除等操作，确定仅向该本地站对应的部分机房下发配置数据，使下发的配置数据仅在部分机房生效。

在本说明书一个或多个实施例中，中心站的全局管理平台在向本地站下发配置数据时，需要下发主配置数据与包含预定隐私内容的配置数据。其中，主配置数据表示本地站运行需要的主要配置信息，其作为配置数据下发的主体，所占比重较大。包含预定隐私内容的配置数据包括风控配置数据，风控配置数据表示在集团电商、海外电商、跨境等风控防控场景下风控运行需要的配置信息，包括策略规则、底层脚本、名单可信配置、历史数据、图查询等。风控配置数据作为配置数据下发的辅助，所占比重较小。

在实际应用中，不同本地站所需的主配置数据往往是相同的，而作为辅助的风控配置数据确不同。但是，由于主配置数据往往对应有更多的话语权(比如，由公司的核心团队维护)，从便于管理和整体效率的角度而言，小体量的风控配置数据往往不得不迁就于主配置数据，被笼统地全量下发，从而也导致背景技术的问题。基于此，针对这种被迫迁就的业务场景，本方案采用更小粒度的精细化管控，从配置数据中，拆分出风控配置数据和作为主体的主配置数据，风控配置数据用于辅助主配置数据，根据风控配置数据，为上述的至少两个本地站分别确定差异化的风控配置数据，将对风控配置数据的这种下方方式称为第一下发方式。而对于主配置数据，则采用效率高于第一下发方式的第二下发方式(比如，不走本地管理平台，直接下发到本地站上实际的加载模块上，再比如，通过邻近的本地站相互之间下发等)，将相同的主配置数据下发给这至少两个本地站，如此，既不耽误主配置数据下发，又提高了风控配置数据下发的精准性，降低了风控配置数据下发的冗余性，有助于公司里的主辅团队责权更明确，提高解耦性。

在主配置数据不包含隐私内容时，全局管理平台可同时向多个本地站下发相同的主配置数据，使各本地站进行相应的配置。但在下发包含隐私内容的风控配置数据时，全局管理平台可为至少两个本地站分别确定差异化的风控配置数据，并分别进行差异化的风控配置数据的下发。这样能够在主配置数据同时下发、提高配置效率的同时，提高各本地站的风控配置数据的安全性。

由于多个本地站对应的主配置数据通常相同，因此，中心站在下发主配置数据时，无需对其进行区分。而针对具有差异的本地站对应的差异化的风控配置数据，则可为其预先设置对应的业务标识，以便于区分。

具体地，本地站在获得差异化的风控配置数据后，可通过本地管理平台，确定风控配置数据对应的业务标识。从本地站中运行风控配置数据的多个风控运行平台中，可确定与相应业务标识对应的风控运行平台。于是，本地站可通过确定出的风控运行平台，对下发得到的风控配置数据进行加载使用。这样实现了不同业务之间的独立隔离，由风控运行平台分别对相应业务标识的风控配置数据进行加载，提高了风控配置数据的加载处理效率，避免风控运行平台加载不匹配的风控配置数据而产生的冗余计算。

也就是说，若风控运行平台确认存在对应匹配的业务标识，则可对相应的风控配置数据加载使用。若风控运行平台确认不存在对应匹配的业务标识，则可不对任何风控配置数据进行处理。

在本说明书一个或多个实施例中，本地站接收到配置数据后，可通过本地管理平台，基于本地站所在国家的技术规范、数据合规要求等条件，对下发得到的差异化的配置数据进行形式上、内容上的各项检查。在检查通过后，本地管理平台可对差异化的配置数据进行配置处理，并在处理完成后进行站内发布。

进一步地，本地站的本地管理平台在站内进行配置数据发布时，根据预设的发布数量上限进行发布，以避免一次发布的配置数据的内容过多。

在本说明书一个或多个实施例中，中心站可通过全局管理平台，对本地站内的配置数据和/或配置数据的配置结果进行读取。

具体地，中心站的全局管理平台可接收针对指定业务的读取请求。响应于该读取请求，全局管理平台可在多个本地站中，确定具有指定业务的本地站。之后，全局管理平台可通过确定出的具有指定业务的本地站的本地管理平台，获取本地站对应的配置数据和/或配置数据的配置结果。

在本说明书一个或多个实施例中，优选地让每个本地站的数据库相互独立隔离，一方面提高了安全性，另一方面及时有部分相同配置下发到不同的本地站，也不会有数据标识冲突的问题。另外，为了提高本地站的配置效率，本地站可在一定条件下，向其他本地站开放配置数据同步接口，以允许其他本地站获取该站内的配置数据，进行配置数据同步。

其中，上述条件可包括：同属一个国家的其他本地站；或者同属一个国际组织、国际联盟等该本地站所加入并承认的组织，且业务领域相同、接近的其他本地站；或者具有同一客户的业务的其他本地站；等等。

这些其他本地站均与该本地站具有一定的关联，且具有该本地站的信任，能在保证配置数据安全的基础上，通过各本地站之间的不完全隔离，实现各本地站之间的通信，在这种情况下，这些有关联的多个本地站也可以视为一个整体的虚拟本地站，进行统一管理下发配置数据。

为了进一步提高配置数据的安全性，中心站的全局管理平台可向确定出的风险站点下发混淆配置数据，以保护真实的配置数据，缓解配置数据泄露的风险。

中心站的全局管理平台可从确定出的正常站点中，选择一个正常站点，作为监控站点，对上述确定出的风险站点进行监控。针对下发给风险站点的配置数据，监控站点将该配置数据在本站内模拟加载运行，风险站点和监控站点分别将配置结果和模拟结果上传给中心站，中心站通过对这些数据分析比对，判定风险站点的配置数据是否确实被篡改。

其中，风险站点为经过检测确定可能存在数据泄露或者篡改风险的站点，具体检测方式可通过举报信息、本地站状态上报等方式实现。

结合前面的说明，本说明书一个或多个实施例提供了的一种应用场景下，图1中方法对应的一种具有隐私保护的多站点配置控制的系统结构示意图，该结构对应了前面一些可选的方案，该结构如图2所示。

国家多站点体系包括中心站与多个本地站。

中心站包括全局管理平台、本地管理平台、数据库与运行平台。全局管理平台用于管理中心站内的元数据；本地管理平台用于管理中心站内部的配置数据，负责本地配置的读写；运行平台用于加载配置数据；数据库用于存储中心站内部的配置数据及其他数据。

中心站在配置人员的控制下，通过全局管理平台，基于HTTP、RPC等远程调用的方式，与本地站的本地管理平台通信。

本地站包括本地管理平台、数据库、运行平台。本地管理平台用于与中心站通信接收来自中心站下发的配置数据；数据库用于对配置数据及其他数据进行存储；运行平台用于对本地站内的配置数据加载使用。

结合前面的说明，本说明书一个或多个实施例提供了的一种应用场景下，图1中方法对应的一种详细的方法流程示意图，该流程对应了前面一些可选的方案，该流程如图3所示。

配置人员通过中心站的全局管理平台提供的入口，编辑获得配置数据，并确定要下发到本地站。

针对指定业务发出指示信息，并根据指定业务，确定下发的配置数据对应的本地站中的机房。

通过调用相应本地站的本地管理平台的下发接口，向相应本地站下发对应的配置数据。

各本地站对应的本地管理平台基于下发得到的配置数据，执行下发逻辑处理，对配置数据进行检查，确定检查通过后，对配置数据进行配置处理，并将处理完成的配置数据在站内发布。

中心站在向相应的本地站下发配置数据后，获取本地站返回的配置数据的配置结果，进行结果合并。若所有配置结果中，存在下发失败的站点，则向相应的本地站重新下发配置数据。若多次重新下发配置数据得到的配置结果仍为失败，则可对本次下发过程进行全局回滚，对对应的所有本地站均重新下发配置数据。若回滚后，仍存在配置数据下发失败的本地站，则重新进行回滚，或报错，由配置人员通过人工介入修正配置数据下发失败的错误。

本地站的本地管理平台在接收下发的配置数据的过程中，根据预设的灰度阶段，对本地站内的配置数据进行逐步配置更新。在每个灰度阶段中，本地管理平台均向全局管理平台反映本次灰度阶段的配置结果。本地管理平台在每个灰度阶段中，基于预先关联的监控装置，对当前的配置发布进行监控，若存在报错，则确定当前灰度阶段阻断，否则确定当前灰度阶段完成。

全局管理平台确定一个灰度阶段中所有对应的本地站均完成配置处理，则确定该灰度阶段完成，可执行下一灰度阶段。全局管理平台调用灰度推进接口，通过本地管理平台，继续执行下一灰度阶段。当所有灰度阶段执行完成后，可确定配置数据下发完成。

本地管理平台在处理配置数据的过程中，保障处理过程的冥等性，以确保无论是否重复操作，其结果都只有一次，保障需要的数据只响应执行一次。

结合前面的说明，本说明书一个或多个实施例提供了一种应用场景下，本地站内的配置数据加载处理示意图，该过程对应了前面一些可选的方案，该过程如图4所示。

本地站内的本地管理平台在接收到下发的配置数据后，在对配置数据进行持久化存储时，对配置数据的业务标识、时间戳、类型、唯一用户标识(Unique User Identifier，UUID)、具体参数等一同存储进数据库中。其中，配置数据表示包含隐私内容并具有差异化的风控配置数据。

同时，本地管理平台以业务标识与时间戳为标志，对配置数据进行公布。于是，本地站内的运行平台可基于配置数据对应的业务标识，确定是否存在匹配的业务标识。图中运行平台A确定不存在匹配的业务标识，则忽略该发布消息。运行平台B确定存在匹配的业务标识，则从数据库中确定对应的配置数据的具体信息，进行配置加载读取，并在加载完成后回写发布回执。

结合前面的说明，本说明书一个或多个实施例提供了的一种应用场景下，具有隐私保护的多站点配置控制方法的另一种详细的方法流程示意图，该流程对应了前面一些可选的方案，该流程如图5所示。

配置人员通过中心站的全局管理平台提供的入口，针对指定业务，确定对配置数据和/或配置数据的配置结果的读取请求，并确定对应的本地站中的机房。

通过调用相应机房的本地管理平台的读取接口，获取相应机房的配置数据和/或配置数据的配置结果。

各机房对应的本地管理平台基于中心站的读取请求，执行逻辑处理，对读取请求进行检查，确定检查通过后，对读取请求进行处理，并读取对应的配置数据和/或配置数据的配置结果。

中心站在向相应的机房发送读取请求后，获取机房返回的配置数据和/或配置数据的配置结果的读取结果，进行结果合并。

具体地，全局管理平台可根据读取结果对应的UUID，对各机房返回的读取结果进行分类聚合展示。通过展示的读取结果，可确定指定业务在对应机房中的配置数据和/或配置数据的配置结果。

若所有读取结果中，存在读取请求下发失败的站点，则向相应的本地站重新下发读取请求，或者对相应的本地站进行人工介入检修。若重新下发读取请求得到的读取结果仍为失败，则报错，由配置人员进行人工检查。

中心站的全局管理平台确定相应本地站均读取成功后，可对读取结果进行数据检查。若数据正常，可将各本地站的读取结果进行合并展示，并确定读取结束。若存在数据异常，则发出报错提示，进行人工检查。

基于同样的思路，本说明书一个或多个实施例还提供了上述方法对应的装置和设备，如图6、图7所示。

图6为本说明书一个或多个实施例提供的一种具有隐私保护的多站点配置控制装置的结构示意图，图中虚线所示的模块为可选的模块，所述多站点包括至少一个中心站，以及设置于境外国家的多个本地站，所述装置包括：

获取模块602，通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化，所述隐私内容与所述境外国家相关；

本地站确定模块604，接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站；

差异化确定模块606，在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据；

差异化下发模块608，将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

加载模块610，通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

可选地，所述至少两个所述本地站设置于境外国家，所述指定业务与所述境外国家关联；所述差异化确定模块606在所述配置数据中，获取适应于所述境外国家的合规信息的配置数据；

根据所述适应于所述合规信息的配置数据，为所述至少两个本地站分别确定差异化的配置数据。

可选地，所述本地站确定模块604确定预先根据所述境外国家内的不同商户划分出的不同支付业务；接收针对指定的所述商户的支付业务的指示信息。

可选地，所述差异化确定模块606确定至少两个所述本地站分别对应的机房；在所述配置数据中，为所述至少两个所述本地站分别对应的机房确定差异化的配置数据；所述差异化下发模块608将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站对应的机房内的本地管理平台，所述本地管理平台不具有针对所述配置数据的操作入口。

可选地，所述差异化确定模块606，从所述配置数据中，拆分出风控配置数据和作为主体的主配置数据，所述风控配置数据用于辅助所述主配置数据，根据所述风控配置数据，为至少两个所述本地站分别确定差异化的风控配置数据；

所述装置还包括：

主配置下发模块612，采用效率高于所述风控配置数据的第一下发方式的第二下发方式，将相同的所述主配置数据下发给所述至少两个所述本地站。

可选地，所述加载模块610通过所述本地管理平台，确定下发得到的所述差异化的风控配置数据的业务标识；在所述本地站内的多个风控运行平台中，确定与所述业务标识对应的风控运行平台；通过所述确定的风控运行平台，对相应的风控配置数据进行加载使用。

可选地，还包括：配置读取模块614，接收针对指定业务的读取请求；响应于所述读取请求，在所述多个本地站中，确定具有所述指定业务的本地站；通过所述具有指定业务的本地站的本地管理平台，获取所述本地站对应的配置数据和/或配置数据的配置结果。

可选地，还包括：检查发布模块616，通过所述本地管理平台，按照预定策略，对下发得到的所述差异化的配置数据检查通过并发布。

图7为本说明书一个或多个实施例提供的一种具有隐私保护的多站点配置控制设备的结构示意图，所述多站点包括至少一个中心站，以及多个本地站，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化；

接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站；

在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据；

将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

处理器与存储器之间可以通过总线通信，设备还可以包括与其他设备通信的输入/输出接口。

基于同样的思路，本说明书一个或多个实施例还提供了对应于上述方法的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化；

接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站；

在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据；

将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本说明书实施例可提供为方法、系统、或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。

Claims (17)

1.一种具有隐私保护的多站点配置控制方法，所述多站点包括至少一个中心站，以及多个本地站，所述方法包括：

通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化；

接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站，所述至少两个所述本地站设置于境外国家；

在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据，具体包括：在所述配置数据中，获取适应于所述境外国家的合规信息的配置数据，根据所述适应于所述合规信息的配置数据，为所述至少两个本地站分别确定差异化的配置数据；

将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

2.如权利要求1所述的方法，所述指定业务与所述境外国家关联。

3.如权利要求2所述的方法，所述接收针对指定业务的指示信息，具体包括：

确定预先根据所述境外国家内的不同商户划分出的不同支付业务；

接收针对指定的所述商户的支付业务的指示信息。

4.如权利要求1所述的方法，所述在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据，具体包括：

确定至少两个所述本地站分别对应的机房；

在所述配置数据中，为所述至少两个所述本地站分别对应的机房确定差异化的配置数据；

所述将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台，具体包括：

将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站对应的机房内的本地管理平台，所述本地管理平台不具有针对所述配置数据的操作入口。

5.如权利要求1所述的方法，所述在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据，具体包括：

从所述配置数据中，拆分出风控配置数据和作为主体的主配置数据，所述风控配置数据用于辅助所述主配置数据，根据所述风控配置数据，为至少两个所述本地站分别确定差异化的风控配置数据；

所述方法还包括：

采用效率高于所述风控配置数据的第一下发方式的第二下发方式，将相同的所述主配置数据下发给所述至少两个所述本地站。

6.如权利要求5所述的方法，所述加载使用，具体包括：

通过所述本地管理平台，确定下发得到的所述差异化的风控配置数据的业务标识；

在所述本地站内的多个风控运行平台中，确定与所述业务标识对应的风控运行平台；

通过所述确定的风控运行平台，对相应的风控配置数据进行加载使用。

7.如权利要求1所述的方法，所述方法还包括：

接收针对指定业务的读取请求；

响应于所述读取请求，在所述多个本地站中，确定具有所述指定业务的本地站；

通过所述具有指定业务的本地站的本地管理平台，获取所述本地站对应的配置数据和/或配置数据的配置结果。

8.如权利要求1所述的方法，所述加载使用之前，所述方法还包括：

通过所述本地管理平台，按照预定策略，对下发得到的所述差异化的配置数据检查通过并发布。

9.一种具有隐私保护的多站点配置控制装置，所述多站点包括至少一个中心站，以及多个本地站，所述装置包括：

获取模块，通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化；

本地站确定模块，接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站，所述至少两个所述本地站设置于境外国家；

差异化确定模块，在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据，具体包括：在所述配置数据中，获取适应于所述境外国家的合规信息的配置数据，根据所述适应于所述合规信息的配置数据，为所述至少两个本地站分别确定差异化的配置数据；

差异化下发模块，将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

加载模块，通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

10.如权利要求9所述的装置，所述指定业务与所述境外国家关联。

11.如权利要求10所述的装置，所述本地站确定模块确定预先根据所述境外国家内的不同商户划分出的不同支付业务；

接收针对指定的所述商户的支付业务的指示信息。

12.如权利要求9所述的装置，所述差异化确定模块确定至少两个所述本地站分别对应的机房；

在所述配置数据中，为所述至少两个所述本地站分别对应的机房确定差异化的配置数据；

所述差异化下发模块将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站对应的机房内的本地管理平台，所述本地管理平台不具有针对所述配置数据的操作入口。

13.如权利要求9所述的装置，所述差异化确定模块，从所述配置数据中，拆分出风控配置数据和作为主体的主配置数据，所述风控配置数据用于辅助所述主配置数据，根据所述风控配置数据，为至少两个所述本地站分别确定差异化的风控配置数据；

所述装置还包括：

主配置下发模块，采用效率高于所述风控配置数据的第一下发方式的第二下发方式，将相同的所述主配置数据下发给所述至少两个所述本地站。

14.如权利要求13所述的装置，所述加载模块通过所述本地管理平台，确定下发得到的所述差异化的风控配置数据的业务标识；

在所述本地站内的多个风控运行平台中，确定与所述业务标识对应的风控运行平台；

通过所述确定的风控运行平台，对相应的风控配置数据进行加载使用。

15.如权利要求9所述的装置，还包括：

配置读取模块，接收针对指定业务的读取请求；

响应于所述读取请求，在所述多个本地站中，确定具有所述指定业务的本地站；

通过所述具有指定业务的本地站的本地管理平台，获取所述本地站对应的配置数据和/或配置数据的配置结果。

16.如权利要求9所述的装置，还包括：

检查发布模块，通过所述本地管理平台，按照预定策略，对下发得到的所述差异化的配置数据检查通过并发布。

17.一种具有隐私保护的多站点配置控制设备，所述多站点包括至少一个中心站，以及多个本地站，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

通过所述中心站内的全局管理平台提供的操作入口，编辑得到配置数据，以及确定所述全局管理平台不将所述配置数据在所述中心站内持久化；

接收并响应于针对指定业务的指示信息，在所述多个本地站中，确定具有所述指定业务的至少两个本地站，所述至少两个所述本地站设置于境外国家；

在所述配置数据中，为至少两个所述本地站分别确定差异化的配置数据，具体包括：在所述配置数据中，获取适应于所述境外国家的合规信息的配置数据，根据所述适应于所述合规信息的配置数据，为所述至少两个本地站分别确定差异化的配置数据；

将所述差异化的配置数据，从所述全局管理平台，下发给对应的所述本地站内不具有针对所述配置数据的操作入口的本地管理平台；

通过所述本地管理平台，将下发得到的所述差异化的配置数据在所述本地站内持久化，并加载使用。

Images