源宝导读：随着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);}
}
我们来看看不同场景下的兼容性是如何保证的：
5、总结
目前的配置中心服务架构有两个特点：
灵活可扩展的配置项设计：很好的满足了多环境多版本系统不同的配置要求；
可离线的配置同步架构：既满足了配置集中统一管理的需求，又保证不会因为配置中心单点故障导致ERP整体宕机。
随着ERP的应用越来越多，应用间的关系越来越复杂，ERP部署的模式越来越丰富，配置中心的功能也演变的更加复杂，只有通过架构的不断优化演进，配置中心才能更稳定高效的支撑ERP系统的运行。
------ END ------
作者简介
王同学： 研发工程师，目前负责ERP运行平台的设计与开发工作。
也许您还想看
链路追踪在ERP系统中的应用实践
从案例角度解析建模平台动态规则引擎
如何解决大批量数据保存的性能问题
研发协同平台持续交付2.0架构演进
)
)
)
)
)
)
