基于xManager的实例配置管理详解

实例的配置管理，涵盖配置分组，变更，分发，版本演进等实用功能，是所有大数据运维平台的核心要件。xManager平台提供全功能的配置管理能力，支持灵活变更，版本追溯，快速切换，一键分发，对同一实例下不同节点的差异化配置也有效支持。

本文将以X-SCHEDULER服务实例（有关X-SCHEDULER服务的安装请参阅基于xManager的服务安装流程详解）的配置管理作为例子，从程序层面详细介绍xManager平台上实例配置管理的后端设计与实现。

准备知识

—

xManager上的服务是一种元数据，是静态的，包含了服务自身及其组件的定义，安装包，执行脚本，配置文件等。服务只有在节点集（单个服务安装可能跨多个节点）上安装以后，才会形成实例，才能对外提供能力，实例是一种运行时形态，一个服务可在不同节点集上安装，从而形成多个该服务的实例。

服务安装时，须为其组件分配节点，然后编辑配置文件。此时用户看到的配置文件及其内容，都是在服务定义时设置好的，各个配置文件的内容都是原始模板，需要在安装时进行补充编辑。对于X-SCHEDULER服务，其配置元数据存储在xm_service_config表，共有7项，其中名字为custome的配置项为xManager内部规定的默认必备项，有特殊用途，其余6项皆为真实的配置文件。

表字段template为配置文件的原始内容模板，字段addition_info标记了有关该配置文件解析的定义（例如：shell类型不可解析，properties类型可解析）。需要注意的是表字段service_component_id，该字段为空则代表当前配置文件为服务级配置，有值则代表组件级配置，值即为组件id。

• 服务级配置，即配置文件为所有组件所共有，每个组件的正常运行都需要该配置文件

• 组件级配置，即配置文件为指定组件所私有，除了指定组件，其余组件的正常运行都不需要该配置文件

X-SCHEDULER服务的alert.properties配置文件即为组件级配置，对应组件id为196（组件为AlertServer）。组件级配置在服务安装和配置分发时，其在配置文件压缩包conf.tar.gz内的存放有固定的格式。服务级配置直接位于压缩包内根目录下，而组件级配置存放在压缩包内对应组件名的目录下。以X-SCHEDULER服务安装时的配置文件压缩包为例，其解压后内容如下：

配置管理设计

—

用户在UI界面编辑提交的配置文件（不论是初次安装还是后续实例的配置变更），都是跟实例关联的，xManager为了支持用户对实例配置的持续变更，以及引申出来的配置版本演进和切换，再以及不同节点上的差异化配置，引入了配置组概念，结合实例，组件，节点，配置版本等信息设计了一套完整的配置管理体系。

• 配置版本，是实例配置的版本号，由xManager内部自行管理，实例配置变更会产生新版本。需要注意的是，配置版本是实例整套配置的版本，实例配置的任何一个版本都包含一套完整的实例配置文件，以X-SCHEDULER的实例来说就是7个。用户即使只修改实例多个配置文件中的一个，其余未修改的配置文件也会在新版本号下复制保存。配置版本全局递增。

• 配置组，用来解决同一实例下不同节点上的差异化配置，不同的节点其硬件能力大相径庭，不适合使用相同的一套配置。例如：某个实例跨两个节点，一个节点内存只有4G，另一个节点内存有32G，该实例的配置文件中有关于运行内存的设置，这时该实例就需要两套独立的配置分别对应两个节点。配置组是对实例节点的再划分，配置版本作用在配置组上。

xManager在服务初次安装时默认指定了一个配置组，配置组id为1，名为default，存储在xm_config_group表中。

xManager上所有实例的配置组及其配置版本历史信息都保存在此表中，下面是重要表字段的说明：

• service_instance_id，实例id，利用该字段可查询到目标实例的所有配置组

• config_group_id，配置组id，同一实例的各个配置组id不同

• config_group_name，配置组名

• version，配置版本

• is_current_version，实例配置组的配置版本是否当前版本。实例配置组的配置版本会变更，变更前后对应的版本信息都会保存在此表中，只有当前版本的is_current_version值为true，其余非当前版本的值都为false。对于给定的一个实例配置组，其所有历史配置版本中有且仅有一条记录的is_current_version值为true。

• status，配置分发状态，当前配置组对应配置版本的配置文件在分发操作时的状态，例如未分发，分发中，分发失败，分发成功等。

为了解释的更直观，下面以一个例子做说明。图中id为2的实例，其配置组当前共有3个，配置组id分别为1，2和3，其中id为2的配置组有两个历史配置版本（即2和4，且2为当前版本），id为3的配置组有两个历史配置版本（即3和5，且5为当前版本），状态102表示当时都已分发成功。

配置组对实例节点的划分详情保存在xm_node_component表中。还是以上图id为2的实例为例，总共有三个节点192.168.0.20，192.168.0.6，192.168.0.16，其中192.168.0.6和192.168.0.16位于配置组3下，192.168.0.20位于配置组2下，而配置组1并没有节点，是个空配置组，因此实际影响实例配置的只有配置组2和3，用户通过UI界面可以重新调整节点的划分。

实例的每一个配置版本都对应着一套完整的实例配置，xManager存储实例配置在xm_service_config_instance表，关键字段介绍如下：

• service_instance_id，实例id

• version，配置版本，使用实例id和配置版本可以查到完整的一套配置

• config_id，引用自xm_service_config表的id字段（详情参阅基于xManager的服务安装流程详解），可映射查询到具体的配置文件名，解析方式等信息

• config_data，实际的配置文件内容，来自用户在UI界面的编辑提交

• service_component_id，同xm_service_config表的service_component_id

还是以上图id为2的实例为例，其所有历史配置如下。可以清楚的看到，其配置版本共有5个，分别为1，2，3，4和5。每个配置版本下都有config_id为1，2和3的三个配置文件。

而id为2的实例，其服务id为13，回到xm_service_config表看service_id为13的配置项：

xManager就是通过核心的这几张表支撑起配置管理的所有功能。

配置管理实现

—

接下来继续以X-SCHEDULER服务为例，具体讲述配置管理的实现。

服务初次安装

初次安装时，用户分配好节点，编辑好配置，提交安装作业给xManager。配置文件共有6个（说好的7个呢？那是因为名为custome的配置项比较特殊，只供xManager内部使用，不给UI呈现，即用户无感知），节点分配如下：

|-Master
  |-192.168.0.11
|-Worker
  |-192.168.0.16
  |-192.168.0.6
|-AlertServer
  |-192.168.0.11
|-ApiServer
  |-192.168.0.16

xManager收到安装参数后，在xm_service_instance，xm_service_instance_component，xm_node_component表添加实例相关信息。本次安装，实例名为ds，实例id为13，对应的X-SCHEDULER服务id为116，有关X-SCHEDULER服务安装请参阅基于xManager的服务安装流程详解。

初次安装默认分配id为1名为default的配置组，版本号为1。

所有实例节点都归于此配置组， xm_node_component表的主键为“实例id-组件id-节点id”，因此会有5条记录。

用户提交的配置文件存储在xm_service_config_instance表中，版本号都是1，共7项，与xm_service_config表中对应。config_data字段存储的是用户提交的配置文件内容。

相关的数据库表持久化完成后，xManager将版本号为1的这些配置生成真实的文件，并冠以对应的真实配置文件名，一起打成压缩包conf.tar.gz存放，并提供下载链接供安装脚本使用，然后向当前实例配置组为1的所有节点提交安装作业。

增加配置组

用户在UI界面创建新的配置组，组名为newgroup，并且将节点192.168.0.6划分到新配置组（一个节点只能属于一个配置组，因此名为default的配置组下不再有192.168.0.6）。

xManager创建名为newgroup的配置组，配置组id指定为2，配置版本指定为3。

新的配置组节点划分：

xManager取节点192.168.0.6之前所在配置组对应配置版本的配置文件，进行复制，指定版本号为3。

变更配置

变更配置针对指定配置组的配置，用户在UI界面上对newgroup配置组配置版本为3的配置中的application.properties文件内容做了修改，然后点击保存。

xManager在xm_config_group表中添加该配置组新的配置版本，版本号指定为4。因为本次配置编辑仅仅只是做了保存，并未实际应用（需要在界面执行切换版本操作），因此这条新添加记录的is_current_version字段值为false，原来版本号为3的记录其is_current_version字段依然保持true。

虽然用户只修改了application.properties文件，但其它配置文件也是必需的。xManager保存所有配置文件到xm_service_config_instance表，指定版本号为4。

切换配置

用户在UI界面将newgroup配置组的配置版本从当前正在使用的3切换到4。

xManager更新xm_config_group表中newgroup配置组对应配置版本的is_current_version字段。版本为3记录的is_current_version字段值更新为false，版本为4记录的is_current_version字段值更新为true。

接着，xManager将版本号为4的配置从xm_service_config_instance表中取出来，逐个生成真实文件并冠以对应的真实配置文件名，一起打包成conf.tar.gz存放，提供下载地址供配置分发脚本使用。最后，xManager向newgroup配置组的各个节点提交配置分发作业，核心就是执行配置分发脚本并更新相关配置分发状态，与服务安装时作业提交并安装脚本执行的原理一致，不再赘述。

与安装脚本类似，配置分发脚本也有固定的执行参数，共4个，第一个为服务安装路径，第二个为配置压缩包下载路径，第三个为服务名，第四个为组件名。配置分发脚本内容部分截图如下：

总结

—

至此，配置管理设计及核心功能的实现都已讲完。每个配置组的版本历史从xm_config_group表中可以直接查到，配置文件解析定义在xm_service_config表的addition_inofo字段中，主要是支撑UI界面对可解析文件的友好展示，例如properties文件和xml文件。其它细节处理或者疑惑，读者可查阅源码，或邮件作者本人。

本文转载自奇麟大数据

---

留言区

往期精彩回顾

世界读书日|关于读书那些事儿

360技术中台招聘啦！！

实习招聘|360云平台火热招聘中

---

360技术公众号

技术干货|一手资讯|精彩活动

扫码关注我们