在集群里手动配置每一台服务器上的程序很明显是不明智的，劳神费力还可能出差异造成程序不一致。
而且在发生配置改变的时候还需要一一去做修改，更是麻烦
将配置内容的获取与载入作为一个功能插件内化到程序中，并以消息监听器的方式接收配置服务管理端发来的更改通知，移除旧的配置数据在本地生成的数据文件，然后载入新的数据文件，并加载到程序中。
这样就形成数据的两处存储，一处是在服务管理端，一处是在应用程序所在服务器，为什么不直接加载进入程序中呢？
因为服务端有可能离线，而同时应用程序重启，在本地保留一份以应对服务端离线。
数据库设计
解决方案表：每一个解决方案代表一系列服务所需要的配置文件组合，为了防止程序间修改配置造成的问题，不同程序的配置数据不可以共享，虽然造成一定工作量，但是不会由于共享配置数据改变造成的程序间配置需求差异造成的问题。
| 字段 | 类型 | 作用 |
| SoluationId | guid | 方案id |
| SoluationName | 字符 | 方案名 |
| SoluationSimple | 字符 | 方案简介 |
| AppId | guid | 程序id |
| Enable | 布尔类型 | 方案是否启用 |
| CreateTime | 时间类型 | 创建日期 |
| CreateBy | 整型 | 创建人 |
| ModifyTime | 时间类型 | 修改日期 |
| ModifyBy | 整型 | 修改人 |
| IsDelete | 布尔 | 是否删除 |
| 字段 | 类型 | 作用 |
| AppId | guid | 应用程序id |
| AppName | 字符 | 程序名 |
| AppTitle | 字符 | 程序展示名 |
| CreateTime | 时间类型 | 创建日期 |
| CreateBy | 整型 | 创建人 |
| ModifyTime | 时间类型 | 修改日期 |
| ModifyBy | 整型 | 修改人 |
| IsDelete | 布尔 | 是否删除 |
组件表：通过组件数据在组件发生重大变更时对配置文件表进行统一性更改
| 字段 | 类型 | 作用 |
| Id | 整型 | 数据id |
| AppplusId | guid | 组件id |
| AppPlusName | 字符 | 程序组件名 |
| CreateTime | 时间类型 | 创建日期 |
| CreateBy | 整型 | 创建人 |
| ModifyTime | 时间类型 | 修改日期 |
| ModifyBy | 整型 | 修改人 |
| IsDelete | 布尔 | 是否删除 |
配置文件表：程序组件需要的配置文件，此表的数据只增不修改
| 字段 | 类型 | 作用 |
| Id | guid | id |
| SoluationId | guid | 配置方案解决方案id |
| AppplusId | guid | 组件id |
| Title | 字符 | 配置展示名 |
| Content | xml | 配置内容 |
| Version | 整型 | 版本号，修改一次内容就自动新增一个版本 |
| Enable | 布尔类型 | 方案是否启用 |
| CreateTime | 时间类型 | 创建日期 |
| CreateBy | 整型 | 创建人 |
| StopTime | 时间类型 | 停用日期 |
| ModifyBy | 整型 | 修改人 |
| 字段 | 类型 | 作用 |
| Id | 整型 | id |
| SoluationId | guid | 配置方案解决方案id |
| SoluationVersion | 整型 | 解决方案版本号 |
| MdsId | guid | 服务配置文件id |
| Version | 整型 | 服务配置文件版本号 |
| CreateTime | 时间类型 | 创建日期 |
| CreateBy | 整型 | 创建人 |
版权声明：本文为博主原创文章，未经博主允许不得转载。