多用户场景下的参数配置方法、系统、电子设备及介质

技术领域

本申请涉及通信技术领域，特别涉及一种多用户场景下的参数配置方法、系统、电子设备及介质。

背景技术

在支持多租户的微服务系统中，通常会使用配置参数来驱动系统逻辑。租户不同，其所需的用于驱动系统逻辑的配置参数设定值也不同。

以时区配置参数为例，微服务系统使用时需要设置时区配置参数值来控制显示时间，当两个租户来自不同的时区时，为了便于向各租户显示其所在时区的具体时间，就需要开发人员在代码中硬编码时区配置参数。目前常用的一种操作方式为记录各租户账号或者名字与其所在时区的映射关系，在用户登录后，系统会通过映射关系等条件判断该用户的具体时区，以加载该时区对应的参数值至上述时区配置参数中。

然而采用上述配置参数编码方式，一旦租户数量有变，开发人员就需要频繁编写或修改代码，这样会使程序编写的出错率升高，进而导致系统不稳定且难以维护。

发明内容

本申请实施例提供了一种多用户场景下的参数配置方法、系统、电子设备以及存储介质，以解决现有技术中的配置参数编码方式所存在的一旦租户数量有变，开发人员就需要频繁编写或修改代码的问题。

第一方面，本申请实施例提供了一种多用户场景下配置参数获取方法，用于包括用户终端、配置中心服务器和业务服务器的系统，配置中心服务器内存储有全局参数和专有参数，专有参数的名称中包括用户代码信息；该方法包括：

用户终端向业务服务器发送服务请求；

业务服务器基于服务请求获取目标用户代码和待配置参数，并基于目标用户代码和待配置参数向配置中心服务器请求确定目标专有参数；

在基于目标用户代码和待配置参数在配置中心服务器内获取到目标专有参数的情形中，配置中心服务器将目标专有参数的参数值发送至业务服务器；

在基于目标用户代码和待配置参数在配置中心服务器内未获取到目标专有参数的情形中，配置中心服务器将待配置参数名称相对应的目标全局参数的参数值发送至业务服务器；

业务服务器基于配置中心服务器输出的参数值配置待配置参数。

本申请的多用户场景下的用于包括用户终端、配置中心服务器和业务服务器的系统，配置中心服务器内存储有全局参数和专有参数，专有参数的名称中包括用户代码信息参数配置方法，通过以同时包含用户代码信息和参数名的形式定义用户专有参数，在使用配置参数时，只需要基于用户和待配置参数名称，系统就会自动检查是否存在当前租户的重载参数(即名称中包含有该用户代码信息和待配置参数名称的专有参数)，如果该重载参数存在，则使用该重载参数，如果该重载参数不存在，则使用与待配置参数名称相应的全局参数。本申请提供的方法可以实现配置参数的租户级重载，无需修改代码，大大简化了配置参数管理的难度。

在上述第一方面的一种可能的实现中，基于目标用户代码和待配置参数向配置中心服务器请求确定目标专有参数，包括：

业务服务器基于服务请求获取目标用户代码和待执行的待配置参数，并存储目标用户代码；

业务服务器响应于执行待配置参数，调取其所存储的目标用户代码，并将目标用户代码和待配置参数进行重组以构建目标专有参数的标识；

业务服务器基于目标专有参数的标识向配置中心服务器请求确定目标专有参数。

在上述第一方面的一种可能的实现中，服务请求中包括登录用户的用户令牌参数，以及，基于服务请求获取目标用户代码，包括：

基于服务请求获取用户的用户令牌参数；

解析用户令牌参数，获取目标用户代码。

在上述第一方面的一种可能的实现中，系统还包括数据库服务器，数据库服务器内存储有多个数据资源，每一数据资源对应一与参数配置值相关的连接；方法还包括：

业务服务器基于配置后的待配置参数获取目标连接，并基于目标连接访问数据库服务器中的目标数据资源。

在上述第一方面的一种可能的实现中，配置中心服务器包括能够被全部用户访问的全局配置平台和各用户专有的用户配置平台，其中，全局参数定义于全局配置平台中，各用户的专有参数定义于与用户对应的用户配置平台中。

在上述第一方面的一种可能的实现中，每一用户配置平台均包括用户共享配置子平台和用户专用配置子平台，其中，用户共享配置子平台中的参数能够被用户的所有服务读取；

专有参数包括定义在用户共享配置子平台中的用于配置时区和登录令牌的各参数，以及，定义在用户专用配置子平台中的用于配置用户数据源连接的各参数。

在上述第一方面的一种可能的实现中，专有参数以用户代码作为参数名前缀的形式进行定义，全局参数以参数名形式定义。

第二方面，本申请实施例提供了一种参数配置系统，包括用户终端、配置中心服务器和业务服务器，

用户终端，用于向业务服务器发送服务请求；

业务服务器，用于基于服务请求获取目标用户代码和待配置参数，并基于目标用户代码和待配置参数向配置中心服务器请求确定目标专有参数，并基于配置中心服务器输出的参数值配置待配置参数；

配置中心服务器用于，在基于目标用户代码和待配置参数获取到目标专有参数的情形中，将目标专有参数的参数值发送至业务服务器，以及，在基于目标用户代码和待配置参数未获取到目标专有参数的情形中，将待配置参数名称相对应的目标全局参数的参数值发送至业务服务器。

在上述第二方面的一种可能的实现中，业务服务器还用于基于服务请求获取目标用户代码和待执行的待配置参数，并存储目标用户代码；业务服务器还用于响应于执行待配置参数，调取其所存储的目标用户代码，并将目标用户代码和待配置参数进行重组以构建目标专有参数的标识；

业务服务器还用于基于目标专有参数的标识向配置中心服务器请求确定目标专有参数。

在上述第二方面的一种可能的实现中，用户终端被配置为在用户登录后，对用户通过其发出的每一服务请求均添加用户的用户令牌参数后再发出；基于服务请求获取目标用户代码，包括：

基于服务请求获取用户的用户令牌参数；

解析用户令牌参数，获取目标用户代码。

在上述第二方面的一种可能的实现中，系统还包括数据库服务器，数据库服务器内存储有多个数据资源，每一数据资源对应一与参数配置值相关的连接；

业务服务器还用于基于配置后的待配置参数获取目标连接，并基于目标连接访问数据库服务器中的目标数据资源。

在上述第二方面的一种可能的实现中，配置中心服务器包括能够被全部用户访问的全局配置平台和各用户专有的用户配置平台，全局参数定义于全局配置平台中，各用户的专有参数定义于与用户对应的用户配置平台中。

在上述第二方面的一种可能的实现中，每一用户配置平台均包括用户共享配置子平台和用户专用配置子平台，其中，用户共享配置子平台中的参数能够被用户的所有服务读取；

专有参数包括定义在用户共享配置子平台中的用于配置时区和登录令牌的各参数，以及，定义在用户专用配置子平台中的用于配置用户数据源连接的各参数。

在上述第二方面的一种可能的实现中，专有参数以用户代码作为参数名前缀的形式进行定义，全局参数以参数名形式定义。

第三方面，本申请实施例提供了一种电子设备，包括：存储器，用于存储电子设备的一个或多个处理器执行的指令，以及处理器，是电子设备中的一个或多个处理器之一，用于执行上述第一方面的任一种可能的实现中的多用户场景下的参数配置方法

第四方面，本申请实施例提供了计算机可读存储介质，计算机可读存储介质上存储有指令，该指令在计算机上执行时使得计算机执行上述第一方面的任一种可能的实现中的多用户场景下的参数配置方法。

附图说明

图1根据本申请的一些实施例，示出了多用户场景下参数配置方法的应用场景图；

图2根据本申请的一些实施例，示出了多用户场景下参数配置系统的结构框图；

图3根据本申请的一些实施例，示出了多用户场景下参数配置方法的流程图一；

图4根据本申请的一些实施例，示出了多用户场景下参数配置方法的流程图二；

图5根据本申请的一些实施例，示出了一种应用场景下的参数配置方法的具体流程图；

图6根据本申请的一些实施例，示出了另一种应用场景下的参数配置方法的具体流程图；

图7根据本申请的一些实施例，示出了一种电子设备的结构示意图；

图8根据本申请的一些实施例，示出了片上系统(System on Chip，SOC)的结构示意图。

具体实施方式

下面结合具体实施例和附图对本申请做进一步说明。可以理解的是，本公开的说明性实施例包括但不限于多用户场景下的参数配置方法、电子设备以及存储介质。此处描述的具体实施例仅仅是为了解释本申请，而非对本申请的限定。此外，为了便于描述，附图中仅示出了与本申请相关的部分而非全部的结构或过程。

以下由特定的具体实施例说明本申请的实施方式，本领域技术人员可由本说明书所揭示的内容轻易地了解本申请的其他优点及功效。虽然本申请的描述将结合较佳实施例一起介绍，但这并不代表此申请的特征仅限于该实施方式。恰恰相反，结合实施方式作发明介绍的目的是为了覆盖基于本申请的权利要求而有可能延伸出的其它选择或改造。为了提供对本申请的深度了解，以下描述中将包含许多具体的细节。本申请也可以不使用这些细节实施。此外，为了避免混乱或模糊本申请的重点，有些具体细节将在描述中被省略。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在支持多租户的微服务系统中，通常会使用配置参数来驱动系统逻辑，配置参数一般包含全局的参数配置和租户专有的参数配置。在一些技术方案中，存在比较难以实现配置参数的租户级重载的缺陷。

图1示出了本申请提供的一个应用场景。系统使用时，服务端10需要设置一个参数zoneId(下以时间参数代称)来控制用户端电子设备的显示时间，其默认值一般为UTC零时区。现有租户a来自中国，希望系统时区为东八区，其对应的时间参数值为Asia/Shanghai，租户b来自日本，希望系统时区设置为东九区，其对应的时间参数值为Asia/Tokyo。当两租户在使用系统服务端10时，服务端10很难知道租户希望的时区是哪个。目前的一种方式是在代码中硬编码租户的专有配置，例如：记录租户账号或者名字与时区的映射关系，通过条件判断来确定租户的具体时区，但是利用该编码方式，租户数量一有变动就需要频繁编写代码，这样会使程序的出错率高，不稳定，导致系统较难维护。

基于此，本申请的实施例还提供了一种新的多用户场景下的参数配置方法或方式，以解决上述研究过程中发现的问题。本实施例的方法，通过包含用户代码信息的形式定义用户专有参数，在使用配置参数时，只需要基于用户代码和待配置参数名称，系统就会自动检查是否存在当前租户的重载参数(即名称中包含有该用户代码信息和待配置参数名称的专有参数)，如果该重载参数存在，则使用该重载参数的参数值来为待配置参数赋值，如果该重载参数不存在，则使用与待配置参数名称相应的全局参数的参数值来配置待配置参数。本申请提供的方法可以实现配置参数的租户级重载，无需修改代码，大大简化了配置参数管理的难度。

根据本申请的实施例的多用户场景下的参数配置取方法，其用于包括用户终端、配置中心服务器和业务服务器的系统，其中，配置中心服务器内存储有全局参数和名称中包括用户代码信息的专有参数。该实施例的参数配置方法包括，用户终端向业务服务器发送服务请求，业务服务器基于服务请求获取目标用户代码和待配置参数，并基于目标用户代码和待配置参数向配置中心服务器请求确定目标专有参数。若配置中心服务器中存在目标专有参数，则配置中心服务器将目标专有参数的参数值发送至业务服务器，否则配置中心服务器将待配置参数名称相对应的目标全局参数的参数值发送至业务服务器，业务服务器基于配置中心服务器输出的参数值配置待配置参数。

上述方法可以实现配置参数的租户级重载，无需修改代码。当需要为某租户定制参数时，只需要添加包含有用户代码信息的专有参数(例如专有参数可采用{用户代码}.{参数名}的形式)，即可实现参数重载，简化配置管理难度。同时，本方法适用于任何需要支持多租户并参数化系统逻辑的服务系统，可以有效实现配置参数的租户级重载，提高系统的灵活性和可维护性。当存在参数变更时，也只需要维护好全局参数和各租户的重载参数，服务系统无需任何修改即可得到最新的配置，大大降低了维护成本。

在本申请的一些实施例中，目标专有参数的确定步骤包括，业务服务器基于服务请求获取目标用户代码和待执行的待配置参数，并存储目标用户代码，业务服务器响应于执行待配置参数，调取所存储的目标用户代码，并将目标用户代码和待配置参数进行重组以构建目标专有参数的标识；业务服务器基于上述标识向配置中心服务器请求确定目标专有参数。

具体地，目标专有参数的标识可以目标专有参数的定义名称，其可表示为{目标用户代码}.{待配置参数的名称}的形式。

以下为了方便说明，结合具体实施例对本申请技术方案作进一步地详细描述。

参考图2所示，本申请实施例的提供了一种参数配置系统包括，用户终端100、配置中心服务器200、业务服务器300和数据库服务器400，配置中心服务器200内存储有全局参数和专有参数，其中，全局参数以参数名形式定义，专有参数以用户代码作为参数名前缀的形式定义，即，“用户代码.参数名”的形式。

在一些实施例中，各参数统一在配置中心服务器200中管理，全局参数可被全部用户读取，其定义在配置中心服务器200的全局配置平台内。全局配置平台包括全局共享配置子平台以及至少一个全局专有配置子平台。其中，全局共享配置子平台内的参数可被集群里的所有服务读到，而全局专有配置子平台内的参数仅可被其相应的单个服务读取到。具体地，全局共享配置子平台可命名为public->platform，全局专有配置子平台可命名为app->platform。

一般而言，用于全局自定义时区的时区配置参数例如{zoneId}，以及，用于全局自定义登陆令牌的令牌参数例如{token}等参数，均存储于全局共享配置子平台内。用于配置全局数据源连接信息的参数(例如，专用于配置当前服务的参数信息的参数jdbc.url和jdbc.user)存储于全局专有配置子平台内，全局专有配置子平台仅能被其对应的服务读取。

在一些实施例中，专有参数即仅限于各租户自己的参数，也可称之为租户级别参数，存储于配置中心服务器200的用户配置平台。专有参数采用用户代码作为前缀的形式，以便于被程序确认为租户级别参数。用户配置平台包括用户共享配置子平台和用户专用配置子平台。专有参数分别存储于用户共享配置子平台和至少一个用户专用配置子平台内。具体地，用户共享配置子平台的名称中可包含用户代码的信息，其可命名为public->{租户代码}，用户专用配置子平台的名称中也包含用户代码的信息，为app->{租户代码}。即每个用户对应自己的一套配置平台和微服务集群。

用户共享配置子平台内的参数能够被用户的全部服务读取，包括用于租户自定义时区的时区配置参数：{租户代码}.{zoneId}，以及用于租户自定义登陆令牌的令牌参数：{租户代码}.{token}等。用户专用配置子平台仅能被其对应的服务读取，其内存储的参数常用于配置租户数据源连接信息，例如：{租户代码}.jdbc.url和{租户代码}.jdbc.user，专用于配置当前服务当前租户的参数信息。

在一些实施例中，用户终端100用于向业务服务器300发送服务请求，业务服务器300用于基于服务请求获取目标用户代码和待配置参数，并基于目标用户代码和待配置参数向配置中心服务器200请求确定目标专有参数，并基于配置中心服务器200输出的参数值配置待配置参数。

在基于目标用户代码和待配置参数在配置中心服务器200内获取到目标专有参数的情形中，配置中心服务器200将目标专有参数的参数值发送至业务服务器300，以使业务服务器300根据目标专有参数的参数值来配置待配置参数。

在基于目标用户代码和待配置参数在配置中心服务器200内未获取到目标专有参数的情形中，配置中心服务器200将待配置参数名称相对应的目标全局参数的参数值发送至业务服务器300，以使业务服务器300根据全局参数的参数值来配置待配置参数。

例如，租户a发送请求给具体的服务，其间用到了file.s3client.accessKey这一待配置参数，配置中心服务器200会优先取参数名为a.file.s3client.accessKey的参数值发送给业务服务器300使用，如果获取不到上述参数，则配置中心服务器200取参数名为file.s3client.accessKey的全局参数的参数值发送给业务服务器300。

在一些实施例中，数据库服务器400内存储有各数据资源，每一数据资源对应一与参数配置值相关的连接；当业务服务器300获取到配置中心服务器200输出的参数值后，会基于该参数值获取相应的目标连接，并基于该目标连接访问数据库服务器400中的目标数据资源。

在一些实施例中，业务服务器300包括代码编辑层和数据持久层，其中，代码逻辑层用来实现整体的业务逻辑，比如获得配置中心服务器200输出的参数值数据后，代码逻辑层对这些数据进行解析、校验等操作。数据持久层主要用于固化存储数据。

在一些实施例中，用户终端100被配置为在用户登录后，对用户通过其发出的每一服务请求均添加用户的用户令牌参数后再发出，其中，用户令牌参数中包含用户代码的信息。

即，在租户在用户终端100登录自己域名之后，从用户终端100发送的任何请求都需要带上租户令牌信息，以便于接收服务请求的后端服务集群(即业务服务器300)可以通过解析令牌识别出具体的租户的用户代码并存储到应用程序上下文中，以方便业务服务器300在程序执行的过程中，遇到其他使用参数的地方，会通过调取用户代码向配置中心请求获取相应的目标专有参数的参数值。便于节约程序运行时间。

在一些实施例中，用户终端100可以提供用户交互界面来实现服务请求的发布等功能，例如，这些功能可以由安装在用户终端100上的一个软件实现。示例性的，用户终端100可以为具有显示屏的设备，包括但不限于台式机、便携式电脑、掌上电脑、手机、平板电脑等。

在一些实施例中，配置中心服务器200以及业务服务器300可以为独立服务器，还可以为云端服务器。其中，独立服务器拥有整台服务器的所有软硬件资源，可以自行分配与实行多种网络功能服务，如可以独立存储微服务的应用数据和配置数据。另外，云端服务器可以是硬件服务器，也可以植入虚拟化环境中，例如，云端服务器可以是在包括一个或多个其他虚拟机的硬件服务器上执行的虚拟机。

在一些实施例中，本申请提供的参数配置系统中除了包括图2示出的各个设备外，还包括一个代码管理设备，用于存储各种服务的代码数据。从而，用户终端100可以从该代码管理设备中获取各个服务的代码数据。

本申请通过使用“{租户代码}.{参数名}”的方式定义租户专有的专有参数，实现了租户隔离。在使用配置参数时，只需要使用参数名，系统会自动检查是否存在当前租户用户代码所对应的专有参数，如果存在，则优先使用该专有参数，否则使用全局参数。这种方案可以实现配置参数的租户级重载，无需修改代码，大大简化了配置参数管理的难度。

同时，采用租户隔离的原则，各个租户有自己的一套专有参数配置就能构建起属于租户自己的服务集群和专属平台。其中几个关键的专有配置参数有用于租户自定义时区的参数{租户代码}.{zoneId}，用于租户自定义登陆令牌的参数{租户代码}.{token}，用于租户自定义数据库连接的参数{租户代码}.{jdbc.*}，以及租户自己的平台域名，例如：https://{租户代码}-gi-dev.insuremo.com/ui/admin/#/等等。在租户登录自己域名之后，从租户的用户终端100发送的任何请求都需要带上租户令牌，后端服务集群通过解析令牌识别出具体的用户代码并存储到应用程序上下文中，在程序执行的过程中，遇到使用参数的地方，会优先选取带有租户代码前缀的专有参数，如不存在，才会取全局参数。即本申请还能够通过重载租户专有参数，达到隔离域名，隔离数据库的效果，进而实现在同一套服务集群及代码前提下，各个租户也能安全、精确的管理自己的数据。

下面参考图3，对本申请的实施例条提供的可用于上述参数配置系统的多用户场景下参数配置方法进行示例性说明。

如图3所示，本申请实施例提供的参数配置方法包括以下步骤：

步骤S101：用户终端100向业务服务器300发送服务请求。

具体地，用户终端100被配置为在用户登录后，对用户通过其发出的每一服务请求均添加用户的用户令牌参数后再发出，用户令牌参数中包含用户代码的信息。

即，在租户在用户终端100登录自己域名之后，从用户终端100发送的任何请求都需要带上租户令牌信息，以便于接收服务请求的后端服务集群(即业务服务器300)可以通过解析令牌识别出具体的租户的用户代码并存储到应用程序上下文中，进而方便业务服务器300在程序执行的过程中，遇到其他使用参数的地方，会通过调取应用程序上下文中存储的用户代码向配置中心请求获取该用户代码相应的目标专有参数的参数值，节省程序运行时间。

可以理解，利用租户令牌(Token)值可以来判断用户的登录状态，Token类似于加密之后的长字符串，以作客户端进行请求的一个“令牌”。在用户登录成功之后，服务器端会根据用户信息生成一个唯一的值，这个值就是Token值，每个Token值对应一唯一的用户信息，因而可以用Token值来解析用户代码。

当用户第一次使用账号密码成功进行登录后，服务器便生成一个Token并将此返回给客户端，若成功登陆，以后客户端就会带上这个Token前来请求数据。

步骤S102：业务服务器300基于服务请求获取目标用户代码和待配置参数，并基于目标用户代码和待配置参数向配置中心服务器200请求确定目标专有参数。

参考图4，在一些实施例中，步骤S102可具体包括：

步骤S1021：业务服务器300基于服务请求获取目标用户代码和待执行的待配置参数，并存储目标用户代码。

由于用户终端100所发出的每一服务请求均添加有用户令牌(一般而言，请求会在其请求头携带Token)，因而在业务服务器300接收到用户终端100发送的服务请求后，业务服务器300可以通过该服务请求首先获取用户令牌，然后再对用户令牌进行解析以获得该服务请求所对应的当前用户的用户代码(即目标用户代码)。

步骤S1022：业务服务器300响应于执行待配置参数，调取其所存储的目标用户代码，并将目标用户代码和待配置参数进行重组以构建目标专有参数的标识，其中，上述标识可用于向配置中心服务器200获取目标专有参数。

具体地，业务服务器300通过解析用户令牌识别出租户具体的用户代码，并将用户代码存储到应用程序上下文中，业务服务器300在程序执行的过程中，如果遇到其他使用参数的地方，便会先调取存储于程序上下文中的用户代码，节约程序运行时间。当在程序上下文中获取到用户代码后，业务服务器300会基于用户代码和待执行的待配置参数重组构建目标专有参数的标识，以向配置中心服务器200获取目标专有参数。

可以理解，程序上下文相当于一个存储模块，其中包含了程序运行的一些参数的配置信息。即上下文可以理解为程序执行的背景环境，包含了在特定时刻程序所需的所有信息。这些信息可以包括变量的值、函数的调用情况、执行的位置等等。

在一些实施例中，专有参数以用户代码作为参数名前缀的形式进行定义，全局参数以参数名形式定义，例如，专有参数的名称为：用户代码.参数名称，全局参数直接以其参数名称命名；此时，基于用户代码和待配置参数重组构建的目标专有参数的标识可以表示为{目标用户代码}.{待配置参数名称}的形式。

步骤S1023：业务服务器300基于目标专有参数的标识向配置中心服务器200请求确定目标专有参数。

步骤S103：判断配置中心服务器200内是否存在上述目标专有参数。即，判断配置中心服务器200内是否存在名称为“{目标用户代码}.{待配置参数名称}”的参数。

具体地，在基于目标用户代码和待配置参数在配置中心服务器200内获取到目标专有参数的情形中(即配置中心服务器200内存储有上述目标专有参数，也即步骤S103为是的情形)，则执行步骤S104：配置中心服务器200将目标专有参数的参数值发送至业务服务器300。

如果没有基于目标用户代码和待配置参数在配置中心服务器200内获取到目标专有参数(步骤S103为否的情形)，则执行步骤S105：配置中心服务器200将待配置参数名称相对应的目标全局参数的参数值发送至业务服务器300。

换言之，业务服务器300会先向配置中心服务器200请求检查配置中心服务器200内是否存在目标租户的重载参数，即名称为{目标用户代码}.{待配置参数名}的专有参数，没有的话，再进一步获取名称为{待配置参数名}的全局参数。

根据具体的业务逻辑，使用参数时会根据待配置参数具体的参数名称在配置中心服务器200内尝试获取带有目标租户代码前缀的参数值，也就是名为{目标用户代码}.{待配置参数名}的参数的值，如果获取不到，则认为租户未重载当前参数，则会取名为{待配置参数名}的参数的值，继续程序的执行。

再换言之，程序根据上下文中存储的租户代码，先将待配置参数的名称前添加{目标租户代码}.前缀构建目标专有参数的标识，然后根据该标识向配置中心服务器200获取该标识名称的专有参数继续执行，获取不到，则获取名称为待配置参数名的全局参数的参数值继续执行。

例如，租户a发送请求给具体的服务，其间用到了file.s3client.accessKey参数，程序会优先取参数名为a.file.s3client.accessKey的参数值使用，否则取参数名为file.s3client.accessKey的参数值使用。

步骤S106：业务服务器300基于配置中心服务器200输出的参数值配置待配置参数。

本实施例的方法采用租户隔离的原则，各个租户有自己的一套重载配置就能构建起属于租户自己的服务集群和专属平台。其中几个关键的配置参数有{租户代码}.{zoneId}，租户自定义时区，{租户代码}.{token}，租户自定义登陆令牌，{租户代码}.{jdbc.*}，租户自定义数据库连接，以及租户自己的平台域名，例如：https://{租户代码}-gi-dev.insuremo.com/ui/admin/#/等等。在租户登录自己域名之后，从平台界面发送的任何请求都需要带上租户令牌，后端服务集群通过解析令牌识别出具体的租户并存储到应用程序上下文中，在程序执行的过程中，遇到其他使用参数的地方，会优先取带有租户代码前缀的参数，如不存在，才会取全局参数。

租户隔离的核心思想在于通过重载租户参数，达到隔离域名，隔离数据库的效果，进而实现在同一套服务集群及代码前提下，租户也能安全，精确的管理自己的数据。

图5示出了本申请一具体应用实施例的参数配置过程的示意图。

租户a和租户b分别通过用户终端上的操作界面向业务服务器发送请求连接其数据源的服务请求，业务服务器接收租户a和租户b的服务请求后，分别对各服务请求进行解析，获取各服务请求中的用户代码(以租户a的用户代码为a，租户b的用户代码为b，待配置参数名词为config_center_url为例)，租户a对应的微服务集群将用户代码a存储到其对应的程序上下文中，租户b对应的微服务集群将用户代码b存储到它对应的程序上下文中。租户a对应的服务在程序执行过程中，其对应的待配置参数为前缀为a的config_center_url参数，即a.config_center_url，而租户b对应的服务在程序执行过程中，其对应的待配置参数为前缀为b的config_center_url参数，即b.config_center_url。配置中心服务器分别读取名称为a.config_center_url和b.config_center_url的参数，并将a.config_center_url的参数值输出至租户a的微服务集群中，将b.config_center_url的参数值输出至租户b的微服务集群中。租户a的微服务集群的逻辑代码层接收到配置中心输出的参数值后，在数据持久层中获取到该参数值对应的数据连接，然后根据该数据连接访问其相应的租户数据库a。同样的，租户b的微服务集群的逻辑代码层接收到配置中心输出的参数值后，在数据持久层中获取到该参数值对应的数据连接，然后根据该数据连接访问其相应的租户数据库b。

即使用“{租户代码}.{参数名}”的方式定义租户专有的专有参数，实现了租户隔离，使得各个租户可以根据自己的一套专有参数配置就能构建起属于租户自己的服务集群和专属平台。业务服务器在执行租户用户终端发送的服务请求的过程中，当遇到使用参数时，会优先选取带有该租户对应的用户代码作为前缀的专有参数，以实现重载该租户的专有参数，从而达到隔离域名、隔离数据库的效果，进而实现在同一套服务集群及代码前提下，各个租户也能安全、精确的管理自己的数据。

图6示出了本申请另一具体应用实施例的参数配置流程的示意图。

租户c通过用户终端上的操作界面向业务服务器发送请求存储文件的服务请求，业务服务器接收租户c的服务请求后，分别对服务请求进行解析，获取服务请求中的用户代码c(以待配置参数名词为file.s3client.accessKey为例)，租户c的微服务群将用户代码c存储到各请求对应的程序上下文中。

当该服务在程序执行过程中，遇到待配置参数file.s3client.accessKey时，微服务集群将参数名file.s3client.accessKey前添加c作为前缀构成c.file.s3client.accessKey，向配置中心服务器读取名称为c.file.s3client.accessKey的参数，配置中心服务器优先获取c.file.s3client.accessKey的参数值，若获取到，则将c.file.s3client.accessKey的参数值输出至租户c的微服务集群，租户c的微服务集群的逻辑代码层接收到配置中心输出的参数值后，在数据持久层中获取到该参数值对应的数据连接，然后根据该数据连接访问租户数据库。

若配置中心没有获取到c.file.s3client.accessKey的参数值，则进一步获取file.s3client.accessKey的参数值，并将获取的file.s3client.accessKey的参数值输出。租户c的微服务集群的逻辑代码层接收到配置中心输出的参数值后，在数据持久层中获取到该参数值对应的数据连接，然后根据该数据连接访问相应的公共数据库。

即使用“{租户代码}.{参数名}”的方式定义租户专有的专有参数，还可实现配置参数的租户级重载。在使用配置参数时，只需要使用参数名，系统会自动检查是否存在当前租户用户代码所对应的专有参数，如果存在，则优先使用该专有参数，否则使用全局参数。这种方案可以实现配置参数的租户级重载，无需修改代码，大大简化了配置参数管理的难度。例如，当需要为某租户定制参数时，只需要添加以该用户代码作为前缀的专有参数，即可实现参数重载，简化配置管理难度。

本申请的参数配置方法适用于任何需要支持多租户并参数化系统逻辑的服务系统，可以有效实现配置参数的租户级重载，提高系统的灵活性和可维护性。当存在参数变更时，也只需要维护好全局参数和各租户的重载参数，服务系统无需任何修改即可得到最新的配置，大大降低了维护成本。

现在参考图7，所示为根据本申请的一个实施例的电子设备1400的框图。图7示意性地示出了根据多个实施例的示例电子设备1400。在一个实施例中，电子设备1400可以包括一个或多个处理器1404，与处理器1404中的至少一个连接的系统控制逻辑1408，与系统控制逻辑1408连接的系统内存1412，与系统控制逻辑1408连接的非易失性存储器(NVM)1416，以及与系统控制逻辑1408连接的网络接口1420。

在一些实施例中，处理器1404可以包括一个或多个单核或多核处理器。在一些实施例中，处理器1404可以包括通用处理器和专用处理器(例如，图形处理器，应用处理器，基带处理器等)的任意组合。在电子设备1400采用增强型基站(Evolved Node B，eNB)101或无线接入网(Radio Access Network，RAN)控制器102的实施例中，处理器1404可以被配置为执行各种符合的实施例，例如，如图2或6所示实施例。

在一些实施例中，系统控制逻辑1408可以包括任意合适的接口控制器，以向处理器1404中的至少一个和/或与系统控制逻辑1408通信的任意合适的设备或组件提供任意合适的接口。

在一些实施例中，系统控制逻辑1408可以包括一个或多个存储器控制器，以提供连接到系统内存1412的接口。系统内存1412可以用于加载以及存储数据和/或指令。在一些实施例中电子设备1400的内存1412可以包括任意合适的易失性存储器，例如合适的动态随机存取存储器(DRAM)。

NVM/存储器1416可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性的计算机可读介质。在一些实施例中，NVM/存储器1416可以包括闪存等任意合适的非易失性存储器和/或任意合适的非易失性存储设备，例如硬盘驱动器(Hard Disk Drive，HDD)，光盘(Compact Disc，CD)驱动器，数字通用光盘(Digital Versatile Disc，DVD)驱动器中的至少一个。

NVM/存储器1416可以包括安装电子设备1400的装置上的一部分存储资源，或者它可以由设备访问，但不一定是设备的一部分。例如，可以经由网络接口1420通过网络访问NVM/存储1416。

特别地，系统内存1412和NVM/存储器1416可以分别包括：指令1424的暂时副本和永久副本。指令1424可以包括：由处理器1404中的至少一个执行时导致电子设备1400实施如图2或6所示的方法的指令。在一些实施例中，指令1424、硬件、固件和/或其软件组件可另外地/替代地置于系统控制逻辑1408，网络接口1420和/或处理器1404中。

网络接口1420可以包括收发器，用于为电子设备1400提供无线电接口，进而通过一个或多个网络与任意其他合适的设备(如前端模块，天线等)进行通信。在一些实施例中，网络接口1420可以集成于电子设备1400的其他组件。例如，网络接口1420可以集成于处理器1404的，系统内存1412，NVM/存储器1416，和具有指令的固件设备(未示出)中的至少一种，当处理器1404中的至少一个执行指令时，电子设备1400实现如图2或6所示的方法。

网络接口1420可以进一步包括任意合适的硬件和/或固件，以提供多输入多输出无线电接口。例如，网络接口1420可以是网络适配器，无线网络适配器，电话调制解调器和/或无线调制解调器。

在一个实施例中，处理器1404中的至少一个可以与用于系统控制逻辑1408的一个或多个控制器的逻辑封装在一起，以形成系统封装(SiP)。在一个实施例中，处理器1404中的至少一个可以与用于系统控制逻辑1408的一个或多个控制器的逻辑集成在同一管芯上，以形成片上系统(SoC)。

电子设备1400可以进一步包括：输入/输出(I/O)设备1432。I/O设备1432可以包括用户界面，使得用户能够与电子设备1400进行交互；外围组件接口的设计使得外围组件也能够与电子设备1400交互。在一些实施例中，电子设备1400还包括传感器，用于确定与电子设备1400相关的环境条件和位置信息的至少一种。

在一些实施例中，用户界面可包括但不限于显示器(例如，液晶显示器，触摸屏显示器等)，扬声器，麦克风，一个或多个相机(例如，静止图像照相机和/或摄像机)，手电筒(例如，发光二极管闪光灯)和键盘。例如，上述显示屏可以显示管控服务界面支持用于查看各个服务的基础配置参数，并触发为各个服务配置基本配置参数。

在一些实施例中，外围组件接口可以包括但不限于非易失性存储器端口、音频插孔和电源接口。

在一些实施例中，传感器可包括但不限于陀螺仪传感器，加速度计，近程传感器，环境光线传感器和定位单元。定位单元还可以是网络接口1420的一部分或与网络接口1420交互，以与定位网络的组件(例如，全球定位系统(GPS)卫星)进行通信。

现在参考图8，所示为根据本申请的一实施例的片上系统(System on Chip，SoC)500的框图。在图8中，相似的部件具有同样的附图标记。另外，虚线框是更先进的SoC的可选特征。在图8中，SoC500包括：互连单元550，其被耦合至处理器510；系统代理单元580；总线控制器单元590；集成存储器控制器单元540；一组或一个或多个协处理器520，其可包括集成图形逻辑、图像处理器、音频处理器和视频处理器；静态随机存取存储器(Stat芯片Random access Memory，SRAM)单元530；直接存储器存取(Direct Memory Access，DMA)单元560。在一个实施例中，协处理器520包括专用处理器，诸如例如网络或通信处理器、压缩引擎、图形处理单元上的通用计算(General-purpose computing on graph芯片sprocessing units，GPGPU)、高吞吐量M芯片处理器、或嵌入式处理器等。

静态随机存取存储器(SRAM)单元530可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性计算机可读介质。计算机可读存储介质中存储有指令，具体而言，存储有该指令的暂时和永久副本。该指令可以包括：由处理器中的至少一个执行时导致SoC实施如图3或图4所示方法的指令。当指令在计算机上运行时，使得计算机执行上述实施例中公开的方法。

在附图中，可以以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可能不需要这样的特定布置和/或排序。而是，在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。

需要说明的是，本申请各设备实施例中提到的各单元/模块都是逻辑单元/模块，在物理上，一个逻辑单元/模块可以是一个物理单元/模块，也可以是一个物理单元/模块的一部分，还可以以多个物理单元/模块的组合实现，这些逻辑单元/模块本身的物理实现方式并不是最重要的，这些逻辑单元/模块所实现的功能的组合才是解决本申请所提出的技术问题的关键。此外，为了突出本申请的创新部分，本申请上述各设备实施例并没有将与解决本申请所提出的技术问题关系不太密切的单元/模块引入，这并不表明上述设备实施例并不存在其它的单元/模块。

需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

虽然通过参照本申请的某些优选实施例，已经对本申请进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。