ERP的配置管理实践

源宝导读：随着ERP系统的日益复杂，应用部署的方式越来越复杂，应用的配置也变得越来越庞杂，难以维护和管理。本文将介绍配置中心服务通过集中化、可离线的架构设计，解决ERP配置问题的实践经验。

一、背景

随着ERP业务的日益复杂，程序配置越来越多，应用部署的方式越来越复杂，对程序配置管理的要求越来越高：

配置集中管理，一处修改全局生效，避免应用集群中配置不一致的问题。
不同的应用环境（生产、测试）需要不同的配置。
部分配置修改后需要立即生效。
复杂的配置难以理解，容易出错，需要有友好的交互界面来提供辅助。

在这样的复杂环境下，传统的通过配置文件的方式已无法满足要求，我们开始设计配置管理中心，统一接管ERP的应用配置。

二、基础模型

配置中心被设计为一个独立的Windows服务，以HTTP方式对外提供服务。

如上图所示：

在ERP安装部署时，向配置中心写入安装过程产生的初始配置。
安装部署完成之后，如果环境还有调整，就需要进入配置管理界面，修订配置。
配置修订完成后，会产生配置变更通知。订阅了配置变更事件的客户端就会收到配置变更通知，重新读取就能获取到最新配置。

三、配置项的设计

不同ERP版本的配置项存在差异，而配置中心不仅需要适配最新版本的ERP，还需要兼容历史版本。为了解决这个问题，配置中心为每个大版本ERP提供独立的配置定义文件，文件采用XML格式。

示例：（系统设置-多时区的配置）

<options><group title="系统设置"><option title="启用多时区" name="Timezone-enable" type="string" ui="radio" description="启用多时区后数据中日期字段将会以“标准时区”存储" defaultvalue="0"><item text="启用" value="1" /><item text="禁用" value="0" /></option><option title="存储时区" name="Timezone-store" type="string" ui="radio" description="系统标准时区，默认为当前站点服务器对应时区，如选择此配置需要保证海外、国内服务器时区设置一致。" defaultvalue="0"><item text="服务器时区" value="0" /><item text="协调世界时（UTC）" value="1" /></option></group>
</options>

group：配置分组，便于从逻辑视角对配置项进行分组管理；
option：代表一个具体的配置定义，根据其中的ui字段，产生相应的UI。

四、配置客户端设计

上图简要描述了配置中心客户端的实现原理：

客户端和服务端保持了一个轮询（15s一次），从而能较快的获得配置更新的推送；
客户端从配置中心服务端获取到应用的最新配置后，会保存在内存中；
客户端会把从服务端获取到的配置在本地文件系统缓存一份。在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置；
应用程序可以从客户端获取最新的配置、订阅配置更新通知。

可用性考虑

配置中心作为基础服务，可用性要求非常高，下面的表格描述了不同场景下配置中心的可用性：

五、兼容性设计

兼容性设计的目标：

任意配置中心服务端兼容所有版本的配置中心客户端。
任意配置中心客户端兼容所有版本的配置中心服务端。

服务端兼容主要是服务API的兼容，只要API接口不发生变化，旧版本的客户端就能正常调用。

我们制定了相关的规范：

接口一旦确定，就不能调整接口签名。唯一例外情况是增加参数，由于WebApi的性质，不存在的参数会以默认值填充。
在增加新特性时，不能修改原有接口的行为，如果原有接口无法满足，就增加新的接口；如果数据结构发生变化，原有接口无法完全支持时，需要在原接口的实现中做兼容处理（牺牲掉一部分新特性）。

例如：

在2.0版本支持应用分库特性后，允许为不同的应用配置不同的数据库，于是数据库的配置变成了多值。
原有的接口需要调整为：如果数据库配置是多值，就返回第一个值。
这样处理后，历史版本的应用也可以使用到最新版本的配置中心，但是不能用到新特性。

为了保证新版本的客户端可以正常使用旧版本的服务端，还需要做客户端的兼容处理。

这里定义一个配置读取接口IConfigReader：

internal interface IConfigReader { // 接口方法略 }

特性上有较大变化时，就重新写一个接口实现版本。到目前为止，一共有3个版本的接口实现。

当应用需要读取配置时，首先确认服务端的版本，然后创建一个相应接口的实现版本。

public static IConfigReader Get(string serviceUri, string env, string siteGroupKey, string appId,
Version serviceVersion)
{if (serviceVersion >= new Version(2, 1, 0, 17)){// 支持合并接口读取和变更时间戳return new ConfigClientV3(serviceUri, env, siteGroupKey, appId);}else if (serviceVersion >= new Version(2, 1)){// 支持分离部署return new ConfigClientV2(serviceUri, env, siteGroupKey, appId);}else{// 兼容版本：1.xreturn new ConfigClientV1(serviceUri, env, siteGroupKey, appId);}
}

我们来看看不同场景下的兼容性是如何保证的：