https://gitee.com/sleepywang1024/easyconfig/blob/master/design-guide.md
基于easyconfig的系统配参设计指南
结合企业应用系统的特点以及easyconfig，讨论如何规划及设计系统的配参管理。
不要改变现有工作习惯、不要给现有安排增加任务
配参管理与业务需求不同，它有自己的特点：
配参虽然重要，但不是一个系统的核心，不值得为此做太大投入。
配参虽然不算业务核心，但对系统运转却很关键，不应该为此承担很大风险。
配参不是高优先级，把配参纳入管理通常是对现有系统优化，而不是从头设计的一个新系统。方案需要考虑研发工作习惯和历史负担。
基于配参管理的需求特点，需要选择可靠性好、兼容性高、简单易用的方案。对于研发同学自身来讲，就要选择不要改变现有工作习惯、不要给现有安排增加任务的方案。
系统配参管理方法与工作流程
在源码中HardCode魔幻码肯定是百害无一利，要遭到反对的。但如何解决此问题却不容易统一认识，例如：
代码中定义常量、枚举类型，以便能明确意义、方便统一修改；
属性文件中定义参数，以便不修改代码，通过启动时指定改变系统行为；
配置中心统一管理，随时随地修改、不用重启就能生效；
如何选择本质上依赖于业务需要、成本和收益的平衡。如果没有成本或成本很低，当然能力越强大越好，不过这种好事比较少见，通常是没有。
平衡是设计的精髓，一个常见的策略是选择在满足需要的前提下，功能更强但成本不增加的方案。考虑到功能与成本伴随，这个策略可能退化成满足需求的前提下的简单(便宜)的方案。如果所能承担的成本与所需功能产生矛盾，需要重新定义需求优先级，把基本需求缩减到成本可承受的范围内（无论是否喜欢都必须这么做）。
建议配参管理优先选择满足需求的简单方案。注意是满足用户的全部需求的简单方案，而不是阉割需求的简单方案。全部需求如果包括进来非用户的真实需求，设计就会过度；如果没有包括用户的全部需求，设计就会不完整。当简单方案不满足时，设法升级到更复杂的方案，而不要一开始就选择一个复杂方案，争强好胜不可取。
设计easyconfig之初衷，就是因为对于企业应用来讲，属性文件不够灵活、而配置中心又过于复杂而产生的。
对不同风格研发的使用建议
超级保守童鞋
对于那些对新技术、新组件表示担心，多一事不如少一事的研发童鞋。建议从quickstart 中介绍的一条指令完成集成开始使用，访问管理控制台，把系统中已有的@Value标注配参装载到easyconfig，进行一些动态修改更新、以及恢复以往修改等基础操作。
普通研发用户
为了更好地发挥easyconfig的能力，建议在前面基础上采取以下行动
使用@EasyValue标注替换@Value标注，为@EasyValue标注提供name属性。
为easyconfig提供系统用户信息，或者使用内置用户安全方案，以便对配参的修改责任到人。
尝试使用复杂数据类型解决一些业务问题。
利用管理控制台的功能，如分组管理、配参探查、数据校验、导入导出、数据加密等。
分布式系统用户
easyconfig没有像流行的微服务架构那样设计成一个配置中心，是因为定位和设计理念的选择，详情参考设计原则。
对于分布式微服务来讲，每个服务中心应该有自己的存储(若需要)，管理自己的数据。依附于服务的配参，应该随服务一起得到管理，放置到其主存储中。
非关系数据库用户
easyconfig目前采用mysql作为配参数据源，对应不使用mysql甚至关系数据的系统来讲怎么办呢。虽然后面还会扩展适配更多环境，目前来看，最简单有效的方式可能就是新搭建一个或借助其它的mysql server存储动态配参。
资深研发用户
欢迎大家提建议，一起维护这个组件。
哪些配参需要联机更新？
外部环境参数
绝大多数的业务系统、企业应用软件、互联网软件都不能独立运行，需要与许多其它系统进行交互，这些与外部系统交互有关的配参通常值得通过动态配参进行管理。原因在于外部环境通常不由当前系统研发小组负责，具有一定的不确定性，借助于动态配参，减轻对外部系统的依赖，减小外部系统问题拖累本系统。
常见的使用场景如
外部系统地址切换。例如性能需要、费用需要、故障应急等
访问所需账户、密码等更新。例如安全策略需要定期更新，或者泄露风险需要进行更新
研发过程中不同环境的隔离，测试、联调等过程中需要切换到挡板服务(Mock Service)
系统规则参数
调整系统运行的各类参数，如周期任务的调度频率、等待超时时间、后台服务的线程池大小等。研发人员需要对其进行决策，但又没时间仔细评估做出最佳选择，或者不同环境或客户下所需配参不同等，通过配参时候动态调整是一个比较好的选择。
业务规则参数
有调整需要、但又不属于日常业务范围内的业务规则，如邮件接受清单、邮件、短信通知模板、工作日历等等。不提供对修改维护能力多有不便，提供又很繁多，得不偿失。
总之，系统运行期间需要动态调整的各类开关、选项、参数等，都是动态配参的管理范围。考虑到参数化是提升系统灵活性的重要手段，动态调整是提升易用性的重要手段，需要动态调整配参的情景通常比感知到的要多，由于缺乏好的工具，通常此类需求被更高优先级的需求压制，因资源和能力不足而放弃。
哪些配参不需要联机更新？
无法动态修改的
典型的如系统进程的启动参数、如JAVA_HOME、user.name、JVM等，用于控制系统进程最基本的的参数，通常无法动态修改，修改就需要关闭进程，调整后再重新启动。
很难动态修改的
有些配参控制系统的基本行为且很少修改，往往在系统启动时一次性地初始化，这类配参动态修改涉及到相关工作的重新初始化，甚至是进行中工作的处置（终止或者等待完成）。出于投入回报、优先级等考量被研发团队放弃支持动态修改，采用更简单的启动前一次性指定配参。典型的有数据库连接配置、日志规则配参等
不适合动态修改的
安全需要严格管理、业务需要简便使用、管理需要独立控制等，这些可以通过动态配参管理，但显然需要更好的方案。
什么情况下需要从联机更新中移除？
原来需要、现在已不再需要的配参
这种情况下显然需要从动态配参中移除，遗留在那里会带来不必要的管理小负担，而不会有任何其它实际用处。
不能进行动态刷新的配参
无法进行动态刷新的配参，通常也不需要加入到动态配参管理。如果加入到动态配参，通过修改发现不能产生实际的效果，会带来不必须要的困惑。常见于哪些系统启动后初始化，接下来运行脱离相关配参的情况。参见前一小结
风险或安全考虑不加入动态刷新
避免错误配参造成的风险，减少动态配参无意的失误修改，可以把这类配参从动态配参中移除。
以业务和功能视角，对配参统一管理
前面谈到并不是所有配参需要联机更新，但配参管理需要一个统一的管理视角，如果各类特性配参分散在各个地方，无疑给管理带来许多不便。例如一个模块两个参数username、password，假设username不能修改放到属性文件、password可以修改放到easyconfig，一个事物两地管理无疑不方便且增加复杂性。
如果需要对所有配参进行管理，就需要对不同的管理特性进行分别对待。
不能修改的配参
针对不能联机更新的配参，可以设置配参属性为ReadOnly，做到只查看不能修改。
高度敏感的配参
对高度敏感的配参进行加密，避免在不恰当的环境中泄露，以造成不必要的风险。系统读到的是明文，但用户看到的是密文提高敏感配参的安全性。
配参分组管理
不同业务模块的全部配参集中到一处，简化统一管理。
为配参设计数据类型
类型选择的出发点和宗旨
做任何事情都不能忽视我们可用的资源、工具，以及我们自身的能力。但做任何方案设计的出发点仍然是业务及问题需要，而不是我们能利用哪些工具。
传统的属性文件配参简单实用，但对于业务需求来讲，工具简单则需要更多工作量，技术模型与业务模型之间差异也更大。SpringBoot里面的propertyProperties在这方面做出一些努力，但还不够好。easyconfig提供复杂数据类型支持及其检查校验能力，能在配参业务模型和技术模型一致性方面提供帮助。
选择何种数据类型
一个简单的配置参数当然会选择一个简单的数据类型。
如果是复杂的配置参数呢？easyconfig不再建议选择简单数据类型：用一组同一前缀的不同属性标识某个配参的不同部分。养成这种习惯是因为这样开发框架实现简单，它们不支持复杂类型，研发人员就没得选。并不是需求自身就是这样，或者研发同学希望这样。
easyconfig提供的复杂类型是一个更强大、更简单的工具，结合配参数据检查、动态更新能力，能为系统提供更多的可能性。即使系统不需要配参管理、不需要动态更新，只要引入easyconfig包，即使没有动态配参数据源也会提供复杂类型支持。
临时替代业务管理界面
研发团队承接到的需求中，许多内容是需要但不重要、重要但不紧急、使用但不常用；企业应用系统研发者，把大量时间耗费在O/R Mapping、CRUD、界面编辑检查上面，而不是真正有价值的业务逻辑和业务处理上。为了更快地且得到良好设计地上线业务功能，把业务配置交给easyconfig就是一个办法，等业务运转顺溜了，等研发腾出手来，再完善业务对应的配置管理功能。
easyconfig提供的复杂数据类型配参就是要承担这个任务。系统定义数据结构但暂缓实现配置管理界面，通过easyconfig支持相关内容的修改，后面视实际情况选择补充开发管理配置界面、还是没有那么重要就一直使用easyconfig下去，主动权在研发产品同学手里。
更多、还是更少配参
鉴于现实世界的复杂性，不敢建议你努力采用更多的配参。但配参确实是进入更高层次抽象、实现通用方案、产品化、平台化软件系统的重要手段之一，是让产品走向康庄大道的一个方便法门。
针对软件系统的设计，建议：
通过配参提升软件的灵活性和通用性；
通过提供恰当的默认值，以简化使用，即：惯例优于配置；